IT-Projektmanagement Teil 2: Der Gegenstand von Softwareprojekten. Wintersemester 2012/2013 Dr. Gerhard Pews

Transkript

1 IT-Projektmanagement Teil 2: Der Gegenstand von Softwareprojekten Wintersemester 2012/2013 Dr. Gerhard Pews

2 Dieser Vorlesungsteil vertieft den Gegenstand von Softwareprojekten. Einordnung in den Fahrplan der Vorlesung Inhalte Einführung Das Was : Der Gegenstand von Softwareprojekten Das Wie : Die Tätigkeiten in einem Projekt und wie man sie ausführt Vorbereitung eines Projekts Projektplanung Durchführen eines Projekts Unterstützende Tätigkeiten Soft Factors Wirtschaftliche Aspekte 2

3 AGENDA Motivation Tätigkeiten bei der SW-Entwicklung Diese Tätigkeiten im Kontext von Vorgehensmodellen Stufen 3

5 Ziel dieser Einheit ist, den Studierenden den Inhalt von SW-Projekten und dessen Implikationen auf das Projektmanagement zu vermitteln. Ziele der Vorlesungseinheit Rahmen Fokus der Vorlesung liegt im BereichSoftware- Entwicklung. Das deckt auch Reengineering, Wartung und Weiterentwicklung in Projektform ab. Häufigster Fall von IT-Projekten Vorgehensweise und Erkenntnisse übertragbar auch auf andere Projekte. Fragestellungen Wie gehe ich in meinem Projekt vor, um es zum Erfolg zu führen? Wie erreiche ich den Projekterfolg mit Sicherheit und nicht nur durch Zufall? 5

7 In Software-Entwicklunsprojekten finden sich immer die gleichen Tätigkeiten wieder. Elementare Tätigkeiten in Software-Entwicklungsprojekten Anforderungsanalyse & Fachliche Konzeption Technische Konzeption Realisierung Integration und Test 7

8 In jedem Softwareentwicklungsprojekt finden sich vier grundlegende Tätigkeiten. Überblick über die Tätigkeiten Tätigkeit Anforderungsanalyse & Fachliche Konzeption Technische Konzeption Realisierung Kurzbeschreibung/Fragen Was soll das System inhaltlich tun? Welche Anforderungen soll es erfüllen? Wie sieht die fachliche Lösung aus? Wie sieht die technische Lösung aus? Wie soll das System programmiert werden? Erzeugen von Code Integration & Test Zusammenfügen mit Nachbarsystemen Funktionaler Gesamttest 8

9 Anforderungsanalyse und Fachliche Konzeption sind schwer zu trennen. Details zur Anforderungsanalyse & Fachlicher Konzeption Tätigkeit Anforderungsanalyse & Fachliche Konzeption Technische Konzeption Realisierung Integration & Test Hinweise Anforderungsanalyse und Fachliche Konzeption sind oft nicht zu trennen. Ergebnisse Anforderungen (funktional und nichtfunktional) Fachliche Beschreibung der Lösung Prozesse Use Cases (durch Software unterstützte Prozess-Schritte) Fachliches Datenmodell Fachlicher Sytemüberblick innen und außen, Fachliche Architektur 9

10 Anforderungsanalyse und Fachliche Konzeption bilden die Grundlage der Softwareentwicklung. Details zur Technischen Konzeption Tätigkeit Anforderungsanalyse & Fachliche Konzeption Technische Konzeption Realisierung Integration & Test Hinweise Inhalte der Technischen Konzeption Technischer Systemüberblick innen und außen Software-Architektur (Module, Schichten, Komponenten, etc.) Technisches Datenmodell Systemarchitektur (Hardware) Betriebsdokumentation Vorlage für die Implementierung, Design für Implementierung 10

11 In der Realisierung wird das System programmiert. Details zur Realisierung Tätigkeit Anforderungsanalyse & Fachliche Konzeption Technische Konzeption Realisierung Hinweise Inhalte der Realisierung Programmieren Testen (Entwicklertest) Dokumentieren Ergebnisse Code Dokumentation Integration & Test 11

