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.

15.02.1985 - 

Ergebnisbewertung beim Tool-Einsatz meist subjektiv gefärbt, Teil 1:

Nur Maßnahmenverbund senkt SWE-Kosten

Methoden und Werkzeuge der Softwareentwicklung zielen auf eine verbesserte Wirtschaftlichkeit in der Erstellung und im Einsatz von Software. Professor Dr. Hubert Österle von der Hochschule St. Gallen stellt in seinem Beitrag die Frage. ob diese Instrumente tatsächlich ihr Ziel erreichen. Die Antwort soll eine Entscheidungshilfe bei der Auswahl und beim Einsatz von Methoden und Werkzeugen sein.

Methoden sind Richtlinien für das Vorgehen des Menschen in der Softwareentwicklung. Werkzeuge sind Programme und Maschinen zur Unterstützung von Methoden.

Bei Methoden denkt man zuerst an die Strukturierte Programmierung oder an Richtlinien für den Programmentwurf. Mit dem Begriff "Werkzeug" verbindet man zunächst Texteditoren und Data Dictionaries. Darunter ist aber wesentlich mehr zu fassen. So fallen Instrumente für alle Phasen und Aufgaben von Softwareprojekten unter diesen Begriff. Wichtig sind hierbei auch die Bestandteile von Methoden und Funktionen von Tools. Aus Literatur und Praxis bekannte Produkte stellen nahezu ausschließlich unterschiedliche Kombinationen der diversen Komponenten dar.

Softwarekosten sind Kosten für die Entwicklung und vor allem für die Wartung von EDV-Anwendungen [1]. Beide Kostenarten fallen in der Abteilung EDV/ORG an. Schwerer berechenbar sind die Kosten im Anwendungsbereich. Sie ergeben sich einerseits aus der Mitwirkung von Fachbereichsmitarbeitern in der Entwicklung und Wartung, andererseits aus den Folgen von Mängeln in der Software beziehungsweise aus verspäteter Verfügbarkeit von EDV-Lösungen. Diese Kostenarten werden heute selten ermittelt. Angesichts der zunehmenden Auslagerung von EDV-Aufgaben an die Fachabteilungen und eines wachsenden Anwendungsstaus dürfen sie aber kaum noch vernachlässigt werden. Sie spielen in der Argumentation für Werkzeuge gerade im Zusammenhang mit sogenannten Endbenutzerwerkzeugen eine große Rolle.

Die Auswirkungen von Methoden und Werkzeugen sind nicht in exakte Prozentwerte faßbar. Hier soll einerseits ein Blick auf Versuche einer Quantifizierung geworfen und andererseits die Möglichkeit einer qualitativen Bewertung untersucht werden.

Die Versuche, die Wirksamkeit von Methoden und Werkzeugen mit Daten zu belegen, sind vielfältig. Es unterscheiden sich sechs Kategorien:

- Berichte über Einsatzerfahrungen einzelner Betriebe

- Erhebung der Einsatzhäufigkeit

- Erhebung von persönlichen Einschätzungen über den Erfolg des Einsatzes

- Vergleiche "konkurrierender" Methoden und Werkzeuge

- Analyse der Einflußfaktoren auf die Softwarekosten

- Software Metrics aus der Software Science

Die Literatur liefert seit Jahren Erfahrungsberichte über den Erfolg von Methoden- und Werkzeugeinsätzen. Im Vordergrund stehen bei Aussagen über Methoden für den Funktionsentwurf (Jackson, Composite Design oder SADT), die Strukturierte Programmierung, Reviewtechniken und Projektorganisationsformen sowie Texteditoren und Sourcecode-Verwaltungssysteme.

Hier sei die Aussagekraft anhand einiger Beispiele aus Kasten 1 betrachtet.

Die Erhöhung der Produktivität, eine Senkung der Softwarekosten oder eine Reduktion der Entwicklungszeit basieren einerseits auf einer bestimmten Ausgangssituation und andererseits auf dem Ausschluß anderer Einflußfaktoren. Die Ausgangssituation ist in keinem der genannten Berichte auch nur annähernd detailliert beschrieben. Kaum eine Methode wird ohne begleitende Maßnahmen eingeführt. Daneben ist eine Vielzahl weiterer Einflußfaktoren wie etwa der Hawthorne-Effekt nicht kontrolliert, Berücksichtigt man weiter, daß viele dieser Berichte aus betriebsinternen Abschlußberichten von Methodeneinführungen entstehen, so sind die Angaben mit großer Skepsis zu lesen. Produktivitätssteigerungen, wie sie gerade im Zusammenhang mit der Markteinführung von sogenannten Werkzeugen der vierten Softwaregeneration

genannt werden, beeinträchtigen das Vertrauen in derartige Aussagen zusätzlich.

