Planung "über den Daumen" kann ins Auge gehen:

Function Points optimieren Projektmanagement

01.05.1987

Fehlkalkulationen und mangelhafte Planung haben schon so manches DV-Projekt zum Scheitern gebracht. Die heute oft übliche Schätzmethode "Pi mal Daumen" kann sich also als sehr gefährlich erweisen. Als Alternative empfiehlt Robert Hürten das Function-Point-Verfahren.

"Es wird immer teurer als geplant." Dieser Stoßseufzer vieler DV-Verantwortlicher wird bestätigt durch Untersuchungen der Universitäten Köln und Osnabrück: Im Rahmen ihrer Studien stellten die Forscher der Hochschulen Überziehungen der Planzahlen um bis zu 300 Prozent fest. Dabei zeigte sich ferner, daß die Abweichungen zwischen Plan und Ist mit zunehmender Projektdauer stiegen.

Dies verwundert den Fachmann nicht. Bei Projekten, die länger als zwei Jahre dauern, wird der planerische Ansatz von der betriebswirtschaftlichen Realität allzu oft überholt. Dadurch erweisen sich Korrekturen an der Aufgabenstellung als notwendig. Bei langen Projekten wächst ferner die Wahrscheinlichkeit, daß das Projektteam der normalen Fluktuation unterworfen ist. Damit steigt der Aufwand für Kommunikation und Einarbeitung neuer Teammitglieder merklich.

Will man heute die Ursache für die Überziehung der geplanten Projektdauer ermitteln, so wird dies in den meisten Fällen nicht möglich sein; denn in den Unternehmen gibt es oft keine Unterlagen, die als Basis für die Ermittlung der Planansätze vorliegen.

Drei Hauptfaktoren bestimmen den Aufwand für ein DV-Projekt:

- der Funktionsumfang des Projektes,

- die Qualitätsanforderungen an das zu erstellende Produkt,

- die Produktivität der Organisationsabteilung beziehungsweise der Softwareentwicklung.

Das Function-Point-Verfahren zur Schätzung des Projektaufwandes basiert als einzige Schätzmethode auf den genannten drei Faktoren. Diese Methode wurde von Allen Albrecht, einem Mitarbeiter der IBM in den USA, entwickelt und kann schon in einem sehr frühen Projektstadium eingesetzt werden. Außerdem orientiert sie sich vorwiegend an der Anwendersicht und führt zu zuverlässigen Ergebnissen.

Die Ermittlung des Aufwandes erfolgt beim Function-Point-Verfahren in drei Schritten:

In der ersten Phase wird der Funktionsumfang des zukünftigen Softwareproduktes auf wenige Begriffe reduziert: Eingaben, Ausgaben, Abfragen, Datenbestände und Referenzdaten/Tabellen.

Der Schätzer hat auf der Grundlage des organisatorischen Grobkonzeptes zu ermitteln,

- wie viele Aufgaben (zum Beispiel Auftragserfassung, Auftragskorrektur, Erstellen Versandpapiere) geplant sind und welche Funktionen (Erfassen Auftragskopf, Erfassen Auftragsposition, Druck Auftragsbestätigung) verlangt werden und

- welche Datenbestände, Referenzdaten und Tabellen aus der Datensicht notwendig sind.

Die Ermittlungen sind zunächst rein quantitativ. Das heißt, es werden zunächst die Funktionen gezählt, ohne detaillierte Kenntnisse über den Inhalt und den Aufbau von Bildschirmen, Druckausgaben und Dateien zu haben. Der Schätzer sagt lediglich aus der Sicht des Anwenders, ob die Funktionen leicht, mittel oder komplex zu bewerten sind. Als komplex zu bewerten wäre zum Beispiel eine Bildschirmeingabe mit mehr als zehn Eingabefeldern, die besondere Prüfroutinen verlangen und bei der außerdem hohe Ansprüche an die Bedienerführung gestellt werden

Qualitätsanforderungen sind abzuklären

In einem zweiten Schritt ist anhand von wenigen Fragen festzustellen, ob geringe oder hohe Qualitätsanforderungen vorliegen. Zu klären ist beispielsweise, ob die Lösungen auch in anderen Organisationsbereichen verwendet werden sollen oder ob hohe Ansprüche an die Antwortzeiten bei großer Systembelastung zu stellen sind.

Aus Funktionsumfang und Qualitätsanforderung errechnet man in einem dritten Schritt nach einer einfachen Rechenregel eine Summe von Function-Points. Diesem Ergebnis kann dann der Schätzer über eine Funktionskurve "Function-Points pro Mann-Monaten" den Aufwand in Mann-Monate zuordnen.

Die Funktionskurve beschreibt die Produktivität der Software-Abteilung. Da zum Beispiel neue Mitarbeiter, Methoden und Tools Einfluß auf die Produktivität einer Abteilung haben, liegt hier keine starre Relation vor. Man muß deswegen ständig prüfen, ob und wieweit sich die Produktivität in der Softwareentwicklung verändert hat.

Das Function-Point-Verfahren verlangt einen Formalismus in der Darstellung des Funktionsumfanges. Damit liegt zwangsweise eine Dokumentation der Schätzgrundlage vor. Man kann also zu einem späteren Zeitpunkt noch feststellen, welcher Funktionsumfang, welche Qualitätsanforderungen und welche Produktivitätsvorstellung in die Schätzung einflossen.

Baut man das Function-Point-Verfahren in das Projektmanagement ein und wiederholt das Schätzverfahren zum Ende der wichtigsten Entwicklungsphasen, so läßt sich feststellen, ob Änderungen in den Planungsgrundlagen vorgenommen wurden. Sind bereits zu diesem Zeitpunkt Terminverschiebungen eingetreten, so werden aus der neuen Schätzung die Ursachen für diese Terminverschiebungen ersichtlich.

Erfahrungen werden in einer Datenbank gesammelt

Auch wenn bis zum Zeitpunkt der neuen Schätzung noch keine Terminverschiebung eingetreten ist, gibt das Function-Point-Verfahren wichtige Informationen über den bisherigen und zukünftigen Projektverlauf. Unterscheiden sich die Summen der Function-Points aus der neuen Schätzung von der Summe der alten Schätzung, so bedeutet dies, daß in der Zukunft mit einem veränderten Aufwand gerechnet werden muß. Aus den Differenzen bei den drei Schritten des Function-Point-Verfahrens kann dann gefolgert werden, ob sich der Funktionsumfang verändert hat, ob andere Ansprüche an die Qualität gestellt werden oder ob gar eine Verschiebung in der Produktivität eingetreten ist.

Die praktische Arbeit mit dem Function-Point-Verfahren bestätigt immer wieder, daß der Aufwand auch bei wiederholtem Schätzen im Vergleich zu der Gesamtprojektdauer verschwindend gering ist. Der gegenüber der heute üblichen Daumenschätz-Methode eventuell entstehende Mehraufwand zahlt sich dadurch aus, daß eine fundierte Analyse des Projektverlaufes erfolgt. Außerdem läßt sich eine Erfahrungsdatenbank aufbauen, mit deren Hilfe zukünftige Projekte von Fall zu Fall genauer geschätzt werden können.

*Robert Hürten ist Berater bei der ECU EDV-Controlling Unternehmensberatung GmbH Heppenheim.