Schätzung auf Basis empirischer Daten

Schätzung des Aufwands

Wie schon beschrieben, wird der Aufwand mittels der Maßeinheit Personenmonate bestimmt.

Der Aufwand ist also gerade die Zeit, die die Gesamtheit aller Projektmitarbeiter für dieses Projekt aufgewendet haben.

Bundschuh und Fabry nennen für die Ermittlung des Aufwandes unter zu Hilfenahme der ISBSG-Projektdatenbank folgende Daumenregel:

 

Durchschnitt (>300 Projekte)

Aufwand = 11,79 * FP0,898

3GL Projekte

Aufwand = 5,76 * FP1,062

4GL Projekte

Aufwand = 9,32 * FP0,912

 

Schätzung des Aufwands aus Basis der ISBSG-Projektdatenbank

Quelle: [BUNDSCHUH00], S. 138)

{FP = FP nach IFPUG}

Demnach würde beispielsweise der Aufwand für ein Projekt mit 100 FP sich folgendermaßen berechnen:

Aufwand in PM = 11,79 * 1000,898 = 737.

 

Schätzung der Produktivität

Neben dem Aufwand lässt sich auch für die Basisgröße Produktivität eine Daumenregel finden. Bundschuh und Fabry nennen auch hierfür eine Daumenregel, die auf der ISBSG-Projektdatenbank Release 5 basiert. In der folgenden Tabelle ist die Project Delivery Rate (PDR) auf Basis dieser Datenbank dargestellt:

 

Durchschnitt

PDR = 5,8 Stunden pro FP

3GL Projekte

PDR = 8,8 Stunden pro FP

4GL Projekte

PDR = 5,1 Stunden pro FP

 

Schätzung der PDR auf Basis der ISBSG-Projektdatenbank

Quelle: [BUNDSCHUH00], S. 138)

{FP = FP nach IFPUG}

Aus dieser PDR kann nun die Produktivität errechnet werden und zwar in FP pro Personenmonat. Dies geschieht, indem die Nettoarbeitsstunden pro Monat durch die PDR geteilt werden.

Bei Annahme von 120 Nettoarbeitsstunden pro Monat ergibt dies bei einer beispielsweise angenommenen PDR von 10 Stunden pro FP eine Produktivität von 12 FP pro Personenmonat.

FP / PM = Nettoarbeitsstunden pro Monat / PDR

(Vgl. [BUNDSCHUH00], S. 138-139).

Schätzung der Dauer

 

Neben dem Aufwand und der Produktivität lässt sich auch die Dauer mittels einer Daumenregel schätzen. Diese wird ebenfalls aus der ISBSG-Projektdatenbank Release 5 abgeleitet.

Demnach gelten folgende Gesetzmäßigkeiten:

 

 Durchschnitt (>300 Projekte)

Dauer= 0,80 * FP0,404

3GL Projekte

Dauer = 0,33 * FP0,559

4GL Projekte

Dauer = 1,11* FP0,342

 

Tabelle : Schätzung der Dauer auf Basis der ISBSG-Projektdatenbank

(Quelle: [BUNDSCHUH00], S. 140) {FP = FP nach IFPUG}

 

Durch Alain Abran et al. wurde aus der ISBSG-Projektdatenbank zusätzlich folgender Zusammenhang ermittelt:

Dauer = 0,662 * Aufwand0,328 ([BUNDSCHUH00], S. 140).

Weiterhin lassen sich auch andere Basisgrößen schätzen: Bundschuh und Fabry nennen hier die kostenoptimale Dauer nach Barry W. Boehm mit COCOMO. Für diese gilt folgender Zusammenhang (Vgl. [BUNDSCHUH00], S. 140):

  • für einfache Software-Projekte ergibt sich die optimale Dauer aus 2,5 * PM0,38,
  • für mittlere Software-Projekte aus 2,5 * PM0,35 und
  • für komplexe Software-Projekte gilt: Optimale Dauer = 2,5 * PM0,32.

Dem liegt die Annahme zu Grunde, dass ein Personenmonat aus 152 Arbeitsstunden besteht. Nun lässt sich daraus die optimale Anzahl der Mitarbeiter mit folgender Formel berechnen:

Optimale Anzahl der Mitarbeiter = 2,5 * PM0,32.

 

