SZ.2 Inkrementelle Entwicklung

  SC.2 Incremental Development

Verknüpfungen mit dem Glossar

Inhalt		SZ.2.1 Ablaufbeschreibung für die Aktivitäten im Submodell SE SZ.2.2 Zusammenspiel mit den übrigen Submodellen       SZ.2.2.1 Zusammenspiel der Submodelle SE und PM       SZ.2.2.2 Zusammenspiel der Submodelle SE und QS       SZ.2.2.3 Zusammenspiel der Submodelle SE und KM SZ.2.3 Kriterien für die Auswahl des Szenarios Verknüpfungen mit der V-Modell Mailingliste

SZ.2.1 Ablaufbeschreibung für die Aktivitäten im Submodell SE

Die inkrementelle Vorgehensweise geht davon aus, daß die Anwenderforderungen in ihren wesentlichen Aspekten vollständig bereits zu Beginn der Entwicklung erfaßt werden können und daß es möglich ist, das gesamte System in verschiedenen Teilabschnitten bzw. Ausbaustufen (im Englischen "increments" oder "builds") zu entwerfen, zu entwickeln, einzuführen und zu nutzen.

Die einzelnen Ausbaustufen erfüllen jeweils einen Teil der gesamten geplanten Funktionalität des Systems. Dabei ist es notwendig, frühzeitig das gesamte System durch die Definition der Systemarchitektur zu entwerfen. Für die Ermöglichung eines inkrementellen Vorgehens werden an die Systemarchitektur besondere Anforderungen gestellt. So müssen Schnittstellen klar definiert sein und einen modularen, schrittweisen Ausbau des Systems ermöglichen

Im weiteren Vorgehen wird dann die Systemarchitektur (im Regelfall nach funktionalen Kriterien) in Teile zerlegt, so daß die einzelnen Ausbaustufen bezüglich Umfang und Reihenfolge der Bearbeitung festgelegt werden können.

Die Vergabe der einzelnen Ausbaustufen als einzelne Verträge ist möglich. Der Endnutzer kann bereits die jeweiligen Ausbaustufen für seine Aufgabenerfüllung einsetzen.

Der Ablauf der SE-Aktivitäten bei einer inkrementellen Entwicklung ist in Abbildung SZ.1 illustriert.

Abbildung SZ.1: Ablauf der SE-Aktivitäten bei einer inkrementellen Entwicklung

Zeitpunkt T 0-Start

Zeitpunkt T 1-First Increment

Für einige der in Aktivität SE1.5 - System fachlich strukturieren identifizierten Bereiche (erste Ausbaustufe) sind die fachlichen Anforderungen zum Teil vollständig (Bereich 1), zum Teil unvollständig (Bereich 2) erstellt.

Die Ergebnisse der Aktivitäten SE1.2 und SE1.5 bilden zusammen die Anwenderforderungen, die zum Zeitpunkt T 1 in einer ersten Version vorliegen

Die Anwenderforderungen müssen so detailliert sein, daß folgende Ziele erreicht werden

• Alle relevanten fachlichen Bereiche müssen möglichst benannt und in ihrem Funktionsumfang gegeneinander abgegrenzt werden. (1)
• Das Zusammenspiel der Bereiche muß für die Projektbeteiligten klar dargestellt sein.
• Es muß klar sein, in welchen (bereichsspezifischen) Stufen das System aufwachsen soll und welche Gesamtfunktionalität im Endausbau abgedeckt werden soll. Dazu müssen Meilensteine (gegebenenfalls als Baseline mit Zeitpunkt und Funktionsumfang) angegeben werden.

Die einzelnen Bereiche werden soweit detailliert und ausgearbeitet, wie es für die erste produktive Systemversion notwendig ist. In späteren Stufen können die einzelnen Bereiche verfeinert und um neue ergänzt werden.

Durch die Berücksichtigung von technischen Lösungen im Rahmen der SE1 - System-Anforderungsanalyse-Aktivitäten entsteht eine fachlich fundierte und ausreichend spezifizierte Vorgabe für die Realisierung der ersten Ausbaustufe durch einen Auftragnehmer. Die Systemarchitektur und die Technischen Anforderungen werden ergänzt und alle weiteren, realisierungsspezifischen Dokumente und Entwicklungsergebnisse erstellt. Nach Abschluß der Realisierung wird die erste Ausbaustufe in die Nutzung übergeleitet

Zeitpunkt T 2 bis T N-1 - Weitere Ausbaustufen

Für die Bestandteile der zweiten Ausbaustufe werden die fachlichen Anforderungen erarbeitet. Dabei können bisher nicht berücksichtigte Bereiche neu beschrieben und bereits vorhandene verfeinert werden. Erste Rückmeldungen aus der Nutzung der ersten Ausbaustufe werden berücksichtigt.

