Projekt-Management in der Praxis (Teil 21)

Die Software-Entwicklungsprozesse müssen von Anfang an synchronisiert werden

16.10.1992

Die Definition der Vorgaben, an denen sich die Entwicklungsarbeiten orientieren, erfolgt in vielen Projekten im Vorlauf zur Etablierung des notwendigen Wissensstands und Konsenses unter den Beteiligten. Gefordert ist eine Synchronisierung dieser Entwicklungsprozesse.

Die klassischen Vorgehensmodelle für die Entwicklung von Software wie Phasenmodell und Wasserfallmodell bestechen durch die stringente Abfolge der einzelnen Entwicklungsschritte: Zuerst werden Ziele definiert, daraus sodann die Anforderungen abgeleitet, danach werden diese realisiert; schließlich wird die so entstandene Software getestet und eingeführt. Solche Vorgehensmodelle erscheinen plausibel und erfüllen offenbar sowohl den Bedarf von Auftraggebern wie den von Entwicklern, sollen sie doch jene stabilen Grundlagen liefern, mit denen der Entwicklungsprozeß zu planen und zu steuern ist.

Vorgaben mußten mehrmals geändert worden

Für die meisten Softwareprojekte, die wir untersuchten, war ein Vorgehen nach dem Phasenschema geplant. Aber nur bei wenigen ließen sich die vorgesehene Phasenaufteilung und die Termin- wie Budgetplanung auch einhalten. Dies gilt nicht nur für Projekte, bei denen man das Vorgehensmodell ohnehin nicht so ernst nahm und sich deshalb nicht sonderlich um exakten Nachvollzug bemühte, sondern auch für Vorhaben, die strikt nach dem Phasenschema geplant waren und wo Ziele und Anforderungen genau definiert vorlagen. Auch dort mußten Vorgaben für die Realisierung im Verlauf des Entwicklungsprozesses mehrmals geändert und umgeschrieben, bereits realisierte Teile der Software verändert oder neu entwickelt werden. Die Phasen ließen sich kaum voneinander trennen, sondern überlappten sich mehr oder weniger stark, Zeitpläne wie Budgets wurden - zum Teil erheblich - überzogen.

Dabei war die Gefahr, daß Projektplanung und Projektwirklichkeit auseinanderklafften, um so größer, je neuartiger und innovativer die Gestaltungsaufgabe war. Aber auch dort, wo man für die Durchführung des Entwicklungsvorhabens auf langjährige Erfahrungen zurückgreifen konnte und damit gute Voraussetzungen für ein systematisches phasenbezogenes Projektmanagement gegeben erschienen, wich man häufig vom gesteckten Rahmen ab. Daß Projekte aus dem Ruder liefen, liegt demnach nicht allein an mangelnder Kompetenz und Erfahrung. Vielmehr führen tieferliegende strukturelle Ursachen dazu, daß Projektplanung und Projektdurchführung bei solchen Vorhaben, die nach dem orthodoxen Phasenmodell angelegt wurden, auseinander traten.

Im Phasenmodell ist implizit eine Reihe von Prämissen enthalten, die erfüllt sein müssen, wenn man nach diesem Schema vorgehen will:

1. Es ist möglich, zu Beginn des eigentlichen Entwicklungsprozesses stabile unveränderliche Vorgaben für die Softwaregestaltung zu definieren.

2. Dies setzt voraus: Das für die Definition der Vorgaben erforderliche Wissen ist bei Auftraggebern, Anwendern und Entwicklern gleich zu Beginn des Prozesses vorhanden.

3. Alle involvierten Stellen tragen die Vorgaben in einem Konsens, und Auftraggeber, Anwender und Entwickler sind sich einig darüber, was entwickelt werden soll.

Das Phasenmodell geht davon aus, daß Wissensakquisition, Konsensbildung und Vorgabendefinition im Vorlauf zum eigentlichen Entwicklungsprozeß erfolgen. Bei der technischen Entwicklung geht es dann im wesentlichen nur noch darum, die in der Anfangsphase festgelegten Anforderungen an das System möglichst deckungsgleich umzusetzen (vgl. Abbilddung 1).

