Einführung
Dieses Prinzip erläutert, warum der iterative Ansatz für die Softwareentwicklung so wertvoll ist. In
einem iterativen Prozess können Änderungen und Feedback problemlos im Projekt untergebracht, Risiken
früh minimiert und Prozessanpassungen dynamisch vorgenommen werden.
|
|
Vorteile
|
-
Verminderung von Risiken in einem frühen Stadium
-
höhere Vorhersagbarkeit im ganzen Projekt
-
Vertrauen der Stakeholder
|
Muster
|
-
Berücksichtigung von Feedback durch Bereitstellung von Produkten in jeder Iteration
-
Pläne in einem iterativem Prozess anpassen
-
Änderungen behandeln und verwalten
-
Bedeutende technische, wirtschaftliche und programmbezogene Risiken in einem frühen
Stadium angehen
|
Antimuster
|
-
Gesamten Lebenszyklus im Detail planen, Abweichungen vom Plan verfolgen (die zu
einem Scheitern des Projekts beitragen können)
-
Status in den ersten zwei Dritteln des Projekts auf der Basis von Prüfungen der
Spezifikationen anstatt den Status von Testergebnissen und Demonstrationen
funktionierender Software bewerten.
|
|
Beschreibung
Dieses Prinzip baut auf mehreren Grundsätzen auf. Der erste Grundsatz lautet wie folgt: Wir müssen einen
Wertzuwachs liefern, um frühes und kontinuierliches Feedback zu ermöglichen.. Hierfür wird das Projekt in eine
Reihe von Iterationen eingeteilt. In jeder Iteration führen wir einige Aufgaben in den Bereichen Anforderungen, Design,
Implementierung und Test aus und erzeugen damit ein Liefergegenstand, der der endgültigen Lösung jeweils einen Schritt
näher kommt. Auf diese Weise können wir den Benutzern und anderen Stakeholdern die Anwendung demonstrieren oder zur
direkten Verwendung bereitstellen und geben ihnen damit die Möglichkeit, schnelles Feedback zu unserem Fortschritt zu
geben. Bewegen wir uns in die richtige Richtung? Sind die Stakeholder mit dem, was wir bisher produziert haben,
zufrieden? Müssen wir die bisher implementierten Features ändern? Und schließlich, welche weiteren Features müssen
implementiert werden, um den Wert des Produkts zu steigern? Wenn wir diese Fragen zufriedenstellend beantworten können,
gewinnen die Stakeholder mehr Vertrauen darin, dass das System, das wir entwickeln, auch ihre Anforderungen
berücksichtigt. Außerdem laufen wir weniger Gefahr, es mit unserem Engineering zu übertreiben oder Funktionalität
hinzuzufügen, die für den Endbenutzer nicht von Nutzen ist.
Der zweite Grundsatz ist der, Demonstrationen und Feedback zu nutzen, um unsere Pläne anzupassen. Anstatt auf
die Bewertung von Spezifikationen, z. B. Anforderungsspezifikationen, Designmodelle oder Pläne, zu vertrauen, müssen
wir bewerten, wie gut der bis dahin entwickelte Code wirklich funktioniert. Das bedeutet, wir müssen den Stakeholdern
Testergebnisse und Demonstrationen funktionierenden Codes liefern, damit diese unseren Fortschritt beurteilen können.
Auf diese Weise geben wir ein Bild von uns ab, zeigen, welche Fortschritte das Team macht, und erkennen, ob wir
Kurskorrekturen vornehmen müssen, um das Projekt erfolgreich durchzuführen. Diese Informationen können anschließend
verwendet werden, um den Gesamtplan für das Projekt zu überarbeiten und detaillierte Pläne für die nächste Iteration zu
entwickeln.
Der dritte Grundsatz ist, Änderungen willkommen zu heißen und zu verwalten. Die heutigen Anwendungen sind zu
komplex, um Anforderungen, Design, Implementierung und Test perfekt im ersten Durchgang zu gestalten. Die effektivsten
Methoden für die Anwendungsentwicklung heißen die Zwangsläufigkeit von Änderungen willkommen. Durch frühes und
kontinuierliches Feedback lernen wir, wie wir die Anwendung verbessern müssen, und der iterative Ansatz gibt uns die
Möglichkeit, diese Änderungen inkrementell zu implementieren. Für die Verwaltung dieser Änderungen müssen Prozesse und
Tools bereit stehen, damit wir Änderungen effektiv verwalten können, ohne die Kreativität zu behindern.
Der vierte Grundsatz dieses Prinzips ist die Erfordernis, Schlüsselrisiken so früh wie möglich im Lebenszyklus zu
eliminieren. Dies wird in der folgenden Abbildung veranschaulicht. Wie müssen die wichtigsten technischen,
wirtschaftlichen und programmatischen Risiken so früh wie möglich angehen, anstatt die Risikolösung bis zum Projektende
hinauszuschieben. Dazu müssen wir die Risiken, denen wir gegenüber stehen, ständig bewerten und die vorrangigen Risiken
in der jeweils nächsten Iteration angehen. In erfolgreichen Projekten werden Stakeholder an den früheren Iterationen,
d. h. an der Entwicklung der Vision und übergeordneter Anforderungen, zu denen das Architekturdesign, die
Implementierung und Tests gehören, beteiligt, um technische Risiken zu mindern. Außerdem müssen Informationen
zusammengestellt werden, die für die Entscheidungen bezüglich der wichtigsten wiederverwendbaren Assets und des
Einsatzes kommerzieller Software (COTS, Commercial-of-the-Shelf) herangezogen werden.
Risikominimierungsprofile für Wasserfallentwicklung und iterative Entwicklung.
Ein übergeordnetes Ziel bei der iterativen Entwicklung ist eine frühere Risikominimierung. Hierfür werden die
vorrangigen Risiken in jeder Iteration analysiert, priorisiert und in Angriff genommen (siehe Unterstützendes Material: Iterative Entwicklung). Zusätzliche Anleitung zur
Organisation des Entwicklungszyklus mit Iterationen finden Sie in den Abschnitten Konzept:
Iteration und Konzept:
Phase.
|