Die damit in einer zweiten Version vorliegenden Anwenderforderungen bilden den Ausgangspunkt für die Verfeinerung und Ergänzung der Systemarchitektur und der Technischen Anforderungen.

Der Realisierer, beispielsweise ein Auftragnehmer, erweitert die bereits produktive Systemversion 1 um die neu hinzugekommenen Teile und integriert sie im Rahmen der Integrationsschritte. Eventuell sind im Rahmen der Integrationsarbeiten auch Änderungen an der Systemversion 1 durchzuführen. Nach Abschluß der Realisierung wird auch die zweite Ausbaustufe in die Nutzung übergeleitet.

Diese Arbeitsschritte werden für jedes Inkrement wiederholt.

Zeitpunkt T N-Conclusion of the System Development

SZ.2.2 Zusammenspiel mit den übrigen Submodellen

SZ.2.2.1 Zusammenspiel der Submodelle SE und PM

Abbildung SZ.2 dargestellt.

Abbildung SZ.2: PM-Zyklus bei einer inkrementellen Entwicklung

Auf der Basis einer groben Beschreibung des Planungshorizonts und der Systemarchitektur muß im Rahmen der Grobplanung die Konzipierung der Inkremente erfolgen. Dies betrifft sowohl die inhaltliche Abgrenzung der Inkremente gegeneinander als auch die zeitliche Planung für die Erstellung der einzelnen Inkremente. Bedingung für die Aufteilung der Systemarchitektur in die einzelnen Realisierungsstufen ist die Modularität der Architektur. Sie muß den schrittweisen Aufwuchs des Systems ermöglichen, ohne bereits fertiggestellte Inkremente grundsätzlich überarbeiten zu müssen. Für jede Ausbaustufe wird im Rahmen der Projektplanung eine Baseline als Basis für die nachfolgende Entwicklung definiert

Die Realisierbarkeitsuntersuchungen auf der technischen Entwicklungsebene liefern wertvolle Informationen für das Risikomanagement. Die Ergebnisse sind Teil der Entscheidungsgrundlage für das Projektmanagement.

Forderungscontrolling wird für alle Ausbaustufen durchlaufen und kann bei Entscheidungsbedarf zu einer Durchführungsentscheidung führen.

SZ.2.2.2 Zusammenspiel der Submodelle SE und QS

SZ.2.2.3 Zusammenspiel der Submodelle SE und KM

SZ.2.3 Kriterien für die Auswahl des Szenarios

Vorteile:

• Frühzeitige Auslieferung eines Basissystems und dadurch frühzeitiger Einsatz eines operablen Systemkerns beim Anwender,
• Priorisierung der Lieferreihenfolge durch den Anwender (evtl. auf der Basis von Erfahrungen mit den ersten ausgelieferten Systemteilen),
• einfacher Austausch von Systemteilen (nämlich den Inkrementen) im Pflege- und Änderungsfall,
• Problemloser Wechsel des Auftragnehmers nach Abschluß der Realisierung eines Inkrements,
• Verfeinerung der Anwenderforderungen im Laufe der Entwicklung (die Anwenderforderungen müssen zu Beginn nicht vollständig vorliegen),
• deutlich kürzere Zyklen bei Änderung von Anwenderforderungen gegenüber konventioneller Entwicklung.

• Änderungen des geplanten Vorgehens beim Systemaufwuchs müssen den jeweiligen Auslieferungsstand berücksichtigen. Durch eine geeignete Modularisierung und die Definition von sauberen Schnittstellen können Probleme nachhaltig vermieden werden.
• Die Notwendigkeit der frühzeitigen Festschreibung des Gesamthorizonts für die gesamte Entwicklungszeit kann bei langen Projektlaufzeiten schwierig sein. Hier kann es sinnvoll sein, mehrere aufeinanderfolgene Projekte zu definieren.

• Separierbarkeit des Systems bei klaren Schnittstellen (modularer Aufbau der Systemarchitektur).
• Die genannten Vor- und Nachteile sind jeweils im Einzelfall zu überprüfen und zu bewerten. Sie dürfen nicht pauschal für alle Projekte als gültig angesehen werden, sondern müssen vor dem Hintergrund der fachlichen und technischen Anforderungen sowie der zu beachtenden Randbedingungen geprüft werden.

Verknüpfungen mit der V-Modell Mailingliste

Verknüpfungen mit dem Glossar

(1) Es ist möglich, daß neue fachliche Bereiche im Laufe der Entwicklung hinzugefügt werden. Dies kann aus vertragsrechtlichen Gründen problematisch sein.

This page online  •  GDPA Online  •  Last Updated 03.Mar.2004 by C. Freericks