Projektplanung

3. Analyse der Einflussfaktoren 4. Berechnung der bewerteten Function - Points 5. Ermittlung des Aufwandes

COCOMO (Constructive Cost Model)

Unterschied zwischen Function Points und COCOMO Quellenverzeichnis: Verwendete Links:

Einleitung

Die Aufwandschätzung hat das Ziel, die im Verlauf des gesamten Projekts auftretenden Aufwände vorauszuplanen und festzuhalten.

Dabei sind im wesentlichen folgende Faktoren (Aufwandtreiber) zu berücksichtigen:

· Leistungsumfang

· Qualität

· Termin

· Produktivität

Die Aufgabe dabei ist die Hauptaufwandstreiber zu identifizieren, geeignete Maßzahlen für jeden Aufwandtreiber zu finden und deren Einfluss auf den Aufwand zu eruieren.

Bei der Auswahl von geeigneten Aufwandschätzmethoden müssen daher folgende Punkte berücksichtigt werden:

· Frühzeitige Verwendbarkeit der Methode

· Abdeckung der Hauptaufwandtreiber

· Erhebbarkeit der notwendigen Schätzfaktoren (z.B. Ein-/Ausgaben bei Function Points)

· Aufwand für Schätzung ist zumutbar

Abweichung

Aufwandschätzungen finden unter Ausnutzung des jeweiligen Kenntnisstandes zu mehreren Zeitpunkten im Projekt statt, wobei das Ergebnis dann auf der einen Seite die aktualisierte Gesamtschätzung - etwa aufgrund geänderter Projektziele oder eingetretener Schwierigkeiten

- und auf der anderen Seite die Detailschätzung der nächsten Aufgaben ist. Wie die Abbildung verdeutlicht, nehmen in der Regel die Abweichungen der Schätzungen über den Projektablauf ab, die Genauigkeit der Schätzungen verbessert sich also.

Function Points

Allgemeines:

Die Methode wurde 1979 von einen Mitarbeiter von IBM namens Allan Albrecht entwickelt.

Die Function Point - Methode basiert auf Zählungen der Externbeziehungen des Systems (Eingaben, Ausgaben, Abfragen) und der logischen Datenbestände, sowie der Bewertung von Einflussfaktoren (Komplexität, Qualität, Projektdauer, Produktivität). Aus der Zahl der Externbeziehungen und Datenbestände, sowie den Wert der Einflussfaktoren werden die Function Points errechnet.

Voraussetzungen :

Vorteile :

Nachteile :

Vorgehensweise der Methode:

1. Quantifizierung des Umfangs - Ermitteln von ,,Functions"

2. Bewertung des Schwierigkeitsgrades der Functions durch ,,Points"

3. Analyse der Einflussfaktoren von 7 vorgegebenen Faktoren

4. Berechnung der bewerteten Function - Points

5. Ermittlung des Aufwandes mittels historischer Daten

1. Quantifizieren des Funktionsumfanges

1. Quantifizieren des Funktionsumfanges

Dieser Umfang kann aus dem Datenfluß abgelesen werden. Betrachtet werden alle Prozesse einer Ebene (2. oder 3. Ebene der Dekomposition bzw. des zugehörigen Datenflusses) sowie alle an diesen anliegenden Flüsse. Jeder Fluß entspricht dabei einer Function (einer vom System zu bearbeitenden Aufgabe).

2. Bewertung des Schwierigkeitsgrades durch ,,Points"

