25. Grundlagen der Software-Kostenkalkulation Methoden der Aufwandsabschätzung, Kosten

1. 25. Grundlagen der Software-KostenkalkulationMethoden der Aufwandsabschätzung, Kosten Einflußfaktoren der Aufwandsschätzung Die Entwicklung eines Software-Produktes soll wirtschaftlich sein. Die Art der Wirtschaftlichkeit hängt davon ab, ob ein Software-Hersteller für einen anonymen Markt Produkte entwickelt oder ob ein Produkt für einen bestimmten Auftraggeber hergestellt wird. Bei der Entwicklung eines Standard-Produktes für den anonymen Markt, ist es Aufgabe des Marketings, die potentiellen Absatzchancen abzuschätzen und einen marktgerechten Preis festzulegen. Die Wirtschaftlichkeit des Produkts ergibt sich aus folgender Gleichung: Gewinn(Verlust) = Deckungsbeitrag * geschätzte Menge - einmalige Entwicklungskosten mit Deckungsbeitrag = Preis - laufende variable Kosten, wobei der Anfall der Zahlungen zu unterschiedlichen Zeitpunkten aus Vereinfachungsgründen unbeachtet bleibt.

2. Wird ein Produkt für einen individuellen Auftraggeber hergestellt, dann müssen auf der Seite des Auftragnehmers nur die Kosten ermittelt werden. Kosten plus Gewinnspanne ergeben dann den Verkaufspreis. Jeder Käufer eines Produkts muß für sich selbst eine volle Wirtschaftlichkeitsrechnung durchführen, um die Wirtschaftlichkeit des Produkteinsatzes zu ermitteln. Aus der Sicht des Software-Herstellers bzw. Auftragnehmers werden die Kosten eines Software-Systems im wesentlichen durch die Entwicklungs-kosteneinschließlich der Lizenzkosten für zugekaufte Softwarekompo-nenten bestimmt. Den Hauptanteil der Entwicklungskosten bilden die Personalkosten. Die zweite, weit geringere Kostengröße ist die anteilige Umlegung der CASE-Umgebungskosten (einschließlich Hardware und Systemsoftware) für die Produktentwicklung.

3. Um die Entwicklungskosten schätzen zu können, wurden Methoden zur Kosten- und Terminschätzung entwickelt. Die meisten Modelle basieren auf dem geschätzten Umfang des zu erstellenden Software-Produkts in „Anzahl der Programmzeilen“ bzw. in Lines of Code (LOC) Bei höheren Programmiersprachen werden z.B. alle Vereinbarungs- und Anweisungszeilen (ohne Kommentare) geschätzt, bei der Assembler-Programmierung entspricht eine Zeile einer Anweisung oder einer Datendefinition. Im einfachsten Fall wird dann der geschätzte Umfang durch einen Erfahrungswert für die Programmier-Produktivität (in LOC) eines Mitarbeiters pro Jahr oder Monat geteilt. Daraus erhält man einen geschätzten Aufwand in Mitarbeiterjahren (MJ) oder Mitarbeitermonaten (MM) bzw. Personalmonaten (PM). Um Urlaubs- und sonstige Fehlzeiten sowie Schulungszeiten zu berücksichtigen, wird i.a. ein Mitarbeiterjahr neun oder zehn Mitarbeitermonaten gleichgesetzt.

4. Wird der so ermittelte Aufwand noch durch die nach der Terminvorgabe zur Verfügung stehende Entwicklungszeit geteilt, dann erhält man theoretisch die Zahl der für die Entwicklung einzusetzenden, parallel arbeitenden Mitarbeiter. Empirische Untersuchungen der Firma „Hewlett-Pachard“ haben zu folgender „Faustregel“ geführt. Eine durchschnittliche Software-Entwicklung liefert ungefähr 350 Quellcodezeilen (ohne Kommentare) pro Ingenieurmonat. Dabei umfaßt die Ingenieurzeit alle Phasen von der Definition bis zur Implementierung. Beispiel: Es soll ein Software-Produkt mit geschätzten 21.000 LOC realisiert werde. Beträgt die durchschnittlich Produktivität pro Mitarbeiter 3.500 LOC/Jahr, dann werden 6 Mitarbeiter zur Erstellung benötigt. Arbeiten 3 Mitarbeiter im Team zusammen, dann werden zwei Jahre bis zur Fertigstellung benötigt. Eine einfache Methode ist:

