Aufwandschätzung von Softwareprojekten

Transkript

1 Aufwandschätzung von Softwareprojekten Einsatz und Nutzen der Function-Point-Methode 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 Aufwandschä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 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 Function Points zahlreiche Metriken, u.a. zur Qualitätsplanung und für Management- Reviews, mit denen Stabilität und Zuverlässigkeit sowie Produktivität von IT-Systemen beurteilt werden kann. Durch die internationale Standardisierung sind sogar unternehmensübergreifende Benchmarks möglich. Herausforderungen der Aufwandschätzung Bei der Aufwandschä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 Aufwandschätzung e.v., oder der GI-Fachgruppe (Software-Messung und -Bewertung, Gesellschaft für Informatik e.v., 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 Aufwandschätzung interessiert sind. Oder sie haben schmerzhaft erfahren, was der Guru der Aufwandschä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 Die wichtigsten Themen der Aufwandschätzung Schätzobjekt Zeitpunkte der Aufwandschätzung Schätzgenauigkeit Schätzfehler Aufwand für die Aufwandschätzung Schätzmethoden Tracking der Schätzungen Schätztools Schätzparameter Schätzehrlichkeit Schätzerfahrung Einführung der Aufwandschätzung Schätzkultur Abb. 1: Hauptthemen der Aufwandschätzung Chancen, die die professionelle Aufwandschä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, daß Softwareanbieter bei staatlichen Stellen den Leistungsumfang in Function Points angeben müssen. Die Hauptthemen der Aufwandschätzung sind in Abb. 1 zusammengefasst.! 23

2 WISSEN Eingabe (EI) Interner Datenbestand Benutzer Ausgabe (EO) Abfrage (EQ) Anwendungsgrenze Abb. 2: Die Function-Point-Methode EI EO EQ Die Function-Point-Methode als Voraussetzung für solide Aufwandschä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 anerkannte Methode zur Messung der funktionalen Größe bzw. des Umfangs einer Anwendung aus Benutzersicht, d. h., 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 Aufwandschätzung sind Informationen über das zu schätzende Projekt, z. B.: Ü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. Function Points auf einen Blick Externer Datenbestand Andere Anwendung 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 Aufwandschä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. Der Schritt vom Messen zum Schä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 Aufwandschä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 Aufwandschä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 xb 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 bzw. andere Parameter als den Um- 24

3 fang. Teilweise werden diese Einflußgröß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 LOC Cobol und damit eine Produktivität von LOC pro PM. Das gleiche Programm in Assembler entspricht einem Umfang von LOC (Assembler-Äquivalent) und hat damit eine Produktivität von 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ße nach ISO-Norm Es gibt in der Software-Industrie die international normierten Metriken der ISO (ISO = International Organization for Standardization). ISO ist seit 1999 Standard und beschreibt die grundlegenden Prinzipien einer funktionalen Größenmetrik (Functional Size Metric) und die nötigen Definitionen dazu. ISO beschreibt die Prüfkriterien zur Feststellung, ob eine Methode funktionale Metrik im Sinne von ISO ist. ISO stellt Messkriterien in Form von Checklisten für Assessments zur Verfügung, anhand derer bewertet werden kann, wie gut eine funktionale Größenmetrik ISO erfüllt. Derzeit (Ende 2004) sind nur Varianten der Function-Point-Methode nach ISO anerkannte Public Available Standards (PAS). Dabei handelt es sich um die IFPUG-Function-Point-Methode Version 4.1 (IFPUG = International Function Point User Group, ISO/IEC 20926; die COSMIC Full Function Points (COSMIC = Common Software Measurement Consortium, ISO/IEC 19761; die NESMA-Function-Point-Methode (NESMA = Niederländische Metrik Organisation, ISO/IEC 24570; die Mark-II-Function-Point-Methode (von Charles Symons in England für Entwicklungen mit Programmiersprachen der 4. Generation entwickelt, ISO/IEC COSMIC Full Function Points (FFP) Die IFPUG-Methode ist anerkannt für Zählungen von so genannten Geschäftsanwendungen und MIS-Syste- Anzeige 25

4 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 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. Praktische Erfahrungen und Synergieeffekte beim Einsatz der Function-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 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 ggf. 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. Die Aufwandschätzung als Voraussetzung für solide Projektplanung Voraussetzung für das Gelingen eines Softwareprojekts ist eine fundierte Planung. Dazu gehört vor allem eine realistische Aufwandschätzung. Aufwandschä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 Aufwandschä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 Aufwandschätzungen (oder Projektplanungen) vornehmen müssen. Da hilft nur, sofort damit anzufangen, sonst kann der Teufelskreis nie durchbrochen werden! [2] Kritische Erfolgsfaktoren der Aufwandschätzung Die in Abb. 1 aufgeführten Hauptthemen der Aufwandschä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ätzgenauigkeit und Schä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 Aufwandschätzung nachverfolgt wird [2]. Ein weiteres Problem liegt in einem schleichenden Funktionszuwachs (requirements creep) aufgrund technischer Änderungen. Dieser Funktionszuwachs kann, in 26

5 Studie 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, Unterstützung durch das Management. Die Auswirkungen fehlender Akzeptanz sind Wider- Projektvorbereitung Start Projekt Abschluss Analyse Design Realisierung Test Einführung 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 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 Aufwandschä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 evtl. mit Hilfe Dritter validiert, trägt dies weiter zu einer Qualitätssteigerung bei. Frühe Schä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 Abb. 4: Function-Point-Prognose 27

6 WISSEN Function Points sind unbeliebt, weil sie von Theoretikern erstellt und praxisfern sind.... sie Verwaltungsaufwand produzieren.... sie nicht für objektorientierte Anwendungsentwicklung geeignet sind. Abb. 5: Killerphrasen und Gegenargumente 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. Aufwandschätzung in speziellen Umgebungen Das Aufkommen neuer Technologien in der Software-Entwicklung hat für die Aufwandschä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. Objektorientierte Metriken Ursprünglich von A. Albrecht in einem Projekt zur Erstellung von Systemsoftware entwickelt. Der Aufwand ist im Vergleich zu Nutzen und Projektgesamtaufwand vernachlässigbar gering. Die FP stellen ein Meta-Modell dar, daher ist eine Abbildung der Requirements, egal in welcher Beschreibung, möglich. Ü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ählung von Datawarehouse- 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.]. Aufwandschätzung von Web-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 Aufwandschä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. Widerstand Ist natürlich und unvermeidlich. Zeigt sich nicht immer offen. Hat viele Ursachen. Diskutieren Sie über die Bedenken, nicht über die Argumente! Es gibt nicht nur einen Weg, Widerstand zu bekämpfen! Erwarten Sie Widerstand! Finden Sie Widerstand! Verstehen Sie Widerstand! Konfrontieren Sie Widerstand! Managen Sie Widerstand! Tabelle 1: Maßnahmen zum Umgang mit Widerständen 28

7 Aufwandschätzung von Wartungsaufträgen/Changes Bei Wartungsaufträgen/Changes handelt es sich um kleinere Arbeitspakete, die in der Regel weniger als EUR kosten und keine funktionale Weiterentwicklung der Software betreffen (0 Function Points). Damit entfällt der Umfang als wesentlicher Einflussfaktor für die Aufwandschä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 Standardaufwandsä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 Aufwandschätzungen in fünf Abteilungen gesammelt, ausgewertet und daraufhin die Standardwerte verbessert. Im letzten Jahr wurden 130 Aufwandschä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 Aufwandschä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. Software. Sie fördert die Bewertung der Software zur Verbesserung ihrer Nutzung in Wirtschaft und Verwaltung. Gegründet 1993 in Darmstadt, hat sie derzeit (2003) ca. 60 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 Aufwandschätzung [3, Seite 254 ff.]. GI-FG Software-Messung und -Bewertung Die GI-Fachgruppe Software-Messung und -Bewertung in Magdeburg besteht seit 1992 und wird von Prof. 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. Abran) stattfindet (Proceedings 2001 unter Die Fachgruppe betreut auch das Softwaremesslabor (SMLab), das den Prototyp einer Messdatenbank im Internet anbietet. Darüber hinaus publiziert sie zweimal im Jahr die Me- Anzeige Professionelle Hilfestellung durch Metrikorganisationen Speziell für Anfänger, aber auch zur Diskussion mit Fortgeschrittenen und Experten empfiehlt sich die Mitgliedschaft in einem nationalen Metrikverband, ggf. 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. Projektmanagement mit EDV ¼ Seite hoch + sw (92 b 125h) 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 29

8 WISSEN trics News mit Informationen zu den Themen Softwaremessung und -Metriken. Die Homepage der Fachgruppe ( 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 Standard für die Umfangmessung von Software anerkannt worden (ohne die 14 Systemmerkmale). Die Aufwandschätzung der IT-Projekte soll mit der Version 4.1 der IFPUG-Function-Point-Methode in einen en Stand versetzt und überbetrieblich vergleichbar werden. 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 ( bietet Foren zum Informationsaustausch und e Informationen zu Software-Metriken und Aufwandschä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 8 der ISBSG-Benchmarking- Datenbank erschien im Juni 2003 auf der Basis von Projekten. Der bisher letzte Report The Benchmark Release 8 wurde Mitte Januar 2004 anhand von Projekten publiziert. Alle Unterlagen der ISBSG 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: Die Function Point Methode im praktischen Einsatz bei Softwareprojekten. In: Schelle et al (Hrsg.): Loseblattsammlung Projekte erfolgreich managen. 13. Aktualisierungs- und Ergänzungslieferung, Köln, November 1999 [2] Bundschuh, Manfred: Aufwandsschätzung als Voraussetzung für die Projektplanung. In: Bernecker, Michael; Eckrich, Klaus: Handbuch Projektmanagement. R. Oldenbourg Verlag München Wien 2003, S [3] Bundschuh, M.; Fabry, A.: Aufwandschätzung von IT-Projekten. 2. Auflage, MITP Verlag, Bonn 2004, ISBN X [4] DeMarco, Tom: Was man nicht messen kann kann man nicht kontrollieren. MITP Verlag, Bonn 2004, ISBN [5] Fetcke, T; Abran, A.; Nguyen, T.: Function Point Analysis for the OO-Jacobson Method: A Mapping Approach. In: Proceedings of the FESMA Conference Antwerp, pp [6] ISBSG: The Benchmark, Release 8. ISBSG, Warrandyte, Victoria 2002, ISBN [7] Jones, C.: Applied Software Measurement. McGraw- Hill, New York 1996, ISBN [8] Zuse, H.: A Framework for Software Measurement. DeGruyter, Berlin, New York 1997, ISBN Schlagwörter Full Function Points (COSMIC), Function-Point-Methode, Function-Point-Prognose, ISBSG-Benchmarking-Datenbank, Metrikorganisationen, objektorientierte Metriken, schleichender Funktionszuwachs (requirements creep), Softwareumfang von Web-Entwicklungen, Umfangmaße nach DIN, Zählung von Datawarehouse-Systemen Autor Dipl.-Math. Manfred Bundschuh ist seit über 20 Jahren im IT-Ressort der AXA Service AG tätig, derzeit als IT-Controller. Seit mehr als 20 Jahren hat er Lehraufträge für Software Engineering sowie Projektmanagement und Arbeitsmethodik an der Fachhochschule Köln und hat dabei über 200 DiplomandInnen betreut. Für diesen besonderen Einsatz wurde ihm 1996 die Ehrenmedaille der Fachhochschule Köln verliehen. Seit einigen Jahren ist er Vorstandsvorsitzender der DASMA e.v. (Deutschsprachiger Anwenderverband für Software Metriken und Aufwandschätzung, Er ist Mitautor und Mitherausgeber von einigen IT-Fachbüchern. Sein Buch Aufwandschätzung von IT-Projekten ist 2004 in der 2. Auflage erschienen. Anschrift Sander Höhe Bergisch Gladbach Tel./Fax: / manfred.bundschuh@freenet.de 30