Software Schätzverfahren

19.06.2006 Permalink

Zusammenfassung:
Dieser Text gibt einen Überblick über die wichtigsten Begriffe im Zusammenhang mit Software-Schätzungen in der Praxis. Ziel der Schätztätigkeit ist das Ermitteln quantitativer Vorhersagen, die zu realistischen Zielvorgaben in Plänen führen. Hierzu sind in der Praxis verschiedene Verfahren gebräuchlich, die jeweils kurz vorgestellt und eingeordnet werden, da sie zu unterschiedlichen Zeitpunkten und Zwecken nützlich sind.

Der Leser lernt nicht, wie er sie einsetzt, sondern wann der Einsatz jeweils angezeigt ist. Eine eingehende Beschäftigung mit spezieller Literatur ist unumgänglich.

Einleitung

Das Schätzen von Aufwänden und Terminen ist eine immer wiederkehrende Aufgabe für viele in der Softwareentwicklung tätige Personen. Projekt- und Teilprojektleiter sind verantwortlich für die Durchführung von Schätzungen. Systemanalytiker, Architekten, Qualitätsmanager und Entwickler werden in unterschiedlichen Phasen immer wieder mit den Fragen konfrontiert: Was wird es kosten? Und wann ist es fertiggestellt?

Die Software-Branche hat keine glorreiche Historie im Erstellen von zutreffenden Schätzungen und dem Erreichen gesteckter Ziele. Der jährliche Chaos-Report der Standish Group weist regelmäßig aus, dass mehr als zwei Drittel aller untersuchten Projekte die Ziele im Sinne Termin und Kosten verpassen [1].

Dabei gibt es ausführlich beschriebene Verfahren für gute Schätzungen, es gibt preiswerte, einfache Wege, die Schätzqualität systematisch zu erhöhen. Und es gibt Strategien, um trotz großer Schätzunsicherheit mit Zielen umzugehen, die aggressiv oder gar unrealistisch sind.

Was ist eine Schätzung? Und was ist ein Ziel?

Frei nach Tom DeMarco gebe ich hier eine einprägsame 'Definition' für solche Zahlen an, die gerne als Schätzungen bezeichnet werden, aber keine sind: es ist der kleinste Wert, für den nicht 100% sicher ist, dass er unerreichbar ist [3].

Tatsächlich ist eine Schätzung eine Wahrscheinlichkeitsaussage der Form: 'Mit einer Chance von x% wird das Projekt maximal y Personenmonate kosten.' Schätzungen werden sehr häufig auch als Intervall angegeben, also etwa 'Die Kosten werden zwischen y1 und y2 Personenmonate liegen.' Dabei gibt es zwischen y1 und y2 eine Wahrscheinlichkeitsverteilung, die einer nach rechts 'verschobenen' Normalverteilung ähnelt. Die Intervallgrenzen markieren die Grenzen der Standardabweichung. Je kleiner das Intervall desto höher ist die Genauigkeit. Der nominale Schätzwert ist diejenige Zahl aus dem Intervall, so dass die Wahrscheinlichkeit, dass der in der Realität gemessene Wert darüber liegt, 50% beträgt.

Schätzungen beschränken sich nicht auf Kosten und Termine, obwohl die Ermittlung dieser Kennzahlen häufig die Triebfeder des Schätzvorgangs ist. Schätzen lässt sich z.B. auch die Größe des Systems in Lines of Code oder Function Points, die Anzahl zu erwartender Testfälle und Defekte, die Verlässlichkeit und Verfügbarkeit bei Inbetriebnahme des Systems, die Datenmengen, die eine Anwendung bewältigen muss usw.

Schätzungen sind meistens direkt eingebunden in Planungsprozesse, die vor der Initiierung von Projekten anfangen und noch während Betrieb und Wartung fortgesetzt werden. Gute Pläne, ganz gleich ob früh oder spät erstellt, ob auf der Unternehmens- oder der Mitarbeiterebene relevant, leben von guten Schätzungen.

Am Ende landen in Plänen dann immer Ziele. 'Die Konzepterstellung wird 10 PM benötigen und in 2 Kalender-Monaten abgeschlossen sein.' oder 'Das System wird in 16 Monaten live gehen.' Das ist richtig und erforderlich. Die Tücke steckt im Zielfindungsprozess, in dessen Verlauf entweder auf Schätzungen verzichtet wird, Schätzungen durch unbegründeten Optimismus verfälscht sind oder keine Grundlage für die gewünschte Genauigkeit besitzen oder -- und das erscheint mir fast tragisch -- handwerklich gut erarbeitete Schätzergebnisse aus politischen Gründen ignoriert werden.