5. Die Reduktion des Schätzmodells auf die Faktoren Produkt-Umfang und Mitarbeiterproduktivität stellt ein sehr grobes Raster dar. Hinzu kommt, daß selbst diese Faktoren unsicher sind. Bei kleineren Projekten und vertrautem Anwendungsgebiet sind solche Schätzungen noch hinreichend genau, bei größeren Projekten und neuartigen Produkten sind sie sehr problematisch. Ursprünglich wurde angenommen, daß die Mitarbeiter-Produktivität im Software-Bereich konstant ist. Untersuchungen zeigten jedoch eine große Produktivitäts-Bandbreite in Abhängigkeit vom Software-Technik-Niveau der Firma, von den individuellen Fähigkeiten und der Problemkomplexität. Diese vielfältigen Einflußfaktoren führen zu beträchtlichen statistischen Schwankungen der individuellen Mitarbeiterleistung. Um zu quantitativen und fundierten Ansätzen zu gelangen, wurden bis heute ungefähr 20 Modelle zur Aufwandsabschätzung von Software entwickelt. Sie verwenden unterschiedliche Parameter zur Kosten- und Terminschätzung.

6. Die Faktoren, die einen Einfluß auf die Schätzung haben, lassen sich zu vier Faktorengruppen zusammenfassen: Quantität, Qualität, Entwicklungsdauer und Kosten. Diese Gruppen stehen für die Ziele der Software-Entwicklung. Ihre gegenseitige Wechselwirkung läßt sich durch das sogenannte Teufelsquadrat quantitativ veranschaulichen. Die an den 4 Ecken angetragenen Ziele konkurrieren um die verfügbare Produktivität, die durch die Fläche des inneren Vierecks dargestellt wird. Diese Produktivität ergibt sich aus der Produktivität des eingesetzten Entwicklungsteams. Die begrenzte Größe des Teams spiegelt die begrenzten Personal-Ressourcen wider, die für eine Entwicklung zur Verfügung stehen. Daraus ergibt sich auch eine begrenzte Produktivität - symbolisiert durch die konstante Fläche des Vierecks. Man kann das Viereck zwar in die eine oder andere Richtung strecken, muß dann aber einen geringeren Zielerfüllungsgrad auf der anderen Seite hinnehmen. Einflußfaktoren

7. Soll die Qualität eines zu entwickelndes Produktes erhöht und gleichzeitig die Entwicklungsdauer verkürzt werden, dann muß der Produktionsumfang reduziert werden. Gleichzeitig steigen die Entwicklungskosten. Teufelsquadrat (nach Sneed) Qualität Quantität + + 1 Produktivität a - - b + + c d 2 - - Entwicklungsdauer Kosten

8. Quantität Die Quantität eines Software-Produktes läßt sich durch seine Größe, seinen Umfang und seine Komplexität charakterisieren. Die Größe wird oft durch das Maß „Anzahl Programmierzeilen“ (LOC) angegeben. Das Quantitätsmaß LOC ist als problematisch anzusehen, da einseitig die Implementierungsphase betont wird und eine exakte Definition einer Programmzeile - insbesondere unabhängig von einer Programmiersprache - schwierig ist. Als Quantitätsmaß besser geeignet ist der Funktions- und Daten-Umfang eines Software-Produktes. Der Funktions- und Daten-Umfang eines neuen Produktes wird schon sehr frühzeitig definiert (Planungs- und Definitionsphase), so daß eine frühzeitige Schätzung möglich ist. Außerdem ist dieses Maß unabhängig von einer Programmiersprache.

