Der vorliegende Beitrag soll zunaechst die Schwaechen von herkoemmlichen Verfahren der Durchfuehrung von DV-Grossprojekten charakterisieren. Anschliessend wird ein Entwicklungsprojekt beschrieben, bei dem das V-Modell zum Einsatz gekommen ist.

Wir realisieren seit Ende 1989 Softwareprojekte nach dem V- Modell, wobei dieses in jeweils unterschiedliche Versionen zur Anwendung kommt (Version 1.3, Version 2.0 und die Version vom Februar 1991). Projekte im militaerischen Umfeld setzen wir auch nach dem Nato-Standard AQAP-13 um, dessen Forderungen das V-Modell erfuellt.

Projektabschnitte werden schlecht definiert

Die oft beschworene Softwarekrise hat vielerlei Ursachen - eine liegt zweifellos in den typischen Fehlern beim Projekt-Management. Zur Projektinitialisierung gehoert unter anderem die Erarbeitung eines Projekthandbuchs und eines -plans. Hier beginnt bereits das Dilemma, und zwar in Form einer grossen Begriffsverwirrung. Oft sind fuer die Beteiligten Begriffe nicht definiert oder es ist nicht klar geregelt, wer wann welche Produkte mit welchem Inhalt herzustellen hat.

Meistens wird dann der Firmenstandard bemueht. Der befindet sich allerdings haeufig in Korrektur und wird zudem in der Regel sehr unterschiedlich ausgelegt. Die Folge: Von Projekt zu Projekt entstehen Dokumente unterschiedlicher Auspraegung. Somit sind weder die Dokumente noch die darauf aufbauenden Projekte vergleichbar.

In der Regel werden Zeitpunkte (Meilensteine) festgelegt, zu denen eine bestimmte Phase abgeschlossen sein sollte. Die Diskussion darueber, welche Produkte mit welchem Inhalt zu einem bestimmten Meilenstein fertiggestellt sein muessen, unterbleibt oder wird immer wieder vertagt. Dadurch gestaltet sich jede Kontrolle schwierig. Soll der zu erwartende Restaufwand prognostiziert werden, so ist eher Hellseherei als ingenieursmaessige Arbeit an der Tagesordnung. Die wirtschaftliche Situation von Software-Entwicklungsprojekten stellt sich ohne standardisiertes Vorgehen in der Regel folgendermassen dar:

- Die erste Phase des Projekts (Initialisierung, Anforderungsanalyse, Design) verlaeuft hervorragend, denn noch ist nicht klar, was alles fehlt.

- In der mittleren Projektphase blendet der schnelle Erfolg die Verantwortlichen: Die Entwicklung ist zu 90 Prozent abgeschlossen, alles verlaeuft scheinbar planmaessig.

- In der Endphase kommt dann die 90-Prozent-Regel zum Tragen: In die verbleibenden zehn Prozent muss rund die Haelfte des geplanten Gesamtaufwandes und entsprechend viel Zeit investiert werden.

Die von der Entwicklung durchzufuehrenden Aktivitaeten orientierten sich bislang in der Regel am Wasserfallmodell von Boehm. Wie angedeutet, ist aber meistens nicht klar, welche Produkte mit welcher Struktur zu erzeugen sind.

Dies fuehrt dazu, dass erst unmittelbar bei Beginn oder, viel schlimmer noch, zum Abschluss einer Aktivitaet mit dem Auftraggeber geklaert wird, wie die Produkte inhaltlich zu gestalten sind. Auch Integrationsschritte und -aufwaende werden nicht selten viel zu spaet geplant.

Oft dokumentieren die Entwickler ihre Entscheidung ueber den Einsatz von Methoden und Tools nicht. Schliesslich gilt ja als bekannt, dass das Projekt nach den Methoden A, B, C und mit den Tools X, Y, Z realisiert wird. Die zu erzeugenden Dokumente orientieren sich daher fast ausschliesslich an der angewandten Methode und an den Moeglichkeiten der eingesetzten Tools - nicht aber an dem, was sachlich notwendig waere.

Mehr noch als die Projektverantwortlichen leiden die Software- Entwickler unter einem mangelhaften oder unklar geregelten Informationsfluss. Diese Situation hat in der Vergangenheit dazu gefuehrt, dass sich jeder - mit unterschiedlichem Erfolg - seine eigenen Informationskanaele schaffte.

