Die Programmpflege wird immer aufwendiger: Teilweise müssen bereits 80 Prozent der vorhandenen Kapazität dafür investiert werden. Mit Hilfe des Function-Point-Verfahrens kann der Aufwand für ein Software-Projekt im vorhinein ermittelt werden. Robert Hürten* beschreibt. welche Möglichkeiten und Besonderheiten diese Methode aufweist, wenn sie für die Programmpflege eingesetzt wird.
Eine Analyse der Tätigkeiten im Rahmen der Software-Pflege zeigt daß dabei schwerpunktmäßig Programmfehler behoben werden. Weitere Aufgaben sind die Anpassung, an neue technische Bedingungen (Hard- und/oder Software), die Optimierung der Programme durch bessere Ausnutzung technischer Mittel (zum Beispiel Tuning) sowie die Einfügung neuer oder die Veränderung alter Funktionen.
Die reine Fehlerbehebung ist eine Aufgabe, die schnell und unter Vernachlässigung von Wirtschaftlichkeitsbetrachtungen gelöst werden muß. Hier stellt sich also normalerweise erst gar nicht die Frage, ob sich der Aufwand lohnt, da in der Praxis dieser Vorgang niemals das Ausmaß eines neuen Projektes annimmt. Somit erübrigt sich auch eine Untersuchung darüber, ob mit einem Function-Point-Verfahren (FPV) der Aufwand für die reine Fehlerbehebung ermittelt -werden kann.
Anpassungen vorhandener Programme an eine veränderte technische Umwelt oder auch Optimierungsmaßnahmen sind hingegen in den meisten Fällen wesentlich aufwendiger. Der Anwender wird jedoch keine Veränderungen der Benutzeroberfläche feststellen können; denn für ihn bleibt der Funktionsumfang der Programme gleich. Optimiert wird hingegen das Laufzeitverhalten.
Das FPV ermittelt den Projektaufwand lediglich aufgrund des aus der Benutzersicht ermittelten Funktionsumfanges der Aufgabenstellung. Aber eine reine Tuningmaßnahme zum Beispiel verändert den Funktionsumfang der Software nicht. Von der Systematik des FPV her ist es deswegen unmöglich, hier Zeitbedarf und daraus resultierenden Aufwand zu schätzen.
Daß sich das FVP bei der Fehlerbehebung und bei technischen Anpassungen nicht anwenden läßt, ist für die Praxis kaum relevant. Wichtiger ist der Einsatz des Verfahrens für große Pflegeprojekte, wo bestehende Anwendungen entweder durch neue Funktionen erweitert oder einschneidend verändert werden.
Die Vorteile des FPV liegen unter anderem darin, daß beim Erstellen der Schätzung eine Trennung zwischen funktions-, projekt-, und produktivitätsabhängigen Einflußfaktoren vorgenommen wird ( siehe Abbildung 1). Dabei treten auf den drei Einflußebenen der Software-Pflege der Neuentwicklung gegenüber einige Besonderheiten auf:
Auf der Funktionsebene sind einzelne Aufgaben oder ganze Funktionszweige ergänzend zu gestalten sowie bestehende Funktionen abzuändern (siehe Abbildung 2).
Eine Schwierigkeit bei der Durchführung von Ergänzungen/Änderungen ist, daß vorgegebene Strukturen und Formate eingehalten werden müssen. Vorteilhaft nimmt es sich hingegen aus, wenn Listen oder Bildschirme nicht komplett neu zu gestalten sind, sondern nur ein neues Feld oder eine neue Zeile eingebaut werden muß. Bei der Programmpflege wird sicherlich die Qualität der vorgefundenen Dokumentation oder das Vorhandensein von guten Testdaten Einfluß auf den Projektaufwand haben. Die Produktivität der Programmpflege hängt aber auch davon ab, ob der Mitarbeiter, der die Pflege durchführt, in der Vergangenheit an der Entwicklung des Systems teilgenommen hat.
Um die aufgezeigten Besonderheiten bei der Programmpflege zu berücksichtigen, ist das FPV um zusätzliche Grundfunktionen und Einflußfaktoren zu erweitern. Die Grundfunktionen: Ein- und Ausgaben, Abfragen, Datenbestände sowie Referenzdaten werden bei der Programmpflege mit ihren Standardgewichtungen für alle zusätzlichen Aufgaben angewandt und müssen deshalb geändert werden.
Diese Änderungsfunktionen sind in den drei Gewichtungen einfach, mittel und komplex zu bewerten. Die Kriterien dafür unterscheiden sich von denen normaler Grundfunktionen: Die entsprechenden Function-Points liegen merklich darunter. Durch die speziellen Änderungsfunktionen fallen zwar auf der einen Seite Leistungen an, auf der anderen Seite werden wesentliche Aufgaben wie Design und Testdatenerstellung bei der originären Lösung bereits bewältigt.
Im Rahmen der Programmpflege sind normalerweise bei den projektbezogenen Einflußfaktoren die ursprünglichen Ansätze zu berücksichtigen. Darüber hinaus müssen zusätzliche, speziell auf den Pflegedienst abgestellte Gewichtungen vorgenommen werden. Dies können zum Beispiel die Qualität der Dokumentation und der Testdaten sein. Es leuchtet ein, daß derartige Kriterien dem Projekt und nicht der Produktivität zugerechnet werden, da diese von Projekt zu Projekt sehr unterschiedlich sein können. Sicherlich bringt eine unvollständige Dokumentation bei der Erstentwicklung eine "optisch" hohe Produktivität zuwege; sie schlägt sich jedoch in einer schlechten Qualität der Software nieder.
Eine eigene Produktivitätskurve für die Programmpflege zu erstellen, erscheint nicht notwendig und ist auch nicht zweckmäßig. Extreme Fälle in der aktuellen Teamzusammenstellung für das Pflegeprojekt sollten fallweise durch Zu- und Abschläge berücksichtigt werden. Dies trifft zum Beispiel auf die Mitarbeiter zu, die weder an der ursprünglichen Entwicklung mitgearbeitet haben, noch Erfahrungen auf dem Arbeitsgebiet nachweisen können.
Die Anwendung des FPV bei der Programmpflege setzt zunächst einmal voraus, daß die Anzahl der erbrachten Function-Points für das Projekt vor der anstehenden Änderung bekannt ist (zum Beispiel: 500 Function-Points entsprechen 33 Mannmonaten). Dazu ist nicht in jedem Fall eine detaillierte Nachschätzung für alte Projekte notwendig. Hier kann man sich auch einer Rückrechungsmethode bedienen.
Für die zusätzlich zu ändernden Aufgabenstellungen werden die Function-Points getrennt nach Änderung und Ergänzung ermittelt. Ergänzungen werden mit den gleichen Grundfunktionen und Kriterien bewertet wie bei neuen Projekt-Aufwendungen. Für Änderungen bereits bestehender Funktionen sind neu geschaffene Grundfunktionen anzuwenden. Ist eine Änderung jedoch mit einem Ersetzen zu vergleichen, so sollte das gleiche für Ergänzungen gelten. Die aus den Grundfunktionen ermittelten Function-Points sind dann mit den projektbezogenen Faktoren zu gewichten (zum Beispiel: unvollständige Dokumentation bedeutet 5 Prozent Zuschlag).
Das gewichtete Ergebnis ergibt die Function-Points, aus denen die Mannmonate abgeleitet werden (im Beispiel: 200 Function-Points). Würde dieser Wert sofort in die Produktivitätskurve eingehen, so wären aufgrund der Progressivität die entsprechenden Mannmonate zu gering (200 FP = 9 MM) veranschlagt (siehe Abbildung 3). Aus diesem Grund sind die für die Pflege ermittelten Function-Points auf die ursprünglichen zu addieren (500 FP + 200 FP = 700 FP = 49 MM). Die Differenz zwischen den entsprechenden Mannmonaten ergibt dann den Aufwand, der für die Programmpflege anfällt (49 MM - 33 MM = l 6 MM).
Durch die Ermittlung des Aufwandes aus der Differenz der Mannmonate und nicht aus der Differenz der Function-Points wird die Größe des zu ändernden Projektes berücksichtigt. Je umfangreicher das Vorhaben ist, desto aufwendiger wird bei gleicher Function-Point-Zahl die Änderung ausfallen.
Die oben vorgestellte Erweiterung des FPV für die Programmpflege stehen vor ihrem Einsatz in der Praxis. Es bedarf allerdings einer statistischen Gesamtheit an SW-Pflege-Projekten, um festzustellen, wie die Funktionen zu bewerten und welche Einflußfaktoren zu verwenden sind. Erst dann kann man zu einer abgesicherten Beziehung "Function-Points pro Mannmonate" gelangen. FPV-Anwender sollten deshalb darauf achten, daß abgeschlossene Pflegeprojekte für eine statistische Basis zur Verfügung gestellt werden. In einer Arbeitsgruppe könnten die Bewertungskriterien und deren Gewichtungen für die Grundfunktionen und die Einflußfaktoren für die FPV-Anwendung im Bereich der Software-Pflege immer zuverlässiger ermittelt werden.
*) Robert Hürten ist Mitarbeiter der EDV-Controlling Unternehmensberatung GmbH,
Heppenheim.