Auf diese Weise entstehen unrealistische Ziele. Es mag als 'kernige' Haltung gelten, Ziele mit 'sportlichem Ehrgeiz' zu formulieren, tatsächlich verursachen solche Ziele zwei Probleme [2]:

Das Projekt wird in scheinbare 'Abkürzungen' gezwungen, die letztlich zu einer drastischen Erhöhung von Kosten und Dauer führen.

Das Unternehmen verliert Planungssicherheit, da zwar das Ziel formuliert ist, man sich aber vernünftigerweise nicht darauf verlassen kann. Werden unrealistische Ziele eines Projektes trotzdem verwendet, um z.B. eine Marketingkampagne vermeintlich rechtzeitig zu starten, so kann der entstehende Schaden bei Verpassen der Ziele leicht ein Vielfaches der tatsächlichen Projektkosten ausmachen.

Zusammenfassend: Schätzungen sind also das zentrale Mittel, um erreichbare Ziele zu formulieren.

Was ist eine gute Schätzung? Und was brauche ich dafür?

Eine gute Schätzung besitzt eine den Voraussetzungen entsprechend hohe Genauigkeit. Unter idealen Bedingungen sind Schätzungen mit [0,9;1,1] Genauigkeit erreichbar. D.h. die tatsächlich gemessene Kennzahl liegt maximal 10% über dem nominalen Schätzwert.

In frühen (Vor-)Projektphasen ist das Intervall einer guten Schätzung [0,25;4]. Diese Varianz ist gewaltig. Sie entspricht der großen Unsicherheit, die sich aus den tausenden noch nicht getroffenen Entscheidungen zu Umfang und Architektur des neuen Systems ergibt. Je mehr Entscheidungen getroffen werden, desto stärker treten dessen Konturen hervor und desto besser werden die Vorhersagen.

Frühe Schätzungen sind notgedrungen ungenau, sie besagen z.B., dass das Projekt irgendwas zwischen 2,5 und 40 Millionen Euro kosten wird. Das ist aus Sicht eines Sponsors schlicht unakzeptabel. Und daraus folgt: eine Schätzung, die von Entscheidern akzeptiert wird, benötigt starke Voraussetzungen.

Wenn man einige wenige Kennzahlen wie Systemgröße, Gesamtaufwand und Dauer vorangegangener Vorhaben kennt, kann man unter folgenden Umständen auch in frühen Phasen genauere Schätzungen erwarten:

Messung und Aufbewahrung einiger Metriken ist der Schlüssel zu besseren Vorhersagen und Plänen.

Was kann ich tun, wenn mir das Schätzergebnis nicht 'passt'?

Es gibt zwei Gründe, deretwegen eine qualitativ gute Schätzung keine Hilfe für einen Entscheider darstellt:

Genau genommen ist das Schätzergebnis natürlich doch eine Hilfe, denn im ersten Fall veranlasst die Ungenauigkeit die Entwicklung einer Strategie, um a) das künftige Vorhaben besser eingrenzen zu können und b) beizeiten die Schätzung zu wiederholen. Im zweiten Fall ist klar, dass Gegenmaßnahmen erforderlich sind, z.B. der fachliche Umfang im Sinne eines 'Build-to-Budget' beschnitten werden muss, d.h. die Feature-Menge wird der Aufwands- oder Zeitbeschränkung angepasst. Das bedeutet, dass das Projekt ein Requirements-Management benötigt, das den gelisteten Features früh auch geschätzte Kosten zuordnet. Selbst wenn nichts unternommen wird, so weiß der verantwortliche Manager, dass 'ein heißer Ritt' bevorsteht, und Pokern, Salamitaktik oder Politik erforderlich sein werden.

Für das Genauigkeitsproblem skizziere ich im folgenden einige Maßnahmen:

Wie kann ich kurz-, mittel- und langfristig eine bessere Schätzqualität erreichen?

