next up previous contents
Next: 5.2 Ansätze Up: 5. Softwareprozeß-Verbesserung Previous: 5. Softwareprozeß-Verbesserung

Unterabschnitte

5.1 Einordnung und Ziele

5.1.1 Warum ist die Softwareproduktion so schlecht?

Verschiedene Leute in der Softwaretechnik-Forschung vertreten unterschiedliche Ansichten darüber, warum wir nicht besser Software produzieren können als wir es heute tun. Hier sind die wichtigsten ihrer Theorien:

../Dilbert/d940210.gif

Anforderungen unklar: Einige, beispielsweise Tom DeMarco, sehen es als das Grundübel an, daß wir meistens nicht genau genug wissen, welches System wir eigentlich bauen sollten; die Anforderungen sind zu ungenau oder (seltener) falsch festgestellt worden.
Wirkungsweise: Ungenaue Anforderungen müssen während des Projektablaufs präzisiert werden und führen zuvor meist zu Mißverständnissen und Fehlern. Falsche Anforderungen haben entweder den gleichen Effekt oder führen am Schluß zu Systemen, die geringen Nutzen haben.

Entwurf schlecht: Andere, zum Beispiel David Parnas, halten unsere mangelhafte Fähigkeit zum Finden guter Entwürfe für das größte Problem. Damit ist vor allem die Zerlegung von Systemen in Einzelteile mit möglichst geringen Wechselwirkungen beim Konstruktionsprozeß und bei Änderungen an Anforderungen oder Realisierungsentscheidungen gemeint.
Wirkungsweise: Ein schlechter Entwurf führt zu einer Systemzerlegung in Teile, die viele und komplizierte Wechselwirkungen miteinander haben. Das führt schon bei der planmäßigen Herstellung der Software, erst recht aber bei nachträglichen Änderungen an ihrem Aufbau zu einem sehr hohen Kommunikationsbedarf zwischen den Herstellern der Einzelteile, der ab einer gewissen Systemgröße den Konstruktionsprozeß allmählich ins Chaos stürzt; kleine Ursachen entfalten übermäßig große Wirkungen.

Werkzeugunterstützung gering: Wieder andere mit eher technokratischer Sichtweise sehen als Hauptproblem an, daß in der Softwareherstellung zuviel mit der Hand gearbeitet wird, was auch maschinell erledigt oder zumindest unterstützt werden könnte.
Wirkungsweise: Schwache Werkzeugunterstützung führt vor allem zu drei Effekten. Erstens kostet die Beschaffung und Verwaltung von Informationen zuviel Geld. Zweitens sind selbst mit hohem Aufwand Informationen oft nicht verfügbar, jedenfalls dann und dort, wo sie benötigt werden. Und drittens sind Informationen zu oft falsch oder ungenau, weil ihre Verwaltung ,,von Hand`` zu unzuverlässig ist. Der Begriff ,,Informationen`` bezeichnet hier sowohl alle Teile des Softwareprodukts selbst als auch alle Informationen, die zur Organisation seiner Herstellung verwaltet werden müssen.

Notationen ungenau: Eine weitere Gruppe von mathematisch orientierten Informatikern glauben, das zentrale Problem sei die zu geringe Verwendung von Notationen mit exakt definierter Bedeutung. Formale Notationen erleichterten, so glauben sie, die Entwicklung in einem solchen Maße, daß damit mehr Probleme gelöst werden könnten als mit anderen Ansätzen.
Wirkungsweise: Ungenau definierte Notationen erzeugen Mißverständnisse und verbieten Korrektheitsbeweise bei Transformationen.

Softwareprozeß schlecht: Eine letzte Gruppe schließlich, allen voran zahlreiche Vertreter des Software Engineering Institute der Carnegie Mellon Universität, halten ungenügende Qualität des Herstellungsprozesses von Software für die Wurzel allen Übels und für den Schlüssel zu seiner Beseitigung. Hier geht es also nicht um einzelne Methoden oder Werkzeuge, sondern um deren Zusammenspiel miteinander, mit den Menschen in der Organisation und mit dem gesamten restlichen Umfeld von Kunden, Anforderungen, Beschränkungen und so fort.
Zur Wirkungsweise gleich unten mehr.

Es sollte klar sein, daß alle diese Erklärungen einige Argumente auf ihrer Seite haben; alle diese Problemfelder sind bedeutend5.1. Vermutlich ist jedes davon bedeutend genug, daß die Frage müßig ist, welches das größte Problem darstellt; das hängt zu sehr vom Anwendungsgebiet und der jeweiligen Softwareorganisation ab.

Allerdings nimmt die Softwareprozeß-Verbesserung eine Sonderstellung ein: Zu ihren Anliegen gehört es nämlich, die relative Wichtigkeit der anderen Probleme festzustellen und Lösungen vorzuschlagen, die für die jeweilige Organisation und das jeweilige Projekt geeignet sind.

5.1.2 Ziele von Softwareprozeß-Verbesserung

Alle nachfolgenden Ausführungen beziehen sich vorrangig immer auf Softwareentwicklung in recht großen Projekten mit einigen Dutzend oder mehr Beteiligten. Für kleinere Teams gelten im Prinzip die gleichen Überlegungen, jedoch können kleine Teams die Schwierigkeiten manchmal auf andere Weise überwinden, wenn die Teammitglieder sehr kompetent sind.

Folgende Haupteigenschaften eines Softwareprozesses lassen sich identifizieren, die als Grundlage für einen guten Softwareprozeß gesehen werden können. Die Ziele von Softwareprozeß-Verbesserungsmaßnahmen müssen also zunächst sein, den Prozeß so umzugestalten, daß er diese Eigenschaften aufweist. Erst darauf aufbauend wird dann die eigentliche Verbesserung angestrebt.

Wohldefiniertheit: Die grundlegende Forderung an einen Softwareprozeß für ein großes Team lautet, daß er wohldefiniert sein muß. Das heißt, es muß allen bekannte Regelungen geben, was unter welchen Umständen mit welchen Randbedingungen getan werden muß, soll, darf oder nicht darf. Wenn der Softwareprozeß nicht definiert ist, wird die Arbeit der einzelnen Personen zu oft aneinander vorbeilaufen, werden Arbeitsschritte nicht, unvollständig, falsch oder doppelt erledigt und werden Dokumente unverständlich sein, weil jeder sein eigenes Format verwendet. Definiertheit ist ab einer gewissen Teamgröße Grundvoraussetzung für geordneten Ablauf. Man beachte, daß Definiertheit nicht in Form von Vorschriften erfolgen muß (präskriptiv definierter Prozeß), sondern im Prinzip auch durch passive Beschreibung der Arbeitsweise erfolgen kann, die in einem weiten Rahmen freigestellt bleibt (deskriptiv definierter Prozeß).

Quantitatives Verstehen: Der nächste Anspruch lautet, beobachten und verstehen zu können, was im Softwareprozeß vor sich geht. Das dabei entwickelte Verständnis sollte nicht nur qualitativer Natur sein, sondern quantitativ zu modellieren erlauben, wo im Softwareprozeß wieviel Zeit verwendet wird (desgleichen andere Ressourcen) und wo wie viele und welche Fehler gemacht werden. Dieses Verständnis bildet die Grundlage für Prozeßverbesserung, weil andernfalls Verbesserungen nur aus intuitiven Eindrücken einzelner heraus gemacht werden können, die aber in einem großen Team zwangsläufig nur einen kleinen Ausschnitt des Gesamtprozesses berücksichtigen und meist dementsprechend wenig wirksam sind. Die meisten wichtigen Verbesserungen können ohne quantitatives Verständnis des Prozesses nicht entdeckt werden.

Kontinuierliche Änderung: Als letzte Eigenschaft braucht der Softwareprozeß die Fähigkeit, sich kontinuierlich zu ändern und zwar teilweise, um Verbesserungen zu realisieren, teilweise aber auch, um sich ändernden Anforderungen in der Umgebung gerecht zu werden (Werkzeuge, Anwendungsgebiete, Zusammenarbeit mit Zulieferern etc.). Ist diese Fähigkeit im Softwareprozeß nicht vorhanden, so gibt es zwei Möglichkeiten: Entweder der Prozeß wird (unterschwellig oder gewaltsam) doch geändert und verliert damit seine Wohldefiniertheit, oder er verliert seinen Nutzen, weil er zu ineffektiv ist oder den neuen Anforderungen nicht gerecht werden kann. Ein guter Softwareprozeß muß laufend kleine Änderungen an sich selbst vornehmen -- man kann hier von einem Meta-Prozeß sprechen. Gute Softwareorganisationen haben deshalb oft eine Gruppe von Leuten, die sich nur mit der Weiterentwicklung des Softwareprozesses befaßt, die Software Engineering Process Group (SEPG).


next up previous contents
Next: 5.2 Ansätze Up: 5. Softwareprozeß-Verbesserung Previous: 5. Softwareprozeß-Verbesserung
Lutz Prechelt
1999-04-13