12 Integration und Test bereiten das System auf die Inbetriebnahme vor. Details zu Integration und Test Tätigkeit Anforderungsanalyse & Fachliche Konzeption Technische Konzeption Realisierung Integration & Test Hinweise Ergebnis: Fertiges System Inhalte von Integration & Test Systemintegration: Kopplung mit Nachbarsystemen, Zusammenführen einzelner Module System ist als Ganzes vollständig. Systemtest (gesamt, funktional): Fachliche Tester testen das System so, wie es später im Produktionsbetrieb genutzt werden soll. 12

13 Die grundlegenden Tätigkeiten der Software-Erstellung werden oft unterschiedlich bezeichnet. Synonyme zu den eingeführten Begriffen Unzureichende Standardisierung Die Begriffe des Software Engineering sind (leider) nicht genormt. Sowohl die Inhalte als auch die Bezeichnungen der Schritte können variieren. Häufig werden alternative Namen genutzt. Anforderungsanalyse & Fachliche Konzeption Requirements analysis, Analysis, Analyse, Fachkonzept, Spezifikation, Lastenheft, Pflichtenheft, Technische Konzeption DV-Konzept, Konstruktion, Design, Pflichtenheft. Definition Realisierung Implementierung, Programmierung Integration & Test Systemintegration, Gesamtintegration 13

14 Wie verhalten sich die Kosten für Fehlerbehebung in Relation zum Zeitpunkt im Projekt, an dem sie gefunden werden? Fragestellung? Quelle: B. Boehm, sd&m Konferenz

15 Die Kosten zur Fehlerbehandlung steigen sehr stark an, wenn die Fehler erst spät gefunden werden. Antwort Quelle: B. Boehm, sd&m Konferenz

17 Im Wasserfall-Vorgehen sind die Tätigkeiten sequentiell angeordnet. Schematisches Wasserfall-Vorgehen Fach. Konzeption Tech. Konzeption Realisierung Test & Integration Projektstart Ziel nach Winston W. Royce

18 Der Wasserfall ist ein einfaches und robustes Vorgehen, das Probleme bei Änderungen der Anforderungen erzeugt. Beschreibung und Bewertung des Wasserfall-Vorgehens Wasserfall Alle Schritte werden sequentiell durchgeführt Mit einem Schritt wird erst dann begonnen, wenn der vorige Schritt fertig ist, d. h. das Ergebnis der vorigen Phase vorliegt. Vorteile Einfach zu verstehen Einfach zu managen Einfach zu controllen (Definierte Phasenübergänge) Nachteil Was tun, wenn sich Anforderungen ändern? 18

19 Im Wasserfall-Vorgehen mit Rückkopplung sind Rücksprünge möglich. Schematisches Wasserfall-Vorgehen mit Rückkopplung Fach. Konzeption Tech. Konzeption Realisierung Aber: Was tun, wenn sich Anforderungen ändern? keine wirklich gute Antwort Projektstart Test & Integration nach B. Boehm 1981 Ziel 19

20 Ein Ausweg aus dem Dilemma ist, die Projekte so zu beschleunigen, dass es zu weniger ungeplanten Änderungsanforderungen kommt. Reaktionsmöglichkeiten auf Änderungsanforderungen Abblocken Änderungsanforderung Annehmen und in Software einbauen, im Projekt einplanen Schneller im Projekt sein. Dadurch gibt es weniger Zeit für Änderungen in den Anforderungen 20

21 Iterative Verfahren wiederholen die Schritte mehrfach Schema für ein iteratives Vorgehen Die Kette der Tätigkeiten wird iteriert, bis das Projektziel erreicht ist. 21

22 In der Projektabwicklung erzeugt ein iteratives Verfahren eine Sequenz von Aktivitäten Sequenz der Aktivitäten in der Projektabwicklung Fach. Konz. Tech. Konz Rea Test & Int. Fach. Konz. Tech. Konz Rea Test & Int. Fach. Konz. Tech. Konz Rea Test & Int. Zeit 22

23 Ein evolutionäres Verfahren wiederholt bei jeder Iteration eine Fachliche Konzeption Sequenz der Aktivitäten bei evolutionärem Vorgehen Fach. Konz. Tech. Konz Rea Test & Int. Fach. Konz. Tech. Konz Rea Test & Int. Fach. Konz. Tech. Konz Rea Test & Int. Fragestellung: Wann erreiche ich mein Ziel? Was ist dann überhaupt mein Ziel? Zeit? Kosten? Leistungsumfang? Zeit 23

