Methoden und Verfahren der Aufwandschätzung im Vergleich

Aus Winfwiki

Inhaltsverzeichnis 1 Einleitung 2 Grundlagen 2.1 Grundregeln der Schätzung 2.2 Problematik der Aufwandschätzung 2.3 Definitionen 2.3.1 Methoden 2.3.2 Verfahren 2.3.3 Einflussfaktoren 2.3.4 Aufwand 2.3.5 Schätzung 3 Einflussfaktoren 3.1 Produktbezogene Einflussfaktoren 3.1.1 Quantität 3.1.2 Komplexität 3.1.3 Qualität 3.2 Prozessbezogene Einflussfaktoren 3.2.1 Projektdauer 3.2.2 Personalqualität 3.2.3 Entwicklungsumgebung 4 Methoden der Aufwandschätzung 4.1 Algorithmische Methoden 4.1.1 Parametrische Methode 4.1.2 Faktoren- bzw. Gewichtungsmethode 4.2 Vergleichende Methoden 4.2.1 Analogiemethode 4.2.2 Relationsmethode 4.3 Kennzahlenmethoden 4.3.1 Multiplikatormethode 4.3.2 Produktivitätsmethode 4.3.3 Prozentsatzmethode 4.4 Expertenbefragung 4.4.1 Einzelbefragung 4.4.2 Mehrfachbefragung 4.4.3 Delphi-Methode 4.4.4 Schätzklausur 5 Verfahren der Aufwandschätzung 5.1 Anforderung an Aufwandschätzverfahren 5.2 Verfahrensarten 5.2.1 Function-Point 5.2.1.1 Ermittlung der Komponenten 5.2.1.2 Bewertung der Komponenten 5.2.1.3 Ermittlung der Anzahl der Function-Points 5.2.1.4 Klassifizierung der Einflussgrößen 5.2.1.5 Entwicklungsaufwand berechnen 5.2.2 Cocomo 5.2.2.1 Projektklassen 5.2.2.2 Modellvarianten 5.2.2.3 Entwicklungszeit- und aufwand 5.2.2.4 Projektprofil 5.2.3 PRICE 5.2.3.1 Price H 5.2.3.2 Price S 6 Vergleichende Betrachtung der Aufwandsschätzmethoden- und Verfahren 6.1 Einordnung nach Klassen 6.2 Einsatzzeitpunkt 6.3 Einsatzfelder 6.4 Gegenüberstellung der Expertenschätzungen 7 Zusammenfassung 8 Tabellenverzeichnis 9 Abbildungsverzeichnis 10 Abkürzungsverzeichnis 11 Fußnoten 12 Literaturverzeichnis

1 Einleitung

Diese Fallstudie hat sich zum Ziel gesetzt, einen Überblick und Vergleich über die in der IT-Projektentwicklung gängigen Methoden und Verfahren der Aufwandschätzung zu geben.

Auf alle Methoden und Verfahren detailliert einzugehen, würde die Begrenzung dieser Arbeit auf nicht mehr als 25 Seiten unmöglich machen. Um sowohl den in der Praxis eingesetzten Verfahren und Methoden als auch den Rahmenbedingungen dieser Arbeit gerecht zu werden, werden einige der Methoden und Verfahren daher lediglich benannt.

Aufwandschätzungen werden in Methoden und Verfahren unterteilt, wobei sich die Verfahren aus mehreren unterschiedlichen Methoden zusammensetzen. In Kapitel 2 wird auf Grundlagen und Begriffsdefinitionen eingegangen. Mit den Einflussfaktoren der Aufwandschätzung beschäftigt sich das Kapitel 3. Den Einflussfaktoren wird deshalb eine eigenes Kapitel gewidmet, weil sie in der Aufwandschätzung von großer Bedeutung sind und gerade bei den Verfahren ein sehr starkes Gewicht haben. Im Kapitel 4 wird auf die grundlegenden Methoden eingegangen, wobei hier daraus abgeleitete Methoden nur aufgezählt werden. Die drei wichtigsten Verfahren, das Cocomo-, das Functions-Point und das PRICE-Verfahren werden in Kapitel 5 erläutert. Den Abschluß bildet das Kapitel 6 mit dem Vergleich zwischen den in dieser Fallstudie aufgeführten Methoden und Verfahren.

2 Grundlagen

2.1 Grundregeln der Schätzung

Um Ungenauigkeiten zu vermeiden, sollte man sich an einige Grundregeln halten.

Je genauer die Eingangsinformationen sind, desto besser ist dies für die Schätzung. Daher ist die Beschaffung von aussagekräftigen Information von grundlegender Bedeutung. Die Schätzobjekte sollten in kleine, konkrete Projektteile zerlegt werden. Je kleiner ein Teil ist, desto genauer lässt er sich schätzen. Hier spricht man vom Detailprinzip. Die Schätzung eines Projektes ist keine einmalige Angelegenheit, sondern ein kontinuierlicher Prozeß. Umso weiter die Schätzung in die Zukunft geht, desto ungenauer wird sie. Deshalb muss die Projektleitung im Laufe des Projektes die Schätzungen immer wieder anpassen. Dadurch wird das Schätzergebnis im Laufe der Zeit immer genauer^[1]. Siehe auch Abbildung 5.2.

2.2 Problematik der Aufwandschätzung

Die Problematik liegt unter anderem darin, dass z.B. der Programmieraufwand bei einem IT-Projekt oft nur einen kleinen Teil des Projektes ausmacht. Daneben sind Verwaltungsaufgaben zu planen, Abstimmungen durchzuführen und Fehler zu suchen und zu korrigieren. Der Programmieraufwand wird oft über- und die Nichtprogrammieraufgaben unterschätzt. Dadurch fließen zuwenige oder sogar überhaupt keine Zeitanteile der Nichtprogrammieraufgaben in die Aufwandschätzung ein.

Der Nutzen einer Vorerfahrung wird oft höher angesetzt als er in der Wirklichkeit ist. Auch gibt es für bestimmte Projektteile keine Vorerfahrung. Der Grund ist, dass Projekte sich durch ihre Besonderheiten auszeichnen; sie haben einen Charakter der Einmaligkeit.

Bei Schätzungen mit den Teilnehmern des Projektes trifft man häufig auf einen positive Grundeinschätzung der Situation. Das liegt daran, dass Menschen eher zu einer positiveren Einschätzung tendieren. Auch hat man oft die Situation, dass der Auftraggeber eine gewisse Zeitvorstellung hat und die Aufwandschätzung einfach daran angepasst wird. Wenn dann nicht entsprechende Ressourcen bereitgestellt werden, führt dies zu einem falschen Schätzergebnis^[2].

2.3 Definitionen

2.3.1 Methoden

Methoden sind planmäßig, begründete Vorgehensweisen zur Erreichung von festgelegten Zielen (im Allgemeinen im Rahmen festgelegter Prinzipien)^[3]

2.3.2 Verfahren

Verfahren sind ausführbare Vorschriften oder Anweisungen zum gezielten Einsatz von methodischen Vorgehensweisen. Sie beschreiben den konkreten Weg zur Lösung bestimmter Probleme und Problemklassen^[4].

2.3.3 Einflussfaktoren

Ein Einflussfaktor ist eine unabhängige Variable (z.B. Projektumfang) , deren Veränderung zu einer Erhöhung oder Verminderung einer abhängigen Variablen (z.B. Projektaufwand in Personenmonaten) führt^[5].

2.3.4 Aufwand

Unter Aufwand versteht man die Anzahl an Personentagen(Monaten), die für eine Projektrealisierung notwendig sind^[6].

2.3.5 Schätzung

Eine Schätzung ergibt sich auf der Basis vergleichbarer Projekte, aus Erfahrung und der Frage "Wie lange benötigt ein Mitarbeiter, um diese Aktivität in dieser Phase zu erledigen"^[6].

3 Einflussfaktoren

Der Aufwand für ein Projekt wird auf der Basis von Erfahrungen aus anderen Projekten geschätzt. Ein wichtiges Kriterium für ein Projekt ist die Einmaligkeit. Dies würde im Umkehrschluss heißen, dass man nicht auf Erfahrungen zurückgreifen kann. Dennoch zeigt sich, dass ähnliche Projekte im Unternehmen oder in der Branche schon einmal durchgeführt wurden. Aus diesem Grund kann man Informationen aus anderen Projekten nutzen und analysieren, welchen Einflussfaktoren diese unterlegen haben. Ohne Kenntnis der Einflussfaktoren, die im direkten Zusammenhang mit dem Projektaufwand und den Projektkosten stehen, ist keine sinnvolle Aufwandschätzung möglich^[8].

Da sich der Aufwand bei einem Projekt aus dem Projektziel ergibt, kann man die Ziele in Produkt- und Prozessziele einteilen. Die meisten Schätzmethoden gehen bei Aufwandschätzung davon aus, dass sich produkt- und prozessbezogene Einflussfaktoren ergeben. Hierbei unterteilt man in produktbezogene Einflussfaktoren wie Quantität, Qualität und Komplexität und prozessbezogene Einflussfaktoren wie Projektdauer, Personalqualität und Entwicklungsumgebung^[9].

1982 wurde das erste Mal von Sneed die Theorie des „Teufelsquadrat“ publiziert. Das „Teufelsquadrat“ ist eine Möglichkeit der qualitativen Darstellung der Einflussgrößen auf Aufwandschätzungen von Projekten. Jede Ecke steht für einen Zielerreichungsgrad. Diese Ziele konkurrieren miteinander um Kapazitäten. Dies wird durch das Viereck symbolisiert. Verschiebt sich das Rechteck mit einer Ecke nach außen, so muss man Einbußen an den anderen Seiten hinnehmen^[7].

3.1 Produktbezogene Einflussfaktoren

3.1.1 Quantität

Bei IT-Projekten, die sich mit Programmerstellung durch Programmierung beschäftigen, wird als Merkmal für die Quantität oft die Anzahl der zu erstellenden Zeilen (Line of Codes : kurz LoC) oder die Anzahl der Anweisungen gemessen^[10]. Unberücksichtigt bleibt, dass diese Zählweise in Zeiten objektorientierter Programmierung den modernen Programmiersprachen nicht gerecht wird. Besser wäre hier eine Klassifizierung von Funktionen, die unabhängig von den erstellten Zeilen bewertet wird^[11].

Beschäftigt sich die Aufwandschätzung mit Einführung neuer Software, ist eine Aufteilung in Funktionen sinnvoll. Hier unterscheidet Noth die quantitative Zählung von Hauptfunktionen (absolut notwendig) und Nebenfunktionen (z.B. zur Erhöhung der Benutzerfreundlichkeit)^[12]

Unhabhängig von der Zählmethode gehen aber alle Autoren davon aus, dass eine Zunahme der Funktionen oder Zeilen zu einem überproportionalen Projektaufwand führt.^{[11][10][13][14]}

3.1.2 Komplexität

Je umfassender und vielschichtiger ein Projekt ist, desto mehr steigt seine Komplexität. Diese wird quantitativ über die Festlegung von Klassen, die in „einfache“, „mittlere“ und „komplexe“ Projekt- oder Programmteile eingeteilt werden, erfasst. Mit zunehmender Komplexität ist eine überproportionale Zunahme des Projektaufwandes zu erwarten^[11].

3.1.3 Qualität

Qualität wird in Qualitätsmerkmale wie z.B. Funktionalität, Benutzbarkeit, Wartbarkeit und Stabilität zerlegt. Dadurch kann man den einzelnen Merkmalen Kennzahlen zuordnen und sie dadurch messbar machen. Qualitätsmerkmale gehen zwar nicht in die Schätzmethoden selbst ein, werden aber für die Interpretation der Aufwandschätzung verwendet^[11].

3.2 Prozessbezogene Einflussfaktoren

3.2.1 Projektdauer

Eine Verkürzung der Projektdauer durch den Einsatz von mehr Mitarbeitern führt nicht immer zum Erfolg, es sei denn man betrachtet Projekte, die personell zu schwach besetzt sind. Laut dem Brooksschen Gesetz kann die Hinzuziehung von neuen Mitarbeitern auch kontraproduktiv sein, da der Kommunikationsaufwand größer wird als der zusätzliche Nutzen der neuen Mitarbeiter. Dies kann unter Umständen zu einer Verlängerung der Projektdauer führen ^[11].

Aber auch der Einsatz der Software spielt bei der Projektdauer eine entscheidende Rolle. Werden Standart-Produkte eingesetzt, ist die Einbeziehung externer Mitarbeiter meist unproblematisch. Werden selbst entwickelte Programme oder Scriptsprache eingesetzt, können eigene Mitarbeiter oft schneller Erfolge erzielen als mit Standartsoftware. Die Einbeziehung externer Mitarbeiter erfordert hier allerdings meist einen erheblichen zeitlichen Mehraufwand und gerade in der Endphase eines Projektes führt dies oft zu einer Projektdauerverlängerung ^[16].

3.2.2 Personalqualität

Einer der stärksten Einflussfaktoren bei einem Projekt ist die Personalqualtität. Sie ist stark abhängig von dem Ausbildungsstand und der Erfahrung der Mitarbeiter. Einen kaum zu quantifizierenden Einfluß hat auch die Motivation und die Kooperation von Mitarbeitern. In der Abbildung 3.3 beim Functions-Point-Verfahren ist dieser Einflussfaktor dargestellt. Hier steht die Erfahrungskurve 1 für wenig ausgebildetes, wenig erfahrenes oder unmotiviertes Personal. Hingegen sind diese Parameter bei der Erfahrungskurve 3 sehr hoch.^[18][17].

3.2.3 Entwicklungsumgebung

Eine geeignete Entwicklungsumgebung kann den Projektaufwand herheblich reduzieren. Deshalb zählt die Entwicklungsumgebung zu den Haupteinflussfaktoren einer Aufwandschätzung. Ob das richtige Projektmanagementtool bei einem Softwareimplementierungsprojekt oder die IDE-Umgebung für eine Softwareerstellung; ohne die Berücksichtigung dieses Einflussfaktors ist keine seriöse Aufwandschätzung möglich. Man geht hier von folgenden Zusammenhang aus: Je intensiver die Tools der Entwicklungsumgebung genutzt werden, desto geringer ist der Projektaufwand^[19][14].

4 Methoden der Aufwandschätzung

Die Verfahren der Aufwandschätzung stützen sich auf die Methoden zur Aufwandschätzung. Sie erfassen die Vorteile mehrerer Methoden, um möglichst richtige Ergebnisse zu erzielen. Geeignete Ergebnisse entstehen durch einen kombinierten Einsatz mehrerer, verschiedener Methoden im Fluidum eines Verfahrens zur Aufwandschätzung. Es entsteht eine Maßzahl für den Umfang des Schätzobjekts. Der Aufwand wird auf der Basis einer zugrunde liegenden Metrik ermittelt. Infolge dessen kann anhand von Verrechnungssätzen die Kostengröße errechnet werden. Die Schätzmethoden können untergliedert werden in Vergleichs-, algorithmische - und Kennzahlenmethoden.^[16][21]

4.1 Algorithmische Methoden

Der zu erwartende Projektaufwand wird im Rahmen algorithmischer Methoden mit Hilfe einer geschlossenen Formel berechnet. Diese Formel entsteht auf der Basis empirischer Aufwandserhebungen von bereits abgeschlossenen Projekten oder bereits vorhandenen mathematischen Modellen. Ausprägungen der algorithmischen Methode sind die Gewichts- und die Stichprobenmethode. Diese Methoden unterscheiden sich lediglich in ihrer Anwendung. Die Genauigkeit der berechneten Aufwände stehen in erster Linie in Abhängigkeit zu der Exaktheit der erhobenen Ausprägung der Einflussfaktoren^[22].

Bei algorithmischen Methoden stellt man immer einen formelmäßigen Zusammenhang zwischen messbaren Produktgrößen (z.B. Anzahl der Befehlszeilen oder zu implementierenden Funktionen) und Einflußgrößen zu dem erforderlichen Aufwand an Personal und Zeit her. Die Grundformel dafür lautet^[23]:

4.1.1 Parametrische Methode

Diese Methode stützt sich auf die Analyse bereits fertig entwickelter Projekte. Hier werden unter Anwendung von Korrelationsanalysen Einflussfaktoren ermittelt, welche große Auswirkungen auf die Projektkosten haben. Diese Einflussgrößen, welche eine hohe Korrelation haben, führen einen funktionalen Zusammenhang zu den Projektkosten in Form einer Gleichung zusammen. Für die Aufwandsermittlung neuer Produkte kann diese Gleichung als Grundlage dienen^[24].

Methoden und Verfahren, die auf parametischen Methoden beruhen sind:

• Cocomo-Verfahren: In Kapitel 5.2.2 beschrieben.
• PRICE-Schätzmodell: In Kapitel 5.2.3 beschrieben.
• SLIM-Methode: Die Slim-Methode zeigt die Lebensdauer einer ganzen Entwicklung an. Hierbei ist es nicht notwendig auf die einzelnen Komponenten des Produktes einzugehen. Die Slim-Methode kann in der Beginnphase bereits für eine pauschale Kostenbetrachtung genutzt werden. Die Ausgangsdaten sind empirische Verteilungskurven, welche für Forschungs- und Entwicklungsprojekten notwendig sind^[25].
• Jensen-Methode: Bei der Jensen-Methode wird ein Zusammenhang zwischen Personalaufwand und der Befehlsmenge des geplanten Produkts in Abhängigkeit der Komplexität und der Technologiekonstanten hergeleitet^[25].