Diese Prämissen waren nun allerdings in vielen der von uns

untersuchten Projekte nicht erfüllt. So fehlte den Beteiligten häufig das erforderliche Wissen. Auftraggeber ebenso wie künftige Anwender waren sich über die Möglichkeiten und Auswirkungen der neuen Software nur ansatzweise im klaren, viele hatten sich darüber auch kaum Gedanken gemacht. Dies war nicht nur dort der Fall, wo das Vorhaben auf die Initiative des DV-Bereichs zurückging, sondern auch dort, wo der Anstoß dazu aus dem Anwenderbereich selbst kam.

Diese Wissenslücken konnten die Entwickler durch Informationen nicht vollständig auffüllen. Bei der Beschreibung von dem, was neue Software kann, abstrahierten diese notwendigerweise von der zu unterstützenden Arbeitsaufgabe. Der Abgleich des Leistungspotentials von Software mit der Anwendungssituation stellte in den meisten Fällen ein kompliziertes Unterfangen mit zahlreichen, zum Teil nicht eindeutig fixierbaren Variablen dar und ließ sich nur allmählich im Zuge der Konkretisierung der softwaretechnischen Lösung vollziehen.

Ähnlich lückenhaft oder verschwommen war vielfach der Wissensstand der Entwickler über das Anwendungsgebiet der Software. Selbst mit Hilfe detaillierter Ist-Analysen waren hier Wissensdefizite.

Hinter solchen Mängeln stand nicht unbedingt mangelnde Kompetenz oder fehlendes Interesse, sondern eher die grundsätzliche Schwierigkeit, die vielfältigen und flexiblen Möglichkeiten der Gestaltung von Software auf komplexe Arbeitsaufgaben anzuwenden, die sich zudem im Zuge des Technikeinsatzes verändern konnten. Immer wieder zeigte sich, daß dies durch logische, antizipatorische Analysen nur begrenzt möglich war. Welche Gestaltungsprobleme, aber auch welche Gestaltungspotentiale neue Software für ein bestimmtes Anwendungsfeld beinhaltete, ließ sich meist erst im Zuge ihrer zunehmenden Ausarbeitung Schritt für Schritt konkretisieren und ausdifferenzieren. Erst auf diese Weise entstand eine anschauliche und damit tragfähige Basis für konstruktive Diskussionen zwischen Entwicklern und Anwendern.

In den meisten Projekten erfolgten also Wissensakquisition und die darauf beruhende Vorgabendefinition nicht im Vorlauf zum technischen Entwicklungsprozeß, wie vom Phasenmodell unterstellt, sondern sie hinkten de facto hinterher. Das erforderliche Wissen für die Definition von Gestaltungsvorgaben eignete man sich erst im Lauf des Arbeitsprozesses an, und zwar um so leichter, je mehr man sich mit bereits entwickelten Systemteilen auseinandersetzen konnte. Die Kurve der Wissensakquisition war demnach gekennzeichnet durch erhebliche Defizite in den Frühphasen des Prozesses und durch eine Wissensfülle in den späteren Phasen, die unter Umständen aber überschüssig war, weil das gewonnene Wissen am Ende des Prozesses nicht mehr in die Software-Gestaltung eingehen konnte (vgl. Abbild 2, oberes Diagramm).

Wenig tragfähig erwies sich in vielen Projekten der Konsens, auf dem die Definition der Anforderungen anfangs zu beruhen schien. Dort, wo er zu Beginn des Projekts auf der Basis lückenhafter Informationen zustandegekommen war, haben ihn die Beteiligten im Verlauf des Vorhabens mit der zunehmenden Konkretisierung der Gestaltungsansätze und dem damit verbundenen Wissen häufig in Frage gestellt. Konsensbildung erfolgte dann nicht so sehr im Vorfeld der Software-Entwicklung als vielmehr im Zuge ihrer Realisierung. Überspitzt ausgedruckt: Der Konsens war bei Einführung der Software eher geringer als zu Beginn des Projekts. So verlief denn auch die Kurve der Konsensbildung umgekehrt zur Kurve der Wissensakquisition (vgl. Abbildung 2, oberes Diagramm).