24 Ein inkrementelles Verfahren lässt keine wesentlichen Änderungen in der Fachlichkeit mehr zu. Sequenz der Aktivitäten bei inkrementellen Vorgehen Fach. Konz. Tech. Konz Rea Test & Int. Tech. Konz Rea Test & Int. Tech. Konz Rea Test & Int. Zeit 24

25 Evolutionäres und inkrementelles Vorgehen unterscheidet sich in der Festlegung, welches Ergebnis im Projekt erreicht werden soll. Gegenüberstellung evolutionär und inkrementell evolutionär Anforderungsanalyse und Fachliche Konzeption pro Iteration inkrementell Anforderungsanalyse, Konzeption, konkretes Festlegen der Ziele nur zu Beginn Jede Iteration erzeugt ein weiteres Stück der Lösung Schneller zu ersten Ergebnissen, aber immer noch anfällig gegen Änderung der Anforderungen Grundlegender Konflikt: Flexibilität gegen garantierte Zielerreichung. 25

26 Prototyping ist eine Technik zur Verbesserung der Anforderungsanalyse und fachlichen Konzeption. Vorstellung Prototyping und typische Stolpersteine Grundideen Ergänzender Schritt, bzw. konkrete Ausgestaltung von Anforderungsanalyse & fachliche Konzeption Bau eines Prototypen, der einen Eindruck der zu erstellenden Software vermittelt. Besseres Verständnis für Auftraggeber und Auftragnehmer Besseres Feedback Prototyp wird nach der Konzeption weggeworfen Stolpersteine Kosten für Prototyp müssen erbracht werden. Prototyp wird nicht weggeworfen. 26

27 Prototyping kann sinnvoll durch Tools unterstützt werden Beispiel für Tooleinsatz: Balsamic MockUps Hinweise Es gibt verschiedenste Tools in unterschiedlichen Preisklassen Tools beschleunigen die Erstellung von Prototypen Dem Eindruck, dass die Software schon fast fertig ist, kann durch einen Sketchy-Look entgegengewirkt werden 27

28 Das Spiralmodell wurde 1988 von B. Boehm entwickelt. Spiralmodell 28

29 Das Spiralmodell hat vor allem Bedeutung als Wegbereiter für iterative Ansätze. Hinweise zum Spiralmodell Beschreibt einen iterativen Prozess Wichtiger Aspekt: Risikominimierung Iteratives Durchlaufen der Phasen in einer Spirale Ziele bestimmen, Alternativen, Zusammenhänge Alternativen analysieren, Risken identifizieren und bewerten Entwickeln, verifizieren Nächste Phase planen Flächeninhalt der Spirale repräsentiert Kosten Bewertung Akademische Sicht auf iterative Entwicklung 29

30 Der Rational Unified Process hat in den letzten Jahren zunehmend an Bedeutung gewonnen. Überblicksdiagramm RUP Aufsetzen Ausarbeiten Bauen Einführen 30

31 Der Rational Unified Process ist ein Prozessmodell Charakteristika des RUP Merkmale Prozessmodell. Definition: Ein Prozessmodell legt umfassend fest: - Phasen und deren Aktivitäten - Produkte auch Zwischenprodukte - Rollen (KVQ - Kompetenzen, Verantwortlichkeiten, Qualifikationen) - Methoden, Werkzeuge, Standards, Richtlinien Iterativ, objektorientiert Im Ursprung eine enge Verknüpfung mit den Produkten der Firma Rational, heute IBM Bewertung An vielen Stellen etabliert, zumindest dem Namen nach 31

32 Das V-Modell hat im öffentlichen Bereich eine große Bedeutung. Überblick über Elemente des V-Modells 32

33 33

34 Das V-Modell definiert Entscheidungspunkte, deren Ablauf angepasst werden kann (Tailoring) Entscheidungspunkte des V-Modells Änderungsplan festgelegt Projekt genehmigt Projekt definiert Anforderungen festgelegt Projekt ausgeschrieben Angebot abgegeben Projekt beauftragt Abnahme erfolgt Projekt abgeschlossen System spezifiziert Lieferung durchgeführt Zuordnung der Entscheidungspunkte zu Projekttypen Systementwicklungsprojekt eines Auftraggebers System entworfen Feinentwurf abgeschlossen System integriert Systemelemente realisiert Systementwicklungsprojekt eines Auftragnehmers Einführung und Pflege eines organisationsspezifischen Vorgehensmodells Vorgehensmodell analysiert Verbesserung Vorgehensmodell konzipiert Verbesserung Vorgehensmodell realisiert 34

