Supertools und Sprachen der vierten Generation haben eine neue Ära im Softwarebusiness eingeleitet. Die Programmierschmieden versprechen Produktivitätssteigerungen von 100 Prozent und mehr. Wie ist es jedoch wirklich um diese "objektiven" Meßmethoden für Softwareproduktivität bestellt? Hans-Ulrich Altschoeller, Marketingleiter für Computersysteme der Burroughs Deutschland GmbH, beleuchtet in seinem Beitrag kritisch die etwas euphorischen Wertangaben der Branche.

Im Umfeld sinkender Hardwarepreise sind Softwarekrise und Anwendungsstau griffige Schlagworte für die Situation in der Informationsverarbeitung geworden. An Verbesserungsansätzen hat es bisher nicht gefehlt. Höhere Programmiersprachen, strukturierte Programmierung, modularer Systementwurf sowie Abfrage- und Reportgeneratoren haben subjektiv zur Krisenlösung beigetragen. Auch die Methode des "Prototypings" wird sicherlich die Gesamtwirtschaftlichkeit von Softwareprojekten erhöhen, denn sie geht das klassische Problem der Akzeptanz des Softwareproduktes durch die Fachabteilung an. Aber ist die Verbesserung meßbar?

Es wird heute euphorisch über die durch Anwendungsgeneratoren wie etwa Linc oder Mapper erzielten Kosteneinsparungen bei der Anwendungssoftwareentwicklung berichtet. Beim Einsatz derartiger Generatoren werden Lösungen nach Eingabe von Spezifikationen in einer geschäftlichen Umgangssprache automatisch erzeugt. Es entfällt die aufwendige manuelle Codierarbeit. Das Personal, das sich bisher mit der Lösung von technischen Computerproblemen und komplexen Programmieraufgaben befaßte, kann heute zur Lösung der eigentlichen Geschäftsprobleme eingesetzt werden.

Es ist schon jetzt unbestritten, daß die neuen integrierten Generatoren Software zu einer kalkulierbaren Größe machen. Eine normative Wirkung und eine klare Verschiebung der Entwurfsphasen sind automatisch gewährleistet. Dem Aspekt der Qualitätssicherung wird auch durch die eindeutige Vorverlagerung der Entwicklungsphase Rechnung getragen.

Tools subjektiv interpretiert

Die mächtigen Tools sind also bereits verfügbar, aber es war bisher wenig über Ansätze zur Definition und Messung der Produktivität in der Softwareentwicklung zu hören. Ohne objektive Meßmethoden bleiben Qualität und Implementierung dieser Werkzeuge für subjektive Interpretation weit offen.

Es ist schwierig eine Produktivitätssteigerung zu quantifizieren. Als Produktivitätsfaktor wird generell die Division von Ertrag (Softwareprodukt) durch Aufwand (Zeit) definiert. Bisher wurden im Grunde nur zwei Meßmethoden vorgeschlagen: die LoC-Zählung (Lines of Code) und die Halstead's Metrics.

Die LoC Methode wurde bereits zur Zeit der ersten Sprachengeneration (Maschinensprache) benutzt. Diese veraltete Methode hat nur einen Vorteil: sie ist einfach anzuwenden.

Ihr Nachteil ist, daß Vergleiche nur innerhalb einer bestimmten Sprache möglich sind. Die LoC Methode kann zu einem direkten Vergleich zwischen Sprachen der vierten Generation und konventioneller Cobol-Programmierung nicht herangezogen werden.

Nur Funktionen sind meßrelevant

Die Halstead Metrics Methode geht hier einen Schritt weiter.

Sie stellt nur die für eine Anwendungsbewertung wichtigen Operatoren und Operanden fest unter Verwendung von Methoden und Grundsätzen der experimentellen Wissenschaft. Eine Sprachunabhängigkeit ist mit dieser Methode zwar gewährleistet, sie basiert jedoch immer noch auf der Programm-Syntax und bewertet somit nicht den Inhalt der Anwendung.

Einen deutlichen Meilenstein hat Allan J. Albrecht (IBM, White Plains) im Jahre 1979 gesetzt. Auf einem Shared/Guide Application Development Symposium stellte er erstmals einen Entwurf der Function Point Methode vor. Sie basiert auf der simplen Tatsache, daß eigentlich nur die von einem Programm geleisteten Funktionen für eine Messung relevant sind.

Function Points werden aus der Sicht des Programmanwenders ermittelt und sind somit bereits aufgrund eines Detail-Pflichtenheftes erzeugbar. Die Anwendungsbewertung erfolgt über eine Zwei-Phasen-Analyse: Klassifizierung und Zählung der Anwendungselemente in Komplexitätsgraden wie Input, Output oder Abfragen durch den Anwender sowie logische Dateien und Schnittstellen zu anderen Anwendungssystemen.

Objektivere Aufwandsmessung möglich

In dieser ersten Phase werden die Brutto-Funktionspunkte ermittelt. In der zweiten Phase werden sie dann nach dem Grad des Einflusses unterschiedlicher Faktoren auf Design und Implementierung der Anwendung gewichtet. Zu diesen Faktoren gehören zum Beispiel Anwendungskomplexität, Datenkommunikation, Durchsatzziele, Transaktions- und allgemeine Verarbeitungskomplexität. Diese Gewichtung kann die Summe der Brutto-Function Points um bis zu 40 Prozent verändern.

Es hat die Fachwelt verblüfft, daß durch diese empirische Schätzmethode eine Abweichungsspanne von weniger als 20 Prozent eingehalten wurde. Die Function Point Methode bewertet den Inhalt einer Anwendung, nicht die handwerkliche Form und das Volumen der Programme.

Diese Methode ermöglicht eine objektivere Aufwandsmessung von Projekten. Andere Methoden bieten nur den Anwendungsvergleich bei gleicher Programmiersprache und Softwaretechnologie .

Zwanzigfache Steigerung normal

Dr. Rudolph (Auckland University) hat kürzlich mit einer wissenschaftlichen Studie Aufsehen erregt. Er leitete eine Forschungsgruppe, die nach der Function-Point-Methode eine größere Anzahl von Projekten bei unterschiedlichen Gesellschaften analysierte. Die implementierten Anwendungen wurden zu einem Teil konventionell mit Cobol und zum anderen mit einem Anwendungsgenerator der vierten Generation realisiert. Rudolph konnte eine objektive Produktivitätssteigerung durch Generatoreneinsatz von durchschnittlich 2000 Prozent nachweisen.

Nach ersten zaghaften Experimenten wurde die Function Point Analyse jetzt bei einigen US-Gesellschaften als Meßmethode festgeschrieben.

Die objektive Produktivitätsmessung menschlicher Arbeit ist sicher ein heißes Eisen, denn wer läßt sich bei subjektiv guter Leistung schon gern kontrollieren. Es hat jedoch den Anschein, daß sich sowohl die neuen Bewertungsmethoden als auch die automatisierte Softwarefertigung in der Praxis durchsetzen werden.