Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

23.01.1981

Universität Dortmund vergleicht Programmentwurfsverfahren im praktischen Einsatz:Aufwand gleich - Qualität unterschiedlich

Teil 2

Zeitplanung

Eine große Vorgabe der Aktivitäten wurde von der Projektseminarleitung zu Beginn des Experiments vorgegeben (vergleichbar einer Projektplanung).

An Werkzeugen (rechnerunterstützt) wurden verwendet:

Cobol-Compiler

Der verfügbare Cobol-Compiler hält sich im wesentlichen an den ANSI-Standard, besitzt aber folgende Abweichungen:

- Geschachtelte IF-Anweisungen sind nicht möglich.

- Die Verknüpfung von Bedingungen in der IF-Anweisung ist nicht vorgesehen.

- Der Compiler erzeugt keine Crossreference-table für die Variablendeklaration und

-verwendung.

Bildschirmein-/-ausgabe

Die Aufbereitung der Bildschirmformate sowie das Ausgeben und Einlesen von variablen Bildinhalten ist einfach, bietet aber Fehlermöglichkeiten, die nicht vom Rechner geprüft werden.

Texteditor/Source-Text-Bibliothek

Das Eingeben, Ändern und Verwalten von Programm-Source-Texten geschieht über Bildschirm auf komfortable Weise.

Betriebssystem

- Das Betriebssystem bietet einen Mehrprogramm-Betrieb mit festen Partitiongrößen.

- Die Bedienung ist einfach.

- Die Dateiorganisation ist einfach und effizient.

Programmierwerkzeuge

Über die genannten Softwarekomponenten hinaus standen keine Werkzeuge zur Unterstützung der Programmierung zur Verfügung.

Der von Philips bereitgestellte Rechner P430 bestand aus: Zentraleinheit mit 128 KB Internspeicher, zwei Festplatten zu je fünf MB, zwei Wechselplatten zu je fünf MB, drei Bildschirmen, einem Matrixdrucker sowie einem Konsoldrucker.

Hilfspersonal für die Ersterfassung von Programmen u.ä.m. stand nicht zur Verfügung. Als erheblicher Mangel erwies sich das Fehlen eigener Büroräume.

Praxisrelevanz

Der Wert von Programmentwurfsmethoden zeigt sich erst, wenn diese in einer praxisrelevanten Umgebung eingesetzt werden. Um diese Eigenschaft des Experiments sicherzustellen, haben wir versucht, die Praxisbedingungen so weit wie möglich nachzubilden. Die Überprüfung, wie weit das gelungen ist, führten wir anhand der Parallelentwicklung im kooperierenden Unternehmen durch. Insgesamt gesehen, konnten wir feststellen, daß die Versuchsbedingungen mit denen der Praxis übereinstimmen; Einschränkungen sind in zwei Dimensionen erkennbar, nämlich in der Vergleichbarkeit der Entwicklungen innerhalb des Experiments und in der Übertragbarkeit der Ergebnisse auf die Praxis.

Grenzen der Vergleichbarkeit

Während Aufgabe und Hilfsmittel als für alle drei Teams vollständig vergleichbar (da identisch) angesehen werden können, besteht im Faktor Personen die Gefahr einer Verzerrung. Die Sorgfalt bei der Teamzusammenstellung kann zwar grobe Einseitigkeiten vermeiden; sie kann aber nicht sicherstellen, daß Leistungsfähigkeit und Leistungsbereitschaft vollständig gleich sind.

Da eines der Programmentwurfsverfahren von uns selbst entwickelt worden ist, besteht die Gefahr einer einseitigen Beeinflussung. Auch auf diesen Aspekt haben wir besonders geachtet, können aber eine unbewußte Unterstützung des eigenen Verfahrens nicht mit Sicherheit ausschließen.