35 Die Entscheidungspunkte bei der Systemerstellung haben paarweise Gegenstücke. Entscheidungspunkte bei der Systemerstellung 35

36 Das V-Modell XT ermöglicht eine projektspezifische Ausplanung der Projektdurchführungsstrategie Beispielhaftes Tailoring 36

37 Das agile Manifest fordert eine Orientierung auf die Werte hinter den Formalismen der Softwareentwicklung. Agiles Manifest (Feb 2001) Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge Funktionierende Programme sind wichtiger als ausführliche Dokumentation. Die stetige Abstimmung mit dem Kunden ist wichtiger als die ursprüngliche Leistungsbeschreibung in Verträgen. Der Mut und die Offenheit für Änderungen stehen über dem Befolgen eines festgelegten Plans. In wie weit ist das neu oder einfach nur gesunder Menschenverstand? 37

38 extreme Programming ist ein agiles Verfahren, das weniger Dokumentenbasiert ist. extreme Programming und späte Projektphasen Gedankenspiel Boehm hat nicht recht: Moderne Software- Entwicklungsumgebungen und Sprachen machen den Umbau der Software billiger. Konzeptpflege und -aktualisierung ist aufwändig 38

39 Merkmale des extreme Programming sind kleine Releases, ständiges Refactoring und qualitätsverbessernde Programmiertechniken Wichtige Merkmale des XP-Ansatzes Merkmale von XP XP arbeitet mit kleinen Releases, unterteilt in Iterationen und Arbeitspakete. Anforderungsanalyse: Aufgaben und Anforderungen in Form von Stories Beschränkung auf wenige Anforderungen pro Iteration, Programmierung in kleinen Releases Pair Programming: Zwei Personen vor einem Rechner, einer programmiert, der andere ist Sparringspartner Kontinuierliches Refactoring Umfangreiche Unit-Tests: Voraussetzung für Refactoring. Produkt für Java: JUnit 39

40 extreme Programming hat viele Vorzüge, wird aber wegen der schlechten Planbarkeit relativ selten eingesetzt. Bewertung des XP-Ansatzes Bewertung von XP Technologie-Getrieben: Refactoring Ansatz erfordert entsprechende Programmiersprache und Technologien Refactoring ist für fachliche Anforderungen möglich, nicht aber für Architekturänderungen. Beruht auf der Annahme, dass Code-Umbau billig ist (im Gegensatz zu Boehm) explorativ: Anforderungen dürfen sich ändern Auftraggeber wird besser mit eingebunden, kann konkrete Ergebnisse sehen Enthält Elemente des Prototyping, allerdings ohne Wegwerfen Kostenabschätzung vorab nicht möglich 40

41 Scrum ist ein iteratives Verfahren, in dem Erkenntnisse aus klassischen Produktionsprozessen in die Softwareerstellung übertragen worden sind. Grundsätzliches zu Scrum Wurzeln 1987: Ikujiro Nonaka and Hirotaka Takeuchi 1991: Ken Schwaber, Jeff Sutherland und Mike Beedle Aus Produktionsprozessen, Stichwort: Lean Production Grundideen Agiles Verfahren Software wird in ca. monatlichen Iterationen entwickelt Sprint Das Entwicklungsteam organisiert sich selbst macht kleine, tägliche Iterationen Genau eine Person vertritt die Anforderungsseite Präzise vorgegebener Rahmen mit Rollenbeschreibungen, Prozessen und Artefakten 41

42 Es gibt drei zentrale Rollen in Scrum mit festen Aufgabenbereichen Rollen in Scrum Product Owner Genau 1 Person Vertritt die Fachseite, Anforderungen Ist für die fachliche Tragfähigkeit des Ergebnisses verantwortlich Team Organisiert sich selbst Setzt die Anforderungen um Richtgröße 7 ± 2 Scrum Master Übernimmt Organisation von Product Owner und Team, damit diese ungestört arbeiten können. Greift nicht inhaltlich ein: kein Tech-Guru, ist nicht der Product Owner 42