Jeder dieser Flüsse wird in eine der folgenden Gruppen eingeordnet und anhand der Flussbeschreibung (ERD oder Flow-Expression) bewertet (komplex, mittel oder einfach). Damit wird die in den einzelnen Gruppen angeführte Punktezahl (,,Points") ermittelt und aufsummiert.

Die Bewertung besteht aus:

· Eingabedaten

· Ausgabedaten

· Abfragen

· Datenbestände

· Referenzdaten

Eingabedaten

Dateneingaben können sein:

Bildschirm-Eingaben

Eingaben über Lochkarten, Disketten Interface - Daten von anderen Anwendungen Datenbestände, die vollständig sequentiell abgearbeitet werden Belegleser - Eingaben

Ausgabedaten

Datenausgaben können sein:

Bildschirm - Ausgaben

Berichte in Listenform oder Formulare Ausgabe auf Micro - Fiche und Micro - Film Interface - Daten an andere Anwendungen Druckerausgaben dezentral auf Terminaldrucker

Abfragen

Zu zählen ist jede Abfrage, die zu einem Suchen nach Informationen in einem Datenbestand führt und bei der das Ergebnis dem Benutzer sichtbar gemacht wird. Gezählt wird jeweils jede unterschiedlich formatierte Online-Eingabe. Nicht gezählt werden Abfragen durch Endbenutzersprachen. Abfragen mit vielen Verarbeitungsschritten, Zugriff auf mehrere Dateien, evtl. Zwischenverarbeitung mit Speicherung und/oder Sortierung, zählen nicht als Ausgaben, sondern als Eingaben und als Ausgaben.

Datenbestände

Zu zählen ist jeder Datenbestand, der von der Anwendung "gewartet" (update, insert, delete) und/oder betreut wird (Security, Recovery). Gezählt wird jeweils jede logische Datengruppe, die in der Anwendung verwendet wird (Zwischendateien, Sortdateien werden nicht gezählt). Die Einteilung in logische Datengruppen geschieht nach organisatorischen - nicht technischen - Gesichtspunkten.

Referenzdaten

Zu zählen ist jeweils jede Datei, die in der Anwendung als Informationsträger benötigt wird, z.B.: Tabellen, Read - Only - Dateien. Jene Tabellen, die nur aus technischen Gründen benötigt werden, werden nicht berücksichtigt.

Bei Read-Only-Dateien wird jeweils jede logische Datengruppe gezählt und nach folgenden Kriterien klassifiziert:

Bei Tabellen (jede Tabelle wird gezählt) werden folgende POINTS verwendet:

3. Analyse der Einflussfaktoren

Der Entwicklungsprozess wird zusätzlich zu den Function - Points noch von weitern Faktoren

beeinflusst. Folgende Einflussgrößen werden berücksichtigt:

Die Verarbeitungslogik erhält 0-30 Punkte und summiert sich aus den

4. Berechnung der bewerteten Function - Points

Die Summe der bewerteten Function - Points wird gemäß folgender Formel berechnet:

BFP=FP * (0,7 + EF * 0,01)

BFP = Summe der bewerteten Function Points

FP = Summe der Bewertung des Schwierigkeitsgrades EF = Summe der Analyse der Einflussfaktoren

EF liegt im Bereich 0 - 60. Der Klammerausdruck liefert also einen Wert zwischen 0.7 und 1.3; d.h. die Einflussfaktoren können den Wert FP um 30% verändern. Liefert der Klammerausdruck 1, so liegt kein besonderer Einfluss vor.

5. Ermittlung des Aufwandes

Um jetzt den Aufwand in Form von Mannmonaten zu bekommen muss man geeignete Umrechnungstabellen erstellen. Normalerweise hat man durch die Praxis im Betrieb ausreichende Erfahrung gesammelt mit denen man leicht eine solche Tabelle erstellen kann. Weiters kann es vorkommen, dass der Betrieb schon über eine geeignete Tabelle verfügt. Diese Tabelle dient dann nur als Richtwert, da jeder, der eine Aufwandschätzung vornimmt anders bewertet. In diesem Fall ist es besser eine eigene Tabelle zu erstellen und die daraus resultierende Kurve (x = BFP; y = Mannmonate) an die Betriebseigene anzugleichen. Die eigene Tabelle sollte außerdem laufend aktualisiert werden, d.h. die Erfahrungen abgeschlossener Projekte sollte laufend integriert werden. Sind beide Möglichkeiten nicht vorhanden so kann man die IBM-Tabelle als Vorlage hinzuziehen. Diese Tabelle kann aber nur als Richtwerttabelle verwendet werden, da sie auf Assembler Programmierung aufgebaut ist. Aufwandschätzung (Formular) Eingabedaten Ausgabedaten Datenbestände __einfach x 3 = __ __einfach x 4 = __ __einfach x 7 = ___ __mittel x 4 = __ __mittel x 5 = __ __mittel x 10 = ___ __komplex x 6 = __ __komplex x 7 = __ __komplex x 15 = ___ Referenzdaten Abfragedaten bei Read-Only bei Tabellen

__einfach x 5 = __ __einfach x 5 = __ __einfach x 3 = ___ __mittel x 7 = __ __mittel x 7 = __ __mittel x 4 = ___ __komplex x 10 = __ __komplex x 10 = __ __komplex x 6 = ___ Summe = ____ (= E1) Einflussfaktoren

1) Verflechtung mit anderen Verfahren [0..5] = __ 2) Dezentrale Verarbeitung [0..5] = __ 3) Transaktionsrate [0..5] = __ 4) Verarbeitungslogik Rechenoperationen [0..10] = __ Kontrollverfahren [0..5] = __ Ausnahmeregelungen [0..10] = __ Logik [0..5] = __

5) Wiederverwendung in anderen Verfahren [0..5] = __ 6) Datenbestandskonvertierung [0..5] = __ 7) Benutzerführung [0..5] = __ Summe der 7 Einflüsse = ____ (= E2) Faktor Einflußbewertung: 0,7 + E2/100 = ____ (= E3) Bewertete Function Points: E1 x E3 = ____ Ergebnis in Mannmonaten: ____

