CW: Welches Ziel verfolgt die Funktionspunkt-Analyse?
Rudolph: Ganz simpel ausgedrueckt: Sie soll die Software- Entwicklung kalkulierbar machen. Funktionspunkte erlauben die Messung dessen, was ein Entwickler fuer den Benutzer leistet. Sie sind ein Mass fuer den Umfang einer Entwicklung. Entwicklungsprojekte werden vergleichbar. Mit Funktionspunkten laesst sich nachweisen, vor welcher Anzahl von Software- Entwicklungsproblemen der Benutzer die DV-Abteilung mit seinen Anforderungen steht und wie effektiv diese geloest werden.
CW: Wie erhaelt man die Masseinheit eines Funktionspunktes?
Rudolph: Es gibt aus Benutzersicht fuenf Vorgaenge, fuer die Punkte vergeben werden: erstens Geschaeftsvorgaenge ins System eingeben, zweitens Geschaeftsinformationen herausbekommen, drittens die direkte Abfrage von Dateninhalten, viertens Geschaeftsdaten im System speichern und fuenftens an Geschaeftsdaten anderer Systeme herankommen. Aus diesen fuenf Typen setzt sich jedes Informationssystem zusammen. Jeder Typ erhaelt je nach definiertem Komplexitaetsgrad (einfach, mittel, hoch, Anm. der Red.) eine bestimmte Anzahl von Punkten. So laesst sich etwa die Funktion Eingabe, egal fuer welche Branche, eindeutig festlegen und entsprechend mit Punkten versehen.
CW: Dieses funktionale Verfahren klingt sehr einfach - wird es der Komplexitaet einer professionellen Software-Entwicklung gerecht?
Rudolph: Die Funktionspunkt-Analyse setzt am Anfang des Entwicklungszyklus ein, naemlich dort, wo eine Anforderung formuliert und das Pflichtenheft erstellt wird. Das ist entscheidend, sie wird dort interessant, wo jemand sagt: "Dieses Programm will ich haben, was soll es kosten?" Mit diesem Verfahren und dem Vergleich zu eigenen oder fremden Erfahrungen laesst sich relativ sicher angeben, wieviel eine Entwicklung kosten wird, wie lange sie dauert - und warum sie so lange dauert.
Die Benutzer koennen nachvollziehen, wieviel Zeit die Realisation der einzelnen Funktionen in Anspruch nimmt. Heute erwarten die Kunden: "Das Programm ist in einem Jahr fertig", weil sie es eben in einem Jahr benoetigen. Ohne eine von beiden Seiten getroffene verbindliche Vereinbarung werden falsche Hoffnungen gehegt oder die Anforderungen unterschaetzt. Mit der Funktionspunkt-Analyse aber werden die Kunden gezwungen, einzelne Funktionen aufzuzaehlen.
Das ist wie im Supermarkt: Die Waren, die Sie in Ihrem Einkaufskorb sammeln, kosten vielleicht jeweils zwischen zwei und fuenf Mark - an der Kasse muessen Sie aber 200 Mark zahlen. Wenn Sie wissen wollen, wie dieser Preis zustande kommt, nehmen Sie den Kassenbon und gehen das ganze Punkt fuer Punkt durch. Haben Sie nicht genuegend Geld dabei, dann nehmen Sie eben das eine oder andere wieder aus dem Korb.
CW: Laesst sich mit der Funktionspunkt-Analyse die Effizienz verschiedener Methoden und Programmiersprachen vergleichen?
Rudolph: Richtig, und darin liegt ein riesiger Vorteil. Sie koennen sagen: Im Schnitt ist es guenstiger chaotisch zu arbeiten, oder ganz strukturiert, oder auch mehr mit Werkzeugen. Mit diesem Verfahren kam ich ueberhaupt erst dazu, den Nachweis zu liefern, dass bestimmte Entwicklungsumgebungen produktiver sind als andere (Siehe Vergleich von Software-Entwicklungsumgebungen in den diesjaehrigen CW-Ausgaben 4 (22. Januar 1993) bis 7).
CW: Das Verfahren beruecksichtigt eine ganze Reihe wichtiger Faktoren nicht, zum Beispiel Personalqualifikation, interne Organisationsmaengel, Hardware-Ausstattung etc.
Rudolph: Diese Faktoren beeinflussen die Produktivitaet. Was letztlich zaehlt - und gezaehlt wird - sind die Ergebnisse von Entwicklungsprojekten. Wenn Sie ein Problem einer gewissen Groessenordnung in drei Jahren mit Assembler geloest haben, oder Sie waren pfiffig und haben bemerkt, dass das Ganze eigentlich schon als wiederverwendbarer Code in der Bibliothek existierte und haben es fix in drei Monaten zusammengebastelt, dann haben Sie aus Benutzersicht qualitativ das gleiche geleistet. Nur waren Sie mit Assembler, dem inkompetenten Personal oder der schlechteren Hardware einfach unproduktiver.
Wir machen in der Software-Entwicklung oft einen gravierenden Denkfehler. Wir meinen, nur weil wir lange arbeiten, haben wir auch viel geleistet. Das ist Unsinn. Wenn Sie schreiben: Ein Drei- Millionen-Mark-SW-Projekt ist ein grosses Projekt, dann ist das ein falscher Schluss. Sie wissen zunaechst nur, dass es ein teures Projekt ist. Ob Sie dafuer viel bekommen haben, kann man noch nicht sagen - wahrscheinlich nicht, weil das Projekt zu gross geworden ist.
CW: Gibt die Funktionspunkt-Analyse Hinweise darauf, ob eine Anwendung sinnvoller auf objektorientiertem Wege oder in Cobol oder mit einer 4GL fertigzustellen ist?
Rudolph: Sie stellt zumindest eine Vergleichbarkeit her. Man fragt zunaechst, wie gross ist das Projekt, um dann den Massstab anzulegen und zu sagen: Probleme dieser Groesse wurden bei uns oder anderen in vergleichbaren Situationen so geloest. Der objektorientierte Loesungsansatz dauert so und so lange, es gibt Projekte, die auf diese Weise durchgefuehrt wurden, ich kann vergleichen. Heute existieren laengst Datenbanken, in denen genauestens analysierte Projekte abgelegt sind. Dort lassen sich die kritischen Parameter, zum Beipiel eingesetzte Methoden, Erfahrungen der Mitarbeiter, Kooperation mit Benutzern etc. recherchieren.
CW: Die Wahrscheinlichkeit, identische Projekte vorzufinden, ist doch vermutlich verschwindend gering. Jedes Projekt unterliegt anderen Bedingungen und Einfluessen.
Rudolph: Natuerlich, die Vergleichprojekte sind aehnlich, nicht identisch. Ein Risiko bleibt immer bestehen. Eine gute Aufwandschaetzung wird daher neben dem wahrscheinlichen Zeitpunkt auch das Risiko angehen. das gilt fuer Aufwandschaetzungen generell, nicht nur in der DV.
Wir arbeiten mit im Prinzip messbaren Groessen, ob es sich nun um ein PPS-System fuer Mercedes, ein Abrechnungssystem fuer die Deutsche Bank oder eine Lohnbuchhaltung fuer Unilever handelt: Funktionspunkt ist Funktionspunkt. Natuerlich koennen die Kosten fuer bestimmte Funktionspunkte in den Unternehmen je nach Faktoren wie Personal, Fuehrungsstil etc. unterschiedlich sein.
CW: Woher bekommt man die Vergleichsinformationen?
Rudolph: Da gibt es mehrere Wege. Einer ist die Zusammenarbeit mit einer Benutzergruppe, zum Beispiel der Deutschen Anwendergruppe fuer Software-Metrik und Aufwandschaetzung (DASMA). Oder man kauft die Informationen in Form sogenannter gehobener Aufwandschaetzungs- Programme. Dazu zaehlen zum Beispiel "Slim", "Checkpoint" oder "Estimacs", denen im Schnitt rund 4000 bis 5000, bei Slim sogar 20 000 Projekte zugrunde liegen. Dort sind Mitarbeiterzahlen, Methoden, Qualitaetskontrollen oder besondere Vorkommnisse dokumentiert.
Benutzer koennen das eigene Profil mit einem anderen, aehnlichen abgleichen. Das geht so gut, dass eine ganze Reihe von Softwarehaeusern inzwischen eine Fixpreispolitik eingefuehrt hat, indem sie solche Methoden anwenden.
Sie parametrisieren ihr Projekt und machen dann ihre Aussage, wenn die jeweiligen Punkte zutreffen. Das funktioniert, weil die meisten Einflussgroessen im Unternehmen relativ fix sind: Personal, Management-Stil, Methoden etc. Diese Dinge aendern sich nicht ueber Nacht - uebrigens auch die eingesetzten Werkzeuge nicht. Das einzige, was man aendern kann, ist der Projektumfang.
CW: Projekte verlaufen in der Regel flexibel, die Anforderungen der Fachbereiche koennen sich waehrend des Ablaufs mehrfach aendern...
Rudolph: ...um so sinnvoller ist der Einsatz der Funktionspunkt- Analyse. Dadurch, dass wir aus Sicht des Benutzers zaehlen, haben wir in der Anforderungsphase genau das festgelegt, was wir in einem bestimmten Zeitraum abhandeln koennen. Das ist unser Kassenbon. Wenn jetzt waehrend der Entwicklungszeit gefordert wird: "Da moechte ich noch etwas eingeschoben haben", dann wird das zusaetzlich auf dem Kassenzettel vermerkt. Wir addieren das wie die Buchhalter. Nebenbei: So koennen wir auch dem Benutzer plausibel machen, dass er nicht auf der einen Seite die Anforderungen aendern und auf der anderen Seite auf Einhaltung des Termins bestehen kann.
Wie weit dieses Verfahren gehen kann, zeigt das Beispiel des Oelkonzerns Shell in Australien. Jede Benutzeranforderung, die dort gestellt wird, wird grob analysiert. Das dauert nicht laenger als einen Monat. Die Funktionspunkte werden bestimmt, und das Ganze durchlaeuft ein Aufwandschaetz-Verfahren. So bekommt man Zeitablauf- und Kostenmodell heraus und kann dem Benutzer sagen: "Das ist der Zeitraum, das ist der Betrag - ist das akzeptabel?"
CW: Die bisherigen Schaetzwerte, an denen man sich - unabhaengig von Funktionspunkt-Methoden - orientierte, sind relativ zuverlaessige Erfahrungswerte. Wozu also brauche ich noch Funktionspunkte?
Rudolph: Erstens: Wenn ich schaetze, dass die Arbeit zwei Jahre dauern wird, dann will ich auch wissen, warum das so ist. Nur so kann ich diesen Zeitraum verkuerzen. Dazu benoetige ich unabhaengige Eckwerte. Ich kann sagen: "Die Funktionspunkt-Kosten beim Mitbewerber sind niedriger als bei mir." Das ist nicht moeglich, wenn das Projekt individuell geschaetzt wird.
Zweitens: Es gibt heute ganz neue Anforderungen, die solche Schaetzungen riskant, wenn nicht gar unmoeglich machen. Bei der objektorientierten Programmierung etwa oder bei der Einfuehrung von Client-Server-Architekturen liegen kaum Erfahrungswerte vor.
CW: Wie realistisch sind denn die Vergleichswerte, auf die man bei der Funktionspunkt-Analyse zurueckgreift - etwa anhand von Musterprojekten ?
Rudolph: Da muss man aufpassen. Die Daten, die Sie zur Verfuegung haben, stammen in der Regel von Unternehmen, die ueberdurchschnittlich produktiv sind. Das sind Leute, die wissen, dass sie mit ihrem Projekt gut dastehen - die sorgen schon fuer eine Verbreitung der Fakten. Die anderen sind vorsichtiger mit Aussagen ueber ihre Projekte.
Trotzdem ist die Funktionspunkt-Analyse ein Weg, den eigenen Status quo zu ermitteln. Viele Unternehmen sind heute dabei, intensiv an sich selbst zu arbeiten.
Heutzutage ist die DV nicht mehr die heilige Kuh, die sie einmal war - die Leute fragen sich ernsthaft, ob alles so bleiben muss, wie es seit Jahren ist.
CW: Demnach geht es nicht nur um die Aufwandschaetzung, sondern vor allem um bessere Controlling-Moeglichkeiten?
Rudolph: Hier gehoert die Funktionspunkt-Analyse eigentlich her. Zwangslaeufig wird die Frage auftauchen: Wieso dauert es bei mir so lange, einen Punkt zu erstellen, und bei den anderen nicht? Wir haben doch den gleichen IBM-Computer, das gleiche objektorientierte Vorgehen, die gleiche Mannschaftsstaerke...
CW: Ich nehme an, mit Ihrem Rationalisierungsansatz haben Sie nicht sehr viele Freunde in den DV-Abteilungen...
Rudolph: ... jein. Auf der Projektebene registrieren wir offene Begeisterung, denn der Projekt-Manager kann mit Hilfe dieses Verfahrens die Erwartungen seiner Kunden besser erfuellen.
Er kann zu seinem Kunden vorab sagen: "Was Sie innerhalb von einem Jahr haben wollen, ist so nicht machbar, das hat noch keiner geschafft. Wir koennen aber dieses oder jenes anbieten."
Freunde kann man sich auch beim Controller und weiter aufwaerts machen. Beim gehobenen DV-Management herrscht dagegen in der Tat Skepsis. Es ist nicht gewohnt, ueberwacht und kontrolliert zu werden und die Dinge nachvollziehbar gestalten zu muessen.
Die herrschende Meinung in den DV-Abteilungen ist also eher negativ. Ich habe aber mehrfach erlebt, dass Leute sagten: "Ein solches Verfahren brauchen wir nicht", um dann ploetzlich doch Informationen einzuholen. Das geschieht regelmaessig dann, wenn der Unternehmensfuehrung der Geduldsfaden gerissen ist und die Beratungsfirma vor der Tuer steht, um zu fragen, was bei den Entwicklungen herauskommt. Dann ist es aber immer zu spaet.
Das Verfahren sieht nun einmal vor, ganz ungeschminkt festzustellen, was gut und was schlecht fuer die Effizienz ist, und dieses entweder zu foerdern oder auszuschliessen. Ich kenne Unternehmen, die auf diese Weise innerhalb von drei Jahren ihre Produktivitaet vervierfacht haben.
CW: Haben Sie ein Beispiel parat?
Rudolph: Der Paradefall ist General Electric. Die hatten Anfang der 80er Jahre eine tiefgreifende Umstrukturierung im Management, fortan rangierte die Produktivitaet an allererster Stelle. Das Unternehmen wurde in viele kleine Einheiten gegliedert, die ihre Produktivitaet unter Beweis stellen mussten.
Die DV-Abteilung stand ploetzlich vor erheblichen Problemen, sie konnte ihre Produktivitaet nicht quantifizieren. Das Management argumentierte: "Ihr kostet uns drei Prozent vom Gesamtbudget - was kriegen wir eigentlich dafuer? Koennen wir das gleiche nicht draussen billiger beziehen?" Die Motivation
der DV-Verantwortlichen wuchs, man begann, Funktionspunkte nicht nur fuer die Aufwandschaetzung einzufuehren, sondern in das ganz normale vierteljaehrliche Berichtswesen aufzunehmen. Die haben sich als SW-Fabrik verstanden und genauso ihren Bericht abgeliefert wie die anderen Tochtergesellschaften. Da werden heute die Kosten pro Funktionspunkt quartalsweise verglichen.
CW: Nicht die Software-Entwicklung, sondern die Wartung von Altsystemen schluckt heute die meisten Personalkapazitaeten. Wo greift da die Funktionspunkt-Analyse?
Rudolph: Es faengt schon damit an, dass ich bei der Entwicklung verschiedene Qualitaetsmassstaebe anlege. Manche Entwickler rasen voran, verzichten auf die Qualitaetskontrolle und produzieren eine relativ billige Software. Sie stehen zunaechst da wie die Weltmeister, weil sie ein Problem in sehr kurzer Zeit loesen. Wenn man aber ueber das Jahr verfolgt, wie viele Fehler bei diesen Entwicklungen pro Funktionspunkt auftauchen beziehungsweise wie viele Stunden zu deren Behebung angesetzt werden muessen, dann ist ein Urteil ueber die Qualitaet durchaus moeglich.
Es gibt aber noch einen zweiten Aspekt: Neuentwicklung von Software heisst oft, in ein existierendes System eine neue Funktion hineinzubauen. Werden Funktionspunkte benutzt, so laesst sich sehr gut die Situation eines Wartungsprogrammierers verfolgen. Angenommen, er will ein System mit 50 Funktionspunkten in ein Altsystem mit 2000 Punkten einfuegen. Bei gut strukturierten Programmen oder auch bei objektorientierten laesst sich dieser Bestandteil problemlos integrieren, der Anpassungsaufwand ist minimal. Es muessen wirklich nur 50 Funktionspunkte erstellt werden. In der Regel muss der Programmierer aber, um 50 Punkte in das System hineinzubekommen, eine Vielzahl anderer Punkte zurechtruecken.
Mit der Funktionspunkt-Methode koennen wir das beschreiben. Wir koennen zeigen, dass wir zwar nur 50 effektiv neue Punkte bekommen, die der Benutzer sieht, dass wir aber 300 Punkte bearbeiten muessen, um diese 50 neu zu machen. Da koennen wir sehr schnell sehen, ob es sich noch lohnt, ein System zu warten, oder ob man es abschreiben und von Grund auf neu erstellen sollte. Ein anderes Problem: Sie wollen ein Softwarepaket kaufen und muessen noch 5 Prozent dazustricken - das ist ja auch eine Wartungsaufgabe. Stellen Sie sich vor, Sie muessen mit 50 eigenen Funktionspunkten an ein fremdes Programm mit 5000 Punkten heran - wenn sie Pech haben, muessen Sie darin viel mehr bewegen als Sie eigentlich wollten.
Abb: Funktionspunkte werden aus Benutzersicht fuer die fuenf mit einem Pfeil gekennzeichneten Vorgaenge vergeben. Quelle: Rudolph