4.1.2 Faktoren- bzw. Gewichtungsmethode

Bei der Anwendung der Gewichtungsmethode wird vorausgesetzt, dass zuallererst die Einflussfaktoren ermittelt werden müssen, die für die Projektkosten erheblich sind. Die verwendete Programmiersprache, die eingesetzten Tools, die erforderliche Personalqualifikation und der Schwierigkeitsgrad gehören zu den Einflussgrößen. Die Auswirkungen der Einflussfaktoren auf die Projektkosten werden durch die Gewichtungsfaktoren, die aus Tabellen und Graphiken ermittelt werden, ausgedrückt^[26].

Methoden die die Faktoren- bzw. Gewichtungsmethode benutzen sind:

• IBM-Faktorenmethode: Bei der IBM-Methode ist für den Einsatz das Vorliegen eines fachlichen Feinkonzepts notwendig. Hieraus kann für die restlichen Phasen der Aufwand geschätzt werden. Hierbei wird eine bestimmte Formel in Anspruch genommen^[27].
• Surböck-Methode: Nach Surböck liegen zum Zeitpunkt der Projektfreigabe genügend Informationen vor, um den Aufwand für die DV-technische Realisierung zu schätzen^[28].
• ZKP-Methode: Der Einsatz der ZKP-Methode setzt ein abgeschlossenes fachliches Feinkonzept voraus und bietet die Möglichkeit einer Aufwandschätzung für DV-Grob-und Feinkonzepte, Programmierungen und Codierungen sowie Tests^[29].

4.2 Vergleichende Methoden

Die vergleichende Methode basiert nicht auf einem formel- oder zahlenmäßigen Zusammenhang zwischen der geplanten Produktgröße und des dafür notwendigen Entwicklungsaufwandes. Bei diesen Methoden versucht man vielmehr, einen Bezug zwischen der vergangenen und der geplanten Entwicklung zu erstellen. Um dies zu erkennen, werden die Erfahrungsdaten abgeschlossener Entwicklungsobjekte unter Anwendung entsprechender Vergleichskriterien genutzt. Die vergleichende Methode hat den Vorteil, dass sie bereits in der Frühphase des Entwicklungsprojektes eingesetzt werden kann^[31].

4.2.1 Analogiemethode

Bei dieser Methode wird der Aufwand bestimmt, d.h. es wird die Neuentwicklung nach bestimmten Gesichtspunkten mit abgeschlossenen Projekten verglichen. Hierbei gibt es folgende mögliche Kriterien: den Leistungsumfang, ausgedrückt in der Anzahl der Anweisungen oder der Anzahl der Programme eines Software-Produktes. Ähnliche Projekte und deren Aufwandschätzungen sowie die Ist-Werte sind ein Problem. Projekte gelten als einmalig, so dass eine Vergleichbarkeit die Ausnahme ist^[32].

Grundsätzliche gibt es eine vierstufige Vorgehensweise^[33]:

1. Ähnliche, abgeschlossene Projekte suchen.
2. Neues Leistungsprofil ermitteln
3. Delta zwischen abgeschlossenen und neuem Projekt bestimmen
4. Delta bewerten und Projektkosten ermitteln

Verfahren die sich der Analogiemethoden bedienen sind

• Function-Point-Verfahren: In Kapitel 5.2.1 beschrieben.
• DATA-Point-Verfahren: Das Data-Point-Verfahren ist aus dem Function-Point-Verfahren hervorgegangen und führt Schätzungen auf der Ausgangsbasis von Datenobjekten durch. Anstelle der allgemeinen Einflussfaktoren werden für die Softwareerstellung zehn Einflussfaktoren und acht nichtfunktionale Merkmale verwendet. Der Projektumfang wird anhand betroffener Objekte und ihrer Datenelemente bestimmt^[34][35].

4.2.2 Relationsmethode

Die Relationsmethode basiert auf Daten bereits abgeschlossener Projekte. Im Vergleich zu der Analogiemethode, bei der die Bewertung der Abweichungen dem Schätzenden überlassen wird, formalisiert die Relationsmethode diese weitestgehend. Die Einflussfaktoren des Modells liegen in Form von durchschnittlichen Indexwerten vor. Abweichungen haben quantitative Auswirkungen auf das zu schätzende Projekt. Der Zusammenhang zwischen den Abweichungen von einem durchschnittlichen Indexwert und der quantitativen Auswirkunge werden von Bestimmungen dokumentiert^[36].

Vorgehensweise^[37]:

1. Festlegen der Teilindizes
2. Ermittlung der Index-Basis 100
3. Beurteilung des geplanten Projektes
4. Ermittlung des Aufwandes für das neue Projekt

System	SAP BI	KMS-eisTIK	comboPC	Qlikview	Vista	MS Access-Lösung
Indizes	Indexziffer in %
Integrationsaufwand	80	30	90	85	100	140
Einführungsaufwand	120	50	60	110	100	160
Betreuungsaufwand	60	40	110	70	100	150

Tabelle 4.1: Einführungsaufwand für eine INEK-Kalkulation mit verschiedenen Krankenhausinformationssystemen in Verbindung mit einer Kostenträgerrechung.^[38]

Ein Verfahren, welches die Relationsmethode verwendet, ist das

• EDB-Verfahren:Das EDB-Verfahren kann als Vergleichsverfahren für die Aufwandschätzung genutzt werden. Dieses Verfahren ermöglicht dem Projektplaner beim Bestimmen des zu erwartenden Aufwands anhand vergleichbarer Projekte zu stützen. EDB Verfahren werden bereits in Anwender- und Systemprogrammierung realisiert und wird erfolgreich eingesetzt^[39].

4.3 Kennzahlenmethoden

Die Kennzahlenmethoden erfordern - wie die Vergleichsmethoden - eine systematische Akkumulation projekt- und produktspezifischer Messdaten von abgeschlossenen Entwicklungsvorhaben. Aus diesen Daten werden aussagekräftige Kennzahlen abgeleitet, welche zum Bewerten von Schätzgrössen anstehender Entwicklungsprojekte angewendet werden.^[40]

4.3.1 Multiplikatormethode

Diese Methode nennt man auch Aufwand-pro-Einheit-Methode. Sie setzt bei den Projektkosten an und geht nicht auf den Projektaufwand zurück. Nach Abschluß von Projekten findet eine Nachkalkulation statt, bei der die gesamten Projektkosten und/oder die Höhe gewisser Kostenarten ermittelt werden. Bei der Ermittlung werden die Kosten durch den Leistungsumfang des entwickelten Produktes dividiert. Hieraus resultieren die Gesamtkosten je Leistungseinheit/Modul und auch Kennzahlen wie z.B. Personalkosten je Leistungseinheit/Modul oder Betriebsmittelkosten je Leistungseinheit/Modul. Diese Kennzahlen können bei Kalkulationen von neuen Projekten hilfreich sein, indem der geschätzte Leistungsumfang mit den entsprechenden Kennzahlen der Leistungseinheiten multipliziert wird. Es ist eine regelmäßige Aktualisierung der Kennzahlen notwendig, da diese Kosten - und damit Wertgrößen - sind. An der Methode wird kritisiert, dass sie eine Proportionalität zwischen Leistungsumfang und Kosten unterstellt, obwohl empirisch nachgewiesen ist, dass die Kosten einer Leistungseinheit mit dem Leistungsumfang steigen.^[41].

Kategorie	Anzahl der Subkategorien	Aufwand je Subkategorie	Aufwand je Kategorie
Vorbereitung der Anforderung	6	3	18
Entnahme der Probe	3	2	6
Übermittlung der Anforderung	5	2	10
Änderung der bereits angeforderten Maßnahmen	3	4	12
Aufwand für die Kategorie			46

Tabelle 4.2: Leistungsanforderung mit Probenentnahmen im Krankenhaus.^[42]

Eine Methode nach der Multiplikationsmethode ist die

• Wolverton-Methode: Die Wolverthon-Methode geht bei der Aufwandsermittlung von der proportionalen Beziehung zwischen LoC und Kosten aus^[43].

4.3.2 Produktivitätsmethode