Aussagen in absoluten Werten - wie im Beispiel der Exxon [5]-sind aussagekräftiger. Hier stellt sich allerdings die Frage nach der Produktivitätskennziffer. Die Annahme, daß 1000 LOC (Lines of Code) des Betriebes A mit 1000 LOC des Betriebes B vergleichbar sind, ist für Betriebe mit ähnlicher Organisation, ähnlichen Aufgaben und ähnlichen Hard- und Software-Installationen bis zu einem gewissen Maß vertretbar. Allerdings ist auch hier die Frage nach anderen Einflußfaktoren offen. So kann etwa die untersuchte Methode Bestandteil eines umfangreichen Methoden- und Werkzeugverbundes sein oder mehr oder weniger allein stehen.

Am aussagefähigsten sind Erfahrungsberichte, wenn sie die Gründe für die Kostensenkung ausweisen, wie im Beispiel der Computer Sciences Corporation. Berücksichtigt man, daß Fehler in der Entwurfsphase mit einem geringen Bruchteil dessen beseitigt werden können, was während oder nach der Implementierung notwendig wäre, so wird der Nutzen des Walk-trough in diesem Beispiel deutlich. Doch auch hier ließen sich einige Argumente finden, die den Wert des Berichtes in Frage stellen.

Einigermaßen verläßliche Aussagen könnte man aus Erfahrungsberichten allenfalls durch die Auswertung einer großen Zahl von Berichten und durch eine Abklärung von Rahmenfaktoren in einer Nachuntersuchung gewinnen.

Vor dem Einsatz einer Methode oder eines Werkzeuges findet gewöhnlich eine betriebsindividuelle Evaluation statt. Führt der Einsatz dann zu einem erkennbaren Mißerfolg, so wird das Hilfsmittel wieder beiseite gelegt. Zwar ist der Schluß nicht zulässig, daß eine Entscheidung richtig ist, weil sie von mehreren geteilt wird, doch kann man hier davon ausgehen, daß eine Entscheidung fundierter ist, wenn unterschiedliche Evaluationen zu demselben Ergebnis führen.

Die Einsatzfähigkeit sei hier aus diesen Gründen als ein Indiz für den Nutzen von Methoden und Werkzeugen zugelassen.

Die Bilder 1 und 4 zeigen die Einsatzsituation in 90 von 336 angeschriebenen Mitgliedsunternehmen der Schweizerischen Vereinigung für Datenverarbeitung (SVD) [7].

Hilfsmittel für die Implementierung und darin insbesondere für die Programmierung stehen in beiden Bildern im Vordergrund. Dagegen treten Instrumente für die vorgelagerten Phasen, für den Datenentwurf, das systematische Testen und das Projektmanagement deutlich zurück.

Diese Resultate decken sich von den Einsatzschwerpunkten her mit Umfrageergebnissen der Gesellschaft für Mathematik und Datenverarbeitung (GMD) aus dem Jahre 1980 [8]. Allerdings liefert die (nicht repräsentative) Studie der SVD für die Schweiz im Jahre 1983 deutlich höhere Prozentsätze. Eine weitere Bestätigung dieser Einsatzschwerpunkte liefert eine Guide-Umfrage bei 800 IBM-Kunden aus dem Jahre 1979 [9]. Eine hohe Übereinstimmung finden wir auch in den Ergebnissen einer Umfrage von Seibt [10].

Die Einsatzhäufigkeit liefert eine eher vergangenheitsorientierte Betrachtung. Altere Hilfsmittel sind - infolge einer mäßigen Durchsetzungsgeschwindigkeit neuer Methoden und Werkzeuge - deutlich vorne. Die Aussagen sind damit vor allem für technologisch führende ORG/EDV-Abteilungen von geringem Wert.

Eine weitere Möglichkeit, die Auswirkungen von Methoden und Werkzeugen zu erfassen, liegt darin, die Einstellung von Anwendern der Hilfsmittel empirisch zu erfassen.

Zwar erhalten die Ergebnisse durch breit angelegte Befragungen eine größere Allgemeingültigkeit, doch dürfte das Urteil des einzeln Antwortenden noch wesentlich unsicherer als in einzelnen Erfahrungsberichten sein. Die Aussagen basieren hier weniger auf innerbetrieblichen Erhebungen als auf einem spontanen Werturteil.

Zeitschätzverfahren für Software projekte versuchen, die wichtigsten Einflußfaktoren auf den Zeitaufwand zu erfassen. Voraussetzung dafür sind empirische Untersuchungen zur Ermittlung der Einflußfaktoren und ihrer Wirkung. Herb [12] sowie Doty [13] kamen 1977 auf 46 Einflußfaktoren. Boehm [14] nahm 1981 nur noch 15 in sein Kostenschätzungsmodelle Cocomo auf.