Die Schulung in dem Programmentwurfsverfahren wurde für alle drei Teams mit je zwei Tagen festgesetzt. Diese Gleichbehandlung vermeidet zwar einerseits eine Verzerrung durch eine unterschiedlich intensive Ausbildung, birgt aber die Gefahr in sich, ein leichter schulbares Verfahren zu bevorzugen.

Die Projektdauer von drei Monaten und der Umfang des Programmsystems lassen es nicht zu, von einem routinemäßigen Einsatz von Programmentwurfsverfahren zu sprechen. Unterschiedliche Schwierigkeiten bei der Einführung von Programm entwurfsverfahrenschlagen auf die Ergebnisse durch. Programmentwurfsverfahren, deren Einführung einen hohen Aufwand mit sich bringt, sind im Nachteil.

Schließlich sind Aussagen über die Qualität der Ergebnisse nicht einfach herzuleiten. Operationale Verfahren zur Messung der Softwarequalität mit dem Ergebnis etwa eines Qualitätsindex sind nicht verfügbar und sind deshalb zum Teil von uns entwickelt worden.

Grenzen der Übertragbarkeit

Probleme in der Übertragbarkeit der Versuchsergebnisse auf die Praxis ergeben sich vor allem aus dem Faktor Personen. Studenten mit den genannten Voraussetzungen sind, wie gezeigt, nur bedingt mit Programmentwicklern in der Praxis vergleichbar. Hinzu kommt möglicherweise noch ein Beobachtungseffekt infolge der Aufzeichnung der Projektdaten. Allerdings dürfte die Wirkung der Beobachtung im Laufe von drei Monaten erheblich nachlassen.

Datenerfassung

Die Untersuchung stützt sich auf drei Arten von Daten:

1) die Eingangsbeurteilung der Experimentteilnehmer,

2) die laufende Projektdatenerfassung und

3) die Abschlußbeurteilung des Projektes.

Die Eingangsbeurteilung fand, wie erwähnt auf Basis eines Eingangstests und der Leistung in einer Programmier- Lehrveranstaltung statt.

Während der Projektabwicklung wurden folgende Daten erhoben:

Zeitaufwand

Jeder Teilnehmer erstellte wöchentlich anhand eines Erfassungsformulars und eines Tätigkeitsschlüssels einen Bericht über die eingesetzte Zeit.

Tätigkeitsbericht/Problembericht

Die Tätigkeiten wurden außerdem in einem Tätigkeitsbericht verbal erläutert. Sofern Schwierigkeiten aufgetreten waren, wurden sie in einem Problembericht geschildert.

Compileläufe/Programmänderungen

Die korrigierten Compilelisten wurden gesammelt und bezüglich der von Compilelauf zu Compilelauf beseitigten Fehler ausgewertet.

Beobachtung

Durch die laufende Betreuung der Arbeiten konnten wir uns einerseits ein eigenes Bild verschaffen und andererseits die Aussagen der Seminarteilnehmer verifizieren.

Die Abschlußbeurteilung benutzte folgende Daten:

- Ergebnisse der Softwareentwicklung

Die Softwareentwicklung lieferte die Entwurfsdokumentation und die Programmlisten.

- Testergebnisse

Die von den Teams erstellten Programme wurden von einem unabhängigen Tester intensiven Prüfungen unterworfen.

- Abschlußbefragung

Die Seminarteilnehmer beantworteten nach Abschluß des Experiments einen Fragebogen, in dem ihre Einstellungen zur Entwurfsmethode ermittelt wurden.

Im folgenden wird dargestellt, welcher Aufwand bei der Entwicklung der Programmsysteme anfiel, welche Qualitätsmerkmale die übergebenen Programmsysteme besitzen und mit welcher Effizienz gearbeitet wurde.

Aufwand

Wir betrachten hier ausschließlich den Personalaufwand. Die verbrauchte Rechnerleistung ist auf dem verwendeten Rechnersystem nicht benutzerspezifisch zu ermitteln und kann daher nicht ausgewiesen werden. Da man aber von einer starken linearen Korrelation von Personal aufwand und Rechneraufwand ausgehen kann, ergeben sich daraus keine Verzerrungen. Die Aussagen in diesem Abschnitt beruhen auf den Daten der Zeiterfassung.