Kurzfristig hilft in frühen Projektphasen nur eines: Annahmen treffen, dokumentieren und veröffentlichen oder direkt Entscheidungen zu Art und Umfang des Systems treffen. 'Eingeschlagene Pflöcke' sind für die Formgebung eines Projekts enorm wichtige Fortschritte, und sie wirken sich auch positiv auf die Zahlenarbeit aus. Es ist sehr empfehlensweit, direkt in mehreren System Releases (=Ausbaustufen) zu denken, das ermöglicht ein iteratives Vorgehen, was in frühen Phasen zu einer enormen Risikoreduktion führt.

Existiert dann wenige Wochen später ein Grobkonzept mit eindeutigen Aussagen zum Umfang des ersten Release und ein Blueprint der Architektur, so sollte die Schätzungsgenauigkeit im Bereich [0,5;1,5] liegen.

Mittelfristig greift folgendes Vorgehen:

Vorausgesetzt man arbeitet in Iterationen, die vollständige Releases erlauben, also die Phasen Feinkonzept, Design, Programmierung und Test umfassen, so kann man bereits früh eine Handvoll Kennzahlen sammeln, die ohnehin jedes Software-Projektcontrolling produziert: Aufwände für verschiedene Phasen und Tätigkeiten, Verhältnis von Konzept- zu Softwaregröße, Anzahl Defekte, Plantreue usw. In größeren Projekten (ab 10 Mitarbeiter) dauern solche Iterationen nicht -- wie von Befürwortern 'leichtgewichtiger Prozesse' propagiert wird -- zwei Wochen, man sollte eher acht Wochen veranschlagen. Aber nach dieser doch recht kurzen Zeit besitzt man schon quantitative Erfahrungswerte, die die Varianz auf [0,67;1,33] verringern helfen.

Langfristig sollte man Know-How mit dem Zählen von Function-Points aufbauen, da sie die typische Eingabe für Schätzmodelle (z.B. COCOMO II) in frühen Phasen sind. Da Schätzmodelle kalibriert werden müssen, muss man die Messung und Dokumentation weniger Kennzahlen veranlassen. Neben der Durchführung von Messungen und Aufbewahrung der Messergebnisse sind Projektabschlussberichte (Post Mortem) ein weiteres Werkzeug. Außer dem Zahlenmaterial sollten in diesen Berichten auch Beschreibungen zum System und den zurückliegenden Projektarbeiten enthalten sein:

Die Sicherheit, die auf derlei Langzeiterfahrungen beruht, ist eine spürbare Erleichterung für künftige Entscheidungen.

Schätzverfahren

Zu jedem der hier erwähnten Schätzverfahren werden folgende Fragen beantwortet:

Unabhängig vom konkreten Verfahren gelten immer folgende Imperative:

Nutzen Sie eine Tabellenkalkulation oder ein Schätzwerkzeug. Nichts ist ärgerlicher, als eine Schätzung zu veröffentlichen, bei der man sich schlicht verrechnet hat.

Dokumentieren Sie, was sie schätzen, auf welcher Informationsbasis die Zahlen ermittelt wurden und welche Annahmen Sie zusätzlich getroffen haben. Sobald das Ergebnis öffentlich ist, wird häufig die Frage kommen, was eigentlich alles inbegriffen ist. Achten Sie in Diskussionen darauf, dass nicht mehr Umfang hineininterpretiert wird, als Sie geschätzt haben.

Dokumentieren Sie die Methode, mit der Sie vorgegangen sind. Begründen Sie, warum die Methode geeignet ist.

Dokumentieren Sie die Berechnung. Wenn Sie, wie oben empfohlen, ein Werkzeug nutzen, sollte das leicht möglich sein.

So jetzt aber endlich vom allgemeinen zum konkreten: den in der Praxis gängigen Schätzverfahren.

Bauchschätzungen/Expertenschätzungen

Mit diesen Begriffen werden Aussagen von mehr oder minder Experten zu allen möglichen Kennzahlen bezeichnet. Charakteristisch ist dabei, dass die Schätzung in sehr kurzer Zeit (Minuten) 'nach Gefühl' gegeben wird, selten eine Wahrscheinlichkeitsaussage darstellt, sehr von Erfahrung und persönlicher Stimmungslage abhängt und häufig unter unbegründetem Optimismus leidet.

Solche Aussagen sind akzeptabel, wenn es um Aufwände oder Termine geht, die nicht mehr als drei Tage überspannen. Ansonsten sind sie schlicht inakzeptabel.

