Der Begriff Function Point ist mit "Stueck Software" zu paraphrasieren. Wieviel Stueck Software die Entwicklungsbereiche pro zu definierender Zeiteinheit liefern, ist ein Indikator fuer die Produktivitaet. Zunaechst einmal gebuehrt den Projektleitern Lob, die ein Projekt mit ihrer Methode, also nicht mit der Function- Point-Methode schaetzen. Die Schaetzungen der Projektleiter mit Analogie-, Gewichtungsmethode oder anderen Verfahren weisen eine Genauigkeit auf, die sich von der Bewertung nach Function Point kaum oder nicht unterscheidet.

Aufwandskurve spiegelt den Idealzustand wider

Bei CAP Debis IAS werden zwei unterschiedliche Schaetzungen vorgenommen. Die Projektleiter schaetzen zunaechst nach ihrer Methode und wirken dann bei der Anwendung der Function-Point- Methode mit. Falls Unterschiede zwischen den Ergebnissen der beiden Vorgehensweisen zu verzeichnen sind, lassen sich diese meist durch gegenseitiges Pruefen der Aufwaende pro Funktion, sowohl nach der Methode des Projektleiters als auch nach der FunctionPoint-Methode, minimieren. Bleiben Unterschiede bestehen, so wird dies akzeptiert. Die Bewertung nach Funktion Point hat Vorrang und ist somit Basis fuer das Projekt.

Ungenauigkeiten ergeben sich bei allen Verfahren immer dann, wenn der Projektleiter die aeusseren Einfluesse, das sich laufend aendernde Umfeld, nicht konsequent waehrend des Projektes registriert und es versaeumt, sie in die Schaetzung miteinzubeziehen.

Bei der Ermittlung der Aufwandskurve werden oft Annahmen getroffen, die den Idealzustand eines Projektablaufes darstellen. In diesem Fall haetten die Verantwortlichen alle aeusseren Einfluesse aus ihrer Berechnungen eliminiert. Es empfiehlt sich jedoch, Einwirkungen von aussen als zusaetzlichen Aufwand in die Schaetzung einfliessen zu lassen.

Wurden bei der Aufwandsbestimmung gewisse externe Wirkungen als konstant angesehen, so haben die Projektverantwortlichen eigentlich entschieden, weiterhin mit ihren Einfluessen zu leben, sprich einen gewissen Mehraufwand langfristig zu akzeptieren. Es entsteht das Problem, neue aeussere Einfluesse von akzeptierten zu unterscheiden.

Nun stellt sich die Frage: "Haben Sie bei allen Folgeprojekten diese konstanten aeusseren Einfluesse in genau der gleichen Art und Weise vorgefunden?". Wenn nicht, muss die Genauigkeit der Schaetzung angezweifelt werden.

Um diesen Zustand zu vermeiden, sollten die Projektleiter aeussere Einwirkungen und den daraus resultierenden Mehraufwand der Function-Point-Schaetzung zuschlagen und zwar zu dem Zeitpunkt, wenn diese Externa eintreten. So koennen die Leiter jederzeit dem Management berichten, warum das Projekt gegenueber der urspruenglichen Schaetzung aus dem Ruder laeuft. Das Management kennt die Einflussfaktoren und kann geeignete Gegenmassnahmen ergreifen. Dies kann sich auch auf Folgeprojekte positiv auswirken.

Zu den Faktoren, die bei der Function-Point-Methode nicht beruecksichtigt werden, gehoeren nachtraegliche Aenderungen des Funktionsumfangs in fortgeschrittenen Phasen des Projektes. In dieselbe Kategorie fallen An- und Einpassungsarbeiten in schon abgeschlossene Phasen, beginnend bei der Dokumentation und endend in den Programmen und beim Test. Gleiches gilt auch fuer Funktionen, die waehrend des Projektes entfallen. Dieser Mehr- beziehungsweise Minderaufwand muss, gegebenfalls phasenbezogen, bei jeder Neuschaetzung in das Ergebnis einfliessen.

Ungeplante Kostenverursacher koennen sein:

- unterschiedlicher Detaillierungsgrad in den Pflichtenheften der Fachabteilungen,

- unterschiedliche Mitwirkung der Fachabteilung in der Projektarbeit,

- fehlende Ausbildung oder Praxis der Systementwickler,

- schlechte Arbeitsplatzgestaltung,

- mangelnde Rechnerverfuegbarkeit,

- neue Hardware,

- Zusatzaufwaende bei Funktionsaenderungen in schon abgeschlossenen Projektphasen,

- Einsatz von externen Mitarbeitern sowie

- das Einbeziehen von Projektphasen, die nicht in voller Verantwortung der Systementwicklung liegen.

Die aeusseren Einfluesse und ihre Auswirkungen auf den Aufwand lassen sich am einfachsten mit den entsprechenden Werkzeugen kontrollieren. Neue Tool-Entwicklungen auf dem Markt unterstuetzen nicht nur die reine Function-Point-Methode, sondern ermoeglichen auch die Verfolgung, Klassifizierung und Auswertung der ungeplanten Kostenverursacher. Sie tragen zu einer Transparenz beim Nachweis des Projektaufwands bei, was sich positiv auf das Verhaeltnis zwischen Fachabteilung und Software-Entwicklung auswirkt.

*Hans Gabriel arbeitet im Bereich Qualitaetssicherung und Schaetzverfahren bei CAP Debis in Riemerling bei Muenchen.