9. Um noch mehr Einflußfaktoren zu berücksichtigen, werden in die Schätzmodelle oft spezielle Komplexitätsmaße integriert, die z. B. die Anzahl der Schnittstellen, die Anzahl und Zusammensetzung der Daten usw. bewerten. Maße können sein: „leicht“, „mittel“, „schwer“ oder die Noten von 1 bis 6. Qualität Die für ein zu erstellendes Produkt geforderten Quälitätsziele beeinflussen ganz wesentlich den Entwicklungsaufwand. Je höher die Qualitätsanforderungen sind, desto größer ist der Aufwand. Es gibt nicht die Qualität, sondern es gibt verschiedene Qualitätsmerkmale. Jedem Qualitätsmerkmal lassen sich Kennzahlen zuordnen. In einer Qualitäts-Zielbestimmung werden Qualitäts-Stufen für die Kennzahlen festgelegt, z.B. normale Zuverlässigkeit, gute Änderbarkeit und gute Benutzbarkeit.

10. Die Entwicklungsdauer beeinflußt den Aufwand in folgender Form: Soll die Zeit verkürzt werden, dann werden mehr Mitarbeiter benötigt. Mehr Mitarbeiter erhöhen den Kommunikationsaufwand innerhalb des Entwicklungsteams. Der höhere Kommunikationsanteil jedes Mitarbeiters reduziert seine Produktivität. Kann dagegen die Entwicklungsdauer verlängert werden, dann werden weniger Mitarbeiter benötigt und der Kommunikationsanteil sinkt. Die Produktivität jedes Mitarbeiters steigt. Der Kommunikationsaufwand läßt sich grob berechnen: t ~ 1/n Entwicklungsdauer n2 n (n-1) t ~ 1/n + k = 1/n + k 2 ~ 1/n + k (n2 / 2)

11. t n 3 Abb.: Großer Kommunikationsaufwand Anzahl der Mitarbeiter Optimale Entwicklungsdauer = 2,5 * (Aufwand in MM)s mit s = 0,38 für Stapel-Systeme s = 0,35 für Online-Systeme s = 0,32 für Echtzeit-Systeme Es wird geschätzt, daß der Entwicklungsaufwand für ein neues Online-System neun Mitarbeiter-Monate beträgt. Als optimale Entwicklungsdauer ergibt sich: Dauer = 2,5 * 9 0,35 = 5,3 Monate, die durchschnittliche Größe des Entwicklungsteams beträgt: Anzahl der Mitarbeiter = 9 MM / 5,3 Monate = 1,7  2

12. Die Produktivität wird von vielen verschiedenen Faktoren beeinflußt. Ganz wesentlich wirken sich die Lernfähigkeit und die Motivation der Mitarbeiter sowie die Firmenstruktur auf die Produktivität aus. Basismethoden der Aufwandsschätzung Die meisten Schätzmethoden beruhen auf einer oder mehreren Basismethoden. Diese umfassen u.a.: Die Analogiemethode Der Aufwand wird durch Vergleich der zu schätzenden Entwicklung mit bereits abgeschlossenen Produkt-Entwicklungen anhand von Ähnlichkeitskriterien bestimmt. Als Ähnlichkeiten können verwendet werden: gleiches oder ähnliches Anwendungsgebiet, gleicher oder ähnlicher Produktumfang, gleicher oder ähnlicher Komplexitätsgrad, gleiche Programmiersprache usw. Produktivität

13. Software-Entwicklungen, die in erster Linie vorhandene Software wiederverwenden, benötigen nur ungefähr 1/4 der Zeit und der Ressourcen von Neuentwicklungen. Beispiel: Ein Software-Haus ist auf die Erstellung von Compilern spezialisiert. Für die Entwicklung eines Pascal-Compilers wurden 20 MM benötigt. Um einen neu zu entwickelnden Modula-2-Compiler zu schätzen, wird untersucht, welche anderen und zusätzlichen Sprachelemente Modula-2 gegenüber Pascal enthält und wie komplex diese Konstrukte sind. Es wird ermittelt, daß 20% neue Konstrukte hoher Komplexität in Modula-2 enthalten sind. 50% des Pascal-Compiler-Codes können in leicht modifizierter Form wiederverwendet werden, 50% des vorhandenen Codes müssen völlig überarbeitet werden, was praktisch einer Neuentwicklung entspricht. Faustregel:

14. - 50 % leicht modifiziert: 1/4 von 10 MM = 2,5 MM - 50 % völlige Überarbeitung: 10 MM - 20 % zusätzliche Neuentwicklung hoher Komplexität: 4 MM * 1,5 (Komplexitätszuschlag) = 6 MM Anhand dieser Analogschätzung ergibt sich für den Modula-2-Compiler ein Aufwand von 18,5 MM Bewertung: Die Nachteile der Analogiemethode sind: - intuitiv, globale Schätzung aufgrund individueller Erfahrungen, - fehlende allgemeine Vorgehensweise, - fehlende Nachvollziehbarkeit einer Schätzung. Es ergibt sich daher folgende Schätzung:

15. Ähnlich wie bei der Analogiemethode wird das zu schätzende Produkt direkt mit ähnlichen Entwicklungen verglichen. Im Gegensatz zur Analogiemethode erfolgt die Aufwandsanpassung im Rahmen einer formalisierten Vorgehensweise. Für die Aufwandsanpassung stehen Faktorenlisten und Richtlinien zur Verfügung, wie diese zu berücksichtigen sind. Beispiel: Den Faktoren Programmiersprache, Programmiererfahrung und Dateiorganisation lassen sich folgende Werte zuordnen (nach Heilmann): Die Relationsmethode Programmiersprache Programmiererfahrung PL/1 = 100 5 Jahre = 80 COBOL = 120 3 Jahre = 100 ASSEMBLER = 140 1 Jahr = 140 Dateiorganisation sequentiell = 80, indexsequentiell = 120 Für eine Schätzung erfolgt eine produktspezifische Bewertung der Faktoren. Außerdem wird die quantitative Auswirkung auf den Aufwand anhand von Richtlinien ermittelt.

16. Ein neues Produkt soll in PL/1 realisiert werden. Das Entwicklungsteam hat im Durchschnitt drei Jahre Programmiererfahrung. Es ist eine indexsequentielle Dateiorganisation zu verwenden. Zum Vergleich wird eine Entwicklung herangezogen, die in Assembler programmiert wurde, eine sequentielle Dateiorganisation verwendet und von einem Team mit 5 Jahren Programmiererfahrung erstellt wurde. Geht man davon aus, daß alle drei Faktoren den Aufwand gleichgewichtig beeinflussen, dann ergibt sich folgende Kalkulation: - ASSEMBLER zu PL/1: 140 : 100 = 40 Punkte Einsparung - 5 Jahre zu 3 Jahre: 80 : 100 = 20 Punkte Mehraufwand - sequentiell zu indexsequentiell: 80 : 120 = 40 Punkte Mehraufwand. Für das neue Produkt ergibt sich ein Mehraufwand von 20 Punkten. Anhand von Richtlinien werden diese Punkte dann in prozentuale Aufwandszuschläge umgerechnet. Beispiel zur Relationsmethode:

17. Das zu entwickelnde System wird soweit in Teilprodukte zerlegt, bis jedem Teilprodukt ein bereits feststehender Aufwand zugeordnet werden kann (z.B. Line of Code LOC). Der Aufwand pro Teilprodukt wird meist durch Analyse vorhandener Produkte ermittelt. Oft werden auch Teilprodukte bestimmten Kategorien zugeordnet wie - Steuerprogramme, - E/A-Programme, - Datenverwaltungsroutinen, - Algorithmen usw. Die Anzahl der Teilprodukte, die einer Kategorie zugeordnet sind, wird mit dem Aufwand dieser Kategorie multipliziert. Die erhaltenen Werte für eine Kategorie werden dann addiert, um den Gesamtaufwand zu erhalten. Die Multiplikator-Methode wird auch „Aufwand-pro-Einheit-Methode“ genannt. Die Multiplikatormethode