Zwei der 15 Faktoren von Boehm betreffen Methoden (MODP: Modern Programming Practices) und Werkzeuge (TOOL: Software Tools).

Der Methoden-Faktor gibt an, wie viele der folgenden Methoden eingesetzt werden:

- Top-down-Entwurf

- Strukturierte Darstellungsform des Entwurfs

- Top-down-Implementierung

- Entwurfs- und Code-Walkthroughs oder Inspektionen

- Strukturierter Code

- Funktion des Programm-Bibliothekars im Team

Aus den Entwicklungsdaten von 56 Projekten ergab sich, daß ein umfassender Methodeneinsatz den Zeitaufwand in der ersten Phase nicht beeinflußte, in der Integration und im Test aber um 35 Prozent reduzierte (effort multiplier = 0,65). Den Einfluß auf die verschiedenen Phasen zeigt Bild 2.

Bild 3 stellt den Einfluß von Werk zeugen dar, wobei grundlegende Mikroprozessor-Werkzeuge den Wert "very low" und fortschrittliche "Maxicomputer-Werkzeuge" den

Wert "very high" zugewiesen bekamen.

Die Ergebnisse von Boehm sind allgemein für die Einschätzung der Wirksamkeit von Methoden und Werkzeugen von Bedeutung. Eine Entscheidungshilfe für die Einführung einer bestimmten Methode oder eines Werkzeuges sind sie kaum, da sie über die Wirkung einzelner Hilfsmittel nichts aussagen.

Das Vorgehen von Herb, Doty sowie Boehm stellt aber einen Ansatz dar, der grundsätzlich für die Messung der Wirksamkeit von Methoden und Werkzeugen geeignet ist.

Voraussetzung dafür ist eine sehr differenzierte Projektdatenerfassung.

Auch hier müssen noch methodische Bedenken angebracht werden. Einerseits wurden die Einflüsse der Faktoren aus einer Teilmenge der Projektdaten abgeleitet, an denen hinterher auch die Gültigkeit des Modells geprüft wurde; andererseits wird die Wirksamkeit anhand der Kennzahl Lines of Code/Mannmonat gemessen. Diese methodischen Risiken erscheinen aber gering im Vergleich zu denen der oben genannten Vorgehensweisen.

Eine weitere Form zur Messung des Methoden- und Werkzeugerfolges ist das kontrollierte Experiment. In ihm wird die gleiche Entwicklungsaufgabe nach verschiedenen Vorgehensweisen gelöst. Das Attribut "kontrolliert" besagt, daß alle Einflußfaktoren unter Kontrolle, das heißt am einfachsten konstant gehalten werden und nur das untersuchte Hilfsmittel variiert wird.

In einem derartigen Experiment wurden an der Universität Dortmund drei Methoden zum Programmentwurf verglichen l151. Es waren dies

- Composite Design,

- Jackson Structured Programming und

- mehrdimensional abgestufter Entwurf

Für jede Methode wurde ein Team gebildet. Die drei Teams lösten dann eine Aufgabenstellung aus der Praxis (Teil eines Standardpaketes "Bestellwesen") jeweils nach der ihnen zugeordneten Methode.

Das Ergebnis zeigt, daß der Gesamtaufwand zur Implementierung der Programme in etwa gleich war Obwohl die Programme der drei Teams praktisch leistungsgleich waren, ergaben sich allerdings stark variierende Werte für die Kennzahl "Lines of Code/Mannstunde".

Die Ergebnisse des Experimentes wurden auch hinsichtlich ihrer Qualität bewertet. Hier ergaben sich die größten Unterschiede zwischen den drei Arbeitsergebnissen.

Trotz aller Sorgfalt, mit der das Experiment ausgeführt worden ist, müssen auch diese Ergebnisse vorsichtig interpretiert werden.

Obwohl für die Teambildung ein Eingangstest verwendet worden ist, liegt die größte Schwäche des Experimentes in den Persönlichkeits- und Teammerkmalen. Dieses Problem wäre nur durch eine größere Zahl von Gruppen lösbar, was aber praktisch nicht machbar ist. Ein experimenteller Methodeneinsatz ist nicht ohne weiteres mit einem Routineeinsatz gleichzusetzen. Die Bewertung der Ergebnisse in einem Qualitätsindex ist subjektiv gefärbt.

Der Wert kontrollierter Experimente liegt weniger in einem quantifizierten Beweis für die Vorteilhaftigkeit einer Methode oder eines Werkzeuges als vielmehr im Erkennen

von Wirkungskreisen von Hilfsmitteln und in der Feststellung unterschiedlicher Eigenschaften der Produkte, die mit den Hilfsmitteln erstellt worden sind. (wird fortgesetzt).