Am Tools, Methoden und Techniken für die Software-Entwicklung besteht kein Mangel. Trotzdem ist die Erfolgsbilanz vieler Entwicklungsprojekte eher mager. Claus Kurzendörfer* stellt einen prozeßorientierten Ansatz für die Software-Entwicklung vor, bei dem definierte, ständig kontrollierte Vorgehensmodelle genutzt werden.
Gut 20 Jahre lang sind Unternehmen nun schon im Rahmen des "Software Engineering" dabei, Auswege aus der vielbeschworenen "Softwarekrise" zu suchen. Das ernüchternde Resümee: Die Hoffnung auf ein "silver bullet", das den Vampir auf einfachste Weise unschädlich macht, hat sich nicht erfüllt. Trotzdem ist man immer wieder versucht, das Heil in der jeweils modernsten, scheinbar revolutionärsten "In"-Technologie "X" oder dem Super-Tool "Y" zu suchen.
Von der offenbar sehr menschlichen Hoffnung, möglichst einfache und bequeme Auswege aus schwierigen Problemsituationen zu finden, profitieren die Anbieter von Tools, die zwanzigfache Produktivitätsraten in Aussicht stellen, ähnlich wie die Hersteller von Schlankheitspillen, die angeblich jedes Schlemmermenü neutralisieren.
Die Ernüchterung, die sich einstellt, wenn die Unvereinbarkeit von Erwartung und Realität erkannt wird, führt dann häufig dazu, "das Kind mit dem Bade auszuschütten", indem der erprobte Ansatz global verurteilt wird. Was daher dringend gebraucht wird, sind nüchterne Betrachtungsweisen, die der Vielschichtigkeit des Problems entsprechen und Wege zu einer evolutionären Verbesserung der Vorgehensweisen im jeweiligen Entwicklungsumfeld aufzeigen In diesem Sinne wächst in jüngster Zeit das Interesse an Ansätzen, die ein Prozeß-Management in der Software-Entwicklung propagieren. Das Thema solcher Ansätze ist das Schaffen definierter Vorgehensmodelle, die im Sinne einer andauernden Optimierung regelmäßig analysiert und bewertet werden, um aus der Vielzahl möglicher Verbesserungsmaßnahmen die effektivsten herauszufinden.
Auf diese Weise kann ein Rahmen für die Einführung neuer Methoden, Technologien und Tools geschaffen werden, der sicherstellt, daß die wahren Probleme identifiziert und somit die erforderlichen Investitionen auch wirklich sinnvoll getätigt werden. Wichtig ist, daß dieser Ansatz auch dazu beiträgt, Verbesserungen nicht nur als eine Frage von Technologien oder Werkzeugen zu sehen, sondern möglichst viele Einflußfaktoren - insbesondere auch die sogenannten "human factors" - stärker zu berücksichtigen.
Grundlage ist zunächst eine Betrachtungsweise, bei der die Software-Entwicklung als zielgerichtete Folge von Aktivitäten, die definierte Produkte hervorbringen, gesehen wird. Anders als bei den häufig im Rahmen von Lifecycle-Diskussionen üblichen Betrachtungen steht hier jedoch nicht eine statische Sicht im Vordergrund. Es geht weniger darum, das "ideale" Prozeßmodell zu beschreiben.
Die zentrale Frage ist vielmehr, wie durch Analysen und Bewertungen der Abläufe Ursachen für Schwachstellen eines existierenden Prozesses gefunden und behoben werden können. Ein solcher Ansatz hat sich in vielen industriellen Bereichen als wesentliche Komponente des Qualitäts-Managements bewährt, er geht primär auf die Arbeiten W. E. Demings zurück. Die Prämisse, die diesem Ansatz zu Grunde liegt, ist, daß die Qualität der erstellten Produkte eine Funktion der Qualität des Prozesses ist, der zur Entwicklung und Herstellung dieser Produkte eingesetzt wird.
Die Anwendung dieser Konzepte auf, das Umfeld der Software-Entwicklung ist jedoch zur Zeit noch eher die Ausnahme. Im Rahmen der immer mehr forderten Bemühungen die "Handarbeitsmentalität" in der Softwarebranche zu überwinden, stoßen solche Ansätze aber zunehmend auf Interesse. Angesichts der Vielzahl der heute bekannten technologischen und methodischen Vorgehensweisen zur Optimierung der Software-Entwicklung wird es immer wichtiger, die richtige "Mixtur" von Maßnahmen für den eigenen Bereich definieren zu können. Um Methoden zu etablieren, die dazu eingesetzt werden können, sind eine Anzahl von Voraussetzungen zu erfüllen. Zunächst ist natürlich eine klare Vorstellung der Ziele, die für den jeweils betrachteten Entwicklungsbereich angestrebt werden, wichtig - strategisches Denken ist also gefragt. Um realisierbare Strategien für eine Annäherung an diese Zielsetzungen definieren zu können, muß ferner ein Konzept der möglichen Prozeßentwicklung 'da sein.
Bewertung des Status quo möglich
Dies impliziert das Vorhandensein von "Reifegrad" - Modellen, die die Möglichkeiten der Weiterentwicklung aufzeigen und eine Bewertung des Status quo erlauben.
Solche Modelle sind umso brauchbarer, je mehr sie von Daten getragen werden, die in Untersuchungen realer Projekte gesammelt wurden und damit eine realistische Vorstellung von den heute möglichen Praktiken im Software-Engineering vermitteln. Ein nicht firmenspezifisches Beispiel einer solchen Reifegrad-Modellierung ist das "Process-Maturity-Level" - Modell des Software Engineering Institute der Carnegie Mellon Universität, USA (1). Es unterscheidet fünf Reifegradstufen eines Software-Entwicklungsprozesses.
Die erste Stufe "Initial" repräsentiert die Software-Entwicklung in "Handarbeit". Von einem etablierten Prozeß kann dabei noch nicht die Rede sein. Das bedeutet, daß in einem solchermaßen klassifizierten Umfeld noch keine etablierten Vorgehensweisen oder gar methodischen Ansätze existieren. Der typische Arbeitsablauf ist hier am treffendsten durch das "Coding-and-Fixing" - Modell zu beschreiben. Entsprechend schwierig gestaltet sich das Steuern und Planen in einem solchen Umfeld.
Auf der Folgestufe "Repeatable" existieren bereits verschiedene, häufiger praktizierte Vorgehensweisen, die jedoch auf einem eher informellen Vorgehensmodell beruhen, typischerweise also zum Beispiel das Resultat der Erfahrungen einzelner Projektteam-Mitglieder sind. Charakteristisch ist, daß solche Vorgehensmodelle immer wieder "über Bord geworfen" werden, wenn ein Projekt in Zeitdruck gerät.
Im Gegensatz dazu ist die Stufe "Defined" bereits durch ein dokumentiertes, allgemein bekanntes und vor allem praktiziertes Vorgehensmodell charakterisiert. In der nächsten Stufe "Managed" kommt als weiteres Charakteristikum die quantitative Bewertung von Prozessen und Produkten, also das Erfassen von Maßen (Metrics), hinzu. Dies erlaubt eine wesentlich effektivere Standortbestimmung und liefert nachprüfbare Aussagen über die Auswirkungen von neuen Ansätzen. Damit lassen sich auch die oben erwähnten Erfahrungsdaten aufbauen.
Die höchste Reifegradstufe "Optimizing" kennzeichnet schließlich eine Organisation, die die Idee einer Prozeßoptimierung von in den Unternehmenskultus integriert hat und diese folglich als unverzichtbaren Bestandteil der Management-Aktivitäten praktiziert. Neben diesem "öffentlichen" Modell existieren zum Teil ähnliche firmeninterne Modelle, die aus unternehmensweiten Erhebungen resultieren.
Wichtig ist, daß diese Modelle helfen, die Richtung für zukünftige Entwicklungen aufzuzeigen und die Prioritäten für Maßnahmen zu definieren, die nötig sind, um zur jeweils nächsten Reifegrad-Ebene zu gelangen. Dies dient auch der realistischen Einschätzung der anzusetzenden Zeiträume und Ressourcen. Der Nutzen liegt jedoch nicht nur in der Planung und Korrektur von Vorgehensweisen. Ebenso lassen sich zum Beispiel in bezug auf die einzuführenden Technologien oder Werkzeuge Auswahlkriterien ableiten (2).
So hat sich etwa erwiesen, daß der Prozeß-Reifegrad einer Projektgruppe bei der Auswahl von CASE-Tools eine wichtige Rolle spielt. Eine Organisation etwa, die sich im Zustand "Initial" befindet, wird eine komplexe CASE-Umgebung, die eine Prozeß-Infrastruktur voraussetzt, kaum "verdauen" können. Der Rückgriff auf einfachere CASE-Werkzeuge, die keine derartigen Anforderungen stellen, ist in diesem Fall also angebrachter.
Die enge Verbindung von der Prozeßreife mit dem Reifegrad ,der eingesetzten CASE-Systeme unterstreicht die Notwendigkeit von flexiblen, konfigurierbaren Integrationskonzepten, die, mit der Organisation "mitwachsen".
Neben klaren Vorstellungen bezüglich der möglichen Prozeßeigenschaften ist die kontinuierliche Bewertung des Status quo, also das Feedback über die laufenden Prozesse, eine weitere Voraussetzung für ein erfolgreiches Prozeßmanagement. Hierzu müssen methodische Ansätze etabliert werden, die reproduzierbare Aussagen über den Stand eines Entwicklungsbereichs erlauben. Nur so lassen sich durch mehrere, zeitlich gestaffelte Bewertungen eines Bereichs Trends erkennen oder Vergleichswerte über verschiedene Entwicklungsansätze erlangen.
Bei Hewlett-Packard etwa, wurde zu diesem Zweck ein Verfahren etabliert, das wir als "Software Process Assessment" bezeichnen. Es wird von einer Gruppe speziell ausgebildeter Mitarbeiter in den verschiedenen Entwicklungsbereichen regelmäßig praktiziert.
Die Ergebnisse der Abschätzungen, die über standardisierte, strukturierte Interviews ermittelt werden, sind in sogenannten Kiviat-Diagrammen konsolidiert.
Diese zeigen eine quantifizierte Einstufung des Reifegrads, der im jeweiligen Entwicklungsbereich in bezug auf acht berücksichtigte Themenkreise erreicht wird. Darunter finden sich nicht nur technologische Aspekte, sondern auch Themen wie etwa das Weiterbildungs-Angebot für die Mitarbeiter oder das jeweilige Arbeitsumfeld.
Als dritte Voraussetzung eines erfolgreichen Prozeßmanagements sind schließlich Maße (Metrics) zu nennen, mit deren Hilfe quantitative Aussagen über Prozeß- und Produkteigenschaften gewonnen werden können. Speziell dann, wenn die praktizierten Vorgehensweisen bereits einen hohen Reifegrad erreicht haben, liefern sie detaillierte Informationen für die möglichen Ansatzpunkte weiterer Verbesserungen.
So können etwa Fehlerauswertungen und Erfassungen der Zeitaufwendungen im Bereich von Pflege und Wartung Hin. weise auf Defekte im Entwicklungsprozeß liefern. Auch zur belegbaren Analyse der Brauchbarkeit neuer Technologien oder Methoden lassen sich Aussägen machen, die die eigenen Theorien repräsentieren. Daneben können Informationen generiert werden, die das Management laufender Projekte unterstützen, indem sie den Projektstatus transparenter machen und so zeigen, ob das Projekt unter Kontrolle ist.'
Natürlich setzt all dies auch eine entsprechende organisatorische Struktur voraus. Es müssen Mitarbeiter für die Umsetzung dieser Ansätze verantwortlich sein. Dies ist eine Aufgabe, die nicht "nebenbei" erledigt werden kann. Außerdem gilt hier, wie bei vielen anderen Maßnahmen des Software-Engineering auch, daß solche Konzepte nicht per Management. Order erzwungen werden können, sondern von allen Mitarbeitern getragen werden müssen. Dies funktioniert nur auf der Grundlage einer entsprechenden Unternehmensstruktur.
Angesichts der wachsenden Herausforderungen im internationalen Wettbewerb, der steigenden Attraktivität einer Aus Lagerung der Software-Entwicklung in "Billiglohn"-Länder, aber auch der zu erwartenden Veränderungen im Rahmen der europäischen Harmonisierung und Konsolidierung ab 1993 sind jedoch Ansätze, die Wege zu einem effektiveren Software. Engineering aufzeigen, dringend erforderlich. Neue Methoden, Technologien und CASE-Werkzeuge sind dabei wichtige Bausteine. Sie können aber nur dann wirksam werden, wenn sie zu den wirklichen Belangen eines speziellen Entwicklungsumfeldes passen. Die prozeßorientierte Sichtweise kann wesentliche Beiträge leisten, um dies im jeweiligen Einzelfall sicherzustellen.