Inkrementelle Systementwicklung (AN)

Beschreibung

Wie in Teil 1: "Grundlagen des V-Modells " bereits erläutert wurde, stellt das V-Modell für unterschiedliche Projekttypen jeweils speziell angepasste Projektdurchführungsstrategien zur Verfügung. Die Projektdurchführungsstrategie Inkrementelle Systementwicklung (AN) beschreibt eine entsprechende Vorgehensweise für den Projekttyp Systementwicklungsprojekt eines Auftragnehmers.

Die Inkrementelle Systementwicklung (AN) basiert auf der Grundidee, dass die Anwenderanforderungen bereits zu Beginn des Projekts vom Auftraggeber relativ fest abgesteckt worden sind. Nachträgliche Änderungen an den vertraglich festgelegten Anforderungen sind lediglich über das Problem- und Änderungsmanagement sowie über den Entscheidungspunkt Änderungsplan festgelegt möglich und werden über Zusatzverträge geregelt. Der Auftragnehmer entwirft, realisiert und liefert das System dann in einzelnen Stufen, welche auch Inkrement genannt werden. Jede dieser Stufen wird einzeln vom Auftraggeber abgenommen.

Änderungen durch den Auftraggeber innerhalb einer Projektstufe sind bei dieser Projektdurchführungsstrategie nicht vorgesehen, sondern werden über das Änderungsmanagement frühestens im folgenden Inkrement berücksichtigt. Für den Auftraggeber hat diese Vorgehensweise den Vorteil, dass er bereits frühzeitig in den Besitz einer Vorstufe des Systems gelangt, die bereits die wichtigsten Grundfunktionalitäten des Systems realisiert.

Die Projektdurchführungsstrategie Inkrementelle Systementwicklung (AN) eignet sich vor allem, wenn die Anforderungen an das System als relativ stabil eingeschätzt werden und technologische Risiken eher gering sind. Es können Fertigprodukte eingesetzt werden, der Hauptanteil des Systems wird jedoch im Rahmen des Projekts erstellt.

Ablauf

Abbildung 28: Projektdurchführungsstrategie Inkrementelle Systementwicklung (AN)

Die Entscheidungspunkte der inkrementellen Systementwicklung sowie der Ablauf eines Entwicklungszyklus sind in Abbildung 28 dargestellt. Im Folgenden wird anhand der durchlaufenen Entscheidungspunkte der Ablauf eines Inkrements zur Systementwicklung beschrieben:

1. Vom Auftraggeber erhält der Auftragnehmer eine Ausschreibung mit den Anforderungen an das zu entwickelnde System. Nach Prüfung der Anforderungen entscheidet der Auftragnehmer, ob ein Angebot für diese Ausschreibung in wirtschaftlicher und strategischer Hinsicht sinnvoll ist. Abhängig von der Entscheidung erfolgt die interne Genehmigung des Projekts (Projekt genehmigt ).
2. Wurde das Projekt genehmigt, erstellt der Auftragnehmer ein Angebot zu den Anforderungen. Nach Prüfung des Angebots wird entschieden, ob das Angebot an den Auftraggeber übergeben wird (Angebot abgegeben).
3. Akzeptiert der Auftraggeber das Angebot, wird ein Vertrag zwischen Auftraggeber und Auftragnehmer geschlossen, in dem die Anforderungen an das System, sowie die Rahmenbedingungen des Projekts schriftlich fixiert sind (Projekt beauftragt).
4. Nach erfolgter Beauftragung muss der Auftragnehmer nun das Projekt genauer charakterisieren. Hierzu sind unter anderem das Projekthandbuch und QS-Handbuch zu erstellen. Im Entscheidungspunkt Projekt definiert wird untersucht, ob diese Produkte dem Projekt angemessen sind.
5. Im Projekt werden die Anforderungen unter Beteiligung des Auftraggebers evaluiert und ein erster Grobentwurf des Systems erstellt. Anforderungen und Grobentwurf werden in der Gesamtsystemspezifikation (Pflichtenheft) dokumentiert. Das Pflichtenheft ist Grundlage für die weitere Entwicklung des Systems. Am Entscheidungspunkt System spezifiziert wird abhängig von der Qualität der Ergebnisse entschieden, ob das Projekt fortgeführt wird, Nachbesserungen erfolgen müssen, oder das Projekt abgebrochen werden muss.
6. Ausgehend vom Grobentwurf werden Architekturen für das System sowie alle identifizierten Unterstützungssysteme entworfen. In den Architekturen werden Systemelemente bis auf der Ebene der HW- und SW-Einheiten identifiziert. Die Anforderungen werden den Systemelementen zugeordnet und spezifiziert. Der Entwicklungsprozess und die Prüfstrategie werden festgelegt. Zum Entscheidungspunkt System entworfen wird abhängig von der Qualität der Ergebnisse entschieden, ob das Projekt fortgeführt wird, Nachbesserungen erfolgen müssen, oder ob das Projekt abgebrochen werden muss.
7. Für den Feinentwurf werden die Architekturen der HW- bzw. SW-Einheiten zu Komponenten und Modulen verfeinert. Die Anforderungen werden den SW- und HW-Elementen zugeordnet. Der Entwicklungsprozess und die Prüfstrategie werden festgelegt. Zum Entscheidungspunkt Feinentwurf abgeschlossen wird abhängig von der Qualität der Ergebnisse entschieden, ob das Projekt fortgeführt wird, Nachbesserungen erfolgen müssen, oder das Projekt abgebrochen werden muss.
8. Alle im Feinentwurf identifizierten HW- und SW-Elemente werden entsprechend den Anforderungen realisiert und einer Prüfung unterzogen. Zum Entscheidungspunkt Systemelemente realisiert wird abhängig von der Qualität der Ergebnisse entschieden, ob das Projekt fortgeführt wird, Nachbesserungen erfolgen müssen, oder ob das Projekt abgebrochen werden muss.
9. Alle realisierten HW- und SW-Elemente werden zu Systemelementen und schließlich zum System beziehungsweise zu einem Unterstützungssystem zusammengefügt. Die integrierten Elemente werden einer Prüfung unterzogen. Zum Entscheidungspunkt System integriert wird abhängig von der Qualität der Ergebnisse entschieden, ob das Projekt fortgeführt wird, Nachbesserungen erfolgen müssen, oder ob das Projekt abgebrochen werden muss.
10. Das zu liefernde System wird entsprechend den Anforderungen zu einer Lieferung zusammengestellt. Eine Lieferung umfasst das System selbst, sowie gegebenenfalls Unterstützungssysteme und Dokumentation. Zum Entscheidungspunkt Lieferung durchgeführt wird anhand der Ergebnisse entschieden, ob die Lieferung an den Auftraggeber zur Abnahme übergeben wird.
11. Die Lieferung wird vom Auftraggeber hinsichtlich der Erfüllung der Anforderungen geprüft. Zum Entscheidungspunkt Abnahme erfolgt wird vom Auftraggeber anhand der Ergebnisse entschieden, ob eine Abnahmeerklärung erstellt wird oder ob Nachbesserungen durch den Auftragnehmer notwendig sind. Sollten Nachbesserungen notwendig oder ein Teil der Anforderungen noch nicht realisiert sein, wird diese Projektdurchführungsstrategie bei Punkt 12 fortgesetzt, ansonsten kann das Projekt bei Punkt 13 abgeschlossen werden.
12. Zur Planung eines neuen Inkrements werden in Zusammenarbeit mit dem Auftraggeber alle offenen Änderungsanträge der Änderungsstatusliste geprüft. Zum Entscheidungspunkt Änderungsplan festgelegt wird anhand der Liste entschieden, welche Änderungsanforderungen in das neue Inkrement übernommen und welche vorerst zurückgestellt werden. Gegebenenfalls werden Vertragszusätze mit dem Auftraggeber vereinbart. Die Änderungsanforderungen und die offenen Anforderungen der Gesamtsystemspezifikation sind Grundlage für einen neuen Entwicklungszyklus, der bei Punkt 5 dieser Projektdurchführungsstrategie ansetzt.
13. Wurden alle Anforderungen berücksichtigt und gibt es keine offenen Änderungsanträge mehr an, wird entschieden das Projekt abzuschließen. (Projekt abgeschlossen ). Ein Projektabschlussbericht wird erstellt und an den Auftraggeber übergeben.

Werden im Rahmen des Systementwurfs (Punkt 6) externe Einheiten für einen Unterauftrag identifiziert, so ist vom Auftragnehmer ein Teil-Auftraggeber-Projekt durchzuführen. Es werden die Entscheidungspunkte Projekt ausgeschrieben , Projekt beauftragt und Abnahme erfolgt gemäß der Projektdurchführungsstrategie Vergabe und Durchführung von Systementwicklungsprojekten (AG) durchlaufen, sowie Änderungen über den Entscheidungspunkt Änderungsplan festgelegt berücksichtigt. Die Entscheidungspunkte werden also wie in Abbildung 29 dargestellt durchlaufen, die Ergebnisse des Unterauftrags werden anschließend im Punkt 9 dieser Projektdurchführungsstrategie zum System integriert.

Abbildung 29: Vergabe eines Unterauftrags

Auswahlkriterien

Projektgegenstand	Eingebettetes System, HW-System, Komplexes System, SW-System, Systemintegration
Projektrolle	Auftragnehmer, Auftragnehmer und Auftraggeber
Systemlebenszyklusausschnitt	Entwicklung
Fertigprodukte	Nein
Hohe Realisierungsrisiken	Nein