18. Die Aufteilung eines zu schätzenden Produkts in Teilprodukte hat folgendes ergeben: Beispiel zur Multiplikatormethode: Kategorie Anzahl Summe Aufwands- LOC Teilprodukte LOC faktor bewertet Steuer- 1 * 500 (LOC) 500 1,8 900 programm E/A-Programme 1 * 700 + 2* 500 1700 1,5 2550 Datenverwaltung 1 * 800 + 2* 250 1300 1,0 1300 Algorithmen 1 * 300 + 5 +100 800 2,0 1600 Summe 6350 Die errechneten, bewerteten LOC werden dann anhand von Erfahrungswerten in MM umgerechnet.

19. Zunächst werden Faktoren festgelegt, die für die Schätzung relevant sind. Sie sind subjektiv (z.B. Qualifikation des Personals) oder objektiv (z.B. verwendete Programmiersprache) zu bewerten. Den Faktorausprägungen sind Werte zugeordnet. Die Werte aller Faktoren werden nach einer vorgegebenen mathematischen Formel verknüpft und ergeben dann dem Gesamtaufwand. Die Methode der parametrischen Gleichungen Durch Korrelationsanalysen wird ermittelt, welche Faktoren welchen wertmäßigen Einfluß auf den Gesamtaufwand haben. Solche Analysen müssen mit einer großen Anzahl von abgeschlossenen Entwicklungen und einer Vielzahl von Faktoren durchgeführt werden. Die Faktoren, die die höchste Korrelation besitzen, werden zu einer Gleichung zusammengefaßt. Der zu jedem Faktor gehörende Koeffizient repräsentiert die Stärke des Einflusses auf den Gesamtaufwand. Die Gewichtungsmethode

20. Der Aufwandsfaktor im vorherigen Beispiel repräsentiert den Einfluß des jeweiligen Faktors auf den Gesamtaufwand. Als Gleichung würde sich ergeben: LOC bewertet = LOC Steuerprogramme * 1,8 + LOC E/A-Programme*1,5 + LOC Datenverwaltung * 1,0 + LOC Algorithmen * 2 Bewertung: Es ist eine umfangreiche, empirische Datensammlung und -auswertung erforderlich, um die zu berücksichtigenden Faktoren unternehmensspezifisch zu bewerten. Die Koeffizienten müssen permanent überprüft werden, um den technischen Fortschritt zu berücksichtigen.

21. Aus abgeschlossenen Entwicklungen wird ermittelt, wie der Aufwand sich auf die einzelnen Entwicklungsphasen verteilt hat. Bei neuen Entwicklungen schließt man entweder eine Phase zunächst vollständig ab und ermittelt aus dem Ist-Aufwand dann anhand der Aufwandsverteilung den Soll-Aufwand für die restlichen Phasen. Oder man führt eine detaillierte Schätzung einer Phase durch und schließt hieraus dann auf den Gesamtaufwand. Die Firma Bertelsmann hat die in der Abbildung dargestellte Aufteilung nach der Einführung von modernen Methoden und Werkzeugen erhalten. Die Prozentsatzmethode Entwurf 30 % Definition 30 % Andere Firmen haben Ergebnisse erhalten, die um plus oder minus 10 Prozent variieren. Test 20 - 25 % Codierung 15 - 20 %

22. Die Prozentsatzmethode kann bereits frühzeitig eingesetzt werden, wenn der Aufwand für mindestens eine Phase durch den Einsatz einer anderen Methode bestimmt wurde. Zusammenfassend kann gesagt werden, daß eine der aufgeführten Basismethoden allein nicht ausreichend ist. Je nach Zeitpunkt und Kenntnis von aufwandsrelevanten Daten sollte die eine oder andere Methode eingesetzt werden. Für frühzeitige, grobe Schätzungen müssen die Analogie-, Relations- und Prozentsatzmethode eingesetzt werden. Wenn die Einflußfaktoren während der Entwicklung besser bekannt sind, dann sollten die genaueren Methoden, wie die Gewichtungs- oder Multiplikationsmethode oder die Methode der parametrischen Schätzgleichungen Verwendung finden. Bewertung: