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:
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.
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).