Ein hoher Grad an Einheitlichkeit erleichtert das Verständnis einer Struktur durch einen Dritten, da dieser aufgrund des Entwurfsverfahrens selbst zu ähnlichen Zerlegungen käme und diese daher als natürlich empfindet.

Die Programme von Team 2 und 3 erwecken meist den Eindruck, als ergäbe sich ihre Struktur zwangsweise aus der Problemstellung, während etwa die Modularisierung des Composite Design (Team 1) vielfach den Eindruck des Willkürlichen erweckt.

Modularität

Sowohl das Verfahren des Composite Design als auch das des mehrdimensional abgestuften Entwurfs liefern eine modulare Programmstruktur. Nach dem Jackson-Entwurfsverfahren ergibt sich eine Aufteilung auf Moduln nur im Zusammenhang mit der Inversion (vgl. Tabelle 5).

Das Fehlen von Moduln macht das Lesen der Programme von Team 2 (Jackson-Entwurf) schwierig. Die Struktur, die in der Baumdarstellung der Daten- und Programmstruktur noch gut erkennbar ist, geht in der Programmliste nahezu verloren, Schleifenanfang und -ende liegen teilweise mehrere hundert Anweisungen auseinander. Ebenso kann man den THEN- und den ELSE-Zweig von Selektionen vielfach nicht auf einmal erfassen, da diese weit auseinander liegen.

Redundanz

Redundanz bedeutet, daß die gleichen Aussagen an mehreren Stellen im Programm gemacht werden. Dies können arithmetische Operationen, Entscheidungen,

Ein-/Ausgabeoperationen sein. Redundanz bedeutet aber auch, daß in der Wartung an mehr Stellen geändert werden muß und das Auffinden der Änderungsstellen schwieriger wird.

Tabelle 6 gibt Anhaltspunkte zur Abschätzung der Redundanz. Die auffälligsten Werte sind:

þTeam 2 (Jackson-Verfahren) benötigt erheblich weniger Variablen im Programm "Bestellbearbeitung".

þTeam 3 (mehrdimensional abgestufter Entwurf) benutzt deutlich mehr Steuerungsanweisungen im Programm "Bestellbearbeitung",

þTeam 3 verwendet für die Bestellbearbeitung im Vergleich zu den beiden anderen Teams auffällig viele Zuweisungen.

þDie Anzahl der Maschineninstruktionen unterscheidet sich erheblich weniger als die Anzahl der Procedure Division-Zeilen.

Tabelle 6 deutet auf die geringste Redundanz in den Programmen nach dem Jackson-Verfahren hin. Das Verfahren des mehrdimensional abgestuften Entwurfs scheint die größte Redundanz zu implizieren.

Bei dieser Bewertung ist zu berücksichtigen,

- daß die Lösung nach Jackson keine Anweisungen zur Definition und zum Aufruf von Moduln benötigt, da sie nicht modular ist;

- daß die Mächtigkeit der Anweisungen differiert, da sich die Anzahl der Instruktionen für die Procedure Division nicht wie die Anzahl der Procedure Division-Zeilen verhält und

- daß eine grundsätzliche Entwurfsentscheidung bei Team 3 den Programmumfang spürbar anwachsen ließ.

Diese Entscheidung bestand darin, in der Bestellbearbeitung die Funktion "Bestellkopf erfassen" und "Bestellkopf ändern" in zwei getrennten Teilprogrammen zu realisieren, obwohl diese zu einem hohen Anteil gleich sind. Trotz gemeinsamer Benutzung von Programmteilen bedeutet diese Lösung mehr Anweisungen als die der beiden anderen Teams, in denen diese Funktionen zusammengefaßt wurden.

Eine genaue Analyse, welche Anweisungen tatsächlich mehrfach vorhanden sind, ist äußerst schwierig und wurde aus Zeitgründen nicht versucht. Es scheint aber zumindest für die vorliegenden Programme berechtigt zu sein, die Entwurfsverfahren bezüglich der Redundanzfreiheit der Programme wie folgt absteigend zu ordnen:

(1) Jackson-Verfahren

(2) Composite Design

(3) Mehrdimensional abgestufter Entwurf.

Schachtelungstiefe

Die Schachtelungstiefe beschreibt, auf wieviel Ebenen die Kontrollstruktur innerhalb einer Section (Modul) aufgesparten wird. Stellt man also die Kontrollstruktur eines Moduls als Baum dar, so gibt die Anzahl der Hierarchieebenen die Schachtelungstiefe an. Das Kontrollkonstrukt Sequenz wurde allerdings nicht mitgezählt, Tabelle 7 zeigt die Analyse der Schachtelungstiefe.