43 Das Vorgehen in Scrum ist als Rahmen sehr genau vorgegeben. Beschreibung des iterativen Vorgehens in Sprints Tägliche Iteration Sprint Vorgehen Die Software wird in Sprints entwickelt. Dauer ca. 1 Monat ± 1-2 Wochen Während eines Sprints sind keine Änderungen Change Requests möglich. Ergebnis ist ein potentiell nutzbares Produkt. Ablauf: Zu Beginn Sprint Planung: Festlegen des Ziels und der Anforderungen, die im Sprint umgesetzt werden sollen Sprint wird in täglichen Iterationen umgesetzt Am Ende Review: Produkt wird getestet, typischerweise Demo Sprint Retrospektive: Identifizieren von Prozessverbesserungen 43

44 Die Artefakte in Scrum sind genau wie der Prozess präzise vorgegeben. Artefakte in Scrum Anforderungen in Backlogs Anforderungen Priorisierung Product Backlog: alle Anforderungen an die Software Selected Backlog: Anforderungen für einen Sprint Sprint Backlog: Anforderungen in Ein-Tages-Häppchen Weitere Artefakte Impediment Backlog: Hindernisse in der Softwareentwicklung, werden durch Srcum Master beiseite geräumt. Burndown-Chart: Grafische Darstellung der Restaufwände 44

45 Scrum findet gerade für kleinere Projekte zunehmend Verbreitung. Bewertung von Scrum Bewertung Stellt einen Mittelweg zwischen inkrementellen und explorativen Ansätzen dar: Anforderungen dürfen sich ändern, aber nicht innerhalb der Sprints Findet zunehmend Verbreitung, insbesondere für kleinere Projekte Gutes Beispiel dafür, dass agil nicht chaotisch heißt: gibt einen festen Rahmen für ein Projekt vor Umgeht Probleme in der Anforderungsanalyse, indem genau eine Person als Product Owner vorgegeben wird. Löst damit nicht das Problem, wie aus widersprüchlichen Anforderungen verschiedener Personen eine gemeinsame Lösung entsteht. Setzt intensive Mitarbeit des Product Owners voraus. 45

47 Die Wahl des geeigneten Vorgehens hat eine zentrale Rolle für die Projektdurchführung Entscheidung zwischen den Modellen Fachliche Konzeption Technische Konzeption Realisierung Test & Integration 47

48 Beide Vorgehensmodelle haben ihre Stärken Bewertung der Vorgehensmodelle Hohe Sicherheit für Software-Anbieter Gesamtblick (aber: zu viele Details) Unüberschaubare Konzeptpapiere Geringere Flexibilität, aber Change- Request-Verfahren Nutzen erst bei Einführung Deckel drauf bekommen Einfache Struktur, QS zwischen Phasen Entspricht Denkweise: Geld für definierte Leistung Fachliche Konzepte können die Vorstellungskraft sprengen Früher Nutzen für Kunden Besseres, qualifizierteres Feedback Kosten für Übergangslösungen Schwieriger zu managen Geringeres Einführungsrisiko Wasserfall Iterativ 48

49 Stufen bilden einen Mittelweg zwischen den Extremen Rolle von Stufen Fachliche Konzeption Wasserfall schlecht Technische Konzeption Stufen Realisierung Test & Integration Inkrementell Chaos 49

50 (geschätzte) Kosten Die optimale Stufenzahl muss für jedes Projekt festgelegt werden. Gegenüberstellung von Stufung und Stichtagsumstellung Einführungsrisiko * Kosten: Provisorien, Mehrfachtest, etc. Anzahl Einführungsstufen Bereich der optimalen Stufenzahl * Erwartungswert des Schadens bei Systemausfall 50

51 Bei größeren Aufgaben ist ein gestuftes Vorgehen empfehlenswert. Motivation für ein gestuftes Vorgehen Stufung Wasserfall als Vorgehen stößt an Grenzen Große Projekte werden handhabbar Stufen verringern das Risiko Fachliches Risiko Technisches Risiko Die elegante Art, nein zu sagen: Stufen bedeuten, dass Anforderungen nicht oder erst später erfüllt werden Widerstände für eine Stufung müssen überwunden werden: Management-Aufgabe 51