Schulung

Der Aufwand für die Schulung kann bei den drei Teams als gleich hoch angenommen werden. Vor Beginn der Softwareentwicklung wurde jedes Team zwei Tage im jeweiligen Programmentwurfsverfahren geschult. Während dieser Zeitrahmen für das Composite Design ausreichend war, war er für den mehrdimensional abgestuften Entwurf und vor allem für den Entwurf nach Jackson äußerst eng. Sonderfälle und Verfahrensdetails mußten teilweise übergangen werden. Die Teilnehmer konnten die Verfahren trotzdem ohne wesentliche Probleme auf die gegebene Problemstellung anwenden. Der zusätzliche Lernaufwand, der während der Projektausführung zur Beherrschung der Programmentwurfsverfahren notwendig wurde, ist vernachlässigbar klein.

Entwicklung

Die Entwicklung umfaßte im Experiment folgende Phasen:

Studium, Analyse und Korrektur der Spezifikation

Die Spezifikation wurde von Philips bereitgestellt. Die Seminarteilnehmer erhielten sie als Vorgabe, analysierten sie - beispielsweise in Form einer Anwendungssimulation am Schreibtisch - und überarbeiteten sie, soweit notwendig, innerhalb der Teams.

Programmentwurf

Der Programmentwurf liefet auf Basis der Spezifikation die grobe Struktur der Programme. Die Dokumente, die dabei anfallen, sind in den Entwurfsverfahren definiert.

Codierung

Unter Codierung fassen wir die Entwicklung des Source-Codes, dessen Inspektion und Dokumentation zusammen. Eine Fehlerbeseitigung ist ausgeschlossen.

Test

Unter Test wird die rechnerunterstützte Überprüfung der Programme(Compilieren, Ausführen mit Testdaten) die Analyse der Ausführungsergebnisse, die Identifikation der Fehler im Programm und deren Beseitigung verstanden. Es wird hier nicht zwischen Debugging und Test unterschieden. Eine besondere Form des Tests, die in der Zeiterfassung nicht enthalten ist, war der Übernahmetest. Er wurde von einem unabhängigen Tester vorbereitet und ausgeführt. Sein Ziel war die Qualitätsbeurteilung.

Es sei darauf hingewiesen, daß diese Phaseneinteilung nicht vollständig mit der in der Zeiterfassung benutzten übereinstimmt. Der Tätigkeitsschlüssel der Zeiterfassung differenziert innerhalb der Phasen nach Tätigkeiten. Auf diese Weise war es möglich, den Zeitaufwand auf Phasen nach obiger Definition klar zuzuordnen.

Die Schulung vor Projektbeginn (Verfahren, Betriebssystem, Cobol) und die Bearbeitung eines Übungsprogrammes neben der Projektabwicklung in den ersten drei Wochen gingen nicht in die projektbezogenen Zeitangaben ein. Enthalten sind dagegen phasenunabhängige Verwaltungstätigkeiten; sie sind unter dem Begriff Projektmanegement zusammengefaßt.

Gesamtaufwand

Bild 1 zeigt die von den Teams eingesetzte Zeit für die Entwicklung des Programmsystems.

Die Unterschiede zwischen den Teams sind nicht so groß, daß man auf dieser Basis von einem klaren Vor- oder Nachteil einer Methode sprechen kann, wenn man den schlecht kontrollierbaren Faktor Personen berücksichtigt.

Aufwandsverteilung auf Phasen

Bild 2 zeigt die Aufwandsverteilung über der Zeit, ohne dabei Phasen abzugrenzen. Das Projekt wurde in 14 Perioden (Wochen) zerlegt, die als Berichtszeiträume dienten. Die drei Kurven haben im wesentlichen einen ähnlichen Verlauf.