Sie sind gut geeignet, wenn z.B. Arbeitspakete geschätzt werden und in der Diskussion Einzelposten identifiziert und beziffert werden. In Verbindung mit der PERT-Formel, die vermittels Expected-Case:= (Best-Case + 4 x Most-Likely-Case + Worst-Case)/6 aus drei Schätzungen einen gewichteten Wert produziert, ergibt sich eine im Mittel(!) sehr gute Genauigkeit im Bereich 10% Abweichung.

Dadurch, dass sich individuelle Expertenschätzungen nur für sehr kleine Arbeitseinheiten eignen, ist ihr Einsatz erst bei der konkreten Planausgestaltung auf Basis einer Work-Breakdown-Structure, d.h. mitten im Software-Prozess empfehlenswert. Sie sind ebenfalls geeignet, um Restschätzungen zu Arbeitspaketen zwecks Fortschrittsverfolgung zu erstellen.

Schätzmodelle

Vielen Schätzmodellen ist folgendes Muster gemein: zunächst versucht man eine Aussage über die Größe des Systems zu erreichen. Aus der Größe leitet man den Aufwand ab. Schließlich ermittelt man den Termin, der offensichtlich vom eingesetzten Personalkörper abhängt. (Nicht ganz so offensichtlich ist dagegen, dass diese Abhängigkeit nicht-linear ist!)

Ein prominenter Vertreter ist das Constructive Cost Model, kurz COCOMO II. Um die Vorhersagegenauigkeit zu verbessern, beziehen Schätzmodelle zusätzliche Faktoren mit ein, z.B. den Typ der Software, den Kompetenzgrad der Mitarbeiter oder technologische Faktoren wie die Programmiersprache. Die Freiheit, diese Faktoren festzulegen, macht ein Modell sehr mächtig, die Festlegung selbst ist aber nicht-trivial. Und sie kann zu einem unsachgemässen 'Tuning' des Ergebnisses missbraucht werden.

Die andere Hürde ist die Angabe der Größe des künftigen Software-Systems, die ja selbst erst geschätzt werden muss. COCOMO II erlaubt in frühen Phasen die Eingabe von Function Points, die mit gleichnamigem Verfahren auf Basis recht detailierter Spezifikationen buchstäblich gezählt werden.

Schätzmodelle müssen auf Basis gemessener Daten kalibriert werden. Dann erlauben sie eine [0,75;1,25] Genauigkeit schon dann, wenn eine Größenschätzung mittels Function-Point-Counting oder Analogieschätzung verfügbar ist. Die Notwendigkeit dieser Kalibrierung erfordert vor dem Einsatz von Schätzmodellen also eine Investition, vor allem in Form von Zeit für Vorgänger-Projekte als Kennzahllieferanten.

Zu praktisch relevanten Schätzmodellen gibt es freie oder kommerzielle Software-Pakete, über die man die Schätzeingaben formulieren kann. Das praktische an diesen Werkzeugen ist, dass man den Einfluss verschiedener Faktoren leicht quantitativ simulieren kann.

Function-Point-Counting

Um die Größe eines Software Systems zu quantifizieren, existiert neben Lines of Code das Function-Point-Counting, das auf fachliche Konzepte, die die künftige Anwendung beschreiben, angewendet wird.

Dazu wird in fünf Kategorien jeweils mit drei Komplexitätsstufen gezählt:

Die Bezeichnungen der Kategorien wirken bezogen auf den Aufbau moderner Systeme etwas antiquiert und bedürfen daher einer adäquaten Übersetzung [5].

Zu jedem der 15 Paare (Kategorie, Komplexität) gibt es einen Function-Point-Wert, der mit dem gezählten Wert multipliziert wird. Die Summe aller 15 Produkte ergibt die Unadjusted Function Points.

Zusätzlich gibt es einen Anpassungsfaktor im Intervall [0,65;1,35], der aus 14 verschiedenen Einzelangaben errechnet wird.

Function-Points erfordern Übung und bei umfangreichen Spezifikationen etwas Zeit. Die Genauigkeit ist gut, Abweichungen zwischen verschiedenen erfahrenen Zählern sind innerhalb 10%. Das gilt freilich nur für die Punktwerte selbst, nicht für daraus abgeleitete Aufwands- oder Terminschätzungen (siehe Schätzmodelle).

