DORTMUND - Die Programmentwurfsverfahren Composite Design, Jackson-Strukturierte Programmierung und ein - an der Uni Dortmund entwickelter - mehrdimensional abgestufter Entwurf standen erstmals (und stellvertretend für andere Verfahren der jeweiligen Gattung) unter gleichartigen Bedingungen auf einem wissenschaftlichen Prüfstand. Ermittelt wurden Angaben über den Aufwand beim Einsatz und über die Qualität der erzielten Ergebnisse. Unterschiede zeigten sich dabei nicht so sehr im Gesamtaufwand als vielmehr dann, wenn man die Verfahren in Gestaltungsphasen aufteilte. Hinsichtlich der Qualität ergaben sich sowohl bei den Einzelangaben als auch bei der Gesamtaussage zum Teil erhebliche Differenzen zwischen den jeweiligen Programmprodukten. Einheitlich aber war das Votum der am Test Beteiligten: Entwurfsverfahren fördern die Kommunikation im Team.
Die derzeitige Situation in der Softwareentwicklung ist wie folgt zu umreißen (vergleiche Österle 1):
- Systemanalytiker und Programmierer wenden den weitaus größten Teil ihrer Arbeitszeit für die Fehlerbeseitigung auf. Der Anteil des Tests und der damit verbundenen Fehlerbeseitigung macht etwa 50 Prozent des gesamten Entwicklungsaufwands aus; wenn ein Programmsystem entwickelt ist, fallt anschließend noch rund das Dreifache des Entwicklungsaufwandes in der Wartung an [vergleiche Black, Boehm, Central Computer Agency (Hrsg.), GMD (Hrsg.)].
- Die Fehlerursachen liegen meist im Programmentwurf (vergleiche Endres, Lientz e. a., Thayer).
- Wissenschaft und Praxis - hier vor allem Softwarehäuser und Unternehmensberater - lieferten in den vergangenen Jahren eine Vielfalt von Vorschlagen für Programmentwurfsverfahren .
- Unternehmen, die ein Programmentwurfsverfahren einführen, legen sich durch hohe Schulungsinvestitionen für längere Zeit auf diesen Ansatz fest. Da das Programmentwurfsverfahren darüber hinaus den Programmierstil, die Teamorganisation und ähnliche Bereiche beeinflußt, wirkt die Festlegung auf die gesamte Softwareentwicklung .
- Methodisch einigermaßen abgesicherte Aussagen über den Erfolg des Einsatzes von Programmentwurfsverfahren fehlen. Wenn über Effizienzsteigerungen als Folge der Einführung von Programmentwurfsverfahren berichtet wird, fehlen meist alle Angaben über die Vergleichsbasis.
Zielsetzung
Vor diesem Hintergrund möchten wir durch einen Vergleich von Programmentwurfsverfahren im praktischen Einsatz folgende Fragen beantworten:
- Welchen Aufwand verursachen verschiedene Programmentwurfsverfahren?
- Welche Qualitat besitzen die mit verschiedenen Programmentwurfsverfahren erstellten Softwareprodukte?
Durch Offenlegen der Vorgehensweise in Form eines kontrollierten Experiments möchten wir ferner anregen, aufgrund der beschriebenen Leistungskomponenten des Softwareprodukts möglicherweise weitere Experimente vorzunehmen, um die bisher vorliegenden Aussagen noch zu erweitern [Griese und Österle].
Untersuchungskonzept
Wie schon erwähnt, wollen wir den beiden Fragestellungen nicht theoretisch (vergleiche hierzu beispielsweise Peters und Tripp, Österle 2, S. 77
ff.), sondern empirisch nachgehen, indem wir den Einsatz von verschiedenen Programmentwurfsverfahren bei der Erstellung des gleichen Softwareprodukts in Form eines kontrollierten Experiments verfolgen. Wir bemühen uns dabei, die Vergleichsbasis möglichst gut zu beschreiben (im Gegensatz etwa zu Haeni, Rader) und andere Einflüsse weitgehend auszuschalten (im Gegensatz etwa zu Basili und Zelkowitz).
Experimentanordnung
Das Experiment wurde in Kooperation mit Philips geplant und durchgeführt. Dieses Unternehmen stellte uns die Spezifikation eines Teilsystems (Bestellwesen) aus einem Standardanwendungspaket sowie eine Datenverarbeitungsanlage zur Abwicklung des Experiments zur Verfügung.
Das Experiment wurde im Rahmen eines Projektseminars am Lehrstuhl für Betriebsinformatik der Universität Dortmund im Sommersemester 1980 durchgeführt. Hierbei bildeten 15 Studenten drei Teams zu je fünf Mitgliedern und realisierten die gleiche Spezifikation nach drei verschiedenen Programmentwurfsverfahren .
Variierter Faktor Programmentwurfsverfahren
Der einzige Faktor, der im Experiment variiert werden sollte, war das Programmentwurfsverfahren. Alle anderen Einflußgroßen, wie etwa die Teamorganisation, sollten für alle Teams konstant gehalten werden.
Die eingesetzten Entwurfsmethoden sind:
- Composite Design [Yourdon und Constantine],
- Programmentwurf nach Jackson und
- mehrdimensional abgestufter Programmentwurf [Österle 2, S. 185 ff.].
Composite Design gilt als funktionsorientierter Ansatz; die Zerlegung eines Programmes in Moduln als Teilfunktionen steht im Vordergrund der Betrachtung.
Das Programmentwurfsverfahren von Jackson wird als datenstrukturorientierter Ansatz bezeichnet. Es geht von der Struktur der zu verarbeitenden Dateien eines Programmes aus und leitet daraus die Kontrollstruktur (Steuerung) ab.
Composite Design und die Entwurfsmethode von Jackson sind als typische Vertreter konträrer Richtungen - der funktions- und der datenorientierten - zu sehen. Die dritte Methode, der mehrdimensional abgestufte Entwurf, entstand aus der Analyse zahlreicher Entwurfsverfahren bezüglich der in ihnen angebotenen Entwurfshilfen und einer Weiterentwicklung und Verallgemeinerung der Ansätze. Sie versteht sich als Synthese der zur Zeit verfügbaren Hilfen zur Strukturierung des Entwurfs in einer Methode.
Konstant gehaltene Faktoren
Herd e. a. sowie Doty e. a. haben anhand von Projektdaten einen Katalog von kostenbestimmenden Faktoren aufgestellt [erste derartige Studie: Fleishman, Nelson]. Wir ordnen diese in drei Kategorien [vgl. Wirtz S. 91 ff.]: Faktoren der Aufgabe
Merkmale des zu realisierenden Programmsystems (beispielsweise Dialog/Batch, Anzahl der Dateien)
Faktoren der Personen
Merkmale der an der Realisierung beteiligten Personen (beispielsweise Ausbildung, Erfahrung)
Faktoren der Hilfsmittel
Gesamtheit aller Verfahren und Werkzeuge und ihrer Eigenschaften (beispielsweise Programmiersprache, Testmethode)
Aufgabe
Die Aufgabenstellung ist eine einfache Bestelldisposition im Rahmen eines Standardanwendungspakets, das auch ein Teilsystem Lagerhaltung enthält. Sie ist als typische betriebliche EDV-Anwendung zu bezeichnen. Ihre Merkmale sind Batch- und Dialogverarbeitung, intensiver Gebrauch von Dateien (sequentiell und direkt) detaillierte Eingabeanalyse und Fehlerbehandlung sowie Ausdruck von Listen.
Erleichternd gegenüber der üblichen Entwicklung betrieblicher Anwendungsprogramme wirkten:
- Die Spezifikation war relativ sorgfältig ausgearbeitet.
- Während der Programmentwicklung ergaben sich keine wesentlichen Änderungen der Spezifikation.
- Abstimmungsprobleme mit Benutzern entfielen.
Erschwerend wirkten die besonderen Forderungen nach Zuverlässigkeit, die an ein Standardpaket gestellt werden müssen. Die Komplexität der Aufgabe ist als eher überdurchschnittlich zu bezeichnen.
Personen
Die größte Gefahr einer unkontrollierten Beeinflussung des Experiments geht von den teilnehmenden Personen aus. Einerseits ist hier die individuelle Leistungsfähigkeit der Teilnehmer und andererseits deren Zusammenarbeit im Team zu sehen Wir haben diesem Aspekt daher besondere Aufmerksamkeit gewidmet.
Die Teilnehmer des Seminars waren Studenten der Betriebswirtschaftslehre mit der speziellen Betriebswirtschaftslehre Betriebsinformatik (16 Semesterwochenstunden im Hauptstudium) und Studenten der Informatik mit dem Nebenfach Betriebswirtschaftslehre (14 Semesterwochenstunden für Betriebsinformatik im Hauptstudium). Das Vorwissen kann grob wie folgt umrissen werden:
- Beherrschung mindestens einer Programmiersprache (PL/1, Pascal oder Simula, jedoch nicht Cobol)
- Geringe Erfahrung mit der Erstellung umfangreicher Programme
- Kaum Erfahrung in Teamarbeit
- Keine Erfahrung mit der Programmierung in Cobol und der Programmierung von Bildschirmdialogen
- Wenig oder keine Erfahrung in der Verarbeitung indexsequentieller Dateien
- Grundlagenwissen im Software Engineering
- Kein Vorwissen über den verwendeten Rechner
Das maschinenspezifische Wissen (Betriebssystem, Dateiorganisation Bildschirmein-/-ausgabe sowie Text - editor und Source-Code-Verwaltung) und die Kenntnis von Cobol wurden in einem dreitägigen Kurs zu Beginn des Seminars vermittelt. In den ersten Wochen wurde ein kleines Übungsprogramm entwickelt.
Nach diesem Kurs wurde das Vorwissen der Seminarteilnehmer in einem Eingangstest ermittelt. Außerdem wurde erhoben, welche Erfahrungen die Teilnehmer in der Entwicklung ähnlicher Systeme besaßen und welches Wissen über Software Engineering vorlag. Diese Daten gingen zusammen mit der Leistungsbeurteilung aus einer vorgelagerten Programmier-Lehrveranstaltung in die Bildung der Teams ein.
Es wurde außerdem darauf geachtet, ein möglichst gleichmäßiges Verhältnis von Informatik- zu Betriebswirtschaftslehrestudenten in den Teams zu gewährleisten. Nicht berücksichtigt werden konnten gruppendynamische Aspekte.
Die Motivation ist - verglichen mit der Praxis - eher hoch einzuschätzen. Die erstmalige Bearbeitung einer größeren Aufgabe mit Praxisrelevanz erzeugte eine erhebliche Arbeitsbereitschaft. Eher im Hintergrund blieb die Motivation über die Bewertung des Leistungsscheins, der im Projektseminar erworben wurde.
Verglichen mit dem durchschnittlichen Programmierer in der Praxis dürfte das Abstraktionsvermögen der Studenten besser geschult sein, da mehrere Lehrveranstaltungen gerade dieses fördern. Die Aufnahmefähigkeit und -bereitschaft für neue Methoden ist höher als die eines langjährigen Programmierers, der meist schon seine eigene Arbeitstechnik entwickelt hat.
Als störend muß allerdings angemerkt werden, daß die Seminarteilnehmer das Projekt neben anderen Tätigkeiten (Lehrveranstaltungen und zum Teil Nebenbeschäftigungen) durchführen mußten. Dies führte beispielsweise dazu, daß die Mitglieder der Teams Schwierigkeiten hatten, gemeinsame Termine für Sitzungen zu vereinbaren.
Hilfsmittel
Neben den über die Teams variierten Programmentwurfsverfahren arbeiteten alle nach denselben Methoden. Es waren dies:
Anwendungsbeispiel auf Basis der Spezifikation
Zur detaillierten Prüfung und zur Verbesserung des Verständnisses der Spezifikation arbeitete jedes Team ein Anwendungsbeispiel aus und simulierte dafür am Schreibtisch die Programmausführung .
Entwurfs- und Codeinspektionen
Die Inspektion von Programmentwürfen und codierten Programmen geschah in Kleingruppen mit zwei bis drei Teilnehmern. Das Vorgehen dabei war freigestellt.
Codierrichtlinien
Im Sinne einer leichten Lesbarkeit der Programme wurde ein Codierstandard festgelegt. Dieser wurde allerdings vom Team, das nach der Jackson-Methode arbeitete, nur teilweise eingehalten, da Jackson hierzu von sich aus einige Vorschriften gibt.
Dokumentation
Die Dokumentation bestand aus den Programmlisten und den Entwurfsdokumenten.
Test
Für das Testen wurden keine besonderen Richtlinien vorgegeben. Es wurde lediglich darauf geachtet, daß jedes Statement wenigstens einmal ausgeführt wurde.
Teamorganisation
Jedes Team bestand aus einem! Teamleiter und vier Entwicklern, von denen Jeder eine zusätzliche Spezialaufgabe, z.B. Source-Code-Verwaltung, übernahm.
Wird fortgesetzt