Bild 3 vergleicht den Aufwand pro Team und Phase. Tabelle 1 zeigt die absoluten und prozentualen Anteile der Phasen pro Team.

Die Aufwandsverteilung darf nur eingeschränkt mit verschiedentlich publizierten Angaben verglichen werden; denn die Spezifikation wurde lediglich leicht überarbeitet, und aus der Phase Codierung wurde das Debugging vollständig ausgelagert, um zu klaren Abgrenzungen zwischen den Phasen zu kommen. Die Codierung enthält nun ausschließlich die Erstellung des Source-Codes dessen Inspektion und Dokumentation.

Die maschinelle Prüfung durch den Compiler und das Ausführen der Programme sowie die Korrektur der Programme (sowohl syntaktischer als auch semantischer Fehler) sind vollständig unter "Test" subsumiert. Der Übernahmetest wurde aus dem Experiment ausgelagert und diente ausschließlich der Bewertung der Qualität. Fehler, die den weiteren Testablauf nicht verhinderten, wurden nicht beseitigt.

Betrieb/Wartung

Die Phase Betrieb, das heißt aus der Sicht der Softwareentwicklung die Phase Wartung, konnte im Rahmen des Experiments im gegebenen zeitlichen Rahmen nicht untersucht werden. Der Wartungsaufwand wird von der Softwareentwicklung aus über zwei Faktoren beeinflußt,

1. die Anzahl der Fehler, die in der übergebenen Software enthalten sind und

2. die Änderungsfreundlichkeit der Programme.

Das Ausmaß, in dem nach Fertigstellung der Programme noch Fehler enthalten waren konnte durch den Abnahmetest ermittelt werden. Dieser ist letztlich nichts anderes als eine auf einen kurzen Zeitraum verdichtete und vorweggenommene Benutzung der Software. Die Testfälle sind eine Stichprobe aus den im Betrieb auftretenden Anwendungsfällen. Damit ist es zulässig, aus der Zuverlässigkeit im Abnahmetest auf die Zuverlässigkeit im Betrieb zu schließen. Sowohl die Zuverlässigkeit als auch die Änderungsfreundlichkeit werden im Rahmen der Qualitätsanalyse behandelt.

Qualität

Es gibt kein allgemein anerkanntes Meßverfahren für die Qualität eines Softwareprodukts. Es sind aber zahlreiche Ansätze bekannt, Software-Kennzahlen (Metrics) zu bilden. Beispiele geben die Arbeiten von Boehm e.a., Bowen, Cavano und McCall, Chapin, Clapp und LaPadula, Fischer, Gilb, Halstead, Jelinski und Moranda, Sullivan sowie Yin und Winchester.

Die erwähnten Arbeiten führen nicht zu einem umfassenden Qualitätsmaß, sondern zur Beurteilung einzelner Qualitätsaspekte. Wir versuchen hier, einerseits die relevanten Faktoren der Qualität offenzulegen und zu bewerten und andererseits sie in einer Maßzahl auszudrücken.

Dazu bestimmen wir die Gesichtspunkte der Qualität ausgehend von den Kosten, die infolge von Qualitätsmängeln anfallen. Bild 4 zeigt die Hierarchie der Qualitätsfaktoren, die hier zur Bestimmung des Qualitätsmaßes benutzt wird. Die Qualität bestimmt sich demnach aus

- der Zuverlässigkeit,

- der Wartbarkeit und

- der Effizienz.

Die Zuverlässigkeit steht für die Kosten im Anwendungsbereich infolge von Qualitätsmängeln, die Wartbarkeit für die Kosten von Softwareänderungen und die Effizienz für die Kosten des Betriebes. Die Qualitätsbeurteilung bleibt hier auf Faktoren beschrankt, die in der Softwareentwicklung zu verantworten sind.

Zuverlässigkeit

