Dieser Abschnitt soll nicht das Softwareprojektmanagement als Ganzes abhandeln, sondern nur wenige ausgewählte Aspekte betrachten.

Zur Wiederholung sei die Abgrenzung der Begriffe "Projekt", "Prozess" und "Produkt" empfohlen.

Eine der großen Herausforderungen beim Management von Softwareprojekten ist die Schätzung des Aufwands. Zwei bekannte und oft belegte Thesen lassen dieses Unterfangen sogar fast als ein wenig aussichtslos erscheinen:

1. Parkinson-Gesetz: "Work expands to fill the time available" D.h. ein Projekt wird niemals vor Ende der geplanten Zeit fertig gestellt werden - und sei Zeit noch so großzügig angesetzt.
2. Gesetz von Brook: "Putting more pople on a late job makes it later". Damit wird nicht nur widersprochen, dass die benötigte Zeit mit der Anzahl der Personen sinkt, die daran mitarbeiten, sondern, dass die umgekehrte Korrelation bestehen kann - falls das Projekt schon verzögert ist.

Es gibt eine Vielzahl an Methoden zur Schätzung:

• Schätzung anhand von Analogien, z.B. anhand vergleichbarer Projekte
• "Price to win": Man schätzt so (niedrig), dass man den Auftrag bekommt
• Funktionspunktanalyse (s.u.)
• Buttom-up-Verfahren (s.u.)
• Top-down-Verfahren (s.u.)

Bottom-up

Beim Bottom-up Verfahren wird der Aufwand für jede einzelne Komponenten berechnet und dann das Ergebnis summiert. Beim Hausbau würde das der Berechnung alle Einzelzeiten fürs Mauer, Verputzen, Leitungsverlegen usw. entsprechen.

Dieses Verfahren hat den Nachteil, dass man über die Struktur des Systems schon vertiefte Kenntnisse haben muss. Da man dazu neigt, für jede Komponente ein Sicherheitszuschlag zu gewähren, summieren sich diese Zuschläge und der Projektaufwand wird überschätzt.

 

Top-down

Bei Top-down Ansatz nutzt man algorithmische Modelle zur Schätzung. Bei unserem Analogon des Hausbaus wäre das eine Berechnung anhand von Kenngrößen wie Anzahl der Stockwerke oder Fläche. Diese Berechnungsverfahren nutzen Erfahrungswerte. Darin liegt auch gleichzeitig die Gefahr: Sobald die Charakteristiken zweier Projekte voneinander abweichen, lassen sich die Formeln nicht mehr übertragen. Bekannte Vertreter von Top-Down Verfahren sind die Schätzung anhand der "Lines of Code" LOC und das COCOMO Verfahren (s.u.). 

Die Funktionspunktanalyse ist ein Verfahren zur Größenbestimmung (nicht Aufwandsbestimmung!). Die Schätzung beruht auf der Anzahl von zwei Informationseinheiten und drei Prozesstypen zum Verarbeiten der Informationseinheiten:

• External Interface EIF: Gruppierte Informationseinheit, die außerhalb des Systems gepflegt wird. Ein Beispiel wäre eine Tabelle in einem Fremdsystem
• Internal Logical File ILF: Gruppiere Informationseinheit, die innerhalb des System gepflegt wird. Ein Beispiel wäre eine Tabelle des Systems
• External Input EI: Prozess, der systemexterne Eingabedaten verarbeitet (z.B. Benutzerdaten in einem ILF speichert oder modifiziert)
• External Output EO: Prozess, der Daten aufbereitet, die das System verlassen, z.B. dem Benutzer angezeigt werden
• External Inqury EI: Interaktiver Prozess aus Ein- und Ausgabe, beispielsweise ein Bericht, der von Benutzereingaben gesteuert Daten berechnet und ausgibt

Diese fünf Größen des Systems werden mit Gewichtungsfaktoren multipliziert, die abhängig von der Komplexität sind. Man betrachtet ILFs und EIFs als umso komplexer,

• je mehr Attribute (sogenannte Data Element Types DET) sie haben und
• je mehr Anzahl an logischen Datenuntergruppen, RETs, sie besitzen. Ein Beispiel für die Datenuntergruppe eines Studenten wäre die Gruppe seiner Adressen. (Anmerkung: Intern werden solche RETs oft als Detailtabelle realisiert. Die Funktionspunktanalyse betrachtet die ILFs jedoch nur aus Benutzer und nicht aus Architektursicht.)

Die Prozesse betrachtet man als umso komplexer

• je mehr Attribute (sogenannte Data Element Types DET) verarbeitet werden und
• je mehr ILFs oder EIFs sie referenzieren (Daten darin ändern oder lesen). Die Menge aller ILFs und EIFs wird auch FTR (File Types Referenced) genannt

Komplexitätsmatrix für EI

FTR's	DET's
	1-4	5-15	>15
0-1	niedrig	niedrig	durchschnittlich
2	niedrig	durchschnittlich	hoch
>= 3	durchschnittlich	hoch	hoch

 

Komplexitätsmatrix für EO und EQ

FTR's	DET's
	1-5	6-19	>19
0-1	niedrig	niedrig	durchschnittlich
2-3	niedrig	durchschnittlich	hoch
> 3	durchschnittlich	hoch	hoch

 

Komplexitätsmatrix für ILF und ELF

RET's	DET's
	1-19	20-50	>50
1	niedrig	niedrig	durchschnittlich
2-5	niedrig	durchschnittlich	hoch
>53	durchschnittlich	hoch	hoch

 

Die Gewichtungsfaktoren ergeben sich aus folgender Tabelle:

Komponente	Komplexität
	Niedrig	Mittel	Hoch	Summe
External Input EI	___ x 3 = ___	___ x 4 = ___	___ x 6 = ___
External Output EO	___ x 4 = ___	___ x 5 = ___	___ x 7 = ___
External Inquiries EQ	___ x 3 = ___	___ x 4 = ___	___ x 6 = ___
Internal Logical File ILF	___ x 7 = ___	___ x 10 = ___	___ x 15 = ___
External Logical File	___ x 5 = ___	___ x 7 = ___	___ x 10 = ___
Ungewichtete Funktionspunkte

 

Schließlich wird das Ergebnis, die ungewichteten Funktionspunkte noch mit einem Faktor zwischen 0,65 und 1,35 multipliziert. Dieser Faktor ist abhängig von 14 verschiedenen Systemcharakteristiken wie Anforderungen an die Performance und die Wiederverwendbarkeit, die Anzahl der Lokationen an der die Anwendung entwickelt wird u.v.m.

 

Beispiel

Eine Webapplikation soll eine Liste von Firmen verwalten. Die Applikation besteht aus Benutzersicht aus einer Tabelle, die keinen Bezug zu anderen Tabellen hat und es soll auch kein Fremdsystem geben. Daraus folgt, dass es 0 EIFs und 1 ILF gibt.

Die Webapplikation sehe wie folgt aus:

Die ungewichteten Funktionspunkte würden sich berechnen zu:

Komponente	Typ	DET	FTR	Komplexität	UFP
Externe Tabelle kommt nicht vor	EIF				0
Interne Tabelle	ILF			niedrig	7
Prozess "Firmen listen"	EO	3	1	niedrig	4
Prozess "Firma hinzufügen"	EI	10	1	niedrig	3
Prozess "Firma löschen"	EI	3	1	niedrig	3
Prozess "Firma ändern"	EI	10	1	niedrig	3
Prozess "Firma anzeigen"	EO	10	1	niedrig	4
Prozess "Bericht erstellen"	EQ	10+	1	niedrig	3
Summe Ungewichtete Funktionspunkte UFP					27

Die 27 ungewichteten Funktionspunkte könnten nun noch mit obigem Faktor multipliziert werden um final die Anzahl der Funktionspunkte zu erhalten.

COCOMO steht für Constructive Cost Model. Im Gegensatz zur Funktionspunktanalyse schätzt COCOMO den Aufwand. Es gibt verschiedene Verfahren:

a) Basic

Der Aufwand in Mannmonaten berechnet sich als a * (KLOC)^b, wobei KLOC 100 Codezeilen bedeuten. Die Faktoren a und b hängen von der Organisationsstruktur ab:

• Für kleine Projekte mit eingespielten Teams ("organic mode") betragen sie 2,4 und 1,05
• Für mittlere Projekte mit nicht homogenen Teams ("semi-detached mode") erhöhen sich die Faktoren zu 3,0 bzw. 1.12
• Schließlich werden die Werte für a und b für große Projekte mit starrer Struktur ("embedded mode") mit 3,6 und 1,2 angeben.

Alternativ zur Größenschätzung mit KLOC können auch die Funktionspunkte herangezogen werden. Für Java setzt man einen Funktionspunkt mit 35 LOC, bei C mit 150 LOC gleich.

 

b) Intermediate

Im intermediate Fall wird obiges Ergebnis noch mit einem "Effort Adjustment Factor" EAF multipliziert, der wiederum das Produkt von 15 Korrekturfaktoren ist. Diese Faktoren können Werte zwischen X und Y annehmen (TODO) und sind abhängig von

• Produkteigenschaften: Größe der Datenban, geforderte Verfügbarkeit, Komplexität
• Plattformeigenschaften: Begrenzung beim Hauptspeicher, Anforderung an Performance, geforderte Unabhängigkeit vom Betriebssystem, Möglichkeit des Austauschs von Hardwarekomponenten
• Personaleigenschaften: Erfahrung mit Programmiersprache, der Anwendung selbst und dem Betriebssystem; Fähigkeit der Programmierer und Qualifikation der Analysten
• Projekteigenschaften: Einsatz von Werkzeugen und modernen Programmierpraktiken, Einwicklungszeitplan

 

c) COCOMO II

COCOMO II zwei ähnelt dem vorherigen Typ, allerdings sind die EAFs ebenso von der Phase abhängig wie die Konstante a. Die Konstante b wird als Funktion von 5 Faktoren betrachtet:

1. Erfahrung mit ähnlichen Projekten
2. Flexibilität der Entwickler
3. Architekturrisiko
4. Teamzusammenhalt
5. Reifegrad des Entwicklungsprozesses

Je genauer Top-Down-Ansätze wie COCOMO das Ergebnis vorhersagen sollen, umso mehr Faktoren müssen berücksichtigt werden. Diese Faktoren müssen als Erfahrungswerte vorliegen, die spezifisch sind für das Projekt und die Organisation. Sie lassen sich schlecht von anderen Teams übernehmen.

So empfiehlt sich mehrere Schätzverfahren zu kombinieren und dabei die Top-Down-Ansätze mehr zu Projektbeginn und die Bottom-Up-Verfahren mehr im Verlauf des Projekts zu nutzen.

Ohne kontinuierliches Messen von Projektparametern (Teamgröße, Erfahrung, Produkteigenschaften, Technologie usw.) und den resultierenden Projektzeiten kann kein Lerneffekt erreicht werden kann. In einem fortwährenden Zyklus gilt es, Annahmen zu treffen, zu messen und die Annahmen zu verbessern.