Obwohl wahrscheinlich jeder Software-Entwickler Qualitaet erzeugen will, ist es nicht selbstverstaendlich, dass auch eine durchgeplante, projektbegleitende Qualitaetssicherung stattfindet. Bisweilen reduziert sich die offizielle Qualitaetssicherungs- Aktivitaet in zivilen Projekten auf eine Art Ausgangskontrolle. Die Entwickler haben fuer die von ihnen zu erarbeitenden Module und Programme oft selbst die Pruefprozeduren geschrieben und die Nachweispruefungen durchgefuehrt. In diesen Faellen hatte die Qualitaetssicherung eher eine administrative Aufgabe wahrzunehmen.

Auch das fehlende Konfigurations-Management sorgt bei vielen DV- Projekten fuer Aerger. Hauptaufgaben sind die Versionskontrolle und das Aenderungs-Management. Die Versionskontrolle stuetzt sich nicht selten ausschliesslich auf Tools, die innerhalb der Entwicklungsumgebung eingesetzt werden (zum Beispiel SCCS und Make unter Unix). Eine Festlegung des Produktflusses fehlt in der Regel ebenso wie die Vergabe von Zugriffsberechtigungen zu bestimmten Produkten in bestimmten Zustaenden.

Das Aenderungs-Management wird oft erst nach schlechten Erfahrungen eingefuehrt. Unternehmen erkennen, dass es unumgaenglich ist, Verfahren festzulegen, wie Fehler behoben oder Aenderungen nachvollziehbar in die installierte Software integriert werden koennen. Fehlendes oder zu spaet installiertes Konfigurations- Management ist eine der haeufigsten Ursachen fuer die Kostenexplosion bei der Softwarewartung. Moegen diese Feststellungen auch in dem einen oder anderen Punkt etwas ueberzogen wirken, so wird doch niemand, der in einem Software-Grossprojekt mitgewirkt hat, aehnliche Erfahrungen leugnen. Wird nun durch die Anwendung des Vorgehensmodells jedes Entwicklungsprojekt einfacher, ueberschaubarer und erfolgreicher?

Leider duerfte sich dieser Wunschtraum kaum erfuellen, aber das V- Modell bietet immerhin eine strukturierte Hilfe, um den gewuenschten Zielen in puncto Qualitaet, Termintreue und Kosten naeher zu kommen. Der eigentliche Vorteil liegt darin, dass das Zusammenwirken von Projekt-Management (PM), Software-Entwicklung (SWE), Qualitaetssicherung (QS) und Konfigurations-Management (KM) grundsaetzlich geregelt ist.

Nachdem in den 70er Jahren strukturierte Methoden (Structured Analysis, Structured Design etc.) entstanden und in den 80ern auch die unterstuetzenden Tools verfuegbar waren, entstand eine CASE- Euphorie. Softwareprojekte, so hoffte man, wuerden effizienter und transparenter durchfuehrbar sein. Diese Erwartungen haben sich aus heutiger Sicht nicht erfuellt. Einigkeit besteht aber darin, dass der Einsatz von Standards (Betriebssystem, Datenbank, Netzsoftware etc.) in Softwareprojekten zumindest risikomindernd wirkt. Ein entscheidender Schritt in die Richtung eines effizienteren Softwareprojekt-Managements ist mit der Festlegung auf ein Standardvorgehens-Modell (V-Modell) erfolgt.

Detailabstimmung mit dem Auftraggeber

Das V-Modell, das bei dem hier als Beispiel angefuehrten zivilen Projekt zum Einsatz kam, wurde vom Auftragnehmer zu Beginn des Projekts beim Auftragnehmer und Auftraggeber eingefuehrt. Neben der Informierung aller Projektbeteiligten und der Festlegung einer entsprechenden Organisation mit den Submodellen PM, SWE, QS und KM sind das Tailoring des Projekthandbuchs und die Aufstellung des Projektplans die wichtigsten Aufgaben waehrend der Initialisierungsphase.

