Die Anwendung einer Phasenorganisation ist anerkannte Grundlage bei der Abwicklung größerer Projekte aus allen Bereichen. Von der Vielzahl der entwickelten Phasenorganisationen führten die meisten Anwendungen jedoch nicht zu den gewünschten Ergebnissen. Der Beitrag beschreibt ein in der Entwicklungspraxis von kleinen bis großen Softwareprojekten erprobtes Verfahren bei der Siemens AG.

Durch die konsequente Einhaltung einiger Prinzipien lassen sich die häufig bei Phasenorganisationen geschilderten Probleme vermeiden. Die Forderungen sind:

- Ausrichtung am technischen Prozeß;

- Definition unabhängiger Teilprozesse;

- eindeutige Ergebnisdefinition;

- klare Entscheidungsprozeduren;

- strenge Kopplung mit dem Konfigurationsmanagement.

Die Anwendung einer Phasenorganisation (Prozeßorganisation, Prozeß-Technologie, Life-Cycle-Modell) ist anerkannte Grundlage jeder zielgerichteten Projektdurchführung in der Softwareproduktion. Dies gilt von sehr kleinen (1 MA) bis zu sehr großen (100 MA) Projekten, die Ausprägung der Anwendung in ihrer Formalisierung ist jedoch stark unterschiedlich.

Die sach- und sinngerechte Anwendung der hier vorgestellten Phasenorganisation (PhO) gestattet es, die Ursachen der oft zitierten "Softwarekrise" weitgehend zu beseitigen und damit die Softwareproduktion erheblich zu verbessern.

Folgende Ziele werden erreicht:

- Die erstellten Produkte entsprechen den Anforderungen der Auftraggeber und den Erfordernissen der Benutzer.

- Die Produkte werden mit einer angemessenen hohen Qualität ausgeliefert.

- Die Wirtschaftlichkeit des Entwicklungsprozesses ist hoch.

- Die Durchlaufzeit für den Entwicklungsprozeß ist niedrig.

- Alle Aussagen zum Entwicklungsprozeß hinsichtlich Leistung, Qualität, Termin und Kosten sind hinreichend sicher.

- Es besteht laufende Transparenz über Projektstandard, Ziele und Erwartungen.

- Durch Planungssicherheit und Transparenz wird das Vertrauen des Auftraggebers positiv beeinflußt.

Die vorgestellte Phasenorganisation ist durch folgende Charakteristika beschrieben:

- Einteilung des Entwicklungsprozesses vom Anstoß bis zur Betreuung in eine geordnete Folge von Einzelphasen und Prozeßschritten. Dadurch läßt sich der im allgemeinen lange Entwicklungszeitraum in zeitlich überschaubare und damit saubere Einzelschritte auflösen. Das technische und wirtschaftliche Risiko der Entwicklung wird begrenzt.

- Klare Definition der Ergebnisse jeder Phase und jedes Prozeßschritts als logische Zwischenschritte zum Produkt. Ein eindeutiger Entwicklungsprozeß wird vorgezeichnet. Klare Begriffsbestimmungen ermöglichen eine allgemeingültige Sprachregelung und vermeiden Mißverständnisse. Innovative Teile der Entwicklung können von routinemäßigen getrennt werden. Eine projektbegleitende Qualitätssicherung der Zwischenergebnisse und damit eine Sicherung der Qualität des Endproduktes wird möglich. Die Transparenz der Entwicklung vergrößert sich.

- Aufteilung des Entwicklungsprozesses in nebeneinander laufende, aber sorgfältig synchronisierte Teileentwicklungen für das Produkt, seine Dokumentation, das Testsystem und die Planung. Der komplexe Zusammenhang zwischen Produkt, Testsystem und Planung wird in aufeinander abgestimmte Einzelprozesse aufgelöst. Es wird sichergestellt, daß die Erstellung des Produktes, der Dokumentation, des Testsystems und der notwendigen Planungen zu

definierten Zeitpunkten synchronisiert werden.

- Bewußte Entscheidung über den Beginn und den Anschluß einer Phase beziehungsweise eines Prozeßschrittes. Durch die Entscheidung über die Freigabe der Ergebnisse in definierter Verantwortung und Prozedur wird das Verantwortungsbewußtsein aller am Projekt Beteiligter verstärkt. Es entstehen klare Sachzustände und damit auch klare Verhältnisse gegenüber Auftraggebern.

