MÜNCHEN- "Die Erbsünde der Software-Entwicklung besteht in der einmal getroffenen Entscheidung, überhaupt Software zu entwickeln", urteilt Harry Sneed, Geschäftsführer der Münchener Software Engineering Services GmbH. Auf diese Weise seien wir "in die Endlos-Schleife, Software Life Cycle' gekommen." Sneed erläuterte vor Anwendern und Interessenten des Datendiktionärs "Datamanager" Aspekte der Software-Qualitätssicherung mit Hilfe projektbegleitender Dokumentation.

Wegen der Anwesenheit von Teilnehmern auch aus der Schweiz und Österreich sei es angezeigt, vom dritten deutschsprachigen Datamanager User Group Meeting zu sprechen, meint Ernst H. Kelting, Geschäftsführer der Management Software Products (MSP) GmbH, Rellingen, zur Eröffnung der Tagung. Datamanager Anbieter MSP bot den in München versammelten rund 90 Teilnehmern davon mehr als die Hälfte Anwender - mehrere Vortragsveranstaltungen, Themenvertiefung in Arbeitsgruppen sowie ein Datamanager-Einführungsseminar und kündigte außerdem Release 4 des Datendiktionärs an.

Sneed, der sein Referat auch als Anregung zum Einsatz von Datamanager verstanden wissen wollte, zeichnete ein Bild von der Software der Zukunft, ihrer fabrikmäßigen Herstellung und den Möglichkeiten der Wahrung eines Qualitätsstandards. Seine Gedanken sind im folgenden nachskizziert.

System-Elemente

Entgegen der überkommenen (falschen) Vorstellung von einem Software-System gibt es mindestens drei verschiedene Programme, nämlich

1) die Mensch-Maschine-Kommunikation (sie entspricht der konventionellen Software),

2) die Mensch-Mensch-Kommunikation (sie ist in der Entwurfsphase von entscheidender Bedeutung),

3) die Spezifikation (hier ist besonders auf das Pflichtenheft zu verweisen).

Ein Software-System besteht aus funktionalen und Daten-"Elementen", die bestimmte Eigenschaften haben und zwischen denen Beziehungen existieren.

Der hierzulande noch weithin zu beobachtende Dualismus zwischen der Datenstruktur und der von ihr losgelösten Verarbeitungsstruktur spielt in den USA inzwischen kaum mehr eine Rolle. Dies sollte auch bei uns so sein. Der Weg dorthin: Mit dem Definieren und Erfassen sämtlicher Elemente eines Systems, ihrer Eigenschaften und Beziehungen ist auch die vollständige Dokumentation von Daten und Funktionen gewährleistet.

Man muß sich von dem Irrtum freimachen, bei der Dokumentation komme es allein auf den Objekt- oder Sourcecode an. "Ein Großteil der heutigen Software steckt in den Köpfen einzelner Menschen." Dokumentation soll das, was in den Köpfen steckt - und das sind rund 50 Prozent der Software - maschinell speichern.

Informationsverluste

Dokumentiert werden sämtliche Ebenen eines Software-Systems, die (anwendungsbezogene) logische, die (implementierungsbezogene) physische und die (darstell- und ausführbare) maschinelle Ebene. Logische und physische Ebene sind unterteilt in invariante statische (bei räumlicher Betrachtung) und variante dynamische Strukturen (bei zeitlicher Betrachtungsweise). Das System erfaßt außerdem alle Funktions-, Daten-, Speicher- und Codehierarchien.

Untersucht man die bisherige Art der Erstellung einer maschinellen Problemlösung, so stellt man fest, daß auf der Strecke zwischen Spezifikation, System-, Programm- und Modulentwurf ein Übermaß an Information verlorengeht. Was als Lösung gedacht war, funktioniert nicht oder nur schlecht. Grund: Mangelhafte Mensch-Mensch-Kommunikation .

Die Aufgabe lautet daher, nicht erst die maschinelle Lösung zu überprüfen, sondern in jeder Phase des Entstehungsprozesses die Zwischenergebnisse zu analysieren. Selbst bei dieser Vorgehensweise trifft man die Benutzerforderung meist nicht auf Anhieb exakt, und es wird nachträgliches Tuning erforderlich - wie überhaupt ständiges Optimieren im Zeitablauf unvermeidlich bleibt. "Wir schießen auf ein sich bewegendes Ziel - mit flexiblen Werkzeugen."

Das ist die Schleife, in der wir kreisen und die klar belegt, daß Software Entwicklung kein linearer Prozeß ist. Hier wird auch deutlich, daß das Klagen und Jammern über die mittelverschlingende Software-Wartung am Kern der Sache vorbeizielt. Software kann nie "fertig" sein, doch um sie billig weiterentwickeln zu können muß schon der erste Erstellungsdurchgang voll dokumentiert werden.

Ziele Kompromiß