Analogieschätzungen

Der Rückgriff auf bisherige Ergebnisse ist eine gute und preiswerte Möglichkeit, Schätzungen anzufertigen. Dabei ist wichtig, dass die Referenz, sei es ein existierendes System oder ein abgeschlossenes Projekt oder Arbeitspaket, sich in der gleichen Größenordnung befindet. Als Daumenregel sollte der Unterschied maximal Faktor 3 betragen.

Um z.B. die Größe eines künftigen Systems auf Basis eines existierenden zu ermitteln, kann man im bestehenden die Anzahl der Masken, Berichte und anderer sichtbarer Bestandteile zählen und dann die Summe der jeweils zur Implementierung benötigten Codezeilen (genauer: NCSS, Non-Comment Source Statements) messen. Durch Schätzen der jeweiligen Anzahl für das neue System ergibt sich via Dreisatz sofort eine Aussage zur Anzahl Codezeilen für jeden Bestandteil.

Man kann -- mit Abstrichen in der Genauigkeit -- auch in gröberem Maßstab schätzen, z.B. auf Basis der zu unterstützenden Geschäftsvorgänge.

Dieses Verfahren wird sehr häufig eingesetzt, leider verwendet man als Referenz fast immer Erinnerungen statt dokumentierte Fakten oder analysierte Artefakte, was die Qualität bis zur Unbrauchbarkeit mindert.

Es ist in allen Phasen der Softwareentwicklung einsetzbar. Der Aufwand ist -- sofern man mit einer Tabellenkalkulation umgehen kann -- gering. Dokumentierte historische Daten sind maßgeblich für die Genauigkeit.

Stellvertreterschätzungen

Wenn sich die Zielgröße nicht direkt schätzen lässt, ist es meist möglich eine andere Kennzahl zu erfassen oder zu schätzen, von der aus man mit einfacher Arithmetik die Zielgröße abschätzt.

Dies ist z.B. für den Defektbehebungsaufwand erforderlich. An diesen kommt man heran, wenn man eine Hypothese zur Fehleranzahl sowie zu Fehlerbehebungskosten je Fehler bildet.

Dieses Verfahren ist in vielen Situationen üblich und allgemein mit geringen Kosten verbunden. Die Genauigkeit der Zielgrößenschätzung hängt logischerweise von der Genauigkeit der Stellvertreterschätzung ab.

Branchenstandardwerte

Besitzt man keine historischen Daten, so ist -- verglichen mit einer Bauchschätzung -- der Rückgriff auf Standardwerte aus einschlägiger Literatur eine vernünftige Alternative.

Die Schätzgenauigkeit ist mittelmäßig, da -- wie Schätzmodelle schon zeigen -- viele Faktoren die Kosten und Dauer von Projekten sogar in der Größenordnung beeinflussen.

Im obigen Beispiel zum Defektbehebungsaufwand benötigt man zur Ermittlung der Defektanzahl z.B. eine Idee von der Defektdichte, d.h. wie viele Fehler pro kNCSS gefunden werden (z.B. 15). Und man benötigt eine Idee, wieviele Defekte pro Defektbehebung entstehen (z.B. 0,2), sowie wieviel eine Defektbehebung im Mittel kostet (z.B. 0,5 PT). Für beides kann man sich durch Studium entsprechender Texte einen Eindruck verschaffen.

Man sollte sich sicher sein, dass die Voraussetzungen, die für die Standardwerte gelten, auch in der eigenen Situation zutreffen. Das Verfahren ist deshalb nicht so einfach, wie es aussieht. Es ist zwar in frühen Phasen der Entwicklung einsetzbar, die wenig genaue Schätzung sollte aber möglichst schnell durch ein anderes Vorgehen, d.h. Messung und Extrapolation, verbessert werden.

Top-down Vorgehen

Liegen für das 'Ganze', z.B. das System oder ein Projekt Schätzwerte vor, so können mithilfe von prozentualen Standardwerten Einzelschätzungen für kleinere Einheiten erstellt werden. So ist z.B. für die Feinkonzeption eines Release häufig etwa ein Drittel des Gesamtaufwands zu veranschlagen, und Testaktivitäten werden je nach erforderlicher Verlässlichkeit und Verfügbarkeit eines Systems zwischen 25% und 50% des Gesamtaufwands benötigen.