Es zeigt sich - wie erwartet - die größte Schachtelungstiefe bei den Programmen nach dem Jackson-Verfahren. Dies folgt unmittelbar aus dem Verzicht auf die Modularisierung und zeigt dessen Folgen auf. Zwischen Team 1 und 3 zeigen sich keine bemerkenswerten Unterschiede.

Ermittlung des Qualitätsmaßes

Zur Ermittlung eines Qualitätsmaßes verknüpfen wir die weiter oben behandelten Qualitätskennzahlen miteinander zu einer einzigen Größe. Es bietet sich eine Vorgehensweise analog zur Nutzwertanalyse an.

Dementsprechend ist für die Hierarchie der Qualitätsfaktoren eine subjektive Gewichtung einzufahren und dann eine Bewertung der drei Produkte (Dokumentation und Programme) vorzunehmen. Das Ergebnis ist in Tabelle 8 dargestellt.

Effizienz in der Entwicklung

Nachdem bisher der absolute Aufwand der Software-Entwicklung sowie eine qualitative Einschätzung des Ergebnisses besprochen wurde, soll nun die Effizienz der Entwicklung - also das Verhältnis von Aufwand und Ertrag - beleuchtet werden.

Hierfür existieren - ähnlich wie für die Qualität - keine gesicherten und allgemein anerkannten Kennzahlen. Umstritten, aber dennoch häufig benutzt, ist die Angabe "Lines of Code pro Mannstunde" (LOC/MH). Da die Bedingungen, unter denen das Experiment abgewickelt wurde, oben ausführlich beschrieben wurden, ist es vertretbar, hier diese Kennzahl zu benutzen. Tabelle 9 zeigt die LOC-Leistung der Phasen Entwurf, Codierung

und Test sowie der Programmentwicklung gesamt.

Die Werte lassen einerseits die Problematik dieser Kennzahl klar hervortreten, zeigen andererseits aber doch, daß man sie wenigstens größenordnungsmäßig benutzen kann. Sel... wenn man ausschließlich die Lines of Code der Procedure Division berücksichtigt, ergeben sich gute Werte der Kennzahl LOC/MH (vgl. dazu etwa Belford e.a.). Die Abweichungen der Werte der drei Teams liegen in einem Bereich von ± 16 Prozent um den Mittelwert. Für die Instruktionen pro Mannstunde ist der Bereich noch enger.

Verfahrensbewertung durch die Entwickler

Der bisherigen Bewertung lagen die im Projektablauf aufgezeichneten Zeitdaten und die Produkte der Entwicklung - Dokumentation und Programme - zugrunde. Dieser Darstellung wird nun die persönliche Einschätzung der Entwurfsverfahren durch die Entwickler gegenübergestellt.

Diese wurden dazu nach Fertigstellung der Programme befragt. Das Befragungskonzept sah vor, die oben geschilderten Auswertungen durch die

subjektiven Einschätzungen zu ergänzen. Demnach wurden ähnliche Kategorien für Aufwand und Qualität gebildet.

Bewertung des Aufwands

Von den drei Teams wird übereinstimmend eine positive Wirkung der jeweils verwendeten Entwurfsverfahren auf den Gesamtaufwand angenommen (Tabelle 10). Für Composite Desing ist die Einschätzung am positivsten.

Diese grundsätzlich Positive Einschätzung wurde in zwei Kontrollfragen bestätigt. Interesant ist daß hier bei Team 2 die Verringerung des Codieraufwandes durch den vorangegangenen Entwurf erheblich höher als die beiden anderen einschätzte.

Bewertung der Qualität

Die Verständlichkeit der Programme auf Basis der Entwurfsdokumentation wird unterschiedlich beurteilt (Tabelle 11). Am besten schneidet hier das Verfahren des mehrdimensional abgestuften Entwurfs ab.

Ein ähnliches Bild ergibt sich bezüglich der Struktur der Programme. Team 3 beurteilt die Struktur seiner Programme beziehungsweise den Beitrag seines Entwurfsverfahrens zur klaren Strukturierung mit 1.6 beziehungsweise 1.2, Team 1 mit 1.8

beziehungsweise 1.6 und Team 2 mit 2.8 beziehungsweise 1.8, wobei "1" jeweils den besten und "5" den schlechtesten Wert darstellt.

Ein anderes Bild ergibt sich für die Änderungsfreundlichkeit der Programme. Hier beurteilt Team 2 (Jackson-Verfahren) seine Programme mit 2.2, Team 3 mit 3.4 und Team 1 mit 4.

Gesamtbeurteilung der Verfahren