Dieser Verlauf von Wissensakquisition und Konsensbildung bewirkte, daß die Entwicklungsarbeiten nur selten geradlinig auf eine Vorgabe ausgerichtet waren, die dann am Projektende noch allgemeine Zustimmung fand. Statt dessen handelte es sich um einen vielfach gebrochenen Prozeß, dessen Gestaltungsvorgaben sich laufend veränderten; man konnte sich bei der Entwicklung nur an den jeweils letzten Stand der Vorgaben halten, was bedeuten konnte, daß ein Teil dieser Arbeiten mit dem nächsten Anforderungswechsel praktisch hinfällig wurde und wieder von vorne angefangen werden mußte. Nach mehreren derartigen Kurskorrekturen war dann schließlich der Zeit- und Kostendruck so groß, daß der technische Entwicklungsprozeß von dem Prozeß der, Umdefinierung der Vorgaben abgekoppelt und zu Ende geführt wurde (vgl. Abbildung 2, unteres Diagramm).

Diese Nachbesserungen wirkten sich auf das Ergebnis unterschiedlich aus. Teilweise entsprachen die korrigierten Vorgaben den Nutzungserfordernissen besser, teilweise kam es aber auch zu einer Überfrachtung der Softwarelösung. Da man keine klare, anschauliche Vorstellung von der Anwendung der zukünftigen Technik in der eigenen Arbeit hatte, glaubte man, auf Nummer Sicher gehen zu müssen, indem man möglichst viel forderte, ohne sich allerdings der Nachteile, die damit verbunden sein konnten - etwa kompliziertere Nutzung - bewußt zu sein. Auf der einen Seite also die Chance, im Lauf des Entwicklungsprozesses angeeignetes Wissen und erworbene Erfahrungen einzubringen und für die Lösung fruchtbar zu machen, auf der anderen Seite die Gefahr, durch endlose Veränderung der Vorgaben die große Linie zu verlieren.

Insgesamt war erkennbar, daß die Vorstellung, Entwicklungsprozesse ließen sich mit Hilfedes Phasenschemas stringent planen und steuern, sich eher als Hypothek erwies und vielfach teuer damit zu bezahlen war, daß es praktisch nicht möglich war, die im Projektverlauf gewonnenen Erkenntnisse in den technischen Gestaltungsprozeß einzubringen. Dort, wo der Entwicklungsprozeß hingegen offen blieb für die Prozesse der Wissensaneignung und der Konsensbildung, kam es durch die laufende Korrektur der Vorgaben zu Brüchen, der Ablauf war nur noch sehr schwer steuerbar, und erhebliche Zeitverzögerungen stellten sich ein. In vielen Projekten, die wir untersuchten, verliefen also Wissensakquisition, Konsensbildung und Vorgabendefinition asynchron zum technischen Entwicklungsprozeß, auch wenn dieses Problem nicht überall gleich stark zutage trat. Bei internen Projekten für den eigenen Bedarf trat es offener auf als bei Fremdaufträgen etwa von Softwarehäusern, bei denen der asynchrone Verlauf durch den formalisierten Projektrahmen eher verdeckt blieb - allerdings meist mit nachteiligen Folgen für die Gestaltung der Software.

Das Problem kann nur gelöst werden, wenn es gelingt, die Prozesse der Wissensakquisition, der Konsensbildung und der Vorgabendefinition mit dem technischen Gestaltungsprozeß zu verzahnen. Das sich im Projektverlauf akkumulierende Wissen muß in den Entwicklungsprozeß eingehen können, so wie dieser seinerseits ständig neue Anhaltspunkte und Erkenntnisse liefert; in einem gemeinsamen Lernprozeß müssen die Beteiligten die Anforderungen neu definieren und zugleich einen Konsens über sie erreichen.