Bei Nutzung von Standardwerten ist die Schätzgenauigkeit mittelmäßig, werden hingegen Prozentwerte aus der Erfahrung durch Analogieschluss ermittelt, ist die Genauigkeit besser.

Dieses Vorgehen lässt sich nicht in beliebige Detailierungstiefe fortsetzen, es ist vor allem nützlich, um früh ein 'Mitarbeitergebirge' zwecks Teamstrukturierung, Recruiting und Staffing zu ermitteln.

Die Durchführung ist preiswert, sobald man die Schätzung des Toplevel-Wertes besitzt.

Bottom-up Vorgehen

Bei diesem Vorgehen werden Werte für große Einheiten durch Summieren geschätzter Einzelwerte ermittelt. Üblicherweise liegt eine Work-Breakdown-Structure zugrunde, die sich im Hinblick auf die Release-Erstellung frühestens nach einem Grobdesign des Systems ergibt. Projektplanungswerkzeuge leisten über Roll-Up-Vorgänge diese Summierung automatisch anhand des hinterlegten Projektstrukturplans.

Dabei gibt es einige Dinge zu berücksichtigen:

Die Summenbildung über individuelle Schätzungen gleicht Schätzfehler aus. Dieser Effekt ist ab 20 Einzelwerten statistisch relevant.

Individuell eingerechnete Puffer blähen das Ergebnis auf. Risikopuffer gehören nicht in Schätzungen, sie sind Teil der Planung, um die Wahrscheinlichkeit für das Erreichen von Zielen zu erhöhen. Wenn die Schätzer, z.B. Entwickler, aber Angst haben müssen, dass die Planziele unter ihren Arbeitspaket-schätzungen liegen werden, dann werden die Schätzer unkontrollierbare Puffer 'einbauen'.

Neben Schätzungen für Arbeitspakete, die sich aus der Work-Breakdown-Structure ergeben, gibt es noch Aufwände für Regeltätigkeiten und Management, die sich als Prozentwert vom 'produktiven' Aufwand berechnen lassen.

Die Genauigkeit hängt stark von der Eingrenzung des jeweiligen Gegenstands und Größe der Einzelschätzungen ab, da es sich um Expertenschätzungen handelt (s.o.). Gute Arbeitspaketbeschreibungen, eingespielte Arbeitsprozesse und Teams sowie möglichst wenige Projektabhängigkeiten sind Bedingungen, unter denen hier eine Schätzgenauigkeit von unter 10% Abweichung erreicht wird.

Von hier aus

Dieser Artikel ist keine Anleitung zur Verwendung von Schätzverfahren. Sie haben jetzt aber einen groben Überblick über viele praktische Aspekte dieses Software-Engineering Gebiets erhalten.

Um richtig einzusteigen, empfiehlt sich das 2006 erschienene Buch 'Software Estimation' von Steve McConnell.

Ich hoffe, dass die vorangegangenen Abschnitte eine zentrale Botschaft zum Thema 'Bessere Schätzqualität' klargemacht haben: um die große Unsicherheit in Software-Projekten gegen eine Vorhersagbarkeit einzutauschen, müssen Sie wissen, was Sie bauen wollen. Und dann müssen Sie wissen, wie 'Bauen' in ihrem Umfeld quantitativ aussieht.

Das erste Wissen-Müssen erfordert eine Spezifikation, ein Konzept, eine Reihe von User-Stories oder Use-Cases oder wie auch immer Sie festhalten wollen, was das System leisten soll.

Das zweite Wissen-Müssen erfordert das Messen und Verwalten von Kennzahlen Ihrer Software-Entwicklungsprojekte. Zum hier skizzierten Zwecke reicht glücklicherweise schon etwa eine Handvoll dieser Zahlen, um spürbar besser und sicherer zu werden [4].

Literatur + Referenzen

[1] S.McConnell, "Software Estimation", Microsoft Press, 2006.

[2] E.Yourdon, "Death March", 2nd Ed., Prentice Hall, 2004.

[3] T.DeMarco, "Controlling Software Projects", Prentice Hall, 1986.

[4] E.Fenton, S.L.Pfleeger, "Software Metrics", 2nd Ed., PWS Publishing, 1997.

[5] International Function Point Users Group: www.ifpug.org