Im Handbuch fuehrten wir jede bevorstehende Teilaktivitaet auf und stimmten sie mit dem Auftraggeber ab, angefangen von der Projektinitialisierung ueber die SWE-, QS- und KM-Aktivitaeten bis hin zum Abschlussbericht. Dabei wurde im Detail festgelegt, welche Produkte nach welchen Handbuchbestimmungen, Methoden und Tools zu erzeugen sind. Diese Detailabstimmung mit dem Auftraggeber war nicht einfach zu erzielen und kostete Zeit. Sie hat sich aber im weiteren Projektverlauf ausgezahlt, denn in der Folge liess sich jederzeit relativ zuverlaessig nachpruefen, in welchem Zustand sich das Projekt befand. Zu jedem Zeitpunkt war bekannt, welche Aktivitaeten noch durchzufuehren und welche Produkte zu erzeugen waren.

Der Aufwand fuer die Initialisierungsphase eines Projekts nach dem V-Modell ist deutlich hoeher als der einer konventionellen Projektabwicklung. Die Einfuehrung der vier Submodelle mit streng getrennten Rollen verursacht von Beginn an Kosten, die bei anderen Projekten in dieser Phase nicht anfallen. Diese Kosten werden aber in der Realisierungs- und Wartungsphase eingespart, da die nach dem V-Modell erzeugten Produkte leicht wiederzuverwenden sind.

Die Version 2.0 des V-Modells sieht insgesamt zehn SWE- Hauptaktivitaeten vor. Diese Phasen sind im ersten Teil dieser Serie detailliert vorgestellt worden. Beim Tailoring wurde im vorliegenden Projekt eine der zehn SWE-Hauptaktivitaeten gestrichen, da die dort zu erzeugenden Produkte innerhalb einer anderen Hauptaktivitaet erstellt wurden. Die Erlaeuterungen zu Produkten im V-Modell sowie die Festlegungen im Projekthandbuch erlauben den Software-Entwicklern, nur die dort vereinbarten Produkte zu erzeugen. Damit entfallen die oft so laestigen Diskussionen ueber Struktur und Inhalt von Dokumenten.

Problematisch: Anwendung von Methoden und V-Modell

Der Einsatz des V-Modells in der Software-Entwicklung ist nur dann sinnvoll, wenn auch bekannte und bewaehrte Methoden und die entsprechenden Tools in Verbindung mit ihm genutzt werden koennen. Das vorliegende Projekt wurde nach den Methoden Structured Analysis (SA), Structured Design (SD) und Entity Relationship Modelling (ERM) entwickelt. Mit diesen Methoden hatten wir bereits vor der Einfuehrung des V-Modells Erfahrungen gesammelt. Ihre Anwendung in Verbindung mit dem V-Modell fuehrte allerdings zu Problemen.

Diese haben folgende Ursachen:

- Die Structured Analysis sieht eine strenge Top-down-Verfeinerung vor, waehrend beim V-Modell die Verfeinerung der Anforderungen mittelbar ueber die Entwurfskomponenten der uebergeordneten Ebene erfolgt.

- Die Structured Analysis fordert Prozessspezifikationen (P-Specs, Minispecs) nur auf der untersten Verfeinerungsstufe (atomare Ebene). Das Vorgehensmodell sieht dagegen die Spezifikation von Funktionen auf jeder Ebene (System, DV, Softwarekonfigurations- Einheit (SWKE)) vor.

- Die Anwendung dieser Methoden ergibt einen Strukturbruch beim Uebergang von SA nach SD, wobei das waehrend der strukturierten Analyse erstellte Data-Dictionary die Verbindung zum Design bildet. Dagegen geht das V-Modell auf jeder Ebene von einem Strukturbruch mit dem Uebergang von der Analyse zum Entwurf aus.

Zur Loesung der Probleme ist es notwendig, auf der System- und der DV-Ebene jeweils ein eigenstaendiges SA-Modell zu erzeugen. Im technischen Tailoring vor Beginn jeder SWE-Hauptaktivitaet muss festgelegt werden, wie die jeweils anstehenden Produkte zu erzeugen sind. Dabei definieren die Entwickler, welche Teile von Dokumenten durch ein CASE-Tool erstellt werden. Es ist vielleicht unnoetig, darauf hinzuweisen, dass genuegend Know-how ueber die einzusetzenden Methoden und Tools, aber auch ueber die Produktmuster des V-Modells vorhanden sein muss.