- Systematische Klärung der Produkt- und Projektanforderungen wird durch entsprechende Phasenergebnisse erzwungen. Dadurch läßt sich erreichen, daß das tatsächlich gewünschte Projektergebnis erzielt wird und daß dieses Ergebnis den Erfordernissen des Anwenders entspricht. Die präzise Anforderungsermittlung und Anforderungsanalyse ermöglicht eine frühzeitige Sicherheit der technischen und operativen Planung.

- Betonung der Testaktivitäten und rechtzeitige Vorbereitung jedes Tests. Nur systematische Tests aller Prozeßschritte gewährleisten ein qualitativ hochstehendes Endprodukt.

Die gesamte SW-Phasenorganisation zeigt die Abbildung 1.

Jede SW-PhO muß sich nahtlos in das Gesamtsystem des Managements der SW-Produktion einfügen. Die SW-PhO gibt den logischen Ablauf und damit die zeitliche Segmentierung des Projektes vor. Die Ergebnisse jedes Entwicklungsschrittes, das heißt jeder Phase, werden in Meilenstein-Inhalten festgeschrieben. Um die Komplexität der SW-Entwicklung in den Griff zu bekommen, wird die Entwicklung in parallele Teilprozesse eingeteilt. Der definierte Zustand der Ergebnisse jedes Teilprozesses zu einem Phasenende wird in einer "Baseline" abgestimmt und festgehalten (Abbildung 2).

Die Tätigkeiten der einzelnen Phasen zur Durchführung einer Produktentwicklung werden im folgenden kurz beschrieben. Ausgehend von einer Produktidee, einem Entwicklungsantrag oder einem Planungsauftrag lassen sich die Voraussetzungen für die Entwicklung schaffen. Die Projektziele werden formuliert, erste Aufgabenstellungen des Projektes erarbeitet und erste Planungen hinsichtlich Aufwand und Termin vorgenommen.

Dazu ist es notwendig, die zu lösende Problematik beim Anwender zu erfassen. Nach Abgrenzung und Definition der erwarteten Ergebnisse wird geklärt, welcher Bedarf besteht, welcher Nutzen zu erwarten ist, ob bereits ähnliche Lösungen vorliegen, ob die Wirtschaftlichkeit der Entwicklung gegeben ist und ob die Einbettung der Lösung sinnvoll in bereits vorhandene Systeme möglich erscheint. Auftraggeber, zukünftige Anwender und Entwickler sind zu ermittelt. Die Projektorganisation, insbesondere die Kommunikationswege mit dem Auftraggeber, wird aufgebaut, der Projektleiter ist zu benennen.

Eine Analyse der zu lösenden Probleme soll sodann die vollständigen, fachlichen und leistungsfähigen Anforderungen ("Was" aus Benutzersicht) an das zu erstellende Produkt ermitteln. Dabei wird die technischwissenschaftliche Machbarkeit (System als Black Box) durch den Entwickler vorläufig überprüft. Der nächste Schritt heißt: Lösungsalternativen für das Gesamtsystem erarbeiten, bewerten und entscheiden. Dann folgt der Aufbau einer umfassenden Planung der Anforderungen und der Termine des Projektes sowie die Lösung der Zielkonflikte durch Gewichtung der Anforderungen und gegebenenfalls Änderung der Projektvoraussetzungen.

Aus den Anforderungen werden die fachlichen Lösungswege und die fachlichen Funktionen des Produktes ("Wie" aus fachlicher Sicht) mit den genauen Schnittstellen zu seiner Systemumgebung (unter anderem Benutzer) festgelegt. Lösungsalternativen sind zu beschreiben, zu bewerten und auszuwählen. Spezielle Anforderungen lassen sich durch Realisierbarkeitsuntersuchungen (zum Beispiel Simulation oder Rapid-Prototyping) klären. Die DV-technische Realisierung beginnt durch Aufgliedern des Systems in Teilsysteme und eine erste Festlegung der Systemschnittstellen. Die Systemgemeinschaften werden endgültig beschrieben, für den späteren Test die ersten Zielfestlegungen durchgeführt und zusätzlich die System- und die Prozeßkonventionen festgelegt.

Technische Realisierung wird festgelegt