Bei der Anwendung von Produktivitätsmethoden geht man nicht von den Kosten je Ergebniseinheit aus, sondern von der Produktivität. In diesem Fall errechnet man die Produktivitätsfaktoren, indem man die erbrachten Ergebnisse durch den hierfür notwendigen Aufwand dividiert. Diese müssen auch aus den Daten abgeschlossener Entwicklungsvorhaben als Durchschnittwerte abgeleitet sein. Regelmäßige Anpassung an Gegenwartswerte ist zumeist nicht notwendig, da von einer unveränderten Produktivität ausgegangen wird. Das ist gegeben, wenn die gleiche Entwicklerqualifikation sowie die gleiche Entwicklungsmethodik vorliegt. Der Einsatz neuer Entwicklungsmethoden - sowie werkzeuge wird jedoch eine Angleichung der Produktivitätsfaktoren notwendig machen. Bei den Produktivitätsmethoden unterscheidet man einfache und komplexe Ausprägungen. Bei der einfachen Methode wird der erforderliche Entwicklungsaufwand durch Division der gemessenen Ergebnisgröße mit einem entsprechenden Produktionsfaktor festgestellt. Im Gegensatz hierzu muss bei den komplexeren Methoden aus ganzen Tabellen von Produktivitätsfaktoren unter Berücksichtigung der speziell vorliegenden Entwicklungsmerkmale der zutreffende Produktivitätsfaktor ausgewählt werden, der in der Ermittlung des Entwicklungsaufwandes durch Division zum Einsatz kommt ^[44].

Beispiele für Produktivitätsmethode sind:

• Walston-Felix-Methode: Bei der Walston-Felix Methode wird versucht, einen unterschiedlichen Einfluss auf die Produktivität wichtiger Projektbedingungen und –anforderungen zu berücksichtigen. Diese Methode geht folgendermaßen vonstatten: Mit Hilfe der Vergangenheitsdaten und Regressionsanalysen wird der Verlauf eines Produktivitätsindex angegeben. Hiermit kann man die zu erwartende Produktivität schätzen. Die Produktionsvariable wird aus 29 Einflussgrößen ermittelt, welche durch eine Formel den Produktivitätsindex festlegt. Mit diesem Index wird die anzunehmende Produktivität abgelesen. Den zu erwartenden Personalaufwand ermittelt man, indem man die angenommene Anweisungsmenge durch die Produktivität teilt^[44].
• Boing-Methode: Bei der Boing-Methode muss zunächst einmal das Projekt auf bestimmte Progammtypen aufgeteilt werden. Dann erst kann der Gesamtaufwand in Mann-Monaten errechnet werden. Dieser wird dann in vorgegebenen sechs Phasen den jeweiligen Prozentanteilen zugeordnet. Somit wird der für die einzelnen Phasen errechnete Aufwand mit den angegebenen Werten multipliziert^[45].
• Aron-Methode: Die Aron-Methode bestimmt den Programmieraufwand unter Anwendung einer Produktivitätskennzahl. Diese Größe ist abhängig von der Programmierschwierigkeit sowie der Projektdauer^[46].

4.3.3 Prozentsatzmethode

Bei der Prozentsatzmethode kann als einziger Hinweis aus bereits abgeschlossenen Projekten die durchschnittliche prozentuale Aufwandsverteilung auf die einzelnen Projektphasen verwendet werden. Da die Aufwands- und Kostenerfassung nach den Phasen erfolgen, existiert bereits für die Berechnung der Prozentsätze ein breites Spektrum an Material.

Entweder wird der Gesamtaufwand prognostiziert, indem eine Phase des Projektes erst abgeschlossen und von dem entstandenen Aufwand auf den Gesamtaufwand hochgerechnet wird, oder es wird eine Phase detailliert geschätzt und von diesem Teilaufwand auf den zu erwartenden Gesamtaufwand geschlossen. Die Prozentsatzmethode wird regelmäßig ergänzend zu einer weiteren Schätzmethode angewendet, bei der zuerst einmal der Gesamtaufwand geschätzt wird und dann nur noch zur Verteilung des Gesamtaufwands auf die Projektphasen dient. Es wird immer empfohlen, mit mindestens zwei Methoden parallel zu arbeiten und die Ergebnisse zur Plausibilitätsprüfung zu verwenden^[48].

Aufgabengruppe	Anteil am Aufwand
Patientenbehandlung	40%
Führen der Krankenakte	12%
Arbeitsorganisation und Ressourcenplanung	21%
Krankenhausmanagement	10%
Forschung und Lehre	17%
Aufwand für die Gruppen	100%

Tabelle 4.3: Aufwandsverteilung bei aufgabenbezogenen Anforderungen an ein Krankenhausinformationssystem.^[49]

4.4 Expertenbefragung

Eine quantitiative, heuristische Methode, die das Wissen eines ausgewählten Personenkreises nutzt, ist die Expertenschätzung. Man unterscheidet zwischen vier grundsätzlichen Methoden: die Einzelbefragung, die Mehrfachbefragung, die Delphi-Methode und die Schätzklausur. Der Vorteil dieser Methoten besteht darin, dass sie für alle Projekttypen eingesetzt werden können. Erfahrungen bei der Expertenschätzung zeigen aber, daß diese Methothen sehr stark subjektiv beeinflußt und schwer nachzuvollziehen sind.^[50]. Expertenschätzungen sollten sich nie auf ganze Projekte, sondern immer nur auf Teilprojekte beziehen ^[51].

4.4.1 Einzelbefragung

Die Einzelbefragung ist oft eine der ungenauesten Methoden. Hier wird nur eine Meinung eingeholt, meist die des Projektleiters. Da die Schätzung auf seinem eigenen Wissen beruht und von keiner anderen Meinung beeinflußt wird, kommt es hier oft zu extremen Fehleinschätzungen^[53]. Mögliche Gründe, dass der Schätzwert sehr stark vom künftigen Istwert abweicht sind^[52]:

• mangelnde Fachkenntnis,
• mangelnde Plandurchdringung,
• Übersehen von Aufgabenteilen,
• vergangenheitsbedingte "Vorurteile"
• Überschätzung der eigenen Produktivität
• Unterschätzung von Schwierigkeiten und
• opportune Schätzung.

4.4.2 Mehrfachbefragung

Im Unterschied zu der Einzelbefragung greift man bei der Mehrfachbefragung immer auf mehrere Experten zurück. Diese sollen möglichst aus unterschiedlichen organisatorischen Richtungen kommen. Dadurch liefert diese Mehtode ein genaueres Bild als die Einzelbefragung, da es zu einer Verringerung der Vorhersagefehler kommt^[51]. Um zu einem Schätzergebnis zu kommen, bieten sich drei Möglichkeiten an:

• arthitmetisches Mittel aller Ergebnisse,
• Mittelwert aus Minimal- und Maximalwert,
• arithmetisches Mittel ohne Extremwerte.

4.4.3 Delphi-Methode

Die Delphi-Methode ist eine systematische Befragung von mindestens zwei, aber möglichst mehr fachlich kompetenten Personen. Man unterscheidet zwei Verfahren:

• Standard-Delphi-Verfahren und
• Breitband-Delphi-Verfahren.

Der Unterschied liegt in der Bekanntgabe der Schätzresultate: beim Standard-Verfahren erfolgt die Bekanntgabe anonym, während beim Breitbandverfahren die Schätzergebnisse gegenseitig bekanntgegeben werden und die Experten die Ergebnisse miteinander besprechen und korrigieren können^[54][52].

Die Delphi-Methoden laufen in folgenden Schritten ab^[55]:

1. Der Projektleiter schildert das Projektvorhaben und händigt den Experten die Schätzformulare aus.
2. Jeder Experte füllt das Schätzformular aus, ohne mit den anderen Experten in Kontakt zu treten. Rückfragen beim Projektleiter sind gestattet.
3. Die ausgefüllten Schätzformulare werden ausgewertet. Weichen die Ergebnisse sehr strak von einander ab, werden entsprechende Kommentare auf die neuen Schätzformulare gemacht.
4. Die neuen Formulare werden an die Expetern verteilt und von ihnen selbständig überarbeitet.
5. Schritt 2-4 werden so lange wiederholt, bis eine vorher gewünschte Angleichung der Ergebnisse stattgefunden hat.
6. Der Durchschnittwert der letzten Überarbeitung stellt das Schätzergebnis dar.

Die Breitband-Delphi-Methode läuft wie folgt ab^[56]

1. Der Projektleiter schildert das Projektvorhaben und händigt den Experten die Schätzformulare aus.
2. Alle Experten diskutieren gemeinsam über die zu erstellende Schätzung.
3. Jeder Experte füllt eigenständig das Schätzformular aus, ohne mit den anderen Experten in Kontakt zu treten. Rückfragen beim Projektleiter sind gestattet.
4. Die ausgefüllten Schätzformulare werden ausgewertet. Die Schätzergebnisse werden ohne Kommentare auf einem Formular zusammengefasst.
5. Die Experten diskutieren gemeinsam die Abweichungen und erstellen dann wieder einzeln eine neue Schätzung.
6. Schritt 2-5 werden so lange wiederholt, bis eine vorher gewünschte Angleichung der Ergebnisse stattgefunden hat.
7. Der Durchschnittwert der letzten Überarbeitung stellt das Schätzergebnis dar.

4.4.4 Schätzklausur

Die Schätzklausur ist wie die Delphi-Methode durch ein streng systematische Vorgehen geprägt. Die Experten-Runde wird durch Mitglieder des späteren Projektteam ergänzt. Im Gegensatz zur Delphi-Methode werden jetzt keine Einzelschätzungen vorgenommen, sondern die Schätzungen werden kollektiv in der Gruppe vorgenommen. Die Schätzklausur läuft in drei Schritten ab:

• Vorbereitung der Daten, Projektpläne, Zusammensetzung der Gruppe und Dokumentation der Schätzklausur.
• Durchführung der eigentlichen Schätzung mit Moderation und Protokollführung.
• Nachbereitung mit erster grober Projektplanung und Nachbereitung der Ergebnisse mit evtl. Plausibilisierung durch Kennzahlen-, Vergleichs- oder algorithmische Methoden.

5 Verfahren der Aufwandschätzung

5.1 Anforderung an Aufwandschätzverfahren

Ein „ allgemeingültiges, universell einsetzbares und immer korrekte Ergebnisse lieferndes Schätzverfahren“ existiert laut Litke nicht^[57]. Bezogen auf die Notwendigkeit einer Aufwandschätzung wird trotzdem der Einsatz quantitativer Methoden herangezogen. Zur Minimierung von Schätzfehlern ist die Tabelle 5.1 mit folgenden Anforderungen zu befolgen:

Benutzerfreundlichkeit	Projektsteuerung	Ergebnisqualität
Einsetzbarkeit	Anwendbarkeit	Genauigkeit	Objektivität
Erlernbarkeit	Strukturierung	Nachvollziehbarkeit	Stabilität
Zeitaufwand	Interativität	Bewertbarkeit	Fehlertoleranz
Rechnerunterstützung	Sensitivitätsanalysen	Einflussabdeckung	Anpassung
Transparenz		Parameteranzahl	Adaptivität

Tabelle 5.1: Anforderungen an Aufwandschätzverfahrenen^{[58][59][60][61]}.

5.2 Verfahrensarten

5.2.1 Function-Point

Das von IBM entwickelte Verfahren hat sich dank seiner Übersichtlichkeit und Anpassungsfähigkeit schnell verbreitet. Es beinhaltet sowohl algorithmische als auch vergleichende Schätzmethoden und stützt sich auf fünf Schritte^[62]:

1. Ermittlung der Komponenten
2. Bewertung der Komponenten
3. Ermittlung der Anzahl der Function-Points aus 1. und 2.
4. Klassifizierung der Einflussgrößen
5. Entwicklungsaufwand auf Basis von 4. unter Berücksichtigung von 3. berechnen.

Ein Verfahren, das aus dem Function-Point-Verfahren hervorgegangen ist, ist das Widget-Verfahren. Es wurde speziell für die Aufwandschätzung von GUI-basierten Programmen entwickelt. Widget ist ein Kunstwort, dass aus WINDOWS und GADGET zusammengesetzt ist. Man zählt die Widget's (Radio-Butten, Listboxen usw.) und ermittelt daraus die Function Points. Ansonsten ist das Vorgehen analog des Function-Point-Verfahrens^[63].

5.2.1.1 Ermittlung der Komponenten

Im ersten Schritt werden die Projektaufgaben bis auf die Ebene der Komponenten zerlegt. Hierbei unterscheitet man in sechs Funktionskategorien: Eingabedaten, Ausgabedaten, Abfragen, Datenbestände und Referenzdaten. Diese Aufteilung ist sinnvoll, da eine Änderung des Datenbestandes einen größeren Aufwand erfordert als eine Abfrage^[65].

5.2.1.2 Bewertung der Komponenten

In ersten Schritt werden die ermittelten Komponenten einer der drei Funktionskategorien und in einem zweiten Schritt einem Schwierigkeitsgrad (einfach, mittel, komplex) zugeordnet. Dann werden die Komponenten mit einem Punktewert belegt und multipliziert. Daraus ergibt sich folgende Formel, wobei E1 die Summe der Punkte ergibt:

Funktionskategorie	mittel	einfach	komplex
Eingabedaten	3	4	6
Ausgabedaten	4	5	7
Abfragen	3	4	6
Datenbestände	7	10	15
Referenzdaten	5	7	10

Tabelle 5.2: Funktionspunkte der einzelnen Funktionskategorien.^[66]

5.2.1.3 Ermittlung der Anzahl der Function-Points

Aus den Ergebnissen der Ermittlung und Bewertung der Komponenten kann jetzt eine Summe an Function-Points errechnet werden:

5.2.1.4 Klassifizierung der Einflussgrößen

Jetzt werden die auf das gesamte Projektumfeld einwirkenden Einflussfaktoren bewertet. Diese können Werte von 0 (kein Einfluss) bis 5 (starker Einfluss) haben. Im Function-Point-Verfahren sind sieben Einflussfaktoren definiert^[67]:

• Verflechtung mit anderen IT-Systemen
• Verarbeitung und Verwaltung werden dezentral durchgeführt(DDP-Konzept)
• Komplexität der Verarbeitungslogik
• Schwieriges und komplexes Rechnerumfeld
• Anteil der Wiederverwendbarkeit
• Konvertierung der Datenbestände
• Hilfen für die Benutzerbedienung

Anschließend werden die so bewerteten einzelnen Einflußgrößen (E2) addiert. Es wird versucht, diese Einflussgrößen im Bewertungskalkül durch die globale Bewertungsziffer E3 zu berücksichtigen. Die Bewertungsziffer wird durch folgende Formel errechnet^[68]:

5.2.1.5 Entwicklungsaufwand berechnen

Jetzt werden aus den Funktion-Points (E1) und der Bewertungsziffer (E3) die Total-Function-Points (TFP) berechnet. Die Formel dafür ist^[68]:

Aus der Regressionsanalyse bereits abgeschlossener Systeme kann von den TFP auf auf den Entwicklungsaufwand, sprich Mann-Monat, geschlossen werden:

Total Funktion Point	Mann-Monate	Total Funktion Point	Mann-Monate
50	5	400	28
100	8	450	32
150	11	500	32
200	14	500	36
250	17	550	40
300	20	600	44
350	24	...	...

Tabelle 5.3: Zuordnungstabelle: Totale Function-Points zu Mann-Monaten^[69].

5.2.2 Cocomo

Die Cocomoberechnung ist ein Verfahren, dass auf algorithmischen und parametrischen Methoden basiert^[70]. Es handelt sich um ein empirisches Modell, bei dem mehrere firmenspezifische Daten (Parameter) von Softwareprojekten zusammenfließen. Durch die Analyse können Formeln abgeleitet werden, welche die Beobachtungen bestätigen. Hierdurch findet eine Verknüpfung der Systemgröße, Produkt-, Projekt- und Teamfaktoren mit dem Aufwand für die Entwicklung des Systems statt^[71].

Für den Einsatz des Cocomo-Verfahren sprechen folgende Aspekte:

• es handelt sich um ein gut dokumentiertes, frei verfügbares Verfahren, das von Public-Domain-Software und kommerziellen Werkzeugen unterstützt wird,
• weit verbreitet in Organisationen,
• das Verfahren hat eine lange Historie und wurde über die Jahre an die IT-Entwicklung angepaßt (Das Verfahren wurde bereits 1981 durch Barry W. Boehm, Softwareingenieur bei Boeing, entwickelt)

Die Genauigkeit einer mit dem Cocomo-Verfahren angewendeten Schätzung für ein Softwareprojekt wird mit fortschreitender Projektentwicklung immer höher. Beim Start des Projektes kann die Schwankungsbreite noch (x Monaten) zwischen 0,25x bis 4x liegen. Während des Fortschreitens wird die Schwankungsbreite immer kleiner bis sie kurz vor Beendigung des Projektes auf Null sinkt^[71].

Das Cocomo-Verfahren umfasst eine große Anzahl von komplexen Parametern, die nicht einfach zu beschreiben sind. Es findet eine Unterteilung in Projektklassen, Modellvarianten sowie Entwicklungszeit- und –aufwände sowie Projektprofilen statt.

5.2.2.1 Projektklassen

Die Projekte werden in drei Projektkomplexitäten mit verschiedenen Berechnungsfaktoren eingestuft:

Projektkomplexität	Berechnungs- faktor	KDSI	Beschreibung
Einfach (Organic Mode)	1.05	< 50	ein kleines, gut harmonierendes Team arbeitet zusammen, Umfeld ist bekannt, keine große Innovation notwendig, stabile Schnittstelle, kein Druck durch Endtermin
Mittel (Semidetached Mode)	1.12	50 - 300	Mitarbeiter mit durchschnittlicher Erfahrung, erfahrene und weniger erfahrene Projektteam-Mitglieder, Projektteam-Mitglieder mit einigen Erfahrungen in Teilgebieten arbeiten zusammen
Komplex (Embedded Mode)	1.20	> 300	starker Kosten- und Termindruck, große Innovation, umfangreiches Produkt mit integralen Elementen, hohe Anforderungen ans PT, neue Komponenten

Tabelle 5.4: Das grundlegende COCOMO 81-Modell^[74][70]

5.2.2.2 Modellvarianten

Man unterscheidet zwischen dem Basis-, dem Zwischen- und dem Erweiterten-Cocomo-Verfahren. Bei dem ersten Cocomo-Modell bezieht man sich auf ein Drei-Stufen-Modell. In diesem Modell entsprechen die Stufen der Ausführlichkeit der Analyse einer Schätzung. Bei der ersten Stufe erfolgt eine Basis-Schätzung, eine sog. grobe Schätzung. Mit diesem Basismodell werden überwiegend die Projektkosten in einem frühen Stadium des Projektes nach der Studienphase geschätzt, da der Detaillierungsgrad der Ablaufstruktur noch nicht zu hoch ist. Mittels einer Grundgleichung werden Kosten- und Zeitaufwand errechnet. Das Projekt wird als ein Ganzes betrachtet, ohne eine Unterteilung ins zeitliche und strukturelle vorzunehmen. Der Schwierigkeitsgrad ist konstant gleich hoch. Dieses Basismodell gilt als nützlicher Ausgangspunkt für die nachfolgenden Projektaufwandschätzungen.

Mit Hilfe der zweiten Stufe wird die Basis-Schätzung unter Anwendung von Projekt- und Prozessmultiplikatoren verfeinert. Hier wird noch nicht die Differenzierung der Entwicklungsphasen berücksichtigt. Von einem parametrisierten Typ kann noch nicht gesprochen werden, da eventuell nicht belegbare Daten berücksichtigt werden können. Zu guter letzt werden bei dem erweiterten Verfahren die Schätzungen mit den 15 Einflussfaktoren den verschiedenen Phasen zugeordnet^[75].

5.2.2.3 Entwicklungszeit- und aufwand

Die Formel zur Schätzung des Entwicklungsaufwandes bzw. der benötigten Zeit für die Softwareentwicklung des Basismodells entnehmen Sie der unteren Auflistung:

Einfache SW-Projekte	PM = 2.4 * (KDSI)1,05
Mittelschwere SW-Projekte	PM = 3.0 * (KDSI)1.12
Komplexe SW-Projekte	PM = 3.6 * (KDSI)1.20

Die Formel zur Schätzung des Entwicklungsaufwandes bzw. der benötigten Zeit für die Softwareentwicklung des Zwischenmodells lautet:

Einfache SW-Projekte	PM = 3.2 * (KDSI)1,05
Mittelschwere SW-Projekte	PM = 3.0 * (KDSI)1.12
Komplexe SW-Projekte	PM = 2.8 * (KDSI)1.20

Bei den Berechnungen legt Barry Boehm folgende Parameter fest: ein Personen-Monat besteht aus 152 Arbeitsstunden, bei 19 Arbeitstagen mit 8 Arbeitsstunden pro Tag. Abwesenheiten wie Krankheit, Urlaub und Ferien sind bereits berücksichtigt.

Die nachfolgende Abbildung zeigt, dass je größer ein Produkt ist, desto kleiner die Leistung von einem Full-time-equivalent wird. Konkretisiert heißt das, dass bei kleinen Produktgrößen qualifizierte Informatiker mehr Codes schreiben können als bei im Vergleich zu großen Produkten^[77].

Die für die Berechnung der Entwicklungszeit benötigte Formel lautet:

Einfache SW-Projekte	TDEV = 2.5 * (PM)0.38
Mittelschwere SW-Projekte	TDEV = 2.5 * (PM)0.35
Komplexe SW-Projekte	TDEV = 2.5 * (PM)0.32

5.2.2.4 Projektprofil

Jenny unterteilt die Projetkgrößen nach der Anzahl der Codezeilen (loc) in folgende Klassen^[79]:

Small	Kleines Projektprofil	2000 loc
Intermediate	Mittleres Projektprofil	8000 loc
Medium	Mittelgroßes Projektprofil	32000 loc
Large	Großes Projektprofil	128000 loc
Very large	sehr großes Projektprofil	512000 loc

5.2.3 PRICE

Price beinhaltet eine Ansammlung von Kostenschätzmodellen für verschiedene Gebiete der Entwicklung (HW, SW usw ). Mit Hilfe von Price H werden für den HW-Teil Schätzungen der zu erwartenden Entwicklungs- und Produktionskosten auf der Grundlage quantitativer und qualitativer Größen vorgenommen. Für den SW-Teil wird Price S angewendet, welches eine Ähnlichkeit zum Cocomo-Verfahren aufweist. In diesem Fall können die gesuchten Kosten sowie die beste Dauer der Entwicklung festgesetzt werden^[80].

5.2.3.1 Price H

Das Price H wird zum Schätzen von Entwicklungs- und bzw. Produktionskosten eingesetzt. Vor Beginn der Kostenschätzung sollte dieses Modell an das bereichsspezifische Entwicklungsumwelt zugeordnet werden. Um dies vorzunehmen, müssen entsprechenden Price-Parameter und die zugehörigen Kosten festgestellt werden. Die Kalibrierung geschieht unter Anwendung des Price-Modul ECIRP. Als Ergebnis erhält man entsprechende Komplexitätsdaten, welche für die Grundlage der Kostenschätzung neuer Produkte wiedergibt. Um eine Schätzung durchführen zu können, werden mehrere Eingabeparameter benötigt, diese können auch durch Standartwerte belegt sein. Diese können jederzeit verändert werden. Die Eingabeparameter sind folgendermaßen unterteilt: Physikalische Parameter , Quantitative Parameter, Zeitliche Parameter, Qualitative Parameter, Entwicklungsparameter, Integrationsparameter sowie zusätzliche Parameter^[81].

5.2.3.2 Price S

Dieses Modell dient zum Schätzen der Entwicklungskosten von Produkten bzw. Systemen. Price S wird für Prgrammsysteme, Realsysteme sowie bei Programmiersprachen eingesetzt. Bei diesem Verfahren wird der Prozess in drei Phasen unterteilt: Entwurf, Implementierung und Integration und Test. Bei Price S werden für die Berechnungsgänge auch mehrere Parameter benötigt. Hier findet auch eine Unterteilung der Parameter statt, in Quantitative, Qualitative, zeitliche, Einsatzmittel-, Entwicklungs-, Schnittstellen- und zusätzliche Parameter^[81].

6 Vergleichende Betrachtung der Aufwandsschätzmethoden- und Verfahren

6.1 Einordnung nach Klassen

Basierend auf den vorgenannten Methoden und Verfahren lassen sich verschiedene Einsatzgebiete in IT-Projekten definieren. Entsprechend der Ausgangsbasis werden die Aufwandschätzungen wie folgt eingeteilt:

• Funktionen = funktionsorientiert
• Entwicklungsphasen = prozessorientiert
• Produktergebnisgrößen = produktorientiert
• Projektmerkmal = projektorientiert

Die folgende Tabelle zeigt die in dieser Fallstudie genannten Aufwandsschätzungen entsprechend ihren Methodenklassen zugeordnet. Da Verfahren immer aus einer Kombination mehrerer Methoden bestehen, tauchen sie in der Tabelle ggf. mehrfach auf.

Methodenklasse	Funktionsorientiert	Prozessorientiert	Produktorientiert	Projektorientiert
Algorithmische Methode	ZKP IBM-Faktorenmethode Function-Point-Verfahren	SLIM	COCOMO PRICE S PRICE H Jensen-Methode	Surböck
Vergleichsmethode	Function-Point-Verfahren			EDB
Kennzahlenmethode		Prozentsatzmethode Boing-Methode	Wolverton-Methode Walston-Felix-Methode Aron-Methode

Tabelle 6.1: Einordnung der Aufwandschätzverfahren.^[82]

6.2 Einsatzzeitpunkt

Die Einsatzzeitpunkte unterscheiden sich sehr stark bei den unterschiedlichen Aufwandschätzmethoden bzw.- verfahren. Dies liegt an den unterschiedlichen Arten der Ausgangs - und Einflussgrößen. Wenn für die Schätzmethoden genaue Angaben über das geplante Entwicklungsvorhaben benötigt werden, können diese Methoden erst in einer späteren Projektphase genutzt werden. Dadurch sind die Ergebniss allerdings auch sehr viel genauer als bei Methoden und Verfahren die schon sehr früh zum Einsatz gebracht werden können. Die einzige Methode, die schon in der Projektanstoßphase genutzt werden kann, ist die EDB-Methode. Die meisten Methoden können erst nach dem Systementwurf genutzt werden^[82].

6.3 Einsatzfelder

In vielen Fällen müssen die Parameter und/oder Bewertungen auf die jeweilige Projektart angepasst werden. Dies geschieht auf Basis vorheriger Erfahrungen. So muß z.B. bei der Produktivitätsmethode beim Einsatz in Nicht-Software-Projekten eine Kennzahl für eine relative Ergebnismenge mit den dazugehörigen Einflussfaktoren definiert werden. In Bild 5.6 sind die gängigsten Kombinationen nach Burghardt^[84] aufgezeigt.

6.4 Gegenüberstellung der Expertenschätzungen

Eine Gegenüberstellung mit Vor- und Nachteilen der Expertenschätzungen ist in Abbildung 6.3 dargestellt:

7 Zusammenfassung

In der Literatur ist die Trennlinie zwischen Methoden und Verfahren fließend. So kommt es vor, dass in der gleichen Quelle einmal von der Function-Point-Methode als aber auch von dem Function-Point-Verfahren die Rede ist, obwohl das gleiche gemeint ist. Ausgehend von der Definition von Methoden und Verfahren sind Function-Point als auch COCOMO als Verfahren zu werten. Das gleiche Problem betrifft auch die Delphi-Methode. Der überwiegende Teil der Publikationen bezeichnet die Delphi-Methode als Methode, ein anderer Teil als Verfahren. Eine der Hauptschwierigkeiten dieser Arbeit bestand somit darin, diese Begriffe zu entwirren und entsprechend zu strukturieren^[87].

Das Function-Point-Verfahren schneidet im Vergleich aller Verfahren am besten ab. Weltweit ist es hinsichtlich der Metriken das am weitesten verbreitete und meisten akzeptierte Verfahren. Einer seiner größten Vorteile besteht darin, dass es schon relativ früh - in der Fachkonzept-Phase - eingesetzt werden kann^[88].

Daneben ist das COCOMO-Verfahren in der Softwareentwicklung weit verbreitet. Es gibt in der Praxis zwei Ansätze, den Umfang der zu entwickelnden Software zu messen: Den Umfang der funktionalen Vorgaben und den Programmieraufwand (LOC). Ein Problem des LOC-Ansatz ist, dass die LOC’s erst in einer späteren Phase des Projektes bekannt sind und normalerweise nur ca. 10% der Programmentwicklung ausmachen. Außerdem tritt das Problem von unterschiedlichen Programmiersprachen auf. So hat z.B. Assembler mehr Codezeilen als Java für die gleiche Funktion braucht^[89].

Sehr weit verbreitet sind auch die Expertenschätzungen. Hier ist gegenüber den oben aufgeführten Verfahren ein geringerer logistischer und technischer Aufwand nötig. In vielen Projekten ist jedoch die Gesamtprojektzeit von einem Auftraggeber vorgegeben^[90]. Es handelt sich also um eine „politische Zeit“. In eine Expertenschätzung lässt sich diese Zeitvorgabe sehr gut „einpflegen“, da solche Schätzungen objektiv nur schwer nachzuvollziehen sind.

8 Tabellenverzeichnis

Tab.-Nr.	Tabelle
4.1	Einführungsaufwand für eine INEK-Kalkulation mit verschienden Kranskerhausinformationssystemen in Verbindung mit Kostenträgerrechung.[38]
4.2	Leistungsanforderung mit Probenentnahmen im Krankenhaus.[42]
4.3	Aufwandsverteilung bei aufgabenbezogenen Anforderungen an ein Krankenhausinformationssystem.[49]
5.1	Anforderungen an Aufwandschätzverfahrenen[58][59][60][61]
5.2	Funktionspunkte der einzelnen Funktionskategorien.[66]
5.3	Zuordnungstabelle: Totale Function Points zu Mann-Monaten[69]
5.4	Das grundlegende COCOMO 81-Modell[70]
6.1	Einordnung der Aufwandschätzverfahren.[82]

9 Abbildungsverzeichnis

Abb.-Nr.	Abbildung
3.1	Teufelsquadrat[7]
3.2	Qualitätsmerkmale nach ISO 9126[15]
3.3	Einfluß der Personalqualität auf die Projektdauer bei einem Function Point Verfahren[17]
4.1	Prinzip der Aufwandschätzung[20]
4.2	Vergleichende Methoden[30]
4.3	Phasenbezogene Prozentsatzmethode (Werte aus einer nachrichtentechnischen Entwicklung)[47]
4.4	Formen der Expertenschätzung[52]
5.1	Zu zählende Funktionen am Beispiel eines Kundendepots[64]
5.2	Unsicherheiten bei der COCOMO-Schätzung[72][73]
5.3	Leistungsgröße bei einfachen Software-Projekten[76]
5.4	Entwicklungszeit gemessen an der Produktionsgröße[78]
6.1	Einsatzzeitpunkte von Aufwandsschätzmethoden bzw. -verfahren[83]
6.2	Einsatzfelder von Aufwandsschätzmethoden bzw. -verfahren[85]
6.3	Gegenüberstellung der Expertenschätzungen[86]

10 Abkürzungsverzeichnis

Abkürzung	Bedeutung
COCOMO	COnstructive COst MOdel: algorithmisches, parametisches Aufwandschätzverfahren
EDB	Erfahrungsdatenbank
HW	Hardware
INEK	Institut für das Entgeltsystem im Krankenhaus
KDSI	Kilo delivered source instructions: 1 KDSI = 1000 Codezeilen
LoC	Lines of Code: Anzahl Programmzeilen
PM	Personenmonate
PRICE	Programmed Review of Information for Costing and Evaluation
SLIM	Software Lifecycle Management
SW	Software
TDEV	Time for Devolepment: Entwicklungszeit
TFP	Total Function Point
ZKP	Zeit-Kosten-Planung

11 Fußnoten

1. ↑ Vgl. Boehm (1981) Seite 452
2. ↑ Vgl. Oestereich (2008) Seite 76
3. ↑ Quelle: Balzert (2000) Seite 36
4. ↑ Quelle: Balzert (2000) Seite 37
5. ↑ Quelle: Heinrich (2005) Seite 432
6. ↑ ^{6,0 6,1} Vgl. Schröder (2006) Seite 108
7. ↑ ^{7,0 7,1 7,2} Quelle.: Sneed (1987) Seite 121
8. ↑ Vgl. Wieczorrek (2007) Seite 207
9. ↑ Vgl. Heinrich (2005) Seite 433
10. ↑ ^{10,0 10,1} Noth (1984) Seite 8
11. ↑ ^{11,0 11,1 11,2 11,3 11,4} Vgl. Heinrich (2005) Seite 434
12. ↑ Vgl. Noth (1984) Seite 9
13. ↑ Vgl. Wieczorrek (2007) Seite 208
14. ↑ ^{14,0 14,1} Vgl. Biethan (1992) Seite 206
15. ↑ ^{15,0 15,1} Vgl. ISO 9126 (2001) Seite 7
16. ↑ ^{16,0 16,1} Vgl. Wieczorrek (2007) Seite 209
17. ↑ ^{17,0 17,1 17,2} Vgl.: Gruner (2003) Seite 161
18. ↑ Vgl. Gadatsch (2008) Seite 91
19. ↑ Vgl. Heinrich (2005) Seite 443
20. ↑ ^{20,0 20,1} Quelle: Burghardt (2008) Seite 172
21. ↑ Vgl. Bundschuh (2004) Seite 133
22. ↑ Vgl. Wieczorrek (2007) Seite 212
23. ↑ Burghardt (2008) Seite 172
24. ↑ Vgl. Biethahn (1992) Seite 210
25. ↑ ^{25,0 25,1} Bundschuh (2004)
26. ↑ Vgl. Biethahn(1992) Seite 209
27. ↑ Vgl. Noth (1984) Seite 33
28. ↑ Vgl. Noth (1984) Seite 39
29. ↑ Vgl. Noth (1984) Seite 44
30. ↑ ^{30,0 30,1} Quelle: Burghardt (2008) Seite 176
31. ↑ Vgl. Burghardt (2008) Seite 176
32. ↑ Vgl. Heinrich (2005) Seite 435
33. ↑ Vgl. Biethan (1992) Seite 208
34. ↑ Vgl. Bundschuh (2004) Seite 357
35. ↑ Vgl. Sneed (1987) 601
36. ↑ Vgl. Noth (1984) Seite 22
37. ↑ Vgl. Bundschuh (2004) Seite 148
38. ↑ ^{38,0 38,1} Quelle: DHZB (2008) Seite 102
39. ↑ Burghardt (2008) Seite 228
40. ↑ Vgl. Burghardt (2008) Seite 178
41. ↑ Vgl. Heinrich (2005) Seite 437
42. ↑ ^{42,0 42,1} Vgl. Haux (2001) Seite 10
43. ↑ Vgl. Noth (1984) Seite 76
44. ↑ ^{44,0 44,1} Vgl. Burghardt (2008) Seite 179
45. ↑ Vgl. Noth (1984) Seite 55
46. ↑ Burghardt (2008) Seite 180
47. ↑ ^{47,0 47,1} Quelle: Burghardt (2008) Seite 180
48. ↑ Vgl. Litke (2007) Seite 115-116
49. ↑ ^{49,0 49,1} Vgl. Haux (2001) Seite 7-24
50. ↑ Vgl. Winkelhofer (2005) Seite 270-271
51. ↑ ^{51,0 51,1} Lechtenberg (1998) Seite 32
52. ↑ ^{52,0 52,1 52,2 52,3} Quelle: Burghardt (2008) Seite 238
53. ↑ Litke (2007) Seite 32
54. ↑ Vgl. Jenny (2001) Seite 352
55. ↑ Vgl. Jenny (2001) Seite 353
56. ↑ Vgl. Burghardt (2008) Seite 239
57. ↑ Vgl. Litke (2007) Seite 7
58. ↑ ^{58,0 58,1} Vgl. Litke (2007) Seite 10
59. ↑ ^{59,0 59,1} Vgl. Bundschuh (2004) Seite 169-172
60. ↑ ^{60,0 60,1} Vgl. Noth (1984) Seite 30-32
61. ↑ ^{61,0 61,1} Vgl. Lechtenberg (1998) Seite 7
62. ↑ Vgl. Jenny (2001) Seite 361
63. ↑ Oestereich (2008) Seite 282
64. ↑ ^{64,0 64,1} Quelle.: Gruner (2003) Seite 173
65. ↑ Vgl. Wieczorrek (2007) Seite 217
66. ↑ ^{66,0 66,1} Vgl. Wieczorrek (2007) Seite 218
67. ↑ Vgl. Seibt (1987) Seite 4
68. ↑ ^{68,0 68,1} Vgl. Biethan (1992) Seite 218
69. ↑ ^{69,0 69,1} Quelle Seibt (1987) Seite 8
70. ↑ ^{70,0 70,1 70,2} Vgl. Jenny (2001) Seite 366
71. ↑ ^{71,0 71,1} Vgl. Sommerville (2007) Seite 671
72. ↑ ^{72,0 72,1} Quelle.: Sommerville (2007) Seite 672
73. ↑ ^{73,0 73,1} Vgl. Oestereich (2008) Seite 74
74. ↑ Vgl. Sommerville (2007) Seite 672
75. ↑ Vgl. Jenny (2001) Seite 366-368
76. ↑ ^{76,0 76,1} Quelle.: Boehm (1981) Seite 455
77. ↑ Vgl. Boehm (1981) Seite 455
78. ↑ ^{78,0 78,1} Quelle: Boehm (1981) Seite 457
79. ↑ Vgl. Jenny (2001) Seite 369
80. ↑ Vgl. Bundschuh (2004) Seite 173/174
81. ↑ ^{81,0 81,1} Burghardt (2008) Seite 207 - 210
82. ↑ ^{82,0 82,1 82,2} Quelle: Burghardt (2008) Seite 181
83. ↑ ^{83,0 83,1} Quelle: Burghardt (2008) Seite 183
84. ↑ Vgl. Burghardt (2008) Seite 181
85. ↑ ^{85,0 85,1} Quelle: Burghardt (2008) Seite 182
86. ↑ ^{86,0 86,1} Quelle: Burghardt (2008) Seite 242
87. ↑ Vgl. Noth (1984) Seite 101
88. ↑ Bundschuh (2004) Seite 133
89. ↑ Bundschuh (2004) Seite 134
90. ↑ Vgl. Kellner (2001) Seite 125-127

12 Literaturverzeichnis

Balzert (2000)	Balzert, H.: Lehrbuch der Softwartechnik: Softwareentwicklung, 2. überarbeitete und erweiterte Auflage, Spektrum-Akademischer Verlag 2000
Biethan (1992)	Biethahn, J.; Mucksch, H.; Ruf, W.: Ganzheitliches Informationsmanagement - Band 1: Grundlagen, 2. Auflage, Oldenburg-Verlag, München 1992
Boehm (1981)	Boehm, B.W. Software Engineering Economics, Prentice Hall, Englewood Cliffs, NJ 1981
Bundschuh (2004)	Bundschuh, M.; Fabry, A.: Aufwandschätzung von IT-Projekten, 2. Auflage, mitp-Verlag, Bonn 2004
Burghardt (2008)	Burghardt, M.: Projektmanagement: Leitfaden für die Planung, Überwachung und Steuerung von Projekten, 8. Auflage, Siemens, München 2008
DHZB (2008)	Deutsches Herzzentrum Berlin: Ausschreibungsunterlagen des DHZB, Teilprojektgruppe INEK-Kalkulation, November 2008
Gadatsch (2008)	Gadatsch, A.: Grundkurs IT-Projektcontrolling Grundlagen, Methoden und Werkzeuge für Studierende und Praktiker, 1. Auflage, Vieweg+Teubner, Wiesbaden 2008
Gruner (2003)	Gruner, K.; Jost, C.; Spiegel, F.: Controlling von Softwareprojekten, 1. Auflage, Vieweg & Sohn, Wiesbaden 2003
Haux (2001)	Haux, R.; Ammenenwerth, E; Buchauer, A: Anforderungskatalog für die Informationsverarbeitung im Krankenhaus, Version 1.0b, Deutsche Forschungsgemeinschaft, Heidelberg 2001
Heinrich (2005)	Heinrich, L.; Lehner, F.: Informationsmanagement - Planung, Überwachung und Steuerung der Informationsinfrastruktur, 8. Auflage, Oldenbourg Verlag, München 2005
ISO 9126 (2001)	ISO/IEC 9126-1: Software Engineering - Produkt quality; Part 1 - Quality model 2001
Jenny (2001)	Jenny, B.: Projektmanagement in der Wirtschaftsinformatik, 5. Auflage, vdf Hochschulverlag, Zürich 2001
Kellner (2001)	Kellner, H.: Die Kunst, IT-Projekte zum Erfolg zu führen, 2. aktualisierte Auflage, Hanser-Verlag, München 2002
Lechtenberg (1998)	Lechtenberg, S.: Dissertation: Aufwandsschätzung für den Bau von Multimediainformationssystemen, Papierfiliegr, Vlausthal-Zellerfeld 1998
Litke (2007)	Litke, Hans-D.: Projektmanagement - Methoden, Techniken, Verhaltensweisen, 5. Auflage, Carl Hanser Verlag, München 2005
Lutz (2002)	Lutz,H.: Informationsmanagement, 7. Auflage, Oldenburg-Verlag, München 2002
Oestereich (2008)	Oestereich, B; Weiss, Ch.: APM - Agiles Projektmanagement, 1. Auflage, dpunkt-Verlag, Heidelberg 2008
Noth (1984)	Noth, Th.; Kretzschar, M.: Aufwandschätzung von DV-Projekten, 1. Auflage, Springer-Verlag, Berlin 1984
Schröder (2006)	Schröder J.P; Diekow, S.: Wie Sie Projekte zum Erfolg führen, 1. Auflage,Cornelsen Verglag, Berlin 2006
Seibt (1987)	Seibt D.: Die Function-Point-Methode: Vorgehensweise, Einsatzbedingungen und Anwendungserfahrungen, Journal: Angewandte Informatik 1/1987 Seite 3-11
Sommerville (2007)	Sommerville, I.: Software Engineering, 8. Auflage, Pearson, München 2007
Sneed (1987)	Sneed, H. M.: Softwaremanagement. Rudolf Müller Verlag, Köln, 1987
Wieczorrek (2007)	Wieczorrek, H.; Mertens, P.r: Management von IT-Projekten, 2. Auflage, Springer, Wiesbaden 2007
Winkelhofer (2005)	Winkelhofer, G.: Management- und Projektmethoden, 3. Auflage, Springer, Heidelberg 2007