CEA v6.4
Kaiserslautern, WS 2008/2009 Dr. Gerhard Pews
IT-Projektmanagement Teil 2: Der Gegenstand von SW-Projekten
CEA v6.4 07.11.2008 2
Inhalte
Der Fahrplan durch die Vorlesung
• 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
CEA v6.4 07.11.2008 3
AGENDA
• Motivation
• Tätigkeiten bei der SW-Entwicklung
• Diese Tätigkeiten im Kontext von Vorgehensmodellen
• Stufen
CEA v6.4 07.11.2008 4
Einführung & Motivation
• Fokus der Vorlesung liegt im Software-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. • Grundlegende Frage
– 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?
CEA v6.4 07.11.2008 5
AGENDA
• Motivation
• Tätigkeiten bei der SW-Entwicklung
• Diese Tätigkeiten im Kontext von Vorgehensmodellen
• Stufen
CEA v6.4 07.11.2008 6
In Software-Entwicklunsprojekten finden sich immer die gleichen Tätigkeiten wieder.
Anforderungs- analyse
& Fachliche Konzeption
Technische Konzeption
Realisierung Integration und Test
CEA v6.4 07.11.2008 7
In jedem Softwareentwicklungsprojekt finden sich vier grundlegende Tätigkeiten.
Tätigkeiten
Anforderungsanalyse & Fachliche Konzeption
Technische Konzeption
Realisierung
Integration & Test
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
• Zusammenfügen mit Nachbarsystemen • Funktionaler Gesamttest
CEA v6.4 07.11.2008 8
Anforderungsanalyse und Fachliche Konzeption bilden die Grundlage der Softwareentwicklung.
• Anforderungsanalyse und Fachliche Konzeption sind oft nicht zu trennen.
• Ergebnisse – Anforderungen (funktional und nicht-
funktional) – 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
Tätigkeiten
Anforderungsanalyse & Fachliche Konzeption
Technische Konzeption
Realisierung
Integration & Test
CEA v6.4 07.11.2008 9
Die Technische Konzeption legt fest, wie das System zu erstellen ist.
• 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
Tätigkeiten
Anforderungsanalyse & Fachliche Konzeption
Technische Konzeption
Realisierung
Integration & Test
CEA v6.4 07.11.2008 10
In der Realisierung wird das System programmiert.
• Inhalte der Realisierung – Programmieren – Testen (Entwicklertest) – Dokumentieren
• Ergebnisse – Code – Dokumentation
Tätigkeiten
Anforderungsanalyse & Fachliche Konzeption
Technische Konzeption
Realisierung
Integration & Test
CEA v6.4 07.11.2008 11
Die Technische Konzeption legt fest, wie das System zu erstellen ist.
• 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.
Tätigkeiten
Anforderungsanalyse & Fachliche Konzeption
Technische Konzeption
Realisierung
Integration & Test
CEA v6.4 07.11.2008 12
Geläufige und häufig verwendete alternative Namen für die Tätigkeiten.
• 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
CEA v6.4 07.11.2008 13
Nutzen von Konzepten im Projektmanagment Kosten der Fehlerbehebung in Projekten
Quelle: B. Boehm, sd&m Konferenz 2001
?
CEA v6.4 07.11.2008 14
Nutzen von Konzepten im Projektmanagment Kosten der Fehlerbehebung in Projekten
Quelle: B. Boehm, sd&m Konferenz 2001
CEA v6.4 07.11.2008 15
AGENDA
• Motivation
• Tätigkeiten bei der SW-Entwicklung
• Diese Tätigkeiten im Kontext von Vorgehensmodellen
• Stufen
CEA v6.4 07.11.2008 16
Die sequentielle Anordnung der Tätigkeiten: Wasserfall
Fach. Konzeption
Tech. Konzeption
Realisierung
Test & Integration
nach Winston W. Royce 1970
Projektstart Ziel
CEA v6.4 07.11.2008 17
Beschreibung des Wasserfallmodells
• 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.
• Bewertung – Einfach zu verstehen – Einfach zu managen – Einfach zu controllen (Definierte Phasenübergänge)
• Aber: Was tun, wenn sich Anforderungen ändern?
CEA v6.4 07.11.2008 18
Wasserfall mit Rückkopplung
Fach. Konzeption
Tech. Konzeption
Realisierung
Test & Integration
nach B. Boehm 1981
Aber: Was tun, wenn sich Anforderungen ändern? keine wirklich gute Antwort
CEA v6.4 07.11.2008 19
Reaktionsmöglichkeiten auf Änderung der Anforderungen
• Reaktion 1: Abblocken • Reaktion 2: Schneller im Projekt sein. Dadurch gibt es weniger Zeit
für Änderungen in den Anforderungen • Reaktion 3: Änderung annehmen und in die Software einbauen
CEA v6.4 07.11.2008 20
Iterative Verfahren
• Die Kette der Tätigkeiten wird iteriert, bis das Projektziel erreicht ist.
CEA v6.4 07.11.2008 21
Projektverlauf in Iterativen Verfahren (evolutionär)
• Fragestellung: Wann erreiche ich mein Ziel? Was ist dann überhaupt mein Ziel?
• Zeit? Kosten? Leistungsumfang?
Fach. Konz. Tech.
Konz Rea Test & Int. Fach.
Konz. Tech. Konz Rea Test &
Int. Fach. Konz. Tech.
Konz Rea Test & Int.
CEA v6.4 07.11.2008 22
Projektverlauf in Iterativen Verfahren (inkrementell)
• Fragestellung: Wann erreiche ich mein Ziel? Was ist dann überhaupt mein Ziel?
• Zeit? Kosten? Leistungsumfang?
Fach. Konz. Tech.
Konz Rea Test & Int.
Tech. Konz Rea Test &
Int.
Tech. Konz Rea Test &
Int.
CEA v6.4 07.11.2008 23
Iterative Verfahren: evolutionär und inkrementell
• Evolutionär: – Anforderungsanalyse, Fach. 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.
CEA v6.4 07.11.2008 24
Prototyping
• 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
• Probleme – Kosten für Prototyp müssen erbracht werden. – Prototyp wird nicht weggeworfen.
CEA v6.4 07.11.2008 25
eXtreme Programming - XP
• „Agiles“ Verfahren • Idee: Boehm hat nicht recht: Moderne Software-
Entwicklungsumgebungen und Sprache machen Umbau der Software billiger. Konzeptpflege und -aktualisierung ist aufwändig
CEA v6.4 07.11.2008 26
eXtreme Programming
• Merkmale – 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 • Unit-Tests
– Produkt für Java: JUnit • Bewertung
– Technologie-Getrieben: Refactoring Ansatz erfordert entsprechende Programmiersparche und Technologien
– Beruht auf der Annahme, dass Code-Umbau billig ist (im Gegensatz zu Boehm) – explorativ: Anforderungen dürfen sich ändern
• Auftraggeber wird mit besser eingebunden, kann konkrete Ergebnisse sehen • Enthält Elemente des Prototyping, allerdings ohne Wegwerfen
CEA v6.4 07.11.2008 27
Spiralmodell
CEA v6.4 07.11.2008 28
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
CEA v6.4 07.11.2008 29
RUP – Rational Unified Process
Aufsetzen Ausarbeiten Bauen Einführen
CEA v6.4 07.11.2008 30
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 • Bewertung
– An vielen Stellen etabliert, zumindest dem Namen nach
CEA v6.4 07.11.2008 31
V-Modell Übersicht
CEA v6.4 07.11.2008 32
CEA v6.4 07.11.2008 33
Entscheidungspunkte
CEA v6.4 07.11.2008 34
Systemerstellung überblick
CEA v6.4 07.11.2008 35
Projektspezifische Ausplanung der Projektdurchführungsstrategie
CEA v6.4 07.11.2008 36
AGENDA
• Motivation
• Tätigkeiten bei der SW-Entwicklung
• Diese Tätigkeiten im Kontext von Vorgehensmodellen
• Stufen
CEA v6.4 07.11.2008 37
Wasserfallmodell versus Iterative Software-Entwicklung
Fach. Konz
Tech. Konz.
Rea.
Test & Integr.
Projektvorgehen, Vorgehensmodelle
CEA v6.4 07.11.2008 38
Und was ist besser? Projektvorgehen, Vorgehensmodelle
CEA v6.4 07.11.2008 39
Bewertung Vorgehensmodelle
Wasserfall • Hohe Sicherheit für Sofware-
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“
Iterativ • Früher Nutzen für Kunden • Besseres, qualifizierteres
Feedback • Kosten für Übergangslösungen • Schwieriger zu managen • Geringeres Einführungsrisiko
Projektvorgehen, Vorgehensmodelle
CEA v6.4 07.11.2008 40
Zwischen den Polen
Stufen
Wasserfall ≠ schlecht
Inkrementell ≠ Chaos
Projektvorgehen, Vorgehensmodelle
Fach. Konz
Tech. Konz.
Rea.
Test & Integr.
CEA v6.4 07.11.2008 41
Bereich der optimalen Stufenzahl
Stufung versus Stichtagsumstellung
Kosten: Provisorien, Mehrfachtest, etc.
Einführungsrisiko *
* Erwartungswert des Schadens bei Systemausfall
(ges
chät
zte)
Kos
ten
Anzahl Einführungsstufen
Stufen in Projekten
CEA v6.4 07.11.2008 42
Warum Stufen?
• Wasserfall als Vorgehen stößt an Grenzen – Große Projekte werden handhabbar
• Verringern des Risikos – Fachliches Risiko – Technisches Risiko
• Die elegante Art, „nein“ zu sagen: Stufen bedeuten, dass Anforderungen nicht oder erst später erfüllt werden – Widerstände müssen überwunden werden: Management-Aufgabe
Stufen in Projekten
CEA v6.4 07.11.2008 43
Projekt in Stufen
Studie & Grobanalyse
T&I FK TK R Stufe 1
Stufe 2
Stufe 3
Wie bildet man Stufen?
T&I FK TK R
T&I FK TK R
CEA v6.4 07.11.2008 44
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
Wie bildet man Stufen?
CEA v6.4 07.11.2008 45
Beispiele 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
CEA v6.4 07.11.2008 46
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?
CEA v6.4 07.11.2008 47
Beispiel: sd&m-Projektmodell (entspricht RUP und V-Modell)
Stufen und Stufentypen • Entwicklung erfolgt in Stufen • T-Stufe: Schwerpunkt ist technische Verifikation und
Schaffung der technischen Grundlagen • A-Stufe: Schwerpunkt ist fachliche Anwendung
Jede Stufe hat 5 Phasen
Ausgestaltung der Stufen • Stufenmuster für T- und A-Stufen aus
der Projektpraxis
t Anforderungen des Kunden
Abnahme
Produktion
Anforderungsmanagement & Änderungsverfahren
Querschnitt (PM, QM, CD, etc.)
A-Stufe
R. Release
Systemerstellung
A-Stufe
T-Stufe
CEA v6.4 07.11.2008 48
Das Vorgehen innerhalb der Stufe richtet sich nach dem Projekt – drei Beispiele:
Inkrementelles Vorgehen
Verzahntes Wasserfallmodell
Inkrementell mit Vorspezifikation
• Ist Spezialfall einer Stufe mit nur einem Inkrement
• Funktionsumfang früh definiert und weitgehend fix
Motivation / Einsatz Besonderheiten
• Mischform der beiden obigen Modelle
• Schwerpunkt ab zweitem Inkrement auf Realisierung (weniger Konstruktion)
• Frühes Feedback durch schnell lauffähiges Teilsystem
• Schrittweises Verfeinern
• Gesamtspezifikation zu Beginn der Stufe
• Gesamtaufwand leichter planbar als bei inkrementellem Vorgehen
• Kleines Projekt • Klarer, überschaubarer
Funktionsumfang • Frühe Gesamtspezifikation
erforderlich
• Schnelle Ergebnisse & schnelles Lernen – auch bei komplexer Funktionalität
• Risiko reduzieren durch „Wichtigstes zuerst“
Spezifikation
Konstruktion
Realisierung
Integration Initi
alis
ieru
ng
CEA v6.4 07.11.2008 49
Zusammen. Für nachhaltigen Erfolg.
CEA v6.4