Die ausgewählte Realisierungsalternative ist nach Aufbau und Verhalten zu beschreiben, die Umsetzung der Funktionsstruktur in die DV-technische Lösung muß durchgeführt werden ("Wie" aus DV-technischer Sicht). Das System mit seinen Subsystemen ist in sinnvoll nicht weiter zu zergliedernde Komponenten zu zerlegen. Diese werden DV-technisch nach Aufbau und Verhalten (Schnittstellen) eindeutig beschrieben. Damit Läßt sich der technische Realisierungsweg der in der Phase "Entwurf" beschriebenen Leistungen festlegen.

Die Systemkomponenten werden spezifiziert und in Code umgesetzt. Sie sind in Komponententests auf syntaktische Richtigkeit und auf funktionale Richtigkeit ihrer Schnittstellen und ihrer lokalen Verarbeitung zu überprüfen.

Die realisierten Komponenten werden zu Subsystemen und dem System "montiert", integriert. Dabei ist das Zusammenspiel der Komponentenschnittstellen im Vergleich zur Design-Spezifikation zu prüfen. Das integrierte System muß sich in einer möglichst dem späteren Einsatz entsprechender Systemumgebung und gemäß den in der Benutzerdokumentation festgehaltenen Funktionen und Leistungen des Systems überprüfen lassen.

Die Einsatzbereitschaft des Systems läßt sich über seine Lebensdauer sicherstellen. Sie enthält die Beseitigung von auftretenden Fehlern sowie die Anpassung an eine geänderte Systemumgebung (zum Beispiel bei Änderungen der Hardware). Die Entwicklung einer Folge-Version fällt nicht in diese Phase, sie wird als eine eigene Entwicklung in einem eigenen Projekt behandelt.

Die SW-PhO unterteilt die Entwicklung eines Produktes als Gesamtprozeß in vier thematisch voneinander getrennte Teilprozesse. Damit wird neben der Einteilung der Entwicklung in logisch und zeitlich abgegrenzte Phasen eine weitere Entwicklung in thematisch getrennte Teilprozesse erreicht und die Übersichtlichkeit und Steuerbarkeit der Entwicklung erhöht.

Beim Produkt-Prozeß gilt es, die Entwicklung des eigentlichen Produktes zu regeln. Dieser Teilprozeß ist unterteilt in die drei Prozeßabschnitte. Aufgabendefinition, technische Realisierung und Betreuung. Der Manual-Prozeß regelt die Erstellung der Benutzerdokumentation und der Zusammenhang der Manualerstellung der Manualinhalte zu den Ergebnissen des Produktprozesses wird festgelegt.

- Test-Prozeß

Im Test-Prozeß erfolgt die schrittweise Entwicklung des Testsystems und der verschiedenen Testaktivitäten. Eine intensive Abstimmung mit dem Produkt-Prozeß ist auch zwischen den Baselines notwendig.

- Planungs-Prozeß

Ziel des Planungs-Prozesses ist es, den Inhalt und die Vorgehensweise bei der Planung des Projektes zu regeln. Der Planungs-Prozeß baut auf den Ergebnissen des Produkt- und Test-Prozesses auf, wobei teilweise Ergebnisse dieser Entwicklungen vorausgenommen werden müssen.

In diesen Teilprozessen entsteht eine Folge von Meilensteinergebnissen (Dokumente), die aufeinander aufbauen und jeweils eine spezifische, definierte informatorische Erweiterung beinhalten. Die Definition dieser Ergebnisse (und damit der intellektuelle Abstand zwischen den Ergebnissen) ist wesentlich durch die Phasenergebnisse und damit die Einteilung der Phasen des Phasenmodells bestimmt.

Die aufeinander aufbauende Folge der Ergebnisse ermöglicht die schrittweise Konkretisierung der Eigenschaften des Produktes die laufende Überprüfung der Realisierung der gewünschten Eigenschaften, sowie die sinnvolle Anwendung von Software-Engineering Maßnahmen. In vielen Fällen ist es sinnvoll, einzelne Entwicklungsdokumente zusammenzufassen oder Teile eines Dokumentes bereits in seinem Vorläufer zu erarbeiten.

Um die vielfältigen Möglichkeiten der modernen Entwurfsmethoden, Implementierungs- und Testmethoden nicht einzuschränken, definiert die SW-PhO die je Phase zu erbringenden Ergebnisse (Meilensteine) nicht jedoch deren Erstellung und die dazu notwendigen Tätigkeiten.