Eine Optimierung der Verfahren der Projektabwicklung kann folglich nicht allein an der Verfeinerung technizistischer Methoden etwa des Requirement engineering oder des Tooleinsatzes ansetzen und damit letztlich doch an der Fiktion eines Vorlaufs von Wissen, Konsens und Anforderungsdefinition festhalten; vielmehr kommt es darauf an, Konzepte zur Synchronisierung des Entwicklungsgeschehens zu erarbeiten, die es erlauben, die Wissensaneignung und Konsensbildung während des Prozesses zu fördern und die so gewonnenen Erkenntnisse für die Softwarelösung fruchtbar zu machen.

Eine solche Synchronisierung, die expliziter Teil des Projekt-Managements ist, gewinnt in dem Maß an Bedeutung, als versucht wird, inkrementelle Verfahren der Software-Entwicklung anzuwenden, die wesentlich darauf abzielen, daß im Arbeitsprozeß gesammelte Erfahrungen in die weitere Entwicklung eingehen. Dies setzt eine Synchronisierung von Wissensakquisition, Konsensbildung und Entwicklungsgeschehen voraus.

Ansatzpunkte für ein solches Vorgehen, sind unter anderem:

- eine Gestaltung des Entwicklungsprozesses, durch die möglichst frühzeitig anschauliche, auf die Anwendungssituation unmittelbar beziehbare Gestaltungsentwürfe zur Diskussion gestellt werden;

- ein institutionalisiertes Forum wie Gremien, Projektgruppen etc. für solche Diskussionen;

- Spielregeln, durch die sichergestellt wird, daß ein kontinuierlicher Bezug zwischen Wissensakquisition, Konsensbildung und technischer Entwicklung stattfindet;

- Zeitressourcen, die allen Beteiligten ermöglichen, an den Prozessen der Wissensakquisition, der Konsensbildung und der Anforderungsdefinition

teilzunehmen.

Diese Synchronisierung ist in der Praxis in sehr unterschiedlicher Weise zu erreichen. In unserer Untersuchung war eine ganze Reihe von Ansätzen zu erkennen, die jedoch eher informell, quasi naturwüchsig und

ungeplant zustande gekommen waren und deshalb meist recht instabil erschienen. Um sie dauerhaft abzusichern und als anerkannte Vorgehensmethode einzuführen, müßten sie stärker als bisher auch in der formalen Projektorganisation und den Verfahren des Projektmanagements verankert sein, vor allem in größeren Projekten. Synchronisation wäre damit fest in das Projekt-Management eingebunden. Durch feste Feedback-Schleifen soll die technische Entwicklung jeweils mit dem stufenweise akkumulierten Wissen und der daraus sich ergebenden Anforderungsdefinition synchronisiert werden (vgl. Abbildung 3). Dabei geht es nicht allein darum, die nutzungsgerechte Umsetzung von fest definierten Vorgaben in Teilen von Softwaresystemen zu beurteilen, sondern auch, diese Planungen selbst laufend zu verändern und dem neuen Wissens- und Erfahrungsstand anzupassen.

*Professor Friedrich Weltz ist Geschäftsführer der Sozialiwissenschaftlichen Projektgruppe, München, und Honorarprofessor an der Universität Göttingen; Rolf Ortmann ist Mitarbeiter der Sozialwissenschaftlichen Projektgruppe, München

Serie: Das Softwareprojekt

In dieser Serie wird über eine Untersuchung berichtet, die die Autoren in und an 46 Softwareprojekten durchführten. Sie war soziologischer Teil des interdisziplinären Projekts zur Arbeitssituation in der Softwareentwicklung, das vom Bundesministerium für Forschung und Technologie (BMFT) im Rahmen des Programms "Arbeit und Technik" gefördert wurde. Das Teilprojekt "Informatik" lag in den Händen von Professor Dr. Wolfgang Hesse, ferner von Udo Bittner und Johannes Schnath, Universität Marburg; das Teilprojekt "Arbeitspsychologie" wurde bearbeitet von Professor Dr. Michael Frese sowie Felix C. Brodbeck, Torsten Heinbockel, Sabine Sonnentag und Wolfgang Stolte, Universität Gießen.

Die Studie erscheint in Buchform im Herbst 1992 im Campus Verlag unter dem Titel "Das Softwareprojekt - Projekt-Management in der Praxis".