Die vielzitierte Softwarekrise ist ein Schlagwort, das vielfach strapaziert wird und als Entschuldigung für die meisten Mißerfolge bei der Softwareentwicklung herhalten muß. Die Erfahrung bei der Abwicklung von großen und kleinen Projekten zeigt, daß diese Krise weniger eine Krise der Software an sich, sondern eine Krise des Managements bei der Entwicklung dieser Software ist.

Ähnlich wie der Erfolg der japanischen Industrie weniger mit dem Fleiß der japanischen Arbeitnehmer zu begründen ist, sondern eher mit den Managementmethoden der japanischen Führungskräfte, so ist die Softwarekrise weniger durch ein Versagen der Softwareentwicklung als vielmehr durch ein Versagen des Managements von Softwareprojekten zu begründen.

Diejenigen, die Softwareprojekte leiten, sind nicht in der Lage, die Problematik der Führung von Softwareleuten, der Strukturierung der Projekte und der Planung und Kontrolle von Softwareprojekten in den Griff zu bekommen. Der Schritt, der in der Hardware-Entwicklung längst vollzogen wurde, nämlich die Integration und die strenge Definition des und Verarbeitungsverhaltens ist in der Software noch fern.

Bei der Software-Entwicklung wird heute fast ausschließlich Statement an Statement gereiht, und nur selten werden vorfabrizierte größere Bausteine verwendet. Sogar sogenannte Programmiersprachen wie etwa Pastal unterstützen diese Vorgehensweise nicht.

Auf den Hardware-Entwickler übertragen würde dies bedeuten, daß er die Funktionen eines Mikroprozessors in mühseliger Kleinarbeit aus Transistoren aufbauen würde. Selbst für dieses mühsame Aneinanderreihen von Statements kämpft die Disziplin des Software-Engineerings in endlosen Diskussionen und Aufsatzreihen noch um Methoden, Richtlinien und Verfahren, anstatt sich dem höheren Ziel, nämlich der Möglichkeit zur Integration, zuzuwenden.

Die gfs, München, hat seit 1969 Softwareprojekte aller Art abgewickelt und dieses Problem dabei in aller Breite kennengelernt. Die Konsequenz der gfs war, den Streit um die Methoden, Richtlinien und Verfahren bei der Statement-für-Statement-Entwicklung der Software zumindest innerhalb des Unternehmens endgültig zu beseitigen und sich so für den nächsten Schritt, die Integration, freizumachen.

Projekt-Anwicklung

Der erste Schritt - das Sich-Befreien vom Allerweltsstreit, den heute die Disziplin des Software-Engineerings austrägt - ist getan. Das Resultat ist das gfs-Verfahrenshandbuch. Es ist die Grundlage zur Abwicklung aller gfs-Projekte und Hilfsmittel für das Management zur Strukturierung, Planuntg und Kontrolle der Projekte. Bei Festpreisprojekten ist es Lösung und Garantie dafür geworden, daß die Projekte gewinnbringend angewickelt werden.

Das gfs-Verfahrenshandbuch ist in das Phasenhandbuch und das Organisationshandbuch gegliedert. Das Phasenhandbuch beinhaltet die Methoden, Verfahren und Richtlinien für Software-Projekte, wobei besondere Schwerpunkte

- Top-Down-Vorgehensweise,

- Trennung zwischen fachlichem und DV-technischem Entwurf,

- Hilfsmittel zur Übertragung des fachlichen Entwurfs in den DV-technischen,

- Dokumentation und

- Test

sind.

Das Organisationshandbuch stellt die organisatorischen Grundlagen für die Projektabwicklung dar und beinhaltet

- Projektaufbauorganisation

- Projektablauforganisation sowie

- Vorlagen für Berichte, Protokolle und Formulare.

Es enthält die Vorlagen für den Aufbau des gfs-Projektordners, der für jedes Projekt geführt wird und alle verwaltungstechnischen Unterlagen enthält, die für das Projektmanagement nötig sind.

Dabei - und das sieht die gfs als Vorteil an - ist es nicht unbedingt nötig, daß die Inhalte des Projektordners auf einer EDV-Anlage geführt werden, obwohl dies zweifelsohne eine große Erleichterung darstellt.

Im folgenden werden die wesentlichen Inhalte des gfs-Verfahrenshandbuches und des daraus resultierenden Projektordners wiedergegeben:

1. Phasen-Handbuch

- Top-Down-Vorgehensweise

- Methoden

- Tools

- Analyse

- Problemabgrenzung

- Analyse Ist-Zustand

- Darstellung

- Vorgaben/Wünsche

- Schwachstellen

- Entwurf

- Funktionale Darstellung

- Datenstruktur

- Realisierungsplan

- Wirtschaftlichkeitsüberlegungen

- Spezifikation

- Daten und Funktionserstellung

- DV-Spezifikation

- Realisierung

- Programmierrichtlinien

- Dokumentation

- Teststrategie

2. Organisations-Handbuch

- Projektaufbauorganisation

- Kleinprojekte

- Großprojekte

- Projektablauforganisation

- Planung

- Koordination/Kontrolle

- Maßnahmen

- Berichte/Protokolle

Die Erfahrung zeigt, daß die Entwicklung interner Projektrichtlinien mindestens zweieinhalb Mannmonate erfordert. Verglichen damit ist der Preis des Verfahrenshandbuchs in Höhe von 400 Mark ein geradezu vernachlässigbarer Kostenfaktor.

*Dr. Raschner ist Projektleiter bei der Gesellschaft für Systementwicklung (gfs) GmbH, Grünbauerstraße 30a, 8000 München 71, Telefon: 089/79 90 94.