Ein wesentliches Element der SW-PhO ist die vorausschauende - formale - Definition der Meilensteininhalte. Abbildung 3 zeigt die Meilensteine, die jeweilige Fragestellung und das entsprechende Dokument als Phasenabschluß.

Realisierbarkeit ist genau zu analysieren

Der Requirementkatalog ist das Ergebnis der Phase "Studie". Er enthält alle Anforderungen an das zu entwickelnde Produkt und an das Projekt vom Auftraggeber (zukünftiger Anwender). Er wird - unter Verantwortung der Entwicklung - in systematischer und umfassender Klärung zwischen Anwender und Entwicklung aus dem Anforderungskatalog abgeleitet (Problemanalyse). Dabei ist sicherzustellen, daß hinter allen Anforderungen ein tatsächliches Erfordernis steht. Der Inhalt ist wie im Anforderungskatalog eine Beschreibung der "Was soll erreicht werden" - Anforderungen. Darüber hinaus werden folgende Eigenschaften für den Requirementkatalog angestrebt:

- vollständig

- eindeutig

- verständlich (für Entwicklung, Auftraggeber/Anwender)

- überprüfbar

- redundanzfrei

- widerspruchsfrei (soweit hier ermittelbar)

- mit Prioritäten gewichtet.

Die Leistungsbeschreibung legt endgültig und detailliert den für den Anwender zu erbringenden Liefer- und Leistungsumfang auf der Ebene von Funktionen fest, so daß das fertige Produkt in allen Aspekten an ihr überprüft werden kann. Sie ist die zentrale Produktdefinition und muß daher besonders sorgfältig erstellt sein.

Der vollständige fachliche Feinentwurf (fachliche Funktionen, Abläufe Daten) zur Erfüllung der Requirements ist der Hauptinhalt der Leistungsbeschreibung. Klärung und Festlegung der fachlichen Funktionen sind damit abgeschlossen. Durch diesen Schritt läßt sich die Aufgabenstellung (Requirements) in Lösungen (Funktionen) überführen.

Sinn der Benutzerschnittstelle ist es, die Masken- und Listengestaltung, die Bedienerführung sowie das Fehlerbehandlungs-Konzept endgültig zu beschreiben. Als Ergebnis der ersten Verfeinerung des Systementwurfs werden auf der Grundlage festgelegter Designstandards erarbeitet:

- Die Systembasis

- Die Architektur des Systems mit Subsystemen (dies als black boxes)

- Die Schnittstellen innerhalb des Systems

- Die Zuteilung der fachlichen Funktionen zu Subsystemen

- Die logischen Datenströme

- Die Ablauflogik

- Erste Leistungsabschätzungen

Kritische Leistungsanforderungen setzen eine Analyse der Realisierbarkeit voraus, um auf der Basis des detaillierten Systementwurfs (und der eventuell erst jetzt vorliegenden Ergebnisse von Realisierbarkeitsstudien und Prototyping-Versuchen) die Leistungen des Systems zu ermitteln. So ergeben sich exakt prüfbare Angaben zu Leistungsdaten und Qualitätseigenschaften des Produktes.

Realisierungsalternativen für das Gesamtsystem und für Subsysteme sind zu erarbeiten, zu bewerten und auszuwählen.

Mit der Design-Spezifikation rücken die Fragen des Dv-technischen Entwurfs (Design) in den Vordergrund. Nach der Top-Down-Methode läßt sich die ausgewählte Realisierungsalternative detaillieren. Dabei werden folgende Ergebnisse erzielt:

- Endgültige hierarchische Struktur der Komponenten. Diese bleiben selber eine Black Box.

- Als Komponente wird hier die kleinste zur Realisierung vorgesehene Einheit verstanden, zum Beispiel Modul, Makro, Programm oder Prozedur

- Zuteilung der fachlichen (und der DV-technischen) Funktionen auf die Komponenten

- Detaillierte Festlegung der Schnittstellen zwischen den Komponenten

- Festlegung der Datenstruktur, Datenflüsse und Zugriffsmethoden

- Detaillierte Vorgaben für jede Komponente inklusive Leistungsvorgaben, so daß die Realisierung unmittelbar (auch dezentral) möglich ist

- Festlegung der Steuerungsalgorithmen und Aufrufstrukturen (Ablaufstruktur)

- Festlegung der Speicherstruktur

- Festlegung von Synchronisationsmechanismen

- Fehlerbehandlung

- Modulspezifische Realisierungskonventionen

