Die Produktivität der Datenverarbeitung wird heute in dem Verhältnis von bereitgestellter Funktionalität zur benötigten Zeit dargestellt (Function-Point/ Zeit). Aus der so definierten Produktivität in der Software-Entwicklung lassen sich eine Vielzahl von Erkenntnissen gewinnen: Wie wirken sich Investitionen im Bereich Software-Tools und Methoden aus? Läßt sich die Software für Computer vom Typ A billiger erstellen als für Typ B? Wie steht es um die Produktivität der eigenen Software-Abteilung im Vergleich zum Durchschnitt der Branche?

Nutzt ein Unternehmen die Function Point Analysis, um für bestimmte Produktgruppen und Entwicklungsmethoden Produktivitätskennzahlen zu gewinnen, so kann es aus der geforderten Funktionalität auf den zu erwartenden Aufwand an Zeit und damit auf die Kosten schließen. Die Voraussetzung für eine gesicherte Aufwandsschätzung ist ein zuverlässiges Berichtswesen, das für abgeschlossene gleichartige Projekte deren Größe in Function Points und die Zeit, die für deren softwaremäßige Umsetzung aufgewandt wurde, festhält.

Kennt ein Unternehmen die Produktivität seiner Software-Abteilung, dann lassen sich auch die Entscheidungen für Eigenentwicklung, den Einsatz von Standardsoftware oder die Einbeziehung externer Softwarehäuser auf eine abgesicherte Basis stellen. Nutzt ein Unternehmen die Function Point Analysis, so kann es zur Entscheidungsfindung die zu erwartenden Kosten der zu realisierenden Funktionalität gegenüberstellen.

In der Vergangenheit hingegen lag dem Management nur die Kostenrechnung für eine Maßnahme vor. Die dem Aufwand entsprechenden Leistungen waren nicht darstellbar. Wie unsinnig eine solch einseitige Information ist, zeigt folgendes Beispiel: Sie genehmigen 500 000 Mark für einen Hausbau, ohne zu wissen, wie viele Quadratmeter Fläche das Haus haben wird.

Mit Einführung der Function Point Analysis sind nicht mehr allein die Kosten der Software-Erstellung maßgeblich, sondern auch die voraussichtliche Höhe der Kosten im Verhältnis zur geplanten Funktionalität.

Viele Softwareprojekte scheiterten in der Vergangenheit daran, daß die Aktivitäten Produktplanung und Realisierung nicht getrennt waren. In der DV liegen die Funktionen des Architekten, Statikers und Bauunternehmers immer noch in einer Hand. Das führt dazu, daß die Realisierung beginnt, bevor ausgearbeitete, abgestimmte und vom Auftraggeber genehmigte Pläne vorliegen.

Wenn aber keine Ausgangspläne vorliegen, dann können sowohl Auftraggeber als auch -nehmer unbemerkt Änderungen in den Plänen vornehmen.

Mit der Function Point Analysis läßt sich die Funktionalität einer vorliegenden Planung messen. Damit ergibt sich die Möglichkeit, im Verlauf der Entwicklung zu kontrollieren, ob die Pläne eingehalten werden. Nur wer inhaltliche Abweichungen erkennen kann, ist in der Lage, notfalls einzugreifen.

Der größte Teil des Aufwandes für die Software fällt bei der sogenannten Softwarewartung an. Da in fast allen Unternehmen keine Aufzeichnungen über die Aktivitäten bestehen, die im Rahmen der Wartung anfallen, werden die Kosten global pauschaliert, budgetiert und abgerechnet. Gegenüberstellungen der Kosten in Relation zu den erbrachten Leistungen sind nicht üblich. Somit ist auch keine Analyse des Kosten-Leistungs-Verhältnisses möglich.

Die wenigsten Unternehmen sind sich bewußt, welches Kapital im Anlagenbereich Software gebunden ist selbstgeschriebene Software erscheint nicht in der Bilanz deutscher Firmen. Für die Planung des Softwarebereiches ist nicht nur wichtig, zu wissen, welchen Wert die Software darstellt, sondern welche Funktionalität sie abdeckt und wie alt sie ist.

