Änderungsmanagement bei iterativer SW-Entwicklung Vortrag auf der regionalen Fachgruppe IT-Projektmanagement, 05.05.2006, Stuttgart Dr. Karsten Hoffmann, Steinbeis-Transferzentrum IT-Projektmanagement, Stuttgart Vortrag zum Änderungsmgmt., FG IT-PM, 5.5.06 - Folie 1
Change-Request-Verfahren (Vorgehen im Projekt) Sinn eines CR-Verfahrens: Mit einem sauber geregelte Verfahren fachliche Änderungen in das Projekt aufnehmen Antrag dann, wenn das bisher Festgelegte verändert werden soll Beim Wasserfallmodell Änderungen im Feinkonzept, nachdem dieses verabschiedet worden ist (bzw. Änderungen im bestehenden Programm) Beim Versionsmodell z.b. Änderungen an einer ersten Festlegung in einer früheren Version des Programms Antragsteller ist oft die Fachabteilung, kann jedoch auch von anderer Seite kommen z.b. von Realisierung, um technische Probleme zu umgehen Verfahren: Änderung in Form CR beantragen, Auswirkungen abschätzen, darüber neu befinden, erst dann Freigabe eines CR So definiert ist ein CR eine Nachforderung mit fairer Verhandlung Vortrag zum Änderungsmgmt., FG IT-PM, 5.5.06 - Folie 2
CR-Verfahren: Workflow-Beispiel Fachlicher Änderungsbedarf Fachliche Seite (Kunde) Antrag Change Request Einbringen Change Request Technische Seite (Auftragnehmer, Realisierer) n Prüfung: Fachlich konsistent? j M n Prüfung: Technisch konsistent? V Entscheidung Kunde: Annehmen, Modifizieren, Verwerfen Abschätzen Zusatzaufwand + Zusatzzeit j A Freigabe CR Vortrag zum Änderungsmgmt., FG IT-PM, 5.5.06 - Folie 3
Spiralmodell: Iterative Vorgehensweise in der Objektorientierten SW-Entwicklung OO-Test Version 3 Version 2 Vers. 1 OO-Analyse OO-Konstruktion OO-Design Vortrag zum Änderungsmgmt., FG IT-PM, 5.5.06 - Folie 4
Vorgehen nach Spiralmodell Jede Phase wird mehrfach durchlaufen Rückkopplungen sind ein Kernelement des Spiralmodells ==> Kommunikation zwischen Entwickler und Fachabteilung wichtig Fachliche Anforderungen werden so fein beschrieben, wie für die jetzige Version nötig Aus Alternativen der technischen Umsetzung ergeben sich möglicherweise neue Ideen/Anforderungen der Fachabteilung Die Arbeitsschritte im Modell gehen ineinander über, wiederholen sich, Ganzheitliches Denken und Kreativität ist gefragt Vorgehen nach Spiralmodell erschwert Offshore-Option, Kommunikation und Rückkopplungen erfordern Verständnis der anderen Kultur Vortrag zum Änderungsmgmt., FG IT-PM, 5.5.06 - Folie 5
Änderungen im Spiralmodell Änderungen nach Vers. 2: In Analyse, Design und Realisierung muss geändert werden; Durchführung als eigener CR oder in Vers. 3 Version 3 Version 2 Vers. 1 Da häufige Rückkopplung sind entdeckte Fehlentwicklungen meist klein Wg. systematischem Aufbau bei iterativer SWE, Hauptteil der Änderungen oft in Erweiterungen Beisp.: Änderungen benötigen Mehraufwand zu Version 2 Hauptteil fliesst jedoch in Erweiterungen der Version 3 Vortrag zum Änderungsmgmt., FG IT-PM, 5.5.06 - Folie 6
Weitere Management-Vorteile im Spiralmodell Projektbegleitendes Controlling: Wochenbezogene Aufwandserfassung und Restzeit-Schätzungen, Prozesserfahrung mit steigenden Versionen Durch schlanke Arbeitspakete bleiben Aufwände eher kontrollierbar Change-Management wird früh gelernt Auch im Spiralmodell erzeugen Änderungen einen Mehraufwand, da Probleme früher gesehen, sind die Auswirkungen jedoch meist geringer Neue Management-Möglichkeiten durch flexiblere Vorgehensweise Festlegung fachlicher Spezialfälle erst spät möglich Bessere Chancen, ein System zu erhalten, das zeitnah festgelegte Funktionalitäten enthält Vortrag zum Änderungsmgmt., FG IT-PM, 5.5.06 - Folie 7
Das Spiralmodell passt zur Objektorientierten SW-Entwicklung Unternehmen Analyse Klassenmodell Design Systemdesign Klassendesign Spiralmodell: Zyklisches Wiederholen der Phasen Programmierung + Test Programm DV-System Vortrag zum Änderungsmgmt., FG IT-PM, 5.5.06 - Folie 8
Architekturmodell - Projektbeispiel (frühe Phase) Definition Systemarchitektur Der Durchstich wurde als vertikaler Prototyp definiert Aufgabe des Durchstichs: Evaluieren der Zielarchitektur 1. Es gab ein beispielhaftes Grobfrüheres System Spezifikation 2. Es wurden zwei Alternativen genauer untersucht Projektauftrag Durchstich Fachkonzept Stufe 1 DV-Konzept (Stufe 1) Fachkonzept Stufe 2 evtl. Anpassg. DV-Konzept Zeit System Version 1 System Version 2 System Version 3 ff Vortrag zum Änderungsmgmt., FG IT-PM, 5.5.06 - Folie 9
Architekturmodell - Projektbeispiel (vor und nach 1. Iteration) Definition Systemarchit. Fachkonzept Stufe 1 Grob- Spezifikation 1. Verfeinerung der IT-Architektur 2. Wo erforderlich, Modifikation einzelner Elemente der zu realisierenden Ziel-Architektur Projektauftrag Durchstich DV-Konzept (Stufe 1) evtl. Anpassg. DV-Konzept Fachkonzept Stufe 2 Falls erforderlich, nochmalige Nach- Korrektur der Ziel- Architektur Zeit System Version 1 System Version 2 System Version 3 ff Vortrag zum Änderungsmgmt., FG IT-PM, 5.5.06 - Folie 10
Projektplanung im Spiralmodell Wichtigste Meilensteine sind die Versionen, Funktionsumfänge sind nur grob festgelegt Oft wird ein Gesamtbudget festgelegt, für das eine (festzulegende) Zahl von Versionen erstellt werden soll Für Versionen gilt meist Termin vor Funktionsumfang Verpflichtung auf notwendige Funktionen durch Festlegung von MUSS- Funktionen, an SOLL- und KANN-Funktionen wird ggfs. gekürzt Iterativer Prozess der Feinplanung aufgrund der Erfahrungen in ersten Versionen Controlling wird einfacher (welche Aufgaben?) und sicherer (Aufwand) Vortrag zum Änderungsmgmt., FG IT-PM, 5.5.06 - Folie 11
Timeboxing: Steuerung der Aufwände über Versionen Voraussetzungen zur Steuerungs-Möglichkeit: Die Arbeitspakete für eine Version sind in MUSS-, SOLL- und KANN- Funktionen kategorisiert (MUSS-Funktionen werden für die nächste Version garantiert), Anteil der MUSS-Funktionen ist < 70% (!!) Bei Mehraufwänden Verschiebung von SOLL-Funktionen in die nächste Version - BEACHTE: Funktionen, die zusammengehören! Mögliche Vereinbarung: Der vorgesehene Termin wird auf jeden Fall gehalten, notfalls Streichungen bei SOLL- und KANN-Funktionen in die nächste Version Plan-Aufgaben MUSS SOLL KANN Plan-Kapazität Vorgesehene Kapazität Vortrag zum Änderungsmgmt., FG IT-PM, 5.5.06 - Folie 12