Unter Zuverlässigkeit verstehen wir das Ausmaß, in dem ein Softwaresystem die spezifizierten Leistungen erbringt. Um sie zu messen, haben wir Abnahmetests durchgeführt. Wir gehen davon aus, daß diese eine Stichprobe aus dem laufenden Betrieb eines Softwaresystems bedeuten und somit deren Ergebnisse darauf projizierbar sind. Tabelle 2 zeigt die Ergebnisse.

Während der Zeitaufwand zur Entwicklung der Programme sich nach den drei Entwurfsmethoden kaum unterscheidet, kommt es bezüglich der Zuverlässigkeit zu deutlich differenzierten Ergebnissen. Für die Programme, die nach Composite Design und nach dem Jackson-Verfahren entwickelt wurden, ergibt sich ein fast identisches Bild für die Zuverlässigkeit; Team 3, das nach dem mehrdimensional abgestuften Entwurf arbeitete, lieferte dagegen ein Programmsystem, das nur ein Viertel der Fehler der anderen Teams enthielt.

Zur Relativierung dieser Ergebnisse bezüglich anderer Untersuchungen wird hier die Fehlerrate pro Lines of Code (LOC) angegeben und in Tabelle 3 zwei Werten aus der Literatur gegenübergestellt.

Effizienz

Unter Effizienz wird hier ausschließlich die Beanspruchung der Betriebsmittel verstanden. Da sich die drei Lösungen bezüglich Intern- und Externspeicherbedarf kaum unterscheiden, genügt es, die Laufzeit der Programme zu vergleichen, (zumal der verwendete Rechner keine Aufzeichnungen über den Betriebsmittelbedarf liefert).

Die Antwortzeiten im Dialog unterscheiden sich nicht meßbar. Für die Ermittlung des Bestellvorschlags, einen größeren Batch-Lauf, ergaben sich folgende Laufzeiten (in Minuten):

Dokumentation

Die Dokumentation der Programme besteht aus den Entwurfsunterlagen. Nach Abschluß der Programmentwicklung wurde die Dokumentation von einer Versuchsperson auf Verständlichkeit untersucht. Der Leser der Unterlagen kannte die verschiedenen Entwurfsmethoden in gleichem Maße, nicht aber den Inhalt der Programme. Das Ergebnis ist:

- Bezüglich der Lesbarkeit ergeben sich bei keiner der Methoden Probleme. Die Dokumentation ermöglichte in jedem Fall einen raschen Einstieg in die Programme.

- Die Entwurfsdokumente müssen nach Abschluß der Programmierung überarbeitet werden. In allen Fällen ergaben sich Abweichungen zwischen der endgültigen Dokumentation und den führen Entwurfsdokumenten.

Bezeichner

Mit diesem Faktor wird die Qualität der Bezeichner von Datenvariablen, Paragraphennamen, Sectionsnamen und ähnlich fungierenden Kommentaren angesprochen, also die Lesbarkeit der Programme unter Ausschluß der Klarheit der Struktur.

Die drei Verfahren liefern grundsätzlich in gleicher Weise natürliche, das Verständnis des Inhalts fördernde Bezeichner. Ein Unterschied ist nur bezüglich Paragraphennamen nach dem Jackson-Verfahren zu erkennen. Danach werden die Knotentexte der Programmstruktur um eine Kurzbezeichnung der Kontrollkonstrukte (SEL, SEQ, ITER) erweitert. Diese zusätzliche Aussage verstärkt zwar die Beziehung zwischen Entwurfsdokument und Programm, wird aber beim Lesen eher als erschwerender Ballast empfunden.

Einheitlichkeit

Mit dem Faktor Einheitlichkeit wird erfaßt, ob die Strukturierung des Programms durchgängig nach denselben Regeln gebildet wurde. Sie hängt davon ab, ob das Programmentwurfsverfahren unabhängig von der Person des Entwerfers zur gleichen Zerlegung führt (Strukturierungsstärke) und ob der Entwerfer die Regeln des Verfahrens stets befolgt (Verfahrenstreue). Wird fortgesetzt