Die Bewertung des Softwarebestandes nach der Funktionalität, die dem Anwender zur Verfügung steht, zeigt auch auf, wie hoch der Eigenverbrauch der Software-Entwickler in puncto Software ist. Darunter sind gekaufte und selbstgeschriebene Tools zu verstehen.

Die Spannungen zwischen DV-Anwender und Software-Abteilung entstehen dadurch, daß die Software-Anbieter nicht das Preis- Leistungs-Verhältnis ihrer Produkte verdeutlichen können. Die Anwender erhalten ihrer Meinung nach nie das, was sie benötigen - und für das Falsche ist jeder Preis zu hoch.

Die Function Point Analysis kann dem Anwender den Preis in bezug auf die von ihm verlangte Funktionalität der Software erklären. Diese Methodik läßt es sogar zu, daß er selbst die Kosten seiner Aufgabenstellung ermittelt. Der Käufer muß Softwarelieferanten gegenüber den Preis nicht mehr kritiklos akzeptieren. Er kann dessen Angemessenheit selber nachvollziehen, ohne in die Geheimnisse der Software-Erstellung eingeweiht zu sein.

Wie bei den meisten Rationalisierungsmaßnahmen ist auch bei der Function Point Analysis ein Gesetz zu beachten: Bevor man ins Schlaraffenland gelangt, muß man sich mühselig durch einen Reisberg hindurch essen. Viele geben dabei auf.

Die wichtigste Maßnahme, die vor der Einführung einer Softwaremetrik erfolgen muß, ist die Einführung von einheitlichen Arbeitsmethoden. Aus der Sicht der Softwaremetrik ist es unerheblich, nach welcher Methode gearbeitet wird - nur einheitlich muß es sein. In jeder Methodik lassen sich Zeitpunkte und damit auch Ergebnisse definieren, die als Grundlage für eine Messung dienen. Einheitliche Meßgrundlagen sind die Voraussetzung für vergleichbare Ergebnisse.

Dies bedeutet, daß vorgegeben sein muß, wie die Funktionalität einer Software aus der Sicht des Anwenders zu beschreiben ist und welchen Umfang dieser Kriterienkatalog haben muß. Solange es den Software-Entwicklern gestattet ist, ohne verbindliche Regeln zu arbeiten, wird das Bestreben, Softwaremetriken einzuführen, scheitern. Das Management muß durchsetzen, daß die Entwickler langfristig nach einheitlichen Richtlinien arbeiten und zu bestimmten Zeitpunkten im Arbeitsablauf genau definierte Dokumentationen vorlegen.

Durch die Einführung von Softwaremetriken und Arbeitsrichtlinien allein sind keine Bewertungen der Kostensituation und Prognosen hinsichtlich deren Entwicklung möglich. Um Aussagen darüber zu machen, ob sich etwas verändert hat, müssen Vergleichsbasen vorliegen. In der Software-Entwicklung müssen, wie in jedem anderen Bereich, zwei Kostenbasen definiert sein: zum einen Kosten, die durch Eigenschaften des Produktes bestimmt werden, und zum anderen Kosten, die auf Bedingungen im Entwicklungsbereich zurückzuführen sind.

Einflußfaktoren, die auf Qualitätsmerkmale zurückgehen, können unter anderem sein: Zeitverhalten, Zuverlässigkeit, zulässige Fehlerhäufigkeit, Benutzerfreundlichkeit etc. Faktoren, deren Ursache im Entwicklungsumfeld liegen, sind zum Beispiel Know-how der Mitarbeiter, Kenntnisse der Programmiersprachen, Arbeitsmethoden und Betriebssysteme.

Das Management muß verlangen, daß die Standardmerkmale für die Beschreibung der Qualität der Produkte und des Entwicklungsumfeldes als generelle Kalkulationsbasis definiert sind. Hierzu ein Beispiel: Die durchschnittliche Antwortzeit beträgt drei Sekunden, die Dokumentation ist einsprachig, Standard für die Programmiersprache ist C++, das durchschnittliche Team umfaßt vier Personen, die im Schnitt seit fünf Jahren im Unternehmen tätig sind.

Erst wenn neben Veränderungen im funktionalen Umfang auch die Veränderungen bei den Einflußfaktoren darstellbar sind, lassen sich aussagekräftige Analysen hinsichtlich Entwicklung der Kosten, der Produktivität und so weiter erstellen.

Ergebnisse von Softwaremetriken können nur dann sinnvoll interpretiert werden, wenn die dazugehörigen Objekte klassifiziert sind. Deshalb sind die Berichtswesen in der Software-Entwicklung durch Beschreibungen zu ergänzen. Es kann nicht mehr ausreichen, nur nachzuweisen, daß etwas getan wurde sowohl der Gegenstand der Leistung als auch die Situation, unter der die Leistung erbracht wurde, müssen erkennbar sein.

Im Hinblick auf ein Qualitäts-Management haben bisher nur wenige Unternehmen ein Berichtswesen eingeführt. Hier muß das Management mehr fordern: Es müssen Fehlerstatistiken (Anzahl, Art, Bedeutung, Zeitpunkt des Ereignisses etc.) erstellt werden, die die Auswirkungen von Maßnahmen zur Qualitätsverbesserung belegen und begründen können.

Alle durch das Management veranlaßte Maßnahmen verlieren ihren Wert, wenn es nicht darauf achtet, daß erlassene Regeln auch eingehalten werden. Wichtig ist außerdem die Motivation der Berichtenden das Management muß zu erkennen geben, daß entsprechende Berichte Aufmerksamkeit zuteil wird. Berichte über die Entwicklung der Qualität im Softwarebereich sollen dazu dienen, gezielte Maßnahmen einzuleiten, dahingehend, daß die gestellten Qualitätsanforderungen zu erfüllen sind.

Wenn die Software-Entwickler erkennen, daß die Softwaremetrik - insbesondere durch Einbeziehung der Function Point Analysis - ihre Leistungen verständlicher darstellt, dann braucht das Management nicht zu befürchten, daß die Einführung von Metriken nur auf Widerstand seitens der Entwickler stoßen wird.

Angeklickt

Den Anwender interessiert es weniger, in wie vielen Mannjahren eine Applikation erstellt wurde oder mit wie vielen Programmen und Befehlen sein Problem gelöst wird. Alle modernen Softwaremetriken versuchen heute, die Bedeutung der Software für den Anwender zu messen. Sie machen deshalb die gelieferte Funktionalität zur Basismaßeinheit. Den User interessiert zunächst nur, welche Funktionalität ihm geboten wird und welche Kosten ihm daraus entstehen. Die international am häufigsten angewandte Maßeinheit in der Software-Entwicklung ist das Function Point.

Lexikon

Softwaremetrik faßt alle Methoden und Maßnahmen zusammen, die Kennzahlen zur Bewertung von Applikationen und deren Entwicklung liefern. Solche Kennzahlen geben beispielsweise Aufschluß über funktionalen Umfang der Software, ihre physische Größe, Produktivität in der Entwicklung, Qualität des Produkts etc.

Function Point Analysis ist eine Methode, um die Funktionalität einer Software zu messen, die in bezug auf die Anwender gegeben ist. Function Points (FPs) dienen als Maßeinheit für die Funktionalität. Sie sind unabhängig von der technischen Realisierung eines Programms, zum Beispiel den verwendeten Sprachen, Entwicklungsmethoden und Strukturen. Function Points sind international die Basisgrößen in der Softwaremetrik sie kennzeichnen Aufwand, Programmierfehler, Lines of code, Mannjahre etc. gegenüber FPs. In den USA und einigen anderen Ländern kann man Prüfungen zum "Certified Function Point Analyst" ablegen.

*Robert Hürten ist Geschäftsführer der Hürten & Partner Unternehmensberatung in Riedstadt-Leeheim.