Kaiserslautern, WS 2008/2009 Dr. Gerhard Pews
IT-Projektmanagement
Teil 2: Der Gegenstand von SW-Projekten
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
AGENDA
• Motivation
• Tätigkeiten bei der SW-Entwicklung
• Diese Tätigkeiten im Kontext von Vorgehensmodellen
• Stufen
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?
AGENDA
• Motivation
• Tätigkeiten bei der SW-Entwicklung
• Diese Tätigkeiten im Kontext von Vorgehensmodellen
• Stufen
In Software-Entwicklunsprojekten finden sich immer die gleichen Tätigkeiten wieder.
Anforderungs- analyse
& Fachliche Konzeption
Technische Konzeption
Realisierung Integration und Test
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
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
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
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
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
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
Nutzen von Konzepten im Projektmanagment Kosten der Fehlerbehebung in Projekten
Quelle: B. Boehm, sd&m Konferenz 2001
?
Nutzen von Konzepten im Projektmanagment Kosten der Fehlerbehebung in Projekten
Quelle: B. Boehm, sd&m Konferenz 2001
AGENDA
• Motivation
• Tätigkeiten bei der SW-Entwicklung
• Diese Tätigkeiten im Kontext von Vorgehensmodellen
• Stufen
Die sequentielle Anordnung der Tätigkeiten: Wasserfall
Fach.
Konzeption
Tech.
Konzeption
Realisierung
Test &
Integration
nach Winston W. Royce 1970
Projektstart Ziel
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?
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
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
Iterative Verfahren
• Die Kette der Tätigkeiten wird iteriert, bis das
Projektziel erreicht ist.
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.
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.
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.
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.
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
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
Spiralmodell
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
RUP – Rational Unified Process
Aufsetzen Ausarbeiten Bauen Einführen
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
V-Modell Übersicht
Entscheidungspunkte
Systemerstellung überblick
Projektspezifische Ausplanung der Projektdurchführungsstrategie
AGENDA
• Motivation
• Tätigkeiten bei der SW-Entwicklung
• Diese Tätigkeiten im Kontext von Vorgehensmodellen
• Stufen
Wasserfallmodell versus
Iterative Software-Entwicklung
Fach.
Konz
Tech.
Konz.
Rea.
Test & Integr.
Projektvorgehen, Vorgehensmodelle
Und was ist besser?
Projektvorgehen, Vorgehensmodelle
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
Zwischen den Polen
Stufen
Wasserfall ≠ schlecht
Inkrementell ≠ Chaos
Projektvorgehen, Vorgehensmodelle
Fach.
Konz
Tech.
Konz.
Rea.
Test & Integr.
Bereich der optimalen Stufenzahl
Stufung versus Stichtagsumstellung
Kosten:
Provisorien, Mehrfachtest, etc.
Einführungsrisiko *
* Erwartungswert des Schadens bei Systemausfall
(geschätzte) Kosten
Anzahl Einführungsstufen
Stufen in Projekten
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
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
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?
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
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?
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
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
Initialisierung
