Ergebnisbewertung beim Tool-Einsatz meist subjektiv gefärbt (Teil 1)

Nur Maßnahmenverbund senkt SWE-Kosten

22.02.1985

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.

Innerhalb des Software Engineering hat sich - beginnend mit den grundlegenden Arbeiten von Halstead - die Teildisziplin "Software Science"

herausgebildet. Ihr Ziel ist es, Eigenschaften von Software zu messen. Sie hat dafür zahlreiche Maße (Software Metrics) entwickelt. Beispiele sind (16):

- die Länge von Programmen

- die Schwierigkeiten von Programmen

- der Programmieraufwand

- der Aufwand zum Verstehen eines fremden Programms.

Könnte die Software Science validierte Maße für die oben genannten Programmeigenschaften liefern, so könnte man zumindest Programme, die mit unterschiedlichen Methoden und Werkzeugen erstellt worden sind, nachträglich auf ihre Qualität untersuchen und somit Aussagen über die Auswirkungen von Hilfsmitteln ableiten. Dies ist heute noch nicht ausreichend der Fall. Erste Ansätze aber sind vorhanden. So wurden beispielsweise im oben erwähnten kontrollierten Experiment zur Qualitätsbeurteilung einfache Software Metrics eingesetzt.

Die Betrachtung der quantitativen Ansätze zeigt,

- daß der Einsatz von Methoden und Werkzeugen fast ausnahmslos positiv bewertet wird,

- daß vielfältige Versuche zu einer Quantifizierung der Auswirkungen erkennbar sind,

- daß ein mit Zahlen exakt belegter Beweis für den Erfolg nicht vorhanden ist und

- daß das Ausmaß der Verbesserung noch schlechter abgeschätzt werden kann (17).

Berichte über den Methoden- und Werkzeugeinsatz beziehen sich fast ausschließlich auf geglückte Einführungen. Über mißglückte Versuche, Hilfsmittel in ORG/EDV-Abteilungen zu verankern, liest man kaum Berichte. Gleichwohl kann man fast in jedem Unternehmen hören, daß bestimmte Methoden geschult und zum Teil sogar für verbindlich erklärt wurden, aber trotzdem nicht eingesetzt werden und daß das eine oder andere Werkzeug gekauft aber nicht oder nur von einem Mitarbeiter benutzt wird. (sogenannte "Schrankware").

Die quantitativen Aussagen bieten allein keine Grundlage für die Entscheidung, ob eine konkrete Methode oder ein bestimmtes Werkzeug in einem Unternehmen einzusetzen ist.

Eine einseitige Abstützung auf Ergebnisse der bisher dargestellten Art birgt vielmehr Gefahren in sich. Das Streben nach quantifizierten Entscheidungsgrundlagen verdeckt allzu leicht nicht quantifizierbare Größen. So werden beispielsweise in allen Bereichen über den Erfolg von Hilfsmitteln der Softwareentwicklung Methoden und Werkzeuge der Istanalyse und Grobkonzeption praktisch vernachläßigt. Der Erfolg etwa einer Zielfindungstechnik schlägt sich unter Umständen darin nieder, daß Teile eines Informationssystems nicht programmiert werden. Auf das Maß "Lines of Code/Mannstunde" wirkt dies kontraproduktiv. Ebenso liefert die rückwirkende Erfassung von Datenelementen in Data Dictionaries eine sinkende "Produktivität".

Damit sollen die Bemühungen um die Messung der Wirkungen von Methoden und Werkzeugen nicht rundweg abgelehnt werden. Es sei aber vor einem Taylorismus der Softwareentwicklung gewarnt, in dem der Lines of Code-Umsatz an die Stelle der betrieblichen Ziele einer Softwareentwicklung gestellt wird.

Wenn der Nutzen des Einsatzes von Methoden und Werkzeugen nicht ausreichend quantifizierbar ist, muß man auch qualitative Argumente in die Entscheidung aufnehmen Dies ist ein Vorgehen, das sich in der betrieblichen Entscheidungsfindung gerade im Zusammenhang mit der Einführung von EDV-Anwendungssystemen als einziger Weg erwies

Die Problematik liegt nun in einer Feststellung der Einflußfaktoren, ihrer Gewichtung und einer Bewertung der zur Auswahl stehenden Methoden und Werkzeuge Ein Haupthindernis dafür ist die Ideologisierung des Software eingineering Kombinationen von methodischen Bestandteilen und Werkzeugfunktionen erhalten eigene Methodennamen, werden durch neue Begriffe mystifiziert und dann als Pakete angeboten.

Da jedes softwaretechnologische Hilfsmittel auf die konkrete Einsatzumgebung eines Unternehmens angepaßt werden muß, wird vorgeschlagen, die Bestandteile des Instruments und ihr Zusammenwirken beziehungsweise ihre Schnittstellen zum Bestehenden einzeln zu prüfen Es ist zunächst die Frage zu stellen, was soll mit der Methode/dem Werkzeug erreicht werden Dann ist daraus eine Zielhierarchie abzuleiten.