Der Informationsfluss ist ein bei der Software-Entwicklung entscheidender Aspekt. Er wird durch die Anwendung des V-Modells wesentlich verbessert. Grundsaetzlich regelt dieses den gesamten waehrend der Entwicklung notwendigen Informationsfluss zwischen den einzelnen Submodellen. Besondere Festschreibungen sind darueber hinaus in den einzelnen Management-Dokumenten niedergelegt. Ein sehr wichtiger Gesichtspunkt ist dabei die relativ kurze Einarbeitungszeit neuer Mitarbeiter, die problemlos auf abgestimmte Dokumente zugreifen koennen.

Die Qualitaetssicherung wird durch den Einsatz des V-Modells deutlich aufgewertet. Sie erfolgt projektbegleitend, wobei die konstruktiven und analytischen QS-Methoden bereits zu Beginn des Projekts festgelegt und mit dem Auftraggeber abgestimmt werden. Breiten Raum nahm auch im vorliegenden Projekt die Diskussion ueber die Kritikalitaetseinstufung der einzelnen Produkte ein.

Die Kritikalitaetseinstufung macht dann Sinn, wenn in den einzelnen Stufen deutlich unterschiedliche QS-Massnahmen zum Einsatz kommen. Im hier besprochenen Fall werden beispielsweise Funktionen der Kritikalitaet "hoch" mit White-box-Test und Code- Inspection geprueft, waehrend Funktionen der Kritikalitaet "niedrig" lediglich mit einem Black-box-Test geprueft werden. Auch hier ist fuer den Erfolg der Entwickler und QS-Mitarbeiter die Akzeptanz des QS-Plans entscheidend. Er schreibt bereits in fruehen Projektphasen klar fest, wie zukuenftige Module zu entwickeln und zu pruefen sind.

Fuer ein erfolgreiches Konfigurations-Management (KM) ist die im V-Modell vorgeschlagene Rollentrennung unerlaesslich. Das heisst: Der KM-Verantwortliche ist im Projekt ausschliesslich fuer diesen Bereich zustaendig. Das KM verwaltet alle im Projekt erzeugten Produkte. Im KM-Plan ist festgelegt, welche Produkte (Dokumente, Software, Hardware) der Versionskontrolle unterliegen und welche lediglich archiviert werden.

Mit Hilfe der Versionskontrolle ist das KM jederzeit in der Lage, Auskunft ueber den Zustand von Produkten (geplant, in Bearbeitung, vorgelegt, akzeptiert) zu geben. Nach anfaenglichen Reibungsverlusten begreifen die Projektmitarbeiter das KM als Dienstleister, da der Produktfluss von den Entwicklern zur Qualitaetssicherung und zu den Kunden und umgekehrt ausschliesslich ueber das KM laeuft. Damit werden die Entwickler weitgehend von organisatorischen Ablaeufen ferngehalten. Die Erfahrung lehrt, dass der Produktfluss funktioniert, wenn er, wie im KM-Plan vorgegeben, eingehalten wird. Dagegen gibt es immer dann Probleme, wenn aus meist kurzsichtigen Ueberlegungen von den festgelegten Vorgaben abgewichen wird.

Fuer die Softwarepflege sowie fuer Aenderungsmassnahmen ist der zweite Bestandteil des KM, ein geregeltes Aenderungs-Management, unumgaenglich. Dabei wird eine Liste ueber den Aenderungsstatus gefuehrt, mit der jederzeit Auskunft ueber den grundsaetzlichen Stand von geplanten Aenderungen erteilt werden kann.

Mit der Anwendung des V-Modells, so laesst sich abschliessend bilanzieren, haben wir bisher ueberwiegend gute Erfahrungen gemacht. Daher werden wir es auch bei zukuenftigen zivilen und militaerischen Projekten einsetzen.

*Hermann Becker ist bei der Deutschen Systemtechnik (DST) GmbH in Kiel fuer ein Software-Grossprojekt verantwortlich, das nach dem V- Modell 2.0 entwickelt wird.

Abb: Der in der Structured Analysis gaengigen Top-down-Verfeinerung steht die mittelbare Verfeinerung ueber Entwurfskomponenten im V- Modell gegenueber.