Schätzung der Terminwahrscheinlichkeit

 

Neben der Möglichkeit, Schätzungen unter zu Hilfenahme der ISBSG-Datenbank durchzuführen, werden häufig auch empirische Daten, die in zahlreichen Veröffentlichungen auftauchen, verwendet. Diese beruhen auf empirischen Erfahrungsdaten und können so sinnvolle Hilfestellungen geben, um beispielsweise die Terminwahrscheinlichkeit oder aber die Anzahl der Fehler in einem Softwareprogramm zu ermitteln. Für die Terminwahrscheinlichkeit kann sich folgende Tabelle als zweckmäßig erweisen: Quelle: [BUNDSHUH00], S. 219-220)

 

Wahrscheinlichkeit von Terminen (in %)

IFPUG FP

verfrüht

pünktlich

verspätet

abgebrochen

Summe

100

6,1

74,8

11,8

7,3

100

200

5,5

73,2

12,5

8,8

100

300

5,0

71,7

13,1

10,2

100

400

4,5

70,1

13,8

11,7

100

500

3,9

68,5

14,4

13,1

100

600

3,4

67,0

15,1

14,6

100

700

2,8

65,4

15,7

16,0

100

800

2,3

63,9

16,4

17,4

100

900

1,8

62,3

17,0

18,9

100

1000

1,2

60,8

17,7

20,3

100

1500

1,2

58,9

18,0

21,9

100

2000

1,1

57,1

18,4

23,4

100

2500

1,1

55,3

18,7

24,9

100

3000

1,0

53,5

19,0

26,5

100

3500

0,9

51,7

19,4

28,0

100

4000

0,9

49,9

19,7

29,6

100

4500

0,8

48,0

20,1

31,1

100

5000

0,8

46,2

20,4

32,6

100

5500

0,7

44,4

20,8

34,2

100

6000

0,6

42,6

21,1

35,7

100

6500

0,6

40,8

21,4

37,2

100

7000

0,5

38,9

21,8

38,8

100

7500

0,4

37,1

22,1

40,3

100

8000

0,4

35,3

22,5

41,9

100

8500

0,3

33,5

22,8

43,4

100

9000

0,3

31,7

23,1

44,9

100

9500

0,2

29,8

23,5

46,5

100

10000

0,1

28,0

23,8

48,0

100

Durchschnitt

1,7

52,2

18,7

27,4

100

 

 Tabelle : Schätzung der Terminwahrscheinlichkeit

Diese ursprünglich von Capers Jones stammende Tabelle wurde dabei von den Autoren geringfügig modifiziert.

Sie stellt den Zusammenhang der Basisgröße Terminwahrscheinlichkeit und der Anzahl der in einem Projekt verwendeten FP dar. So ist es möglich, in Abhängigkeit von FP festzustellen, mit welcher Wahrscheinlichkeit ein Projekt

  • verfrüht,
  • pünktlich oder
  • verspätet
  • fertig gestellt wird.

Zusätzlich lässt sich auch der prozentuale Anteil der abgebrochenen Projekte in Abhängigkeit von der Anzahl der verwendeten FP ermitteln. So kann beispielsweise für ein Software-Projekt mit 1.000 FP folgender Zusammenhang festgestellt werden:

Ein Software-Projekt mit 1.000 FP wird mit einer Wahrscheinlichkeit von 1,2 Prozent verfrüht, mit einer Wahrscheinlichkeit von 60,8 Prozent pünktlich und mit einer Wahrscheinlichkeit von 17,7 Prozent verspätet fertig gestellt. Mit einer Wahrscheinlichkeit von 20,3 Prozent wird es abgebrochen.

 

Demnach ergeben sich folgende Gesetzmäßigkeiten:

  • Die Wahrscheinlichkeit einer verfrühten Fertigstellung sinkt mit ansteigender FP-Anzahl.
  • Je höher die FP-Anzahl, desto geringer ist die Wahrscheinlichkeit der pünktlichen Fertigstellung.
  • Die Wahrscheinlichkeit, dass ein Software-Projekt Verspätungen aufweist, vergrößert sich mit der Anzahl der FP.
  • Je höher die FP-Anzahl, desto höher ist die Wahrscheinlichkeit eines Abbruchs des Projekts.