Mit der Design-Spezifikation ist das Produkt hinsichtlich seines DV-technischen Aufbaus und hinsichtlich aller Eigenschaften festgelegt. Damit wird die Design-Spezifikation unter anderem zur Grundlage der Wartungsdokumentation. Alle technischen Entscheidungen des Designs beeinflussen die Ausprägung der Qualitätsmerkmale des Produktes entscheidend.

Aus den Vorgaben und Informationen der Design-Spezifikation ist je Komponente eine Komponentenspezifikation als Fortsetzung der technischen Beschreibung auf unterster Ebene zu erstellen, Sie enthält alle Festlegungen und die Beschreibung des Ablaufs in der Komponente.

Die Komponentenspezifikation läßt sich durch Übertragung in die Programmiersprache oder Realisierung mittels Generatoren, in die codierte Komponente umsetzen.

Nach dem erfolgreichen Komponententest liegt die getestete Komponente vor, mit der Komponentenspezifikation, in die die Änderungen aufgrund Tests übernommen wurden, dem Sourcecode mit Inline-Dokumentation, dem Übersetzungsprotokoll sowie dem Testbericht.

Der Test ist gegen die Komponentenspezifikation vorzunehmen, soweit Teile der Benutzeroberfläche oder abgeschlossene Funktionen betroffen sind, auch gegen die entsprechenden Aussagen in der Leistungsbeschreibung und - falls schon vorhanden - gegen die Benutzerdokumentation. Die freigegebenen Komponenten werden dem Konfigurationsmanagement (Projektbibliothek) übergeben, das sie der Integration und dem Systemtest zur Verfügung stellt.

Das Produkt hat erfolgreich den Systemstest bestanden. Das Gesamtprodukt wird in allen Produktteilen (Code, Daten, Manuale) im Systemtest gegen die Leistungsbeschreibung und auf innere Konsistenz hin überprüft.

Häufig ist während oder nach dem Systemtest noch eine Meß- und Optimierungsphase angesagt. Sie dient dazu, das funktional getestete Produkt hinsichtlich seiner Verbrauchseigenschaften für Zeit (Antwortzeit, Durchsatz) und Ressourcen (Arbeitsspeicher, Peripheriespeicher) zu optimieren.

Test komplexer Software bleibt ein Zentralproblem

Das integrierte und getestete Produkt besteht aus allen Komponenten, den Manualen, den Bindeprotokollen, dem Systemtestbericht, eventuell dem Testsystem, der Freigabenotiz mit aktuellen Statusinformationen, die nicht in den Manualen enthalten sind, sowie der Liste der Einschränkungen. Das eingeführte Produkt liegt nach der Abnahme (gegebenenfalls Piloteinsatz) durch den Anwender vor. Gegenüber dem abnahmereifen Produkt sind die Fehlermeldungen aus der Abnahme-Phase erfaßt und eventuell bearbeitet worden.

Die Entwicklung des Testsystems und die Durchführung der Tests nimmt in der SW-PhO einen besonderen Stellenwert ein. Trotz der großen Fortschritte des Software-Engineering ist der Test komplexer Softwareprogramme ein zentrales Problem geblieben. In größeren Entwicklungen werden bis zu 50 Prozent der Gesamtaufwendungen eines Softwareprojektes für die Gesamtheit der Testaktivitäten aufgewendet. Testsysteme sind daher wie "richtige" Software zu behandeln und sie unterliegen den gleichen Software-Engineering-Maßnahmen wie die eingentliche Produktentwicklung. Das bedeutet:

- Top-Down-Entwurf des Testsystems, eingebettet in den und abgeleitet aus dem Phasenablauf der Produktentwicklung .

- Detaillierte Planung der Testvorbereitung und Testdurchführung, damit nicht Problemen der Projektabwicklung (zum Beispiel Terminverzug) auf Kosten des Tests Rechnung getragen wird.

- Überprüfung des Testsystems und der Testdurchführung mit den Methoden der Qualitätssicherung.

Der Test ist in Einzelschritte mit definiertem Testinhalt aufgeteilt. Die Schritte sind so aufeinander abgestimmt, daß der Aufwand für den Test möglichst gering wird. Dabei wird schrittweise von der Komponente bis zum einsatzreifen Produkt gegen die entsprechenden Entwurfsdokumente getestet. Abbildung 4 zeigt den Zusammenhang.

(wird fortgesetzt)