52 Der Ablauf eines gestuften Projekts ist oft verschränkt. Beispiel für gestuften Projektablauf FK TK R T&I Stufe 1 Studie & Grobanalyse FK TK R T&I Stufe 2 FK TK R T&I Stufe 3 52

53 Stufen können nach festen Kriterien identifiziert werden. Kriterien für Stufen Unabhängig einführbar Fachlich Technisch Das Ergebnis einer Stufe kann produktiv gestellt werden. Nutzen stiften Fachlichen Nutzen stiften Technische Sicherheit gewinnen - Schwieriges zuerst Organisatorische Sicherheit gewinnen Schrittweiser Aufbau von Technologien Fachlichkeit ist größter Hebel zur Stufenbildung In der ersten Stufe wird i. d. R. die technologische Basis geschaffen 53

54 Fallbeispiele zeigen die Anwendbarkeit von Stufungen in Projekten Fallbeispiele für Stufen Buchungssystem Zu Beginn keine Stufung identifiziert Fachliche Stufung: zunächst Buchungen für eine Region Portalanwendung technisch/fachliche Stufung: zunächst Minimalausstattung technische Infrastruktur fachlich: erst eine Applikation komplett entwickelt, andere nur Integriert Provisorium wurde permanente Lösung Data Warehouse fachliche Stufen nach Kundenkreisen 54

55 Stufen sollten zu Beginn eines Projekts identifiziert werden, ggf. auch nach der Fachlichen Konzeption. Hinweise zur Bildung von Stufen im Projekt Bei Aufsetzen des Projekts Immer den Umfang des Projekts im Auge behalten Bei größerem Umfang Stufung versuchen - Umfang niemals unterschätzen! Nach Fachkonzeption oder Studie Zusätzlicher Schnittpunkt für Stufenbildung (fachlich) Indizien für zu großen Projektumfang Umfang der Konzeptpapiere: größer als 200 Seiten? Feedback der Reviewer/externen Beteiligten: wirken sie noch mit, lesen sie die Papiere? 55

56 Das Projektmodell bei Capgemini CSD Deutschland entspricht dem RUP- Modell Initialisierung Beispiel: Projektmodell bei Capgemini CSD Deutschland t Anforderungen des Kunden Anforderungsmanagement & Änderungsverfahren Systemerstellung T-Stufe A-Stufe Jede Stufe hat 5 Phasen Spezifikation Konstruktion Realisierung Integration A-Stufe Querschnitt (PM, QM, CD, etc.) Abnahme Produktion Release R. Stufen und Stufentypen Entwicklung erfolgt in Stufen T-Stufe: Schwerpunkt ist technische Verifikation und Schaffung der technischen Grundlagen A-Stufe: Schwerpunkt ist fachliche Anwendung Ausgestaltung der Stufen Stufenmuster für T- und A-Stufen aus der Projektpraxis 56

57 Initialisierung Spezifikation Initialisierung Initialisierung Das Vorgehen innerhalb der Stufe richtet sich nach dem Projekt. Beispiele für Vorgehen innerhalb einer Stufe Verzahntes Wasserfallmodell Motivation / Einsatz Besonderheiten Spezifikation Konstruktion Realisierung Integration Kleines Projekt Klarer, überschaubarer Funktionsumfang Frühe Gesamtspezifikation erforderlich Ist Spezialfall einer Stufe mit nur einem Inkrement Funktionsumfang früh definiert und weitgehend fix Inkrementelles Vorgehen Spezifikation Spezifikation Konstruktion Konstruktion Realisierung Integration Realisierung Inkrementell mit Vorspezifikation Konstruktion Realisierung Integration Konstruktion Realisierung Integration Integration Schnelle Ergebnisse & schnelles Lernen auch bei komplexer Funktionalität Risiko reduzieren durch Wichtigstes zuerst Gesamtspezifikation zu Beginn der Stufe Gesamtaufwand leichter planbar als bei inkrementellem Vorgehen Frühes Feedback durch schnell lauffähiges Teilsystem Schrittweises Verfeinern Mischform der beiden obigen Modelle Schwerpunkt ab zweitem Inkrement auf Realisierung (weniger Konstruktion) 57

58 Vielen Dank für Ihre Aufmerksamkeit!