Der letzte Punkt ist im Hinblick auf die Höhe der Abbruchquote besonders interessant. Demnach werden immerhin 48 Prozent aller Projekte, bei denen 10.000 FP zum Einsatz kommen, abgebrochen.

Aber auch der zweite Punkt, die Wahrscheinlichkeit der pünktlichen Fertigstellung, ist interessant. So ist auch hier zu erkennen, dass bei einer FP-Anzahl von beispielsweise 10.000 FP die Wahrscheinlichkeit der pünktlichen Fertigstellung gerade einmal bei 28 Prozent liegt.

Demnach kann dieser Sachverhalt bei der Anwendung der Tabelle frühzeitig in die Projektplanung einbezogen werden und entsprechend in vertraglichen Vereinbarungen mit dem Auftraggeber des Projektes berücksichtigt werden, um so eventuelle Vertragsstrafen aufgrund der Verspätungen zu minimieren.

Die der Tabelle von Bundschuh und Fabry entnommenen Gesetzmäßigkeiten sind somit wichtig. Insbesondere für den Entscheidungsprozess, ob ein Projekt durchgeführt werden sollte oder nicht. Es ist nun mit relativ einfachen Mitteln möglich, das wirtschaftliche Risiko des Projektes abzuschätzen.

 

Schätzung der Fehleranzahl

 

Eine weitere Möglichkeit der Schätzung auf der Grundlage von funktionalen Größen ist die Ermittlung der Fehleranzahl. Diese Fehleranzahl ist außerordentlich interessant und von sehr großer Bedeutung. So stellen Bundschuh und Fabry unter anderem fest:

Ein durchschnittliches Projekt arbeitet etwa 80 % seiner Zeit an ungeplanter Behebung von Fehlern, die vorher im Projekt entstehen.“ ([BUNDSCHUH00], S. 222).

Der Planung der Fehlerbehebung kommt daher große Bedeutung zu. Um dieses Ziel sicherzustellen, muss die Anzahl der zu erwartenden Fehler im gesamten Software-Entwicklungsprozess im Vorfeld abgeschätzt werden.

Dazu haben Bundschuh und Fabry, basierend auf Veröffentlichungen von Capers Jones, folgende Tabelle veröffentlicht:

 

Software-Entwicklungsphase

Fehleranzahl pro IFPUG FP

Fachkonzept

1,00

Design

1,25

Codierung

1,75

Benutzerdokumentation

0,6

Fehlerbehebung

0,4

Gesamt

5,5

Fehlerpotentiale im Software-Entwicklungsprozess

(Quelle: [BUNDSCHUH00], S. 222)

 

Demnach kommt es beispielsweise in der Fachkonzeptphase zu einem Fehler pro FP und in der Codierungsphase sogar zu 1,75 Fehlern pro FP.

Die geringsten Fehlerzahlen pro FP treten bei der Fehlerbehebung (0,4 Fehler/FP) und in der Benutzerdokumentation mit 0,6 Fehlern pro FP auf.

Insgesamt generiert somit ein FP im Schnitt 5 Fehler. Bundschuh und Fabry kommen darauf aufbauend zu folgendem Schluss:

Das führt bei einer üblichen Fehlerbehebungsrate von 85 % dazu, dass das fertige Software-Produkt mit 0,75 Fehlern pro Funktion Point an den Endbenutzer ausgeliefert wird.“ ([BUNDSCHUH00], S. 222).

Die Schätzung der Fehleranzahl von Software-Produkten mittels Function Points stellt daher eine interessante Möglichkeit dar, die Qualität einer Software im Hinblick auf die Fehleranzahl zu beurteilen, um frühzeitig hierdurch andere Basisgrößen wie beispielsweise den zu erwartenden Wartungsaufwand abzuschätzen.

Es scheint daher sinnvoll zu sein, die Funktionalität der Abschätzung der Fehleranzahl in das zu modellierende FSeMP zu integrieren.

 

 

[Willkommen] [Wirtschaft] [Informatik] [Bücher] [Impressum]

Copyright (c) 2012 Dipl.-Wirt.-Inform. Dennis A. Winkler, Stand: 02.07.2012
Diese Website ist unter folgenden URLs zu erreichen:
http://www.dennis-winkler.de  -  http://www.winkler-boerse.de