Jeder Anwender sollte ein Phasenkonzept haben. Die Entwurfsmethode, die er wählt, ist nicht so entscheidend, wohl aber daß sein Entwurf konsistent ist. Jede Phase ist praktisch ein Projekt, das überprüfbar sein muß und ohne Werkzeug - beispielsweise ein Data Dictionary - geht es dabei kaum ab. Typische Phasen sind

- die Spezifikation,

- der Entwurf,

- die Programmierung,

- der Test,

- die Integration,

- die Installation.

Die Ziele, um die es bei der Software-Entwicklung gehen muß, sind nicht immer miteinander vereinbar und verlangen ein kompromißbereites Vorgehen. So konkurrieren miteinander die Ziele Effektivität, Effizienz und Zuverlässigkeit (alle drei zusammen sind die Determinanten der Benutzerakzeptanz), ferner Wartungsfreundlichkeit, Anpassungsfähigkeit und Maschinenunabhängigkeit (alle drei zusammen machen die Ausbaufähigkeit einer Software aus).

Schaut man sich in der Realität um, in welchem Maße diese Ziele - sie sind gleichzeitig Software-Qualitätsmerkmale - vom Anwender verfolgt werden, so kommt man zu einem ernüchternden Fazit: Das Software Künstlertum der 60er Jahre ist immer noch nicht ausgerottet. Die Strukturierte Programmierung der 70er Jahre ist noch nicht verdaut. Vom Software Engineering der 80er Jahre ist fast noch nichts zu merken.

Qualitätsmessung

Auf vier Säulen steht die "Software-Fabrik", in der nach den Grundsätzen des Software Engineering- und horizontal arbeitsteilig - verfahren wird. Drei dieser Säulen zeigt die Grafik, die vierte bildet das Projektmanagement. Die in dieser Software-Fabrik hergestellten Produkte dienen zur Prüfung der oben beschriebenen Ziele.

Die Qualität der erstellten Software ist meßbar und nur in einigen Fällen - etwa der Reparierbarkeit - weniger exakt formuliert. Angaben über die Menge der möglichen und der definierten Ergebnisse (auf der Ausgabeseite eines Systems) und über die Menge der möglichen und der definierten Argumente (auf Eingabeseite) oder über die Anzahl der Dateien, Schnittstellen und Moduln oder - um ein weiteres Beispiel zu nennen über die Übereinstimmung zwischen Code und Dokumentation sind erhältlich oder errechenbar und erlauben es, Aussagen über folgende Systemeigenschaften zu machen:

- Korrektheit

- Vollständigkeit

- Konsistenz

- Integrität

- Redundanz

- Sicherheit

- Wiederherstellbarkeit

- Verfügbarkeit

- Kontrollierbarkeit

- Reparierbarkeit

- Transparenz

- Modularität

- Flexibilität

- Portabilität

- Kompatibilität

- Normgerechtheit

Schutzmoduln

Die Bedeutung einer perfekten Dokumentation für das Erreichen der aufgeführten Qualitätsmerkmale ist so groß, daß man sagen kann: "Eine falsche Dokumentation ist schädlicher als gar keine." Wer seine Software aber den genannten Erfordernissen gemäß anlegt, kann auch von einem Problem der Art nicht hart getroffen werden, wie es sich jetzt gerade wieder stellt: dem Nicht-Übergang von IBMs IMS-Datenbank zu IBMs System R-Datenbank.

Vor Schwierigkeiten dieser Sorte schützt sich der Anwender, indem er seine Software mit einer Schicht aus speziellen Moduln "umhüllt", die die Verbindung der Anwendungsmoduln zu - beispielsweise - CICS-, DMS- und TSO-Umgebungen herstellt und damit eine Art virtueller Terminalschnittstelle schafft. Er kann so eventuellen Bewegungen auf dem Feld der Systemsoftware ruhiger ins Auge sehen.

Abschließend sei die Struktur eines Pflichtenhefts aufgezeichnet, wie es zur Spezifikation eines stabilen Software-Systems verwendet werden sollte. Um das Pflichtenheft zu schreiben und zu pflegen, ist Hilfe durch das DV-System unerläßlich. Im Endeffekt bedeutet dies, daß auch für den Systemanalytiker die Zeit reif ist, seine Arbeit vom Terminal aus zu erledigen.

Pflichtenheft

1. Allgemeine an: Management

Begründung

2. Leistungsbeschreibung an: Entwickler

Benutzer

2.1 Datenkatalog

2.2 Funktionskatalog

2.3 Benutzerschnittstellen

2.4 Datenstruktur

2.5 Funktionsstruktur

2.6 Datenfluß

2.7 Entscheidungslogik

3. Abnahmekriterien an: Entwickler

3.1 Organisatorische Bedingungen

3.2 Technische Bedingungen

3.3 Performance-Kriterien

3.4 Zuverlässigkeitskriterien

3.5 Kosteneinschränkungen

4. Ausgangsbasis an: Entwickler

4.1 Systemkonstanten

4.2 Systemvariablen

4.3 Störfaktoren

5. Benutzerhandbuch an: Benutzer

(als ob das System schon fertig wäre)