Für die im Rahmen der Grob- und der Feinplanung des Projektmanagements erforderliche Aufwandsschätzung wird im Hauptteil der Methodenzuordnung die Methodenkategorie "Schätzmodelle" festgelegt. Eine spezifische Methode, ein konkretes Schätzverfahren wie z.B. Function Point Methode oder CoCoMo, wird erst im Rahmen der Operationalisierung der Methodenzuordnung ausgewählt.
Es ist nicht möglich, innerhalb der Methodenzuordnung bereits ein konkretes Verfahren festzuschreiben. Es gibt trotz der großen Anzahl an Schätzverfahren keines, das als die "Standardmethode" vorgeschlagen werden kann. Jedes der Verfahren weist gewisse Mängel auf. Zudem wird die Auswahl eines Verfahrens von vielfältigen Randbedingungen und Faktoren beeinflußt. Hinzu kommt, daß die Methodenzuordnung in diesem Punkt offen sein sollte für Neuentwicklungen.
Die Methodenkategorie "Schätzmodelle" umfaßt zunächst einmal alle zur Aufwandsschätzung anwendbaren Verfahren. Selbst wenn ein Verfahren nach den unten genannten Beurteilungskriterien sich prinzipiell als geeignet für die Anwendung im V-Modell erweist, ist dieses in der Regel dennoch nicht universell einsetzbar, da gerade in der Aufwandsschätzung eine starke Abhängigkeit und Einflußnahme von externen Faktoren wie z. B. dem organisatorischen und dem projektspezifischen Umfeld besteht. Für jedes prinzipiell geeignete Schätzverfahren müssen deshalb die Einsatzkriterien festgelegt werden.
Die Beurteilungskriterien stellen dabei konstante Größen dar, die sich auf das Schätzverfahren an sich beziehen. Die Einsatzkriterien stellen variable Größen dar, die sich auf das jeweilige projektspezifische Umfeld beziehen und sich daher von Projekt zu Projekt unterscheiden. Erst mit den Ergebnissen aus beiden Untersuchungsschritten kann ein bestimmtes Schätzverfahren für ein konkretes Projektumfeld ausgewählt werden. Und selbst dann ist für die meisten noch verbleibenden Methoden, sofern sie nicht nur eine Makroschätzung unterstützen, ein Anpassungsprozeß an die dem V-Modell zugrundeliegende Systematik der Software-Entwicklung erforderlich.
Nachfolgend werden die Kriterien aufgeführt, anhand derer sich die prinzipielle Eignung und die Verwendbarkeit eines Schätzverfahrens im V-Modell (Submodell Projektmanagement) beurteilen läßt. Insbesondere für Neuentwicklungen in diesem Bereich sollen die genannten Beurteilungskriterien als Meßlatte dienen.
Wohl kein Schätzverfahren erfüllt alle diese Kriterien (es sind auch einige "Wunschkriterien" (insbesondere die letzten drei Punkte enthalten)); für die Einstufung als geeignet für den Einsatz im V-Modell sollte aber der überwiegende Teil positiv bewertet werden können.
Nachfolgend werden die Kriterien aufgeführt, anhand derer sich der Einsatzbereich eines Schätzverfahrens näher bestimmen läßt, da nicht alle Schätzverfahren für jeden Anwendungsfall gleichermaßen geeignet sind.
Es ist nicht möglich, im Rahmen dieser Abhandlung alle existierenden Einzelmethoden aufzuführen, allerdings läßt sich jede Schätzmethode auf einen oder eine Kombination mehrerer Grundtypen zurückführen. Die Grundtypen sind nach / Noth, 86 /:
Die beiden bekanntesten Einzelmethoden und mit ihren Varianten und Weiterentwicklungen weit verbreiteten Methoden zur Aufwandsschätzung
werden im folgenden einzeln vorgestellt. Viele der in der Literatur präsentierten und in Werkzeugen implementierten Aufwandsschätzverfahren verfolgen einen dieser beiden Ansätze weiter.
Daneben wird aber auch die weniger bekannte Methode
als relevant betrachtet, deren Kern die Anwendung einer Erfahrungsdatenbank bildet und die von daher interessante Perspektiven zuläßt.
1 Identifikation/Definition der Methode
/ IBM, 85 / S. 7-13
2 Kurzcharakteristik der Methode
Die Function Point Methode (FPM) wurde von der IBM entwickelt; sie ist eine Kombination aus Analogiemethode (FP-Kurve beruht auf Erfahrungswerten ähnlicher Projekte) und Gewichtungsmethode (Einschätzung der Einflußfaktoren auf das Projekt). FPM ist eng mit den funktionsbezogenen Entwicklungsmethoden (wie SSADM, HIPO) verbunden und stellt basierend auf den Benutzeranforderungen die Funktionen in den Mittelpunkt. In der Aufwandsschätzung werden Komplexität, bestimmte SW-Eigenschaften und Produktivität berücksichtigt. Die Function Points (FP) dienen als Produktivitätsmaß, aus welchem der Aufwand abgeleitet wird.
Schritte der FPM:
3 Beurteilung der Methode
Kriterien für den Einsatz der FPM
Stärken der Methode, Schwächen der Methode und mögliche Abhilfen
Schätzbasis "Function Point"
Die Function Points als Schätzbasis werden aufgrund des Typs und Komplexitätsgrades der Funktionen ermittelt und zwar beurteilt aus Sicht des Anwenders; die IT-technische Realisierung übt keinen Einfluß auf den Schätzwert aus (+). Die FPM löste sich von der weit verbreiteten Schätzbasis LOC, die ohnehin erst gegen Ende der Entwicklungstätigkeit wirksam werden. Es können somit auch Mitarbeiter der Fachabteilungen für die Aufwandsschätzung herangezogen werden (+).
Mikroschätzung
Die FPM bietet keine Unterstützung für die Aufteilung des ermittelten Aufwands auf Submodelle, (Teil-) Aktivitäten, (Teil-) Produkte oder V-Modell-Funktionseinheiten (-). Eine Mikroschätzung ist daher nur über Erfahrungswerte, den Einsatz einer Erfahrungsdatenbank oder die Einbindung anderer Methoden möglich.
Einflußfaktoren
Einflußfaktoren aus den Bereichen SW-Qualität, Personal und Software-Entwicklungsumgebung (SEU) werden bei der FPM nicht explizit berücksichtigt. Implizit beeinflussen diese z. T. zwar die FP-Kurve (Wertepaare "Function Point-Aufwand"), müssen deswegen aber entweder über den Großteil der Projekte einheitlich sein oder aber genauestens dokumentiert werden, um die Vergleichbarkeit der Projekte sicherzustellen (-). Bei abweichenden Projektcharakterisitika muß deshalb mit Zu- bzw. Abschlägen zur FP-Kurve operiert werden, oder es müssen jeweils eigene FP-Kurven für verschiedene Projekttypen ermittelt werden, so daß die Streuung der Werte verringert und die Genauigkeit des Verfahrens erhöht wird.
Auf der anderen Seite müssen gleichbleibende Charakteristika von Projekten (i. d. R. Personal und SEU) nicht eigens bewertet werden; diese sind über die FP-Kurve implizit berücksichtigt (+).
Objektivität
Für eine objektive Bewertung muß eine eindeutige Abgrenzung/Einteilung für die Schwierigkeitsgrade und für die Gewichtung der Einflußfaktoren erarbeitet werden (-). Es läßt sich allerdings bis zu einem gewissen Grad eine mangelhafte "objektiv richtige" Einschätzung der Function Points durch eine stete "subjektiv einheitliche" Einschätzung wettmachen.
Einarbeitung in die Methode
Die Einarbeitung in die leicht verständliche und einfach aufgebaute Methode bereitet i. a. keine größeren Schwierigkeiten (+), allerdings muß für die Anwendung der FPM eine gewisse Erfahrung bei der Function Point-Ermittlung vorausgesetzt werden (-), da ein Loslösen von der realisierungstechnischen Sicht gefordert ist.
Anwendung der Methode
FPM ist ein frühzeitig einsetzbares Verfahren zur Aufwandsschätzung und liefert unter Berücksichtigung oben genannter Einsatzkriterien realistische Werte (+).
Um die IBM-FP-Kurve an eigene Verhältnisse anzupassen, müssen für abgeschlossene Projekte Nachkalkulationen durchgeführt werden (-). Um die FP-Kurve auf dem aktuellen Stand zu halten, sollten die neuesten Projektwerte ergänzt oder sukzessive gegen alte ausgetauscht werden. Damit lassen sich auch eventuelle Produktivitätstrends erkennen.
Werkzeugunterstützung
Eine Werkzeugunterstützung für FPM ist für kleine und mittlere Projekte zwar hilfreich, aber nicht unbedingt erforderlich (+), allerdings sollte eine Dokumentation über entsprechende Formulare die Nachvollziehbarkeit der Aufwandsschätzung gewährleisten. Bei großen Projekten ist aufgrund des Mengenproblems eine maschinelle Unterstützung unentbehrlich (-).
4 Anwendung der Methode im V-Modell
FPM in Aktivität PM 1.5 "Grobplan erstellen":
Unter Berücksichtigung der o. g. Einsatzkriterien eignet sich die FPM für die Aufwandsschätzung im Rahmen der Grobplanung. Da jedoch innerhalb FPM keine Aufwandsaufteilung vorgenommen wird, müssen auf der Basis empirischer Studien die Aufwände der Submodelle und Hauptaktivitäten ausgehend vom Gesamtaufwand ermittelt werden.
Die Anwendung von FPM ist sowohl auf Seiten des Auftragnehmers im Rahmen der Projektplanerstellung als auch auf Seiten des Auftraggebers im Rahmen der Vertragsausarbeitung möglich.
FPM in Aktivität PM 4 "Feinplanung":
Für die Aufwandsschätzung im Rahmen der Feinplanung ist die FPM nicht geeignet, da das FPM-Verfahren keine dedizierte Aufwandsschätzung für Teilaktivitäten und Teilprodukte vorsieht. Demnach muß hier ebenfalls auf der Basis von Erfahrungswerten oder unter Zuhilfenahme weiterer Methoden, wie z. B. der Delphi-Methode / Busch, 72 /, die Mikroschätzung erfolgen.
5 Schnittstellen
- entfällt -
6 Weitere Hinweise
Weiterentwicklungen/Varianten
Die FPM wurde bereits in mehrerlei Hinsicht modifiziert. Es existieren verschiedene Ausprägungen z. B. hinsichtlich
- der Einteilung der Geschäftsvorfälle:
/
Albrecht,
83 / und /
Noth,
86 /: Eingabedaten, Ausgabedaten, Datenbestände, Datenbestände für andere Verfahren und Abfragen
/
IBM,
85 /: Eingabedaten, Ausgabedaten, Datenbestände, Referenzdaten und Abfragen
/
Sneed,
87 /: Datenobjekte, Eingabenachrichten, Ausgabenachrichten, Online-Vorgänge, Batch-Vorgänge
- der Anzahl und Art der Einflußfaktoren:
/
Albrecht,
83 / und /
Noth,
86 /: 14 Einflußfaktoren
/
IBM,
85 /: 7 Einflußfaktoren
- der Spanne des Degree of Influence:
/
IBM,
85 /: +/- 30 %
/
Albrecht,
83 / und /
Noth,
86 /: +/- 35 %
- der Erweiterung um einen SW-Qualitätsfaktor /Sneed, 87/.
Verwandte Methoden
Die Data Point Methode wurde von Harry M. Sneed / Sneed, 91 / entwickelt als Alternative zu CoCoMo und FPM und als Antwort auf den Trend zur daten- bzw. objektorientierten Software-Entwicklung.
Das Verfahren zur Ermittlung der Data Points ist ähnlich dem zur Ermittlung der Function Points, nur stehen hier die Datenobjekte statt der Geschäftsvorfälle im Mittelpunkt. Die Data Point Methode eignet sich für die Schätzung kommerzieller Systeme auf der Basis eines Datenmodells, FPM auf der Basis eines Funktionenmodells.
Die Methode ASSET-R / Reifer, 89 / ermittelt über Function Points die Größe und den Aufwand eines Real-Time-Systems. In ASSET-R werden bei der Ermittlung der Function Points echtzeitbezogene Einflußgrößen wie Prozeßschnittstellen und Betreibungsmodi berücksichtigt. Allerdings geht ASSET-R dann über Einflußfaktoren wie Systemarchitektur und Programmiersprache zurück auf die Schätzbasis LOC.
7 Literatur
/ Albrecht, 83 / Vergleich der FPM mit LOC-basierten Aufwandsschätzverfahren
/ Busch, 72 / Definition der Delphi-Methode
/ IBM, 85 / Originalquelle (IBM-Produktinformation)
/ Noth, 86 / Definition und Einführung in FPM, Beurteilung, Weiterentwicklung und Anwendungsvorschläge (S. 89-105, S. 118)
/ Reifer, 89 / Beschreibung der Methode ASSERT-R im Vergleich zu anderen Schätzverfahren
/ Sneed, 87 / Erläuterung der FP-Systematik in einer Gegenüberstellung zu den Methoden CoCoMo und Component Analysis Methode (S. 79-80, S. 175, S. 178-181, S. 185-189, S. 195-196)
/ Sneed, 91 / Kurzbeschreibung der Data Point Methode
/ Symons, 88 / Kritische Betrachtung der FPM, Verbesserungsvorschläge (Mark II)
1 Identifikation/Definition der Methode
/ Boehm, 81 /
2 Kurzcharakteristik der Methode
CoCoMo (Constructive Cost Model) ist eine Entwicklung von Barry W. Boehm; es ist eine Kombination aus parametrischer Schätzgleichung und Gewichtungsmethode. Ausgehend von den geschätzten Anweisungen (Delivered Source Instructions, DSI) wird der Aufwand unter Berücksichtigung von Qualitätszielen und Produktivitätsfaktoren ermittelt.
CoCoMo geht von der klassischen Top-Down Programmierung aus und stellt die Anzahl Anweisungen in den Mittelpunkt. Es umfaßt drei Modellstufen:
3 Beurteilung der Methode
Kriterien für den Einsatz der Methode CoCoMo
Mittlere und große Projekte
Für kleinere Projekte ist der Aufwand für eine Schätzung nach Intermediate und Detailed CoCoMo nicht vertretbar; Basic CoCoMo allein liefert aber zu wenig exakte Ergebnisse.
Technische Anwendung
Für Softwareentwicklungsprojekte kommerzieller Anwendungen liefert CoCoMo in aller Regel überhöhte Aufwandsschätzwerte (vgl. auch / Noth, 86 / S. 87), weshalb CoCoMo in der Praxis nur bei technischer Softwareentwicklung zum Einsatz kommt.
Dieser Umstand muß darauf zurückgeführt werden, daß das in der CoCoMo-Schätzgleichung implementierte Verhältnis von DSI zu Mannmonaten der Produktivitätsrate bei technischer Entwicklung näher kommt; für kommerzielle Softwareentwicklung gilt im allgemeinen eine höhere Produktivitätsrate DSI/Mannmonat.
Stärken der Methode, Schwächen der Methode und mögliche Abhilfen
Schätzbasis "Delivered Source Instructions"
Mit der Schätzbasis Anweisungen (DSI) wurde versucht, die großen Unsicherheiten und Probleme der herkömmlichen Schätzbasis LOC abzuschwächen. Allerdings bleiben einige Probleme bestehen: die Ungenauigkeit einer DSI-Schätzung (-); die Relevanz der DSI für den Entwicklungsaufwand ist aufgrund moderner SW-Engineering-Methoden immer weniger gegeben, da sich der Aufwand immer mehr in die frühen Aktivitäten verschiebt und DSI ohnehin erst gegen Ende der Entwicklungstätigkeit wirksam werden (-), DSI sind wie LOC abhängig von der gewählten Programmiersprache (es existiert aber bereits eine Ada-Anpassung zu CoCoMo).
Eine gewisse Abhilfe kann durch die Gewichtung von Anweisungen nach ihren verschiedenen Arten (siehe /Sneed, 87/ S. 73-74: Compiler-, Datenbeschreibungs-, Transformations-, Steuer- und I/O-Anweisungen oder siehe / Sneed, 87 / S. 183-185: Datenbeschreibungsanweisungen (differenziert nach Integrationsgrad, Nachricht/Datenobjekt, Modifikationsgrad) und Verarbeitungsanweisungen (differenziert nach Batch/Online, Modifikationsgrad, Komplexität, Sprache)) erreicht werden.
Makro- und Mikroschätzung
CoCoMo ermöglicht durch seine verschiedenen Modellebenen sowohl eine Makroschätzung durch Basic CoCoMo als auch eine Mikroschätzung durch Intermediate CoCoMo und Detailed CoCoMo (+). Die Mikroschätzung erlaubt eine Aufwandszuordnung auf Aktivitäten und Funktionseinheiten. Allerdings liegen der Methode CoCoMo sowohl ein vom V-Modell abweichender SW-Life-Cycle als auch eine andere Systemstruktur zugrunde (-). Um einzelne Aufwände der Submodelle, (Teil-) Aktivitäten und (Teil-) Produkte angeben zu können, muß deshalb eine Transformation dieser Punkte der Methode CoCoMo auf das V-Modell-Konzept erfolgen.
Einflußfaktoren/Objektivität
CoCoMo berücksichtigt in der Aufwandsschätzung Charakteristiken des Projekts, des Produkts, des Personals und der Technologie (+). Für eine objektive Bewertung dieser Einflußfaktoren bietet CoCoMo exakte Definitionen an (+). Die Quantifizierung von Einflußfaktoren stellt allerdings ein gewisses Problem dar (-), das die Güte des Schätzverfahrens genauso wie die erforderlichen DSI-Angaben stark beeinflußt.
Einsatzspektrum
Durch die Differenzierung der Schätzgleichungen nach Projektgrößen und Systemtypen weist die Methode CoCoMo ein breites Einsatzspektrum auf (+). Sie ist ferner eine der wenigen Schätzmethoden, die neben der Unterstützung für Entwicklungsprojekte auch eine Unterstützung für die Aufwandsschätzung von SWPÄ-Aufgaben (ebenfalls durch parametrische Schätzgleichungen) und für die Schätzung der Projektdauer bietet (+).
Werkzeugunterstützung
Eine maschinelle Unterstützung ist für Intermediate und Detailed CoCoMo aufgrund des Mengenproblems (Differenzierung der Einflußfaktoren auf die Phasen und Teilprodukte) erforderlich (-).
4 Anwendung der Methode im V-Modell
CoCoMo in Aktivität PM 1.5 "Grobplan erstellen":
Für die Grobplanung in einem frühen Projektstadium eignet sich die Anwendung von Basic CoCoMo, das in einer ersten Näherung den Entwicklungsaufwand, die Entwicklungsdauer und eine grobe "Phasen"aufteilung liefert (Transformation auf Hauptaktivitäten erforderlich, siehe oben).
CoCoMo in Aktivität PM 4 "Feinplanung":
Für die Feinplanung muß Intermediate CoCoMo und Detailed CoCoMo angewandt werden, um eine exaktere Aufwandsaufteilung auf die Aktivitäten und Funktionseinheiten durchführen zu können.
5 Schnittstellen
- entfällt -
6 Weitere Hinweise
Weiterentwicklungen/Varianten
CoCoMo wurde bereits in mehrerlei Hinsicht modifiziert. Es existieren verschiedene Ausprägungen z. B. hinsichtlich
- der Art und Anzahl der Einflußfaktoren:
/
Boehm,
81 /: 15 Einflußfaktoren
/
Sneed,
87 /: 12 Einflußfaktoren und spez. Qualitätsfaktor
- der Systemarten und diesbezüglichen Schätzgleichungen:
/
Boehm,
81 /: Batch-Online-Realtime
/
Sneed,
87 /: Batch-Online-Gemischte Systeme
Verwandte Methoden
In der Literatur (größtenteils zeitlich vor CoCoMo entwickelt) kursieren sehr viele parametrische Gleichungen der Form "Aufwand = a * (KDSI) b" für die Aufwandsschätzung - ähnlich dem Basic CoCoMo, mit genau dem gleichen Nachteil der Ungenauigkeit. Um nur einige Autoren diesbezüglich zu nennen: Nelson (1978), Freburger-Basili (1979), Herd (1977), Frederic (1974), Phister (1979), Jones (1977), Halstead (1977), Schneider (1977). Die Faktoren der Gleichung weisen eine sehr große Bandbreite (a: zwischen 0,7 und 5,3; b: zwischen 0,98 und 1,83) auf, und genau wie diese Verfahren ist auch Basic CoCoMo allein nicht praktikabel.
7 Literatur
/ Boehm, 81 / Originalliteratur
/ Noth, 86 / Kurze Einführung und Beurteilung der Methode CoCoMo (S.86-88)
/ Sneed, 87 / Erläuterung der CoCoMo-Systematik in einer Gegenüberstellung zu FPM und Component Analysis Methode (S. 73-74, S. 174, S. 177-179, S. 183-186, S. 193-195, S. 199-201)