Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

27.03.1992 - 

Projektmanagement in der Praxis (Teil 4)

Die Anforderungsspezifikation: Reduktion von UnbestimmtheitSerie: 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".

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

Rolf Ortmann ist Mitarbeiter der Sozial wissenschaftlichen Projektgruppe, München

Die wichtige Rolle der frühen Phasen der Software-Entwicklung für deren weiteren Verlauf und Ergebnis wird zunehmend erkannt. Die Ergebnisse unserer Untersuchung bestätigen diesen Eindruck nachhaltig. Nicht nur, daß diese "frühen" Phasen in vielen Projekten einen beträchtlichen Anteil am gesamten Zeitaufwand erforderten, sie gestalteten sieh zugleich auch unerwartet schwierig.

In der retrospektiven Darstellung, die uns Projektverantwortliche von Projektverläufen gaben, nahm durchweg der Abschnitt bis zur eigentlichen Realisierung den weitaus größten Raum ein. Besonders in großen "anspruchsvollen" Projekten hatte dieser Projektabschnitt häufig wesentlich länger gedauert, als man es erwartet und geplant hatte, erwies sich als schwerer steuerbar und vor allem offensichtlich recht konfliktträchtig.

Ein Schlüsselproblem, auf das sich die Schilderungen dabei vor allem bezogen, war die Erarbeitung der Anforderungsspezifikationen, aus denen die Vorgaben für die Gestaltung der Software abgeleitet werden konnten. Verbindliche, also allgemein akzeptierte Anforderungsspezifikationen waren der archimedische Punkt für die Lösung der in Folge auftretenden Probleme. Diesen zu etablieren, erwies sich in den meisten Projekten als - für alle Beteiligten überraschend - mühsam.

Es fing bei dem Problem an, kompetenten Input von allen involvierten Stellen zu erhalten und endete mit der Aufgabe, eine gemeinsame Basis für die häufig recht divergierenden Standpunkte und Interessen zu finden. Zwar trafen wir Projekte, in denen der Prozeß der Anforderungsspezifikation offensichtlich reibungslos verlaufen war, etwa wo mehr oder minder spezifische Vorgaben vom Auftraggeber dem Software-Entwickler übermittelt und mit nur gelegentlicher Abstimmung im weiteren Verlauf von diesem dann abgearbeitet wurden (wobei im Augenblick offen bleiben muß, wie lange die Erarbeitung der Anforderungsspezifikationen beim Auftraggeber gedauert hatte und wie zulänglich sich diese dann später erwiesen).

Anders allerdings verliefen Projekte, in denen eine Auseinandersetzung über die Definition der Anforderungen zwischen Auftraggebern, späteren Anwendern und Software-Entwicklern durch die Entstehung, die Organisation und institutionelle Stellung des Projektes im Unternehmen faktisch vorgegeben war. Hier gestaltete sich die Erarbeitung der Anforderungsspezifikation fast durchweg als sehr aufwendig. Es wurde von zahlreichen Sitzungen, Besprechungen, Entwürfen und Gegenentwürfen berichtet, die erforderlich waren, bis man sich auf eine Vorlage geeinigt hatte, mit der alle beteiligten Stellen einverstanden waren.

Die Zeit, die diese Sitzungen, ihre Organisation, Vorbereitung und Nachbereitung erforderte, addierte sich zu einem Volumen, das schließlich einen durchaus ins Gewicht fallenden Anteil am Gesamtaufwand ausmachte - allerdings nur zu einem Teil in der offiziellen Aufwandsberechnung auftauchte. Der Weg zu dieser Einigung war meist langwierig: Eine Vorlage wurde erarbeitet, in Frage gestellt, führte zu einer Überarbeitung, wenn nicht gar zu einer weitgehend neuen Vorlage, diese wurde wiederum diskutiert, mit erneuten Änderungsauflagen und so fort. Nicht selten wurde auch die "endgültige" Vorlage dann im weiteren Projektverlauf noch mehrmals in Frage gestellt, modifiziert und erweitert.

In den meisten Projekten wurden die Verzögerungen, die schließlich zu der Überschreitung der ursprünglich veranschlagten Projektlaufzeit geführt hatten, nicht zuletzt auf den langwierigen Prozeß der Definition der Anforderungen zurückgeführt.

Aufwendig gestaltete sich die Formulierung "stabiler" Anforderungsspezifikationen vor allem dort, wo zahlreiche und häufig sehr unterschiedliche betriebliche (teilweise auch außerbetriebliche) Stellen einzubeziehen waren und wo die Notwendigkeit bestand, einen Konsens zwischen diesen Stellen herzustellen. So wurden in einem Projekt, in dem ein integriertes administratives DV-System von der DV-Abteilung eines Großunternehmens entwickelt wurde, insgesamt 26 Ausschüsse, Projektgruppen, Fachberatungsteams etc. gebildet, in denen etwa 30 verschiedene Stellen vertreten waren.

Die Erarbeitung eines verbindlichen Satzes von Anforderungsspezifikationen war in diesen Projekten nicht allein deshalb so mühsam, weil hier technische und fachliche Aspekte von hoher Komplexität berücksichtigt werden mußten, sondern weil sich im Laufe des Entwicklungsprozesses die Rahmenbedingungen und Vorgaben ständig änderten: durch den Stand der Technik (neue Hard- und Softwareangebote, Veränderungen im Preisgefüge etc. ), durch inner- oder außerbetriebliche Gegebenheiten (Organisationsstruktur, Geschäftspolitik, Marktanforderungen etc.) und vor allem durch die Eigendynamik des Entwicklungsprozesses selbst .

Termini in großer Bandbreite interpretierbar

Mit der zunehmenden analytischen Durchdringung des Gestaltungsproblems und der Konkretisierung einzelner Gestaltungsansätze ergaben sich häufig neue Ansatzpunkte und Anforderungen. Bei einem dreijährigen Entwicklungsprojekt ergaben sich allein aus einer ersten Präsentation des Systementwurfes 600 Anforderungsveränderungen .

Hinzu kommt die Abstraktheit des Gestaltungsgegenstandes. Hier besteht ein wesentlicher Unterschied der Software-Entwicklung zu anderen Entwicklungsprozessen. Das Produkt, sein Leistungsprofil, die Anforderung, die gestellt werden, sind nur in abstrakten Termini beschreibbar. Diese sind meist in einer großen Bandbreite interpretierbar, haben unter Umständen für einzelne Beteiligte gar keine oder sogar eine falsche Bedeutung. Natürlich stellt sich dieses Problem allen Entwicklungsprozessen in ihren Frühphasen.

Anders als im Software-Entwicklungsprozeß allerdings besteht jedoch meist die Möglichkeit, relativ rasch diese Abstraktheit - etwa durch Skizzen, Vorentwürfe etc. - zu reduzieren und damit auch den Spielraum des Mißverstehens, unterschiedlicher Interpretationen etc. zu verringern. Die häufigen Klagen sowohl der Entwickler wie der Anwender, die andere Seite sei unfähig, sich verständlich beziehungsweise präzise auszudrücken, sind unter anderem sicher auch auf solche Übersetzungsschwierigkeiten zurückzuführen .

Diese Abstraktheit des Gestaltungsgegenstandes erschwerte den Austausch der notwendigen Informationen zwischen Software-Entwicklern und Anwendern und zwar in beiden Richtungen. Nicht nur war es für die Anwender schwierig, den besonderen Charakter der Anforderung, die an die Technik gestellt werden, dem Software-Entwickler zu vermitteln, auch umgekehrt fiel es schwer, das Leistungspotential der Technik in vollem Maße anschaulich und nachvollziehbar darzustellen. Vor allem dürfte die Abstraktheit dieses Gestaltungsgegenstandes die systematische Ermittlung aller Interdependenzen, Besonderheiten und Abhängigkeiten, die bei der jeweiligen Anwendung der Technik zu berücksichtigen sind,

erschwert und damit auch zu der systematischen Unterschätzung der Komplexität der Entwicklungsaufgabe beigetragen haben.

Bisweilen wurde versucht, dieser Abstraktheit quasi auf einen Schlag beizukommen: etwa durch die Diskussion sehr konkreter Gestaltungsfragen, die Einzelanwendungen betrafen, etwa den Aufbau einzelner Masken. Man versuchte damit, sozusagen das Pferd vom Schwanz her aufzuzäumen: Durch die Feinstrukturierung des Endproduktes sollten auch die vorgeschalteten Schritte mitgelöst werden. Das Problem der Reduzierung der Abstraktheit war aber so zumeist nicht zu lösen. Letztlich schlugen Grundsatzfragen, deren Klärung man zunächst ausgeklammert hatte, doch immer wieder durch.

Diese Schwierigkeiten stellten sich natürlich um so mehr, je weniger strukturiert und durch eindeutige Regeln vorgegeben die Entwicklungsaufgabe war. Bei solch unstrukturierten Aufgaben stellten sich der Rekonstruktion komplexer Funktionszusammenhänge und der Interdependenzen verschiedener Teilaufgaben und Abläufe besondere Schwierigkeiten. Vor allem war die Bedeutung einzelner Funktionsabläufe häufig erst im Zusammenhang der Gesamtaufgabe richtig zu erfassen, eindeutig interpretierbar. Die Vertrautheit mit der Fachaufgabe und den Bedingungen, unter denen sie erfüllt wird, erwies sich hier für den Prozeß ihrer Übersetzung in das technische System als besonders wichtig.

Erschwert wurde damit der Prozeß der Umwandlung von allgemeinen Zielen und Wünschen in präzise, eindeutige Vorgaben für die Software-Entwicklung. So herrschte bisweilen schon Unklarheit oder Uneinigkeit über die Bedeutung einzelner Schritte in diesem Prozeß .

In einem Software-Entwicklungsprojekt wurden in einer Projektgruppe die Anforderungsspezifikationen für einen Teilbereich erarbeitet. Diesen Spezifikationen wurde allerdings innerhalb der Gruppe ein sehr unterschiedlicher Stellenwert zugewiesen. Während der für diesen Teilbereich zuständige Systemanalytiker in ihnen zunächst nur sehr allgemeine Vorgaben sah, die nun im weiteren noch wesentlich genauer zu fixieren seien, betrachtete sein Abteilungsleiter sie bereits als "fertige" Vorlage, die nun zur Kodierung nach außen gegeben werden könne. Ein Vertreter des Anwenderbereiches hinwiederum nahm hier etwa eine Mittelposition ein.

Indiz für diese Schwierigkeiten war allein schon die Vielzahl der Begriffe, die unter Umständen Gleiches oder Ähnliches oder auch jeweils Unterschiedliches bezeichnen konnten: etwa Fein- und Grobgliederung, Anforderungsspezifikation etc.

Diese Unklarheiten und Mißverständnisse schlugen sich dann im Ablauf der Anforderungsspezifizierung nieder: Häufige Korrekturschleifen, durch die scheinbar erzieltes Einverständnis - etwa dokumentiert in einem Pflichtenheft - wieder in Frage gestellt wurde; Unterschätzung der Komplexität des Vorhabens, auch bei durchaus erfahrenen Software-Entwicklern; Mißverständnisse und Unklarheiten wurden mitgeschleppt und treten erst spät bei der detaillierten technischen Umsetzung zutage.

"Ich habe mir die Aufgabe der Konzeptentwicklung weniger nervig vorgestellt. Manchmal kommt mir das vor wie eine Schraube ohne Ende. Ich unterhalte mich mit jemandem, ich glaube, ich habe alle Informationen bekommen, die ich brauche, und baue mein Konzept. Beim nächsten Gespräch kommt der dann plötzlich mit einer Information, die mein ganzes Konzept umschmeißt."

Das Bild einer Echternacher Springprozession

Auf diesem Hintergrund erscheint die Diskontinuität vieler Software-Entwicklungsprozesse, insbesondere auch der Bestimmung der Anforderungen erklärbar. Bei der Auseinandersetzung mit scheinbaren Detailfragen wird man auf Grundsatzfragen zurückverwiesen, diese erscheinen in neuem Licht, erfordern neue Klärungsprozesse. Statt eines kontinuierlichen Fortschreitens, einer zunehmenden Konkretisierung ergibt sich das Bild einer Echternacher Springprozession, drei Schritte vorwärts, zwei Schritte zurück: Aus dem jeweils erreichten Stand der Spezifizierung und Konkretisierung ergeben sich Impulse, die nicht nach vorne, sondern nach rückwärts verweisen, auf Sünden früherer Stadien, in denen Unbestimmtheiten nicht beseitigt wurden.

Dieser Ablauf der Software-Entwicklung stellt sich dar nicht nur als Prozeß zunehmender Verfeinerung der Spezifikationen, sondern gleichzeitig auch des Reduzierens von Unbestimmtheit, was wie dasselbe scheinen mag, aber nicht ist. Logisch erschiene zunächst der Abbau der Unbestimmtheit als Voraussetzung für die zunehmende Verfeinerung der Spezifikationen erforderlich. In der Praxis allerdings, vor allem dort, wo innovative Gestaltungsaufgaben anstehen, läuft es häufig umgekehrt: Die Reduzierung der Unbestimmtheit erfolgt erst im Zuge der Feinspezifikation. Erst bei der detaillierten Auseinandersetzung mit konkreten Leistungsmerkmalen wird die allgemeine Unbestimmtheit über das Leistungsprofil beseitigt. Als Ausweg aus diesen Schwierigkeiten könnte sich Prototyping anbieten: das Angebot von mehr oder weniger ausgearbeiteten Lösungsalternativen zur Erprobung durch die Anwender schon in einem relativ frühen Projektstadium.

Für das Problem der Erarbeitung verbindlicher Anforderungsspezifikationen erschien Prototyping allerdings vielen unserer Gesprächspartner als kaum praktikabel: Die Ausarbeitung präsentabler und erprobbarer Lösungsangebote in diesem Stadium sei zu aufwendig, vor allem aber wären die eigentlichen Probleme bei einer "fiktiven" Erprobung nicht zu identifizieren.

"Prototyping ist sehr aufwendig, weil ich ja ausgearbeitete Versionen anbieten muß. Ich glaube, daß eine solche technische Ausführung am Bildschirm nicht der Weg zum Ziel ist. Das Spiel mit den Funktionen, die Aufmerksamkeit auf die Bildschirmoberfläche lenkt den Anwender von den eigentlichen fachlichen Problemen ab, von deren intellektueller Durchdringung. Das ist nur bei begrenzten Anwendungen sinnvoll und möglich, nicht aber bei komplexen Problemen." "Die Schwierigkeit ist, daß man über Ideen so schwer kommunizieren kann, erst wenn eine Idee ausgereift ist, hat Prototyping einen Sinn." "Es gibt eine Art Prototyping, von der halte ich wenig." Da sagt man: Wir entwickeln zuerst die wichtigsten Dinge und probieren die aus. Die Feinheiten machen wir dann später. Meine Erfahrung ist aber gerade, daß diese "Feinheiten" noch 85 Prozent der Arbeit erfordern, und das Programm sieht dann am Schluß aus, als sei es 15 Jahre alt.

Grundsätzlich hat auch das Prototyping mit dem Problem der anfänglichen Abstraktheit und Unbestimmtheit des Gestaltungsgegenstandes sich auseinanderzusetzen. Überspitzt ausgedrückt: Prototyping perfektioniert das Verfahren, Unbestimmtheit durch detaillierte Spezifikation zu beseitigen. Es verschiebt sozusagen den Moment der Wahrheit nach vorne ändert aber an dem grundsätzlichen Dilemma wenig.

(wird fortgesetzt)