Die Seminarteilnehmer beurteilen den Einsatz von Entwurfsverfahren grundsätzlich positiv.

þAlle Verfahren werden als Hilfe zur Kommunikation im Team angesehen.

þComposite Design und das Verfahren des mehrdimensional abgestuften Entwurfs unterstützen den Überblick über das Programmsystem. Dem Verfahren nach Jackson wird in dieser Hinsicht eine neutrale Wirkung bescheinigt.

þDas Vorgehen wurde Überwiegend als natürlich empfunden (Team 1 mit der durchschnittlichen Bewertung von 1.4, Team 2 mit 2.4 und Team 3 mit 2.2).

Auf die Frage, ob die Teilnehmer das verwendete Programmentwurfsverfahren wieder einsetzen würden, gab es eine breit gestreute Beantwortung (Tabelle 12).

Die Teilnehmer von Team 2 wurden Überwiegend eine andere Entwurfsmethode vorziehen, die von Team 3 an der benutzten festhalten (Tabelle 13).

Fast alle Teilnehmer, lehnen einen Ersatz der Entwurfsverfahren nur, durch

Programmablaufpläne oder nur durch eine Entwurfssprache ab.

Beobachtungen im Experimentablauf

Die Beobachtungen beruhen auf den Seminarsitzungen, in denen die, Zwischenergebnisse, besprochen und Probleme ausgeräumt wurden, sowie auf Tätigkeits- und Problemberichten, die von den Teilnehmern wöchentlich erstellt wurden.

Global kann man feststellen, daß technische und organisatorische Probleme die verfahrensbezogener, Schwierigkeiten klar übertrafen. Beispiele dafür sind Unklarheiten bezüglich der Arbeitsweise von ISAM-Zugriffen des Betriebssystems, fehlerhafte Benutzung, der Hilfsprogramme für, die Bildschirmbehandlung oder die Verwaltung des knappen Plattenplatzes für die Source-Code-Bibliotheken. Die im Zusammenhang mit Programmentwurfsverfahren relevanten Probleme seien im folgenden kurz geschildert.

Die von Philips vorgegebene Spezifikation des Bestellwesens wurde von den Teilnehmern ohne wesentliche Schwierigkeiten verstanden. Rückfragen ergaben sich fast ausschließlich in Details. Beispiele:

- Bezeichnen Nettoauftragswert, Wert und Gesamtwarenwert denselben Datentyp?

- Welche von verschiedenen Angaben zur Genauigkeit der Zahlendarstellung gilt?

- Was geschieht bei Seitenvorschub?

Im Programmentwurf ergaben sich überraschend wenig Probleme mit der Anwendung der Entwurfsverfahrn. Die wesentlichen waren:

Team 1 (Composite.Design):

þIterationen sind im Datenflußplan schlecht darstellbar. Es folgt daraus meist ein Wechsel in der Abstraktionsebene.

þDie Symbolik zur Darstellung von Steuerungsaspekten im Modulbaum wurde unterschiedlich intensiv genutzt.

þDie Tabellen mit den Ein- und Ausgabebeschreibung von Moduln wurde nach ihrer erstmaligen Beschreibung selten auf aktuellen Stand gehalten.

Team 2 (Entwurfsverfahren nach Jackson):

þDas Fehlen von Statusvariablen führt zur Explosion der Programm-Strukturen. Besonders deutlich wurde dies im Falle der Funktionen "Erfassen Bestellkopf" und "Ändern Bestellkopf" die, von geringen Modifikationen abgesehen, gleich sind. Hier wurden zugunsten der Einfachheit von den strengen Vorschriften des Verfahrens abgewichen. Eine Inversion, durch die letztlich jede Statusvariable vermieden werden könnten, wurde als unnatürliche Lösung mit hoher Komplexität abgelehnt.

þDer verzicht auf die Modularisierung machte das Programm schwer überschaubar. So wurde beobachtet, daß von den Teilnehmern fallweise Programmablaufpläne erstellt wurden, um die Übersicht zu behalten.

Team 3 (mehrdimensional abgestufter Entwurf):

þBezüglich der Iteration ergab sich im Präzedenzgraphen dieselbe Schwierigkeit wie bei Composite Desing.

Professor Dr. Joachim Griese ist Inhaber des Lehrstuhls für Betriebsinformatik an der Universität Dortmund, Abteilung Wirtschafts- und Sozialwissenschaften.

Professor Dr. Hubert Österle lehrt Informatik an der Hochschule St. Gallen für Wirtschafts- und Sozialwissenschaft und ist EDV-Beauftragter dieser Hochschule.