Hier kann nicht eine unternehmensunabhängige Zielhierarchie für die ganze Breite der Softwareentwicklung aufgebaut werden Statt dessen stellt der Kasten als Beispiel eine Zielhierarchie zur Analyse von Methoden und Werkzeugen für den Entwurf dar. Bei den technischen Zielen wurde auf eine möglichst hohe Vollständigkeit geachtet Die sozialen Ziele und die quantifizierten Kostenziele sind stärker unternehmensspezifisch und daher hier nur exemplarisch aufgezählt Daneben müssen alle Kriterien, die bei der Auswahl von Standard Softwarepaketen angewandt werden, eingehen Wie ein Teil der Ziele muß auch die Zielgewichtung unternehmensspezifisch geschehen.

Neben den bereits erwähnten Problemen hat man es in der qualitativen Analyse mit allen Schwierigkeiten der Nutzwertanalyse zu tun Vergleicht man aber allein am Beispiel der Ziele für den Entwurfsbereich die Breite der qualitativen Betrachtung mit der der quantitativen Analyse, so wird klar, daß eine unternehmensspezifische Entscheidung eine detaillierte Betrachtung nicht quantifizierter Faktoren erfordert Hinweise über empirisch "nachgewiesene" Erfolge von Hilfsmitteln können lediglich den Anstoß und die grobe Richtung geben.

Zusammenfassend läßt sich die Frage nach den Auswirkungen von Methoden und Werkzeugen wie folgt beantworten:

- Methoden und Werkzeuge erhöhen die Software-Wirtschaftlichkeit (Die Dunkelziffer der glückten Einführungen darf aber nicht übersehen werden.)

- Methoden und Werkzeuge sind nur eine Möglichkeit unter mehreren zur Steigerung der Produktivität der Softwareentwicklung (Boehm zeigt, daß der Einfluß der Mitarbeiter- und Teameigenschaften doppelt so groß ist (18).)

- Die quantitative Analyse des Erfolges software-technologischer Hilfsmittel und die Berichte darüber sind mit großer Vorsicht zu verwenden, Sie können Hinweise geben, sind aber keine Entscheidungsgrundlage

- Die qualitative Analyse - ergänzt um quantitative Aussagen - muß die Basis für die Entscheidungen liefern

Literaturhinweis

(16) Shen, V. Y, Conte, S. D., Dunsmore, H. E., Software Science Revisited: A Critical Analysis of the Theory and Its Empirical Support, IEEE Transactions on Software Engineering 9 (1982) 2 S.155 - 165.

(17) s. dazu auch Abel, E., Harraß, E., Schoenen, H. J., SchwaId, A., a.a.O., S. 46 sowie Wirtz, K. W., Messung der Programmiererproduktivität bei der Entwicklung betrieblicher Anwendungsprogrammsysteme, Wison Verlag Köln, 1980.

(18) Boehm, B. W., a.a.O., S. 642. vgl. auch Schmitz, P., Situation des Testens und der Aufwandsschätzung in der Praxis. Auswertung der Fragebogenaktion, Bericht der Projektgruppe Softwaretechnologie der Universität Köln 1978, S. 31.

- Zielhierarchie für Methoden und Werkzeuge des Entwurfs

Wirtschaftlichkeit im Entwurf Technische Ziele Bestandteile Explizite Zielformulierung pro Teilsystem Manuelle und maschinelle Informationsverarbeitung Hilfe zur Vollständigkeit Hilfe zur Einfachheit Hilfe zur Systemabgrenzung Hilfe zur Entscheidung über die Implementationsart Regeln zur Namensvergabe

Betrachtung aus der Sicht der Funktionen Funktionshierarchie: Modularisierung Mehrfachverwendung Kontrollstruktur Vollständigkeit der Funktionsbeschreibung

Betrachtung aus der Sicht der Daten Datenhierarchie Datenstruktur Datenbankentwurf Datenkapseln Klassifizierungsrahmen für Daten Vollständigkeit der Datenbeschreibung,

Betrachtung des Datenflusses

Behandlung der Nebenläufigkeit

Rechnerunterstützung Editierunterstützung Testeditor Syntaxgesteuerter Editor Entwurfs- (Entwicklungs-) datenbank Generieren zusätzlicher Darstellungsformen

Zusammenwirken der Bestandteile Vermeidung von Doppelarbeit bei der Beschreibung Minimale Redundanz in der Entwicklungsdatenbank Vollständigkeit der Betrachtungsweisen Durchgängkeit von Vorstudie bis Wartung

Schnittstellen zur Umgebung Sourcecode-Verwaltung: Ablage und Abruf

Data Dictionary: Ablage und Abruf Programmgenerator: Übergabe von Programmteilen Teamorganisation: Zuordnung von Entwurfsfunktionen Test: synchroner Testfallentwurf Review: Definition der Rewiewpunkte, Checklisten

Allgemeine Merkmale Einfache Handhabung der Dokumente Vermeidung unnötiger Teiltätigkeiten Kürze der Darstellung Eindeutigkeit der Darstellung Kommunikationsfähigkeit der Darstellung Ausreichende Standardisierung Klarheit der Regeln Top-down-Vorgehen Normalverarbeitung vor Totalverarbeitung Zurückstellen physischer Aspekte Rekursivität des Vorgehens

Soziale Ziele Akzeptanz Zufriedenheit der Mitarbeiter

Quantifizierbare Kosten Kaufpreis Rechnerbelastung