Umrechnungstabelle: Function Points - Mannmonate

IBM-Tabelle:

COCOMO (Constructive Cost Model)

Das COCOMO - Modell ist eineinfaches Verfahren zur Schätzung des Aufwands und der Zeitdauer von Softwareprojekten. Entwickelt wurde das COCOMO - Modell von Barry W. Boehm.

Als wichtigste Ausgangsgröße des COCOMO - Verfahrens ist zunächst vom Bearbeiter die Anzahl der ,,Kilo Delivered Source Instructions" (KDSI) zu schätzen. Hierbei handelt es sich um die Anzahl der im Programm selbst enthaltenen Befehle in 1000. Im Gegensatz zu den ,,Source Lines of Code" (SLOC) werden bei den KDSI Kommentar- und Dokumentationszeilen sowie Hilfsroutinen für Programmtests nicht mitgezählt.

Zu Beginn des Projektes ist der Aufwand schwer zu schätzen, am Ende jedoch leicht festzustellen ist. Daraus wird der Aufwand in Bearbeitermonaten mit einer logarithmischen Formel errechnet, in die viele aus abgeschlossenen Projekten gewonnenen Parameter einfließen.

Bevor man mit der Aufwandschätzung beginnt muss man den Schwierigkeitsgrad des Projektes bekannt geben:

Man unterscheidet:

Einfache Projekte (Organic Mode oder Anwendungsprogramme)

Mittelschwere Projekte (Semidetached Mode oder Programmsysteme)

Komplexe Projekte (Embedded Mode oder eingebettete Systeme)

Dieses Bild zeigt eine graphische Veranschaulichung der Kosten über der Produktgröße.

Aus dem Grundwert (KDSI) und einer Reihe von Kosten-Multiplikatoren werden Kosten und Durchlaufzeiten berechnet. Die Grundgleichungen lauten:

TDEV = 2,5 MM ^0,38 (TDEV= time to develop)

Die mit den Grundgleichungen ermittelten Nominalwerte können nun noch erheblich genauer gemacht werden, indem man sie mit einer Reihe von Kostenfaktoren multipliziert. Die nächste Seite (Tabelle) zeigt Boehm's Kostenfaktoren-Tabelle.

Die aktuellen Werte aller Kostenfaktoren für ein Projekt werden unabhängig voneinander

geschätzt und anschließend alle miteinander multipliziert. Der Nominalwert für den

Projektaufwand in Personenmonaten wird dann mit diesem Produktfaktor multipliziert.

MM Korr = Produkt der Kostenfaktoren * MM nominal

Unterschied zwischen Function Points und COCOMO

Die Function Point ist besonders für die Aufwandschätzung kaufmännischer Anwendungen

geeignet, für technische oder betriebssystemnahe Anwendungen jedoch ungeeignet. Das Verfahren kann nur für gesamte Anwendungen angewendet werden (d.h. nicht nur auf Modul/Programmebene). Das Anwendungssystem ist dabei aus der Sicht des Benutzers zu betrachten.

COCOMO verwendet die Gewichtungsmethode und parametrische Schätzgleichungen, es ist eher für große und sehr große Anwendungen hoher Komplexität geeignet. Für kleine/mittlere bzw. kaufmännische Projekte liefert COCOMO zu hohe Werte.

Quellenverzeichnis:

Felix Schwab, Wilfried Schneider, Ingrid Schwab-Matkovits;

EDV - Projektentwicklung. Wien: Manz 1999.

Ernst Denert;

Software - Engineering, Methodische Projektabwicklung. Berlin: Springer 1991.

Klaus Gewald, Gisela Haake, Werner Pfadler;

Software - Engineering, Grundlagen und Technik rationeller Programmentwicklung. München; Wien: Oldenbourg 1985

Technische Akademie Esslingen. In Zusammenarbeit mit der Gesellschaft für Informatik e.V.; Software-Entwicklung - Methoden, Werkzeuge, Erfahrungen ... ; ... Kolloquium Ostfildern: Techn. Akad. Esslingen 1995

Verwendete Links:

Einführung in Software-Engineering:

http://www2.informatik.uni-erlangen.de:8081/IMMD-II/Lehre/SS98/SE/index.html

COCOMO-Softwarekostenschätzung:

http://www.fh-dieburg.de/HOME/Seibert/cocomo.htm

Skriptum:

http://www.ifi.unizh.ch/groups/req/courses/se_I/#Herunterladen

Entwicklung einer ProjektDatenbank mit MS Access 2.0:

http://www.schwaben.de/home/peterh/projektdb

Promok Georg Seite /13