Hybride Softwareentwicklung

Drei Dinge muss ein Softwareprojekt einhalten, um erfolgreich zu sein: Zeit, Budget, Funktionen. Theoretisch klingt das ganz einfach. Aber die Realität sieht anders aus, denn laut einer Studie von Forrester werden über 60% aller IT-Projekte nicht nach Plan abgeschlossen. [1]

Als Hauptgrund werden ungenaue oder sich ändernde Anforderungsdefinitionen hinsichtlich der gewünschten Funktionen genannt, die sich wiederum auf den Zeitbedarf und das geplante Budget auswirken. Somit entsteht ein Konflikt, der besonders bei Projekten mit externen Auftragnehmern zum Tragen kommt:

Um eine verlässliche Zeit- und Kostenschätzung vornehmen zu können, benötigen Auftragnehmer vor Projektstart eine ausführliche Anforderungsspezifikation mit allen funktionalen und nicht-funktionalen Anforderungen. Viele klassische Phasenkonzepte in der IT berücksichtigen diesen Aspekt nicht ausreichend, da erst nach Projektstart alle Anforderungen z. B. in Form eines Pflichtenheftes detailliert festgehalten werden. Zu diesem Zeitpunkt haben Auftraggeber und Lieferant aber nicht selten bereits einen Vertrag geschlossen. Ärger ist somit vorprogrammiert.

Eine möglicher Lösungsansatz für dieses Dilemma ist die Kombination klassischer und agiler Softwareentwicklungsmethoden, in denen die Stärken beider Modelle so kombiniert werden, dass die Beteiligten

• Kosten und Zeit verlässlich schätzen und
• gleichzeitig flexibel auf Änderungswünsche reagieren können.

Dazu werden im folgenden Kapitel zunächst die Besonderheiten von phasenorientierten Modellen und agilen Vorgehensweisen näher untersucht.

Phasenorientierte Modelle sind durch eine Unterteilung der Systementwicklung in zeitliche Abschnitte gekennzeichnet. Prominente Vertreter sind das Wasserfallmodell [1] und das V-Modell [4]. Bei diesen Modellen werden die einzelnen Phasen nacheinander und für das gesamte Projekt einmalig durchlaufen. Durch den sequentiellen Charakter ist es allerdings kaum möglich, auf Änderungen zu reagieren, die während des Ablaufs entstehen. Diese Modelle funktionieren dann gut, wenn der Auftraggeber formalisierte Anforderungen auf einer konstanten und strukturierten Basis anbietet.

Agile Vorgehensmodelle (z. B. XP [2] oder Scrum [5]) sind iterativ, d.h. die definierten Phasen werden mehrfach durchlaufen. Teile der umzusetzenden Anforderungen werden nur für die jeweilige Iteration (den nächsten Durchlauf) festgelegt. Somit können Auftraggeber auch mitten im Projekt noch Einfluss auf die Funktionen der Software nehmen. Agile Projekte haben häufig kein definiertes Ende, weil sich das Projekt durch ständige Änderungswünsche verzögert. Die Vereinbarung eines Festpreises ist problematisch, da zu Beginn weder Funktionsumfang noch Projektende feststehen und der Entwurf des Produktes erst während der Entwicklung entsteht.

Im folgenden Kapitel wird ein hybrides Modell vorgestellt, das durch die Kombination phasenorientierter und agiler Vorgehen sowohl formalisierte Prozesse ermöglicht als auch flexibel auf Änderungen im Projekt reagieren kann.

Der Kerngedanke des hybriden Modells ist die Kombination klassischer Phasenmodelle mit agilen Methoden. Durch deren Kombination werden die Stärken beider Denkweisen genutzt und ihre Schwächen bestmöglich vermieden. Es handelt sich um ein 3x3-Phasenmodell mit drei Hauptphasen und jeweils drei Unterphasen. Der Prozess zur Softwareentwicklung im hybriden Modell besteht aus den drei Hauptphasen Vorbereitung, Entwicklung und Finalisierung, die nacheinander durchlaufen werden (siehe Abbildung 1). Jede der drei Hauptphasen ist wiederum in drei Unterphasen aufgeteilt, die entweder direkt den Entwicklungsprozess oder administrative Schritte beinhalten. Zu den administrativen Schritten gehören die Angebotsabgabe, die Kundenabnahme und die Auslieferung. Sie haben vom Wesen her keinen direkten Einfluss auf den Entwicklungsprozess. Eine Besonderheit im hybriden Modell sind die drei Unterphasen Anforderungsanfrage, Angebotsabgabe und Finalisierung. Sie sind spezifisch für Festpreisprojekte und können z. B. in Wartungsprojekten entfallen.

Die Vorbereitungsphase dient dazu, in Zusammenarbeit mit dem Kunden die Anforderungen an die Software zu erheben und vertragliche Rahmenbedingungen zu definieren. Sind diese erfasst, beginnt das Systemdesign. Auch wenn die Entwicklungsphase iterativ durchlaufen wird (vgl. Abbildung 2), so ist es zu Beginn doch erforderlich, die Art der Implementierung (Web-Anwendung, Smartphone-App, Fat-Client-Lösung, etc.) und geeignete Frameworks festzulegen. Dabei wird die Auswahl der Frameworks innerhalb der Entwicklung regelmäßig auf den Prüfstand gestellt, um optimale technische Rahmenbedingungen für die Entwicklung sicherzustellen.

Wie bei den agilen Methoden (z. B. XP oder Scrum) erfolgen Detailplanung und Umsetzung in gleichmäßigen Zeitabständen (Iterationen) von 2-4 Wochen. Nach jeder Iteration liegt ein prüfbares Ergebnis vor, das vom Kunden getestet wird. So werden Abweichungen von den tatsächlichen Wünschen des Kunden zeitnah identifiziert und Fehlentwicklungen vermieden (siehe dazu auch Abbildung 2). Nach jeder Iteration findet erneut ein kurzes Planungstreffen mit dem Auftraggeber statt und es werden die nächsten Anforderungen mit dem höchsten Nutzen für den nächsten Sprint festgelegt. Unterstützt wird die Entwicklung durch typisch agile Methoden wie Test-Driven Development und Continuous Integration. Besonders Continuous Integration  unterstützt die Entwickler bei der Bereitstellung eines Prototypen in hohem Maße, da dadurch die manuelle Integration einzelner Komponenten zu einem Gesamtsystem entfällt.

Durch die frühe Bereitstellung und das entsprechende Feedback der Anwender können bei sehr großen Projekten die Termine und Kosten überschaubar gehalten und die Gesamtkomplexität des Vorhabens reduziert werden. Durch die Zerlegung der Anwendung in kleine Einheiten, die nach ihrem Nutzen priorisiert werden, wird sowohl die Komplexität reduziert als auch zuerst die relevanten Funktionen umgesetzt. Bei einem Festpreisprojekt ist die Anzahl der Sprints und die in dieser Zeit umsetzbare Funktionalität begrenzt. So sind Zeit- und Kostenrahmen für den Auftraggeber zwar leicht zu überprüfen, jedoch besteht das Risiko, dass nicht alle Funktionen umgesetzt werden. Die Priorisierung stellt jedoch sicher, dass die wichtigsten Funktionen auf jeden Fall umgesetzt sind und diese auch in einer hohen Qualität vorliegen, da sie in jedem Sprint getestet wurden. Falls erforderlich werden aus Zeit- und Budgetgründen ausgewählte Funktionalitäten gestrichen. Allerdings haben diese auch keine besonders hohe Priorität, da sie für einen späteren Sprint geplant sind.

Nach Umsetzung aller relevanten Anforderungen folgt die sequentielle Finalisierungsphase. Hier findet die Kundenabnahme statt und die Auslieferung wird vorbereitet. Unter Auslieferung versteht man die Installation der Anwendung für den produktiven Betrieb.

Im hybriden Modell müssen bestimmte Unterphasen abgeschlossen sein, bevor die nächste Phase beginnt. Diese Sequenzialisierung findet sich insbesondere in der Vorbereitung und der Finalisierung wieder. So sollten in der Anforderungsanalyse die Vorstellungen des Kunden möglichst vollständig besprochen sein, bevor ein fundiertes Angebot abgegeben wird oder das Systemdesign beginnt. Wie sich das hybride Modell auch zusammen mit anderen Modellen wie z. B. ITIL kombinieren lässt, wird im folgenden Kapitel beschrieben.

Eine Besonderheit des hybriden Modells ist die Integrationsfähigkeit in unternehmenstypische Prozesse wie Qualitätssicherung und Risikomanagement. Wie das genau erfolgt, ist in [3] ausführlich beschrieben. In diesem Abschnitt wird exemplarisch die Integrationsfähigkeit anhand der Finalisierungsphase und dem ITIL TM Framework [6] beschrieben.

Ist das hybride Modell in den Kontext eines professionellen IT-Betriebes nach dem ITIL-Framework eingebettet, so berücksichtigt das Modell die Prozesse „Change Management“ und „Release & Deployment Management" der Service Transition aus ITIL. Mit Hilfe des „Change Managements“ wird sichergestellt, dass Änderungen kontrolliert ablaufen. Das bedeutet, dass Bewertung, Priorisierung, Planung, Tests, Implementierung und Dokumentation der Änderungen durchgeführt werden. Initiiert wird jeder Change-Prozess über einen Request for Change (RFC) unabhängig von der geplanten Änderung eines Softwaresystems.

Das Ziel des „Release and Deployment Management“ wiederum ist es, Releases erfolgreich in die geplante Zielumgebung zu integrieren, ohne dass unvorhergesehene Auswirkungen auf bestehende Services auftreten. Die Tätigkeiten des „Release und Deployment Management“ finden in der Finalisierungsphase statt. Dies ist in Abbildung 2 durch die Release-Phase gekennzeichnet.

ITIL TM selbst trifft keine Aussage darüber, zu welchem Zeitpunkt der RFC zu erstellen ist. Je früher dies geschieht, umso mehr Zeit steht dem Change-Manager vor dem gewünschten Release-Termin für die geplanten Prüfungen zur Verfügung. In der Regel geschieht dies während der Entwicklungsphase. In Abbildung 2 ist dieser Zeitraum durch die Punkte tC1 und tC2 dargestellt.

Faktisch bedeutet dies, dass je eher sich in der Entwicklungsphase das konkrete Produkt abzeichnet und damit der endgültige Termin für die Auslieferung auf dem Produktionssystem feststeht, desto eher kann der IT-Betrieb die notwendigen Planungen und Tests vornehmen. Werden während der Entwicklungsphase bereits Prototypen in die Zielumgebung ausgeliefert, so ist der Change-Manager in der Lage, die Auswirkungen auf umliegende Systeme abzuschätzen und kann frühzeitig mit Last- und Performancetests beginnen. Der administrative Aufwand des Erstellens eines RFC entfällt für die Bereitstellung eines Prototypen. 

Die Autoren haben das hybride Modell in mehreren Fallbeispielen praktisch und theoretisch erfolgreich getestet. Sie konnten nachweisen, dass dieses Vorgehen auch in der Wartungs- bzw. Weiterentwicklungsphase einer Software angewendet werden kann.

Ein grundsätzlicher Vorteil ergibt sich aus dem regelmäßigen Kundenfeedback innerhalb der Entwicklungsphase, weil so Abweichungen von der ursprünglichen Planung zeitig aufgedeckt werden und ein angemessenes Einlenken ermöglichen.

Die anfängliche Gesamtplanung erlaubt Aufwandsschätzungen, die Festpreisvereinbarungen mit dem Auftraggeber ermöglichen.

Aber ein Modell funktioniert immer nur so gut wie die Menschen, die damit arbeiten. Auch hier zeigt dieses Vorgehen seine Stärke: Sanft und in kleinen Schritten lässt sich die hybride Softwareentwicklung in bestehende Prozesse implementieren – also keine Big Bang Theory!

[1] Balzert, H. (1998): Lehrbuch der Software-Technik. Band II, Heidelberg: Spektrum Akademischer Verlag

[2] Beck, K., Andres, C. (2010): Extreme programming explained. Second Edition. Boston, MA: Addison-Wesley

[3] Berg, B., Knott, P., Sandhaus, G. (2014): Hybride Softwareentwicklung, Springer-Vieweg

[4] Hansen, H. R./Neumann, G.; Bea, F. X./Friedl, B./Schweitzer, M. (Hrsg.) (2005): Wirtschaftsinformatik 1: Grundlagen und Anwendungen. 9. Auflage. Stuttgart: UTB

[5] Schwaber, K. (2004): Agile Project Management with Scrum. Redmond: Microsoft Press

[6] van Bon, J.; de Jong, A. (2009): IT Service Management basierend auf ITIL V3. Das Taschenbuch. Van Haren Publishing, Zaltbommel -> S. 15

Gregor Sandhaus ist seit 2008 Professor für Wirtschaftsinformatik an der Hochschule für Oekonomie & Management (FOM) in Essen. 
E-Mail

Philip Knott, DEVK Versicherung, Köl, Stabsfunktion bei zentralen Themen und der strategischen Weiterentwicklung der IT.

Björn Berg, Vorstand der numetris AG mit den Verantwortungsbereichen Software-Entwicklung, Messdienstleistung und Marketing, Essen

© Springer-Verlag Berlin Heidelberg 2015