PROJEKTMANAGEMENT AKTUELL
pm
2941-0878
2941-0886
UVK Verlag Tübingen
31
2005
161
GPM Deutsche Gesellschaft für Projektmanagement e. V.Einsatz und Nutzen der Function-Point-Methode
31
2005
Manfred Bundschuh
Dieser Aufsatz beschäftigt sich sowohl mit den Problemen als auch mit den Möglichkeiten, in Softwareprojekten zu guten Schätzergebnissen zu gelangen. Er zeigt Chancen auf, die die professionelle Aufwandsschätzung der Projektplanung bietet. Die Function-Point-Methode dokumentiert objektiv und einheitlich die Anwendungssysteme aus Benutzersicht, und zwar konsistent mit dem Verständnis der Anwender (einheitliche Sprache für IT und Fachbereich). Auf dieser Basis können Projektentscheidungen, Investitionen und Verträge abgesichert und kann eine Lieferantenauswahl durchgeführt werden. Außerdem erhält das Unternehmen dadurch konsistente, projektübergreifende Daten über den Umfang seines Anwendungssystem- und Projektportfolios, die beispielsweise der Bewertung dieser immateriellen Vermögenswerte in der Bilanz zugrunde gelegt werden können. Darüber hinaus liefern Fuction Points zahlreiche Metriken, unter anderem zur Qualitätsplanung und für Management-Reviews, mit denen Stabilität und Zuverlässigkeit sowie Produktivität von IT-Systemen beurteilt werden können. Durch die internationale Standardisierung sind sogar unternehmensübergreifende Benchmarks möglich.
pm1610023
23 EinsatzundNutzenderFunction- Point-Methode AufwandsschätzungvonSoftwareprojekten ManfredBundschuh DieserAufsatzbeschäftigtsichsowohlmitdenProblemenalsauchmitdenMöglichkeiten,inSoftwareprojektenzugutenSchätzergebnissenzugelangen.ErzeigtChancenauf, diedieprofessionelleAufwandsschätzungderProjektplanungbietet.DieFunction-Point- MethodedokumentiertobjektivundeinheitlichdieAnwendungssystemeausBenutzersicht, undzwarkonsistentmitdemVerständnisderAnwender(einheitlicheSprachefürITund Fachbereich).AufdieserBasiskönnenProjektentscheidungen,InvestitionenundVerträge abgesichertundkanneineLieferantenauswahldurchgeführtwerden.Außerdemerhältdas Unternehmendadurchkonsistente,projektübergreifendeDatenüberdenUmfangseines Anwendungssystem-undProjektportfolios,diebeispielsweisederBewertungdieserimmateriellenVermögenswerteinderBilanzzugrundegelegtwerdenkönnen.Darüberhinaus liefernFunctionPointszahlreicheMetriken,unteranderemzurQualitätsplanungundfür Management-Reviews,mitdenenStabilitätundZuverlässigkeitsowieProduktivitätvonIT- Systemenbeurteiltwerdenkönnen.DurchdieinternationaleStandardisierungsindsogar unternehmensübergreifendeBenchmarksmöglich. HerausforderungenderAufwandsschätzung Bei der Aufwandsschätzung von IT-Projekten ist Deutschland immer noch Entwicklungsgebiet [1]. Die Anzahl der Teilnehmer bei einschlägigen Tagungen in europäischen Nachbarländern (über 100) im Vergleich zu Tagungen der DASMA (Deutschsprachiger Anwenderverband für Softwaremetriken und Aufwandsschätzung e. V., www.dasma.org) oder der GI-Fachgruppe 2.1.10 (Software-Messung und -Bewertung, Gesellschaft für Informatik e.V., www.ivs.cs.uni-magdeburg.de/ sw_eng/ us) in Deutschland (ca. 50 Teilnehmer) vermittelte in den letzten Jahren jedenfalls diesen Eindruck. Aber es ist Bewegung im Markt, denn die Anzahl der DASMA-Mitglieder z. B. ist in den letzten Jahren auf inzwischen fast 70 gewachsen. Das heißt, dass zunehmend mehr Firmen ernsthaft am Thema Aufwandsschätzung interessiert sind. Oder sie haben schmerzhaft erfahren, was der Guru der Aufwandsschätzung, Capers Jones, in die Worte gefasst hat: „Ein fehlgeschlagenes Projekt kostet mehr als aller Aufwand, um ein Aufwandschätzverfahren in einem Unternehmen zu etablieren.“ [7] Für eine fundierte Planung von IT-Projekten und die Messung des Erfolgs nach Projektabschluss ist es notwendig, Schätzungen über Aufwand, Kosten, Termine und Dauer professionell durchzuführen. Das häufig angesprochene Problem fehlender empirischer Daten sowie der erhöhte zeitliche Aufwand können durch den Einsatz von Werkzeugen, durch ausführliche Dokumentation oder durch den Aufbau eines Competence Centers kompensiert werden [2]. Dieser Aufsatz beschäftigt sich daher sowohl mit den Problemen als auch den Möglichkeiten, zu guten Schätzergebnissen zu gelangen, und den Chancen, die die professionelle Aufwandsschätzung der Projektplanung bietet. Um es mit Capers Jones [7] klar auszusprechen: „Wer diese Software-Entwicklungsaufgabe nicht professionell wahrnimmt, handelt in seinem Beruf grob fahrlässig.“ In Italien ist deshalb gesetzlich vorgeschrieben, dass Softwareanbieter bei staatlichen Stellen den Leistungsumfang in Function Points angeben müssen. Die Hauptthemen der Aufwandsschätzung sind in Abb. 1 zusammengefasst. Die wichtigsten Themen der Aufwandsschätzung Schätzobjekt Zeitpunkte der Aufwandsschätzung Schätzgenauigkeit Schätzfehler Aufwand für die Aufwandsschätzung Schätzmethoden Tracking der Schätzungen Schätztools Schätzparameter Schätzehrlichkeit Schätzerfahrung Einführung der Aufwandsschätzung Schätzkultur ! ! Abb.1: HauptthemenderAufwandsschätzung projekt M A N A G E M E NT 1/ 20 0 5 aktuell 24 WISSEN DieFunction-Point-MethodealsVoraussetzungfür solideAufwandsschätzung Die Function-Point-Methode wurde 1979 von A. J. Albrecht bei IBM entwickelt und hat seither weite Verbreitung gefunden.1986 wurde die International Function Point Users Group (IFPUG) zum Zweck einer internationalen Standardisierung dieser Methode gegründet. Die Mitglieder der IFPUG erhalten kostenlos das so genannte IFPUG Counting Practices Manual (CPM), das die standardisierte und vereinheitlichte Version der Function-Point-Methode beschreibt, derzeit Release 4.2 (ISO- Standard ISO/ IEC 20926: 2003). Die IFPUG-Function-Point-Methode ist eine nach der ISO-Norm 14143-1 anerkannte Methode zur Messung der funktionalen Größe bzw. des Umfangs einer Anwendung aus Benutzersicht. Das heißt, es wird die vom Benutzer geforderte Funktionalität gemessen, die von der Fachabteilung nachgefragt, anhand des logischen Systementwurfs quantifiziert und für sie erbracht wird. Dieses Maß ist unabhängig von der für die Implementierung verwendeten Technologie, da nicht die technische Realisierung der Anwendung betrachtet wird. Grundlage der Aufwandsschätzung sind Informationen über das zu schätzende Projekt, beispielsweise ❏ Übersicht über die benötigten Daten (z. B. Objektkatalog oder relationales Datenmodell), ❏ Masken-, Listenlayout etc., ❏ Anzahl und Umfang der Schnittstellen, ❏ Abläufe aus Benutzersicht, Dialogablauf, z. B. alle Prozessflussmodelle mit den dazugehörigen Aktivitäten, Use Cases etc. Fehlende Informationen müssen durch dokumentierte Annahmen ersetzt werden, ansonsten gerät das Schätzen zum Raten. Die Bandbreite des Schätzergebnisses hängt dabei von der Sicherheit dieser Annahmen ab. Grundsätzlich gilt: Je mehr Informationen über das Schätzobjekt vorliegen, desto genauer wird die Schätzung. FunctionPointsaufeinenBlick Abb. 2 zeigt die Komponenten der Function-Point-Methode. Als Erstes wird die Grenze der Anwendung in einem Architekturdiagramm festgelegt, damit festgestellt werden kann, welche vom Benutzer geforderten Geschäftsvorfälle Daten über die Grenzen der Anwendung transportieren. Das können ❏ Eingaben (EI = External Inputs), ❏ Ausgaben (EO = External Outputs) oder ❏ Abfragen (EQ = External Inquiries) sein. Dazu werden ❏ interne Dateien (ILF = Internal Logical File) und ❏ externe Dateien (EIF = External Interface Files) benötigt. Diese fünf Komponenten (EI, EO, EQ, ILF, EIF) werden für alle vom Benutzer geforderten Geschäftsvorfälle jeweils nach den Regeln des IFPUG CPM mit einfach, mittel oder hoch bewertet. Anhand einer im CPM vorgegebenen Tabelle wird dazu die Anzahl der Function Points bestimmt. Die Summe aller Function Points der Anwendung ist der funktionale Umfang. Der interessierte Leser findet in [3, Kapitel 8 bis 12] eine genaue Beschreibung der Function-Point-Methode. Die Function-Point-Methode unterscheidet zwischen den ungewichteten Function Points und den gewichteten Function Points. Zur Berechnung der gewichteten Function Points werden 14 Systemmerkmale jeweils mit 0 bis 5 Punkten eingestuft. Diese 14 Systemmerkmale berücksichtigen Parameter aus der Systementwicklung. Sie sind daher kein funktionales Maß mehr, sondern bereits ein Schritt in Richtung Aufwandsschätzung. Da diese Schätzparameter unternehmensspezifisch und projektspezifisch sind, werden für das externe Benchmarking sinnvollerweise nur ungewichtete Function Points verwendet. Die ISO hat deshalb als funktionales Maß für IT-Systeme nur die ungewichteten Function Points anerkannt. DerSchrittvomMessenzumSchätzen Grundsätzlich gilt es, zwischen Zählen und Schätzen zu unterscheiden. Das Ergebnis der Zählung von Funktions- Punkten (Function Points) oder Code-Zeilen (KLOCs: Kilo Lines of Code) ist lediglich ein Ausgangspunkt (der wichtigste Parameter) für die eigentliche Aufwandsschätzung. Dabei gilt folgende Prämisse: „Was Sie nicht messen können, können Sie auch nicht kontrollieren.“ [4] Die Schätzerfahrungen vergangener Projekte spielen dabei eine große Rolle, lassen sich jedoch nur nutzen, wenn sie auch ausreichend dokumentiert wurden [2]. Prinzipiell wird bei der Aufwandsschätzung, ausgehend vom Umfang der zu entwickelnden Software, unter Berücksichtigung weiterer Parameter der Aufwand berechnet, indem Daten von Umfang und Ist-Aufwand früherer Projekte zueinander in Bezug gesetzt werden. Dazu werden typischerweise mindestens je drei kleine, mittlere und große Projekte nachkalkuliert, so dass im einfachsten Fall aus den Zahlenpaaren Umfang/ Aufwand durch eine Regressionsanalyse eine Erfahrungskurve berechnet werden kann. Diese Erfahrungskurven haben die Form y = a · x b mit y = Aufwand, x = Umfang und a, b aus der Regressionsanalyse ermittelt: a = Koeffizient, b = Exponent. Weiterentwickelte Verfahren aufgrund von Projektdatenbanken, wie z. B. die ISBSG-Datenbank, COCOMO (Constructive Cost Model, Barry Boehm), SLIM (Software Lifecycle Management, L. H. Putnam) und weitere Schätztools berücksichtigen in ihren Schätzgleichungen noch weitaus mehr beziehungsweise andere Parameter als Anwendungsgrenze Andere Anwendung Benutzer Eingabe (EI) Ausgabe (EO) Abfrage (EQ) Interner Datenbestand Externer Datenbestand EI EO EQ Abb.2: DieFunction-Point-Methode aktuell projekt M A N A G E M E NT 1/ 20 0 5 25 den Umfang. Teilweise werden diese Einflussgrößen von den Anbietern allerdings als Betriebsgeheimnis gehütet. COCOMO und SLIM z. B. sind im Gegensatz zu Function Points LOC-basierte Schätzmethoden. Lines of Code (LOC) sind gegenüber Function Points (Fachkonzept) erst spät im Projekt bekannt (Realisierungsphase) und messen den technischen Umfang, während Function Points den funktionalen Umfang messen. Backfiring nennt man den Versuch, Formeln für die Umrechung von Functions Points in LOC oder umgekehrt zu entwickeln. Das setzt voraus, dass man beide Größen misst und den Unterschied zwischen technischem und funktionalem Maß vernachlässigt. LOCs haben auch mit dem Paradoxon der Sprachumrechnungsfaktoren zu kämpfen (Assembler-Äquivalent). Danach hat z. B. ein Programm bei einem Ist-Aufwand von angenommen einem Personenmonat (PM) einen Umfang von beispielsweise 10.000 LOC Cobol und damit eine Produktivität von 10.000 LOC pro PM. Das gleiche Programm in Assembler entspricht einem Umfang von 30.000 LOC (Assembler-Äquivalent) und hat damit eine Produktivität von 30.000 LOC/ PM, ist also dreimal so produktiv wie die COBOL-Programmierung, was der praktischen Erfahrung widerspricht. LOC-Methoden sind deshalb bei Metrikspezialisten weltweit sehr umstritten. UmfangmaßenachISO-Norm Es gibt in der Software-Industrie die international normierten Metriken der ISO 14143 (ISO = International Organization for Standardization). ISO 14143-1 ist seit 1999 Standard und beschreibt die grundlegenden Prinzipien einer funktionalen Größenmetrik (Functional Size Metric) und die nötigen Definitionen dazu. ISO 14143-2 beschreibt die Prüfkriterien zur Feststellung, ob eine Methode funktionale Metrik im Sinne von ISO 14143-1 ist. ISO 14143-3 stellt Messkriterien in Form von Checklisten für Assessments zur Verfügung, anhand deren bewertet werden kann, wie gut eine funktionale Größenmetrik ISO 14143-1 erfüllt. Derzeit (Ende 2004) sind nur Varianten der Function-Point-Methode nach ISO 14143-1 anerkannte Public Available Standards (PAS). Dabei handelt es sich um ❏ die IFPUG-Function-Point-Methode Version 4.1 (IFPUG = International Function Point User Group, www.ifpug.org), ISO/ IEC 20926; ❏ die COSMIC Full Function Points (COSMIC = Common Software Measurement Consortium, www.cosmicon.com), ISO/ IEC 19761; ❏ die NESMA-Function-Point-Methode (NESMA = Niederländische Metrik Organisation, www.nesma.org), ISO/ IEC 24570; ❏ die Mark-II-Function-Point-Methode (von Charles Symons in England für Entwicklungen mit Programmiersprachen der 4. Generation entwickelt, www. uksma.co.uk), ISO/ IEC 20968. COSMICFullFunctionPoints(FFP) Die IFPUG-Methode ist anerkannt für Zählungen von so genannten Geschäftsanwendungen und MIS-Systeprojekt M A N A G E M E NT 1/ 20 0 5 aktuell 26 WISSEN men (Management-Informationssysteme). Ein wesentlicher Kritikpunkt daran ist jedoch, dass sie nicht für die Messung von Echtzeit-Anwendungen, Anwendungen zur Prozesskontrolle oder auch Betriebssystemen geeignet sein soll, obwohl A. J. Albrecht sie ursprünglich bei einem Projekt zur Entwicklung eines Betriebssystems entwickelt hat. Darüber hinaus war zwar die Technologieunabhängigkeit der Methode begrüßt worden, aber das Fehlen von verschiedenen Sichten (Entwickler, Endbenutzer, …) bemängelt worden. Genau in diese Lücke stößt das Common Software Metrics Consortium (COS- MIC) mit seinen Full Function Points (FFP). Diese COS- MIS FFP Version 2.2 wurden nach zahlreichen Feldversuchen 2003 als ISO-Norm ISO/ IEC 19761: 2003 standardisiert. Das Handbuch dazu kann aus dem Internet heruntergeladen werden unter www.lrgl.uqam.ca/ cosmicffp. Eine genaue Beschreibung der Methode ist in [3, Kapitel 9.3] zu finden. Die COSMIC-FFP-Methode leitet die funktionale Größe aus der Anzahl der zur Durchführung eines Prozesses notwendigen Datenbewegungen ab. Daneben wird ein Schichtenkonzept (Software-Layers) verwendet. Eine Überprüfung von fünf Applikationen mit IFPUG FP und COSMIC FFP ergab kaum Differenzen im MIS-Umfeld, aber 70 % Unterschied bei Realtime-Systemen. In der ISBSG-Benchmarking-Datenbank sind bereits mehr als 60 COSMIC-FFP-Projekte enthalten. Durch die Entwicklung mit einem weltweiten Konsortium von Unternehmen unter wissenschaftlicher Begleitung der Universität von Montreal, Canada (Prof. Alan Abran) ist die COSMIC- FFP-Methode die erste Methode zur Umfangmessung, die vor dem Einsatz validiert wurde. Dadurch stand bereits von Anfang an eine Erfahrungsdatenbank zur Verfügung. Die COSMIC-FFP-Methode konnte auf den Erfahrungen der anderen Methoden aufbauen und wird deshalb auch als Methode der zweiten Generation bezeichnet. PraktischeErfahrungenundSynergieeffektebeim EinsatzderFunction-Point-Methode Die Function-Point-Methode dokumentiert objektiv und einheitlich die Anwendungssysteme aus Benutzersicht, und zwar konsistent mit dem Verständnis der Anwender über die Funktionalität der Anwendungssysteme (einheitliche Sprache für IT und Fachbereich). Damit kann die Benutzerzufriedenheit mit dem Projekt gesteigert werden. Die Strukturierung aus der Sicht der Endbenutzer zeigt die Elementarprozesse entsprechend den Business Requirements (Geschäftsprozesse) und führt damit zu einem besseren Design zu und besseren Steuerungsmöglichkeiten im Projektverlauf. Die Informationen sind für Architektur, Spezifikation, Entwicklung, Weiterentwicklung und Wartung sowie die Ableitung von Testfällen, für die Releaseplanung und nach Dokumentation für die Einarbeitung von anderen Mitarbeitern wiederverwendbar. Veränderungen können damit in der Entwicklungsphase in das Fachkonzept eingearbeitet und abgestimmt werden. Somit können Abweichungen erkannt und gegebenenfalls neue Zielvereinbarungen getroffen werden. Durch Toolunterstützung können die Geschäftsvorfälle standardisiert einem Projekt zugeordnet, festgehalten, beschrieben, gruppiert, Datenfeldern und Dateien zugeordnet und von Fachbereich und IT gemeinsam bearbeitet werden. Der Entwicklungsstand kann in einzelnen Phasen archiviert sowie eingefroren und als IST-Konzept vereinbart werden. Bei wiederholter Zählung kann der schleichende Funktionszuwachs gemessen werden und damit eine Frühwarnung erfolgen, falls das Projekt aus dem Ruder zu laufen droht. Insgesamt fördert das die gute Zusammenarbeit zwischen IT und Fachbereich, hilft Missverständnisse zu beseitigen, unterstützt das Gelingen der Projekte und führt insgesamt zu einer deutlichen Verbesserung der Qualität und zu Reuse-Möglichkeiten im ganzen Software-Entwicklungsprozess. DieAufwandsschätzungalsVoraussetzungfürsolideProjektplanung Voraussetzung für das Gelingen eines Softwareprojekts ist eine fundierte Planung. Dazu gehört vor allem eine realistische Aufwandsschätzung. Aufwandsschätzungen liefern Werte zu Aufwand, Terminen, Kosten und Projektdauer, die in die Planungen einfließen und später nachverfolgt werden können. Neben Planung und Controlling wird dadurch auch die Erfolgsmessung sowie das Lernen aus der Vergangenheit zur Schätzung zukünftiger Projekte unterstützt [2]. Die für eine realitätsnahe Planung benötigten Größen Aufwand, Termine, Kosten, Projektdauer und Ressourcen sind neben den sachlichen Projektzielen die wichtigsten Einflussfaktoren auf den Erfolg eines Projekts. Nur durch eine professionell durchgeführte Aufwandsschätzung kann der Projektleiter diese Informationen verlässlich erhalten. Nicht vorhandene Dokumentationen und fehlende Erfahrungen sind eines der häufigsten Probleme, auf die Projektleiter stoßen, wenn sie Aufwandsschätzungen (oder Projektplanungen) vornehmen müssen. Da hilft nur, sofort damit anzufangen, sonst kann der Teufelskreis nie durchbrochen werden! [2] KritischeErfolgsfaktorenderAufwandsschätzung Die in Abb. 1 aufgeführten Hauptthemen der Aufwandsschätzung sind auch gleichzeitig die kritischen Erfolgsfaktoren. Davon stehen besonders die Schätzgenauigkeit und die Schätzzeitpunkte im Vordergrund, zumindest bei der Einführung von Aufwandschätzmethoden. Außerdem sind frühe Schätzungen und das Managen von Akzeptanzproblemen kritische Variablen des Einführunsprozesses. SchätzgenauigkeitundSchätzzeitpunkte Die, je nach Schätzzeitpunkt (siehe Abb. 3), mehr oder weniger große Unwissenheit über die Schätzparameter hat zur Folge, dass ❏ das Ergebnis einer Schätzung nie eine absolute Zahl, sondern immer ein Intervall ist, ❏ die Bandbreite dieses Intervalls mit dem zur Verfügung stehenden Wissen über das Schätzobjekt zusammenhängt und ❏ die Unsicherheit in dem Maße abnimmt, in dem die Aufwandsschätzung nachverfolgt wird [2]. Ein weiteres Problem liegt in einem schleichenden Funktionszuwachs (requirements creep) aufgrund technischer Änderungen. Dieser Funktionszuwachs kann, in aktuell projekt M A N A G E M E NT 1/ 20 0 5 27 Abhängigkeit vom Projektumfang, bei mehr als drei Prozent je Monat Projektlaufzeit liegen. Er lässt sich durch wiederholte Messung des Umfangs während des Projektverlaufs ermitteln und steuern. Die Aufwandsschätzung darf deshalb nicht als ein einmaliges Ereignis angesehen werden, sondern ist ein Prozess, der das Projekt während der gesamten Dauer begleitet. Erneutes Schätzen mit zeitlichem Fortschritt oder nach größeren Änderungen eines Projekts ist unerlässlich, um die Schätzgenauigkeit zu erhöhen. Werden Schätzungen zudem mit unterschiedlichen Methoden durchgeführt und eventuell mit Hilfe Dritter validiert, trägt dies weiter zu einer Qualitätssteigerung bei. FrüheSchätzungen Paradox an der Situation ist, dass gleichzeitig sowohl frühe als auch genaue Schätzungen benötigt werden. Frühe Schätzungen sind jedoch in der Regel ungenau. Da oft die Schätzungen nicht professionell dokumentiert werden, kann auch nicht aus den Erfahrungen der Vergangenheit gelernt werden. So schließt sich der Teufelskreis: Schätzen erfolgt zu früh und zu selten! Bei frühen Schätzungen kann nur grob anhand der wenigen vorhandenen Informationen geschätzt werden. Für Unsicherheit und Risiken wird mit Zuschlägen, abhängig vom Projektumfang, in Höhe von 10 bis 30 % gerechnet. Hinzu kommt der geschätzte Funktionszuwachs für noch zu erwartende technische Änderungen (siehe oben: Schätzgenauigkeit und Schätzzeitpunkte). Bei Auswertungen genau dokumentierter Function- Point-Zählungen mit Hilfe von Regressionsanalysen konnte in der AXA Service AG ein starker Zusammenhang zwischen der Anzahl der gezählten Eingaben und Ausgaben mit den Funktionspunkten insgesamt ermittelt werden (siehe Abb. 4). Damit können bereits zu frühen Zeitpunkten (zum Zeitpunkt der Studie, also vor Projektbeginn) Prognosen für die erst später genauer zählbaren Function Points vorgenommen werden, die eine hohe Prognosegenauigkeit aufweisen (Fehlermarge ca. 12 %). Akzeptanz Die Einführung einer neuen Methode hat üblicherweise mit Akzeptanzproblemen zu kämpfen. Als Lösung bietet sich an, den Königsweg für die Einführung von Innovationen zu beschreiten: umfassende Information, gute Ausbildung und Partizipation aller Beteiligten! Daneben kann man einige akzeptanzfördernde Maßnahmen ergreifen, wie z. B. ❏ Vorbereitung von Gegenargumenten gegen Killerphrasen und Befürchtungen, ❏ Schätzklausuren, die das gemeinsame Verständnis im Team fördern, ❏ Toolunterstützung, die die Überlebenschancen von Methoden erhöht, ❏ Messen von Prozessen, nicht Personen, ❏ Bewusstsein dafür schaffen, dass Umfangmessung notwendig und nicht Overhead ist und ❏ Unterstützung durch das Management. Die Auswirkungen fehlender Akzeptanz sind Wider- Studie Projektvorbereitung Analyse Design Realisierung Test Einführung Start Projekt Abschluss 1 2 3 4 5 6 7 Grobe Schätzung Verbindliche Schätzung (daran wird der Projekterfolg gemessen) Tracking der Schätzung Schätzerfahrungen dokumentieren, Nachkalkulation durchführen Abb.3: Schätzzeitpunkte IO (Anzahl EI + EO) y = 7,7905x + 43,499 R 2 = 0,9483 Function Points Abb.4: Function-Point-Prognose projekt M A N A G E M E NT 1/ 20 0 5 aktuell 28 WISSEN stände bei den betroffenen Mitarbeitern. Einige beliebte Killerphrasen gegen die Function-Point-Methode und Gegenargumente dazu zeigt Abb. 5. Zum Umgang mit Widerständen sind die in Tabelle 1 gezeigten Maßnahmen empfehlenswert. AufwandsschätzunginspeziellenUmgebungen Das Aufkommen neuer Technologien in der Software- Entwicklung hat für die Aufwandsschätzung und Function-Point-Zählung Herausforderungen gebracht, denn die Methoden wurden aus Erfahrungen der Vergangenheit entwickelt, um Hilfen für die Planung von zukünftigen Projekten und Anwendungssystemen zu bieten. Dabei zeigte sich, dass die bewährten Konzepte auch in neuen Umfeldern einsetzbar sind. Speziell im objektorientierten Paradigma, bei Datawarehouse-Systemen und Web- Entwicklungen ist die Function-Point-Methode einsetzbar, wobei einzelne Anpassungen vorzunehmen sind. ObjektorientierteMetriken Über 200 verschiedene objektorientierte Software-Metriken sind in den letzten Jahren publiziert worden. Horst Zuse [8] hat über 130 davon zusammengestellt und teilweise erläutert. Auch die ISBSG-Benchmarking-Datenbank vom Juni 2002 enthält knapp 25 % Projekte, in denen mit objekorientierten Metoden gearbeitet wurde [6]. Häufig wird behauptet, dass objektorientierte Metriken nicht mit der Function-Point-Methode kompatibel seien, obwohl Fetcke et al. [5] für die objektorientierte Systementwicklung eine Konzeption und konkrete Regeln für die Umsetzung in Function Points vorgelegt haben. Auch die IFPUG hat eine ausführliche Fallstudie (Case Study III) für den Einsatz der Function-Point-Methode bei objektorientierter Systementwicklung vorgelegt. Dabei sind Klassen Kandidaten für interne und externe Dateien. Objekte sind Kandidaten für Eingaben, Ausgaben und Abfragen. Ebenso beschreiben Use Cases aus dem UML- Umfeld (Unified Modelling Language) die Funktionalität aus Benutzersicht und können somit leicht in Function Points bemessen werden [3, Seite 223 ff.]. Function-Point-ZählungvonDatawarehouse- Projekten Die Anforderungen an Datawarehouse-Systeme unterscheiden sich erheblich von den Anforderungen an transaktionsorientierte Systeme. Nach Auswertungen der ISBSG-Benchmarking-Datenbank beträgt der Anteil von Code- und Referenztabellen in Datawarehouse-Systemen im Verhältnis zum funktionalen Umfang bis zu 60 % gegenüber Management-Informationssystemen, wo er oft 30 bis 40 % beträgt. Die Multidimensionalität der Datawarehouse-Architektur ist eine Herausforderung für die Function-Point-Zählung. Inzwischen sind zwei Vorschläge für die Zählung von Datawarehouse-Systemen publiziert worden [3, Seite 386 ff.]. AufwandsschätzungvonWeb-Entwicklungen Web-Entwicklungen unterscheiden sich von konventioneller Software-Entwicklung durch ihre Einbettung in mehrstufige, komponentenbasierte Client-Server-Architekturen (oft vier oder fünf Stufen). Dabei werden häufig bestehende Alt-Anwendungen integriert. Bei der komponentenbasierten Software ist die Implementierung gekapselt. Die Komponentenorientierung ändert nichts an der Zählweise der Function Points, unterstützt vielmehr den Einsatz der Function-Point-Methode für die Messung des Softwareumfangs von Web-Entwicklungen [3, Seite 398 ff.]. Die Erweiterung von Alt-Anwendungen um Web-Frontends kann dabei wie ein Weiterentwicklungsprojekt gezählt werden, die Neuentwicklung kompletter Web-Anwendungen wie ein Neuentwicklungsprojekt. Einzige Herausforderung ist die Aufwandsschätzung statischer Webseiten. Dabei geht es hauptsächlich um die Gestaltung und Verlinkung hart kodierter HTML-Seiten über spezielle Entwicklungsprogramme oder Texteditoren. Die Aufwandsschätzung erfolgt hier zweckmäßiger durch Expertenschätzungen auf Basis der jeweiligen Mengengerüste. Function Points sind unbeliebt, weil … ... sie von Theoretikern erstellt und praxisfern sind. Ursprünglich von A. Albrecht in einem Projekt zur Erstellung von Systemsoftware entwickelt. ... sie Verwaltungsaufwand produzieren. Der Aufwand ist im Vergleich zu Nutzen und Projektgesamtaufwand vernachlässigbar gering. ... sie nicht für objektorientierte Anwendungsentwicklung geeignet sind. Die FP stellen ein Meta-Modell dar, daher ist eine Abbildung der Requirements, egal in welcher Beschreibung, möglich. Vorurteil Gegenargument Abb.5: KillerphrasenundGegenargumente Widerstand Istnatürlichundunvermeidlich. ErwartenSieWiderstand! Zeigtsichnichtimmeroffen. FindenSieWiderstand! HatvieleUrsachen. VerstehenSieWiderstand! DiskutierenSieüberdieBedenken, nichtüberdieArgumente! KonfrontierenSieWiderstand! EsgibtnichtnureinenWeg,Widerstandzubekämpfen! ManagenSieWiderstand! Tabelle1: MaßnahmenzumUmgangmitWiderständen aktuell projekt M A N A G E M E NT 1/ 20 0 5 29 AufwandsschätzungvonWartungsaufträgen/ Changes Bei Wartungsaufträgen/ Changes handelt es sich um kleinere Arbeitspakete, die in der Regel weniger als 100.000 EUR kosten und keine funktionale Weiterentwicklung der Software betreffen (0 Function Points). Damit entfällt der Umfang als wesentlicher Einflussfaktor für die Aufwandsschätzung. Dazu empfiehlt es sich, excelbasierte Schätzformulare zu entwickeln [3, Seite 160 ff.]. Die AXA Service AG hat mehrere Varianten solcher Schätzformulare im Einsatz: für grobe Schätzungen sowie Host, PC und Client/ Server, Bürokommunikation und Agentursystem. Dabei werden meist vorgegebene Standardaufwandssätze mit Einflussparametern multipliziert (z. B. Anzahl Ansprechpartner im Fachbereich mal Standardaufwand). Weitere Gemeinkosten-Zuschläge, z. B. für Projektmanagement und Testen, werden hinzugefügt. Damit wurden in der Pilotphase in zwei Jahren 220 Aufwandsschätzungen in fünf Abteilungen gesammelt, ausgewertet und daraufhin die Standardwerte verbessert. Im letzten Jahr wurden 130 Aufwandsschätzungen aus zwölf Monaten ebenfalls zu einer erneuten Aktualisierung der Standardwerte ausgewertet. Das Verfahren hat sich durch Mund-zu-Mund-Propaganda im Unternehmen verbreitet (Piloten waren drei Abteilungen, aber von fünf Abteilungen lagen am Ende der Pilotphase Aufwandsschätzungen zur Auswertung vor). Funktionale Erweiterungen/ Changes werden generell wie Neuentwicklungen behandelt. Beim Einsatz der Function-Point-Methode mit Toolunterstützung hat sich dabei herausgestellt, dass eine vernünftige Dokumentation der ursprüglichen Function-Point-Zählung (z. B. entlang den Menüpunkten der Bildschirmmasken und entsprechend den Transaktionen) bei der späteren Änderungsschätzung eine schnelle Zuordnung der zugehörigen Function Points erleichtert und damit der Umfang für die Änderungen schnell ermittelt und dem Auftraggeber mitgeteilt werden kann. ProfessionelleHilfestellungdurchMetrikorganisationen Speziell für Anfänger, aber auch zur Diskussion mit Fortgeschrittenen und Experten empfiehlt sich die Mitgliedschaft in einem nationalen Metrikverband, gegebenenfalls auch die weitere Mitgliedschaft in einer internationalen Metrikorganisation. Zum einen erhält man von Anwendern Hilfen für die effektive Einführung der Function- Point-Methode sowie durch den Erfahrungsaustausch in den Gremien der Organisationen die Möglichkeit, die eigene Betriebsblindheit zu überwinden. Außerdem bekommt man ständig neue Anregungen. Zum anderen trägt man durch seine Mitgliedschaft mit dazu bei, dass sich Software-Metriken weiter verbreiten und noch mehr etablieren. Dies ist insbesondere für das Benchmarking wichtig, denn ohne eine internationale Standardisierung ist ein firmenübergreifendes Benchmarking undenkbar. DASMA Die Deutschsprachige Anwendergruppe für Software- Metrik und Aufwandschätzung e. V. (DASMA) ist ein gemeinnütziger Verein und befasst sich mit der Entwicklung und Festsetzung von Standards zum Messen von Software. Sie fördert die Bewertung der Software zur Verbesserung ihrer Nutzung in Wirtschaft und Verwaltung. Gegründet 1993 in Darmstadt, hat sie derzeit (2004) ca. 70 Mitglieder in Deutschland, Österreich und der Schweiz. Außerdem ist die DASMA Mitglied der wichtigsten internationalen IT-Metrikorganisationen. Die DASMA versteht sich als Netzwerk und Berufsverband der deutschsprachigen Anwender von Software-Metriken und der Aufwandsschätzung [3, Seite 254 ff.]. GI-FG2.1.10Software-Messungund-Bewertung Die GI-Fachgruppe 2.1.10 Software-Messung und -Bewertung in Magdeburg besteht seit 1992 und wird von Prof. Reiner Dumke geleitet. Inhaltlich befasst sie sich sowohl mit den theoretischen Grundlagen im Bereich Softwaremessung und -bewertung als auch mit der praktischen Umsetzung im Software-Entwicklungsprozess, wie beispielsweise Zertifizierungen, Metrikdatenbanken oder Experience Factories. Dazu veranstaltet sie regelmäßig den International Workshop on Software Measurement - IWSM, der im Wechsel in Deutschland (zusammen mit der MetriKon- Tagung der DASMA) und Kanada (in Zusammenarbeit mit der Universität Quebec, Prof. Alain Abran) stattfindet (Proceedings 2001 unter www.lrgl.uqam.ca). Die Fachgruppe betreut auch das Softwaremesslabor (SMLab), das den Prototyp einer Messdatenbank im Internet anbietet. Darüber hinaus publiziert sie zweimal im Jahr die Meprojekt M A N A G E M E NT 1/ 20 0 5 aktuell 30 WISSEN trics News mit Informationen zu den Themen Softwaremessung und -Metriken. Die Homepage der Fachgruppe (www.ivs.cs.uni-magdeburg.de/ sw-eng/ us/ ) bietet zahlreiche Informationsmöglichkeiten [3, Seite 256 ff.]. IFPUG Die International Function Point User Group (IFPUG) in den USA (gegründet 1984) hat mit Version 4.1 eine standardisierte Function-Point-Methode verabschiedet, die genaue Anleitungen für die Zählung der Function Points enthält. Dieser Standard ist von der ISO im Oktober 2003 als ISO/ IEC-20926-Standard für die Umfangmessung von Software anerkannt worden (ohne die 14 Systemmerkmale). Die Aufwandsschätzung der IT-Projekte soll mit der Version 4.1 der IFPUG-Function-Point-Methode in einen aktuellen Stand versetzt und überbetrieblich vergleichbar werden. Ende 2004 veröffentlichte die IFPUG die weiter verbesserte Version 4.2. Weiter bietet die IFPUG an, ihre Mitglieder als Function-Point-Zähler zertifizieren zu lassen (seit 2004 auch als Metrikspezialist in mehreren Stufen). Sie richtet jährliche Tagungen zum Erfahrungsaustausch aus und arbeitet in zahlreichen Arbeitsgruppen an der Weiterentwicklung der Function-Point-Methode. So ist bereits 1998 als Ergänzung zu den zwei bereits bestehenden, detaillierten Fallstudien zur Function-Point-Methode noch eine dritte für die objektorientierte Software-Entwicklung herausgegeben worden. Die Homepage der IFPUG (www.ifpug.org) bietet Foren zum Informationsaustausch und aktuelle Informationen zu Software-Metriken und Aufwandsschätzung sowie zahlreiche Links zu anderen IT-Metrikorganisationen und Services für die IFPUG-Mitglieder [3, Seite 257 ff.]. ISBSG Die International Software Benchmarking Standards Group (ISBSG, gesprochen: IceBags - Eistüten) begann als ein loser Zusammenschluss von internationalen IT- Metrikorganisationen. Sie verwenden für die Schätzung des Projektumfangs zum überwiegenden Teil die Function-Point-Methode (meistens nach IFPUG). Diese IT- Metrikorganisationen trugen Informationen und Techniken mit dem Ziel zusammen, die Praktiken zur Software- Entwicklung zu verbessern. Im Juli 1994 trafen sich Vertreter von IT-Metrikorganisationen aus USA, England, Australien und Neuseeland und gründeten die ISBSG. Das bisher letzte Release 9 der ISBSG-Benchmarking- Datenbank erschien im Juni 2003 auf der Basis von mehr als 3.000 Projekten. Der bisher letzte Report „The Benchmark“ Release 8 wurde Mitte Januar 2004 anhand von 2.027 Projekten publiziert. Alle Unterlagen der IS- BSG können auch über das DASMA-Sekretariat bezogen werden [3, Seite 259 ff.]. MAIN Das Metrics Association’s International Network (MAIN) wurde 2002 in Brüssel mit dem Ziel gegründet, den Austausch von Informationen zwischen den europäischen Usergroups im Software-Metrik-Bereich durch Organisation von Konferenzen und Workshops etc. zu koordinieren. Es wurde beschlossen, die Informationen über Aktivitäten und Resultate der nationalen europäischen IT-Metrikorganisationen auszutauschen und eine gemeinsame Vertretung in der ISO, ISBSG und anderen internationalen IT- Metrikorganisationen sicherzustellen [3, Seite 266 ff.]. ■ Literatur [1]Bundschuh,Manfred: DieFunction-Point-Methodeim praktischenEinsatzbeiSoftwareprojekten.In: Schelleet al.(Hrsg.): LoseblattsammlungProjekteerfolgreichmanagen.13.Aktualisierungs-undErgänzungslieferung,Köln, November1999 [2]Bundschuh,Manfred: AufwandsschätzungalsVoraussetzungfürdieProjektplanung.In: Bernecker,Michael; Eckrich,Klaus: HandbuchProjektmanagement.R.OldenbourgVerlagMünchenWien2003,S.239-259 [3]Bundschuh,M.; Fabry,A.: Aufwandschätzungvon IT-Projekten.2.Auflage,MITPVerlag,Bonn2004,ISBN 3-8266-0864-X [4]DeMarco,Tom: Wasmannichtmessenkann…kann mannichtkontrollieren.MITPVerlag,Bonn2004,ISBN 3-8266-1488-7 [5]Fetcke,T.; Abran,A.; Nguyen,T.: FunctionPointAnalysis fortheOO-JacobsonMethod: AMappingApproach.In: ProceedingsoftheFESMAConference1998.Antwerp, pp.395-402 [6]ISBSG: TheBenchmark,Release8.ISBSG,Warrandyte, Victoria2002,ISBN0-9577-2018-1 [7]Jones,C.: AppliedSoftwareMeasurement.McGraw- Hill,NewYork1996,ISBN0-0703-2826-9 [8]Zuse,H.: AFrameworkforSoftwareMeasurement. DeGruyter,Berlin,NewYork1997,ISBN3-1101-5587-7 Schlagwörter FullFunctionPoints(COSMIC),Function-Point-Methode, Function-Point-Prognose,ISBSG-Benchmarking-Datenbank,Metrikorganisationen,objektorientierteMetriken, schleichenderFunktionszuwachs(requirementscreep), SoftwareumfangvonWeb-Entwicklungen,Umfangmaße nachDIN,ZählungvonDatawarehouse-Systemen Autor Dipl.-Math.ManfredBundschuhistseit über20JahrenimIT-RessortderAXA ServiceAGtätig,derzeitalsIT-Controller.Seitmehrals20Jahrenhater LehraufträgefürSoftwareEngineering sowieProjektmanagementundArbeitsmethodikanderFachhochschuleKöln undhatdabeiüber200DiplomandInnenbetreut.FürdiesenbesonderenEinsatzwurdeihm1996 dieEhrenmedaillederFachhochschuleKölnverliehen.Seit einigenJahrenisterVorstandsvorsitzenderderDASMAe.V. (DeutschsprachigerAnwenderverbandfürSoftware-MetrikenundAufwandsschätzung,www.dasma.org/ ).EristMitautorundMitherausgebervoneinigenIT-Fachbüchern.Sein Buch„AufwandschätzungvonIT-Projekten“ist2004inder2. Auflageerschienen. Anschrift SanderHöhe5 51465BergischGladbach Tel./ Fax: 02202/ 35719 E-Mail: manfred.bundschuh@freenet.de www.gm.fh-koeln.de/ ~bundschu aktuell projekt M A N A G E M E NT 1/ 20 0 5