COCOMO COnstructive COst MOdel

Transkript

1 Universität Salzburg Institut für Computerwissenschaften PS Software Engineering II Leitung: Mag. Maurutschek Seminararbeit COCOMO COnstructive COst MOdel Donnerstag, den (SS 2002) Klaus Werdenich ( )

2 Inhaltsverzeichnis 1 Einleitung - Abgrenzung der Themenstellung 3 2 cost estimation - Das Fundament jedes Softwareprojekts Kostenverteilung eines Projekts Gründe für genaues Kostenschätzen? Zeilen der Warnung Schritte bis zum eigenen Aufwandabschätzungsmodell Die Kostenfaktoren - Cost Drivers Wie groß wird mein Projekt? - Size Estimation Das Aufwandabschätzungsmodell Ansätze der Kostenabschätzung für Softwareprojekte 11 4 Grundlegendes - der COCOMO Prolog Nützliches - Metriken Allgemeine Einführung zu COCOMO COCOMO - constructive cost model Die Geschichte - wie es dazu kam Der Mann hinter COCOMO - Barry W. Boehm Die Intention für COCOMO - der SE Ansatz Das COCOMO Die drei Projektmodi - Deklaration der Größe und Art des Projekts Verteilung des Aufwands und der verfügbaren Zeit auf die Entwicklungsphasen bei Softwareprojekten Die drei Berechnungsverfahren Basic COCOMO - das grobe Berechnungsverfahren Intermediate COCOMO - das verfeinerte Berechnungsverfahren Detailed COCOMO - das präziseste Berechnungsverfahren Kostenabschätzung heute - Aufbruch in eine neue (Kostenschätzungs-) Welt Veränderungen im Software Engineering Die Grenzen der alten Software Kostenabschätzungsverfahren COCOMO II Strategie und Ziele Softwareengineering heute - auf dem Marktplatz Marktdifferenzierung - Für wen kann COCOMO II nützlich sein? Die 3 Submodelle Aufwandberechnung

3 7.4.1 Skalen Effekte - Skalenfaktoren Effort Multiplier Time To Develop (TDEV) Anpassen und Wiederverwerten von Code Kalibrierung COCOMO II in der Praxis Vergleich COCOMO 81 bis COCOMO II 39 9 Literatur Anhang - Fragenblock 41 2

4 1 Einleitung - Abgrenzung der Themenstellung Das Ziel dieser schriftlichen Ausführung zum Thema COnstructive COst MOdel (COCOMO) - cost estimation model im Zuge der Lehrveranstaltung Software Engineering II, ist in erster Linie die Präsentation des COCOMO. Weiters soll auf den Themenkomplex cost estimation allgemein eingegangen werden, wobei primär die Absicht darin besteht plausibel zu machen, warum eine Kostenabschätzung von derart immanenter Bedeutung ist. Folgend eine kurze Erläuterung der veschiedenen Ansätze, die für Kostenabschätzungen von Software Projekten bestehen. Schließlich im Zentrum der Ausführungen wird das COCOMO näher betrachtet. Seine Intention, was es ist, wie es dazu wurde und woher es kam. Der nächste große Abschnitt wird die Software - Kostenabschätzung heute zum Inhalt haben. Hier wird auf die Veränderung der Softwareentwicklung seit COCOMO 81 näher eingegangen, der Marktplatz Software Engineering, wie er sich derzeitig präsentiert, beleuchtet, und die Gründe, warum eine neue Generation der Software - Kostenabschätzung notwendig ist - COCOMO 81 nicht mehr funktioniert. Der Vertreter dieser neuen Software-Kostenabschätzungs- Generation ist COCOMO II. Die Betrachtung des COCOMO II, dem Kostenabschätzungs Werkzeug für heute und morgen, wird den Blick in die Gegenwart abschließen. Diese Arbeit wird eine Gegenüberstellung der COCOMOs (COCOMO 81 bis COCOMO II) beenden, die auch Ada COCOMO mit einschließt. Eine nähere Betrachtung von Ada COCOMO, sowie alternativer Kostenabschätzungsmodelle, sieht diese Version der Arbeit, in ihrem Wesen als Seminararbeit, aus Gründen der, bereits in der aktuell vorliegenden Form überschrittenen, Soll Anzahl an Seiten nicht vor. Aus dem selben Grund ist die Behandlung von COCOMO II, im Vergleich zu COCOMO 81 sehr bescheiden. 2 cost estimation - Das Fundament jedes Softwareprojekts Zu Beginn eines Softwareprojekts stehen folgende Fragen: Wie hoch ist der gesamte Arbeitsaufwand für das Projekt? Wie viele Monate wird das Projekt dauern? Wie viele Mitarbeiter benötige ich für das Projekt? Was kostet das Projekt insgesamt? Diese Fragen gilt es möglichst präzise zu beantworten, und dies zu einem Zeitpunkt zu dem präzise Informationen noch nicht verfügbar sind. Eine detaillierte Anforderungsanalyse, die diese 4 Fragen beantworten kann, scheitert primär an der geringen Zeitspanne, die bis zur Frist der Angebotsabgabe festgelegt wird. Ein weiterer Punkt, der eine ausführliche, und gewissenhafte Analyse der Notwendigkeiten für das ausgeschriebenen Projekt problematisch gestaltet ist der dadurch entstehende Aufwand. Dennoch muss innerhalb kürzester Zeit eine 3

5 möglichst genaue Schätzung erfolgen um ein Angebot unterbreiten zu können. Dies geschied mit Hilfe einer Kostenschätzung, die sich nicht auf die Beantwortung jede Frage im Einzelnen konzentriert, sondern sich die Abhängigkeit dieser zu Nutze macht und eine komplette Schätzung, die alle vier Fragen beantwortet, zum Ergebnis hat. 4x Relative Size Range 2x 1.5x 1.25x x Completed Programs USAF/ESD Proposals Size (SLOC) Cost ($) 0.5x 0.25x Concept of Rqts. Operation Spec. Feasibility Plans and Rqts. Product Design Product Design Spec. Detail Design Detail Design Spec. Devel. and Test Accepted Software Phases and Milestones Figure 2. Software Costing and Sizing Accuracy vs. Phase Grafik 1 zeigt die Größenordnung der möglichen Fehlschätzung zur jeweiligen Projektphase coarse-grained 2.1 cost Kostenverteilung driver information eines the Projekts early project stages, and increasingly fine-grained information in later stages. Consequently, COCOMO 2.0 does not produce point estimates of software cost and effort, but rather range estimates tied to the degree of definition of the estimation In einem Softwareprojekt entstehen drei verschiedene Arten von Kosten: inputs. The uncertainty Hardwarekosten ranges (z.b.: in Figure die Rechner 2 are used am Arbeitsplatz as starting der points Mitarbeiter, for these spezielle Peripheriegeräte) estimation ranges. With respect to process strategy, Application Generator, System Integration, and Infrastructure software projects Spesen will und involve Schulungskosten a mix of three (z.b.: major wenn process der Sitz models. des Kunden The appropriate sehr weit sequencing of these models will weg depend ist oder on die the Mitarbeiter project s immarketplace Umgang mitdrivers neuen Anforderungen and degree of konfrontiert werden (z.b.: Programmiersprache)) product understanding. The Application Personalkosten Composition (Effortmodel costs) involves prototyping efforts to resolve potential high-risk issues such as user interfaces, software/system interaction, performance, or technology maturity. Die Hardwarekosten verändern sich nicht in großem Maß, deshalb können sie als The costs Fixkostenpunkt of this type of bezeichnet effort are werden. best estimated Spesen und by Schulungskosten the Applications sind Composition zwar nicht model. The Early konstant, Design allerding model spielen involves sie imexploration gesamten Kostenaufkommen of alternative software/system des Projekts einearchitectures and concepts of operation. At this stage, not enough is generally known to support fine-grain cost estimation. The corresponding COCOMO 2.04capability involves the use of function points and a small number of additional cost drivers. The Post-Architecture model involves the actual development and maintenance of a software product. This model proceeds most cost-effectively if a software life-cycle architecture has been developed; validated with respect to the system's mission, concept of operation, and risk; and established as the framework for the product. The corresponding COCOMO 2.0 model has about the same granularity as the previous COCOMO and Ada COCOMO models. It uses source instruc-

6 sehr kleine Rolle. Deshalb besteht eine Kostenschätzung fast ausschließlich aus einer Schätzung der Personalkosten. Dafür ist von Bedeutung eine Schätzung über den Gesamtaufwand, die Zahl der Mitarbeiter und die Gesamtdauer des Projekts vorliegen zu haben. Für eine erfolgreiche Kostenschätzung ist also die Beantwortung der ersten 3 Fragen notwendig, da aus diesen Informationen der vierte Punkt, die Projektkosten, folgendermaßen errechnet werden können: Kosten = Hardware + Spesen und Schulung + Stundenlohn * Gesamtaufwand. 2.2 Gründe für genaues Kostenschätzen? Warum ist ein genaues Schätzen der mit einem (Software)Projekt verbundenen Kosten von Wichtigkeit? Die Genauigkeit der Schätzungen sind wichtig für das Ansehen eines Unternehmens am Markt. Da das zu stellende Angebot unmittelbar abhängig von der Schätzung ist, haben zu hohe Schätzungen zur Folge, dass das Unternehmen als teuer gilt. Fällt das Angebot zu billig aus, gewinnt man sicher mehr Ausschreibungen, aber die zusätzlichen Kosten müssen entweder vom Kunden oder von der Softwarefirma übernommen werden. Diese Frage der Kostenübernahme führt oft zu einem Gerichtsverfahren, was auch kein gutes Licht auf die Softwarefirma wirft. Falsche - in diesem Fall zu hohe Schätzungen haben weiters zur Folge, dass wohl nur wenige Ausschreibungen gewonnen werden. Für den Zeitplan eines Projekts muss dessen Gesamtaufwand und die Dauer feststehen. Das heißt, eine Kostenschätzung sollte die Basis jedes Projektplans sein. Der Projektplan wiederum ist Grundlage für das ingenieurmäßige Erstellen von Software. Da während des laufenden Projekts die Kostenschätzung aktualisiert wird ergibt sich ein weiterer Vorteil für die Projektsteuerung. Treten in einer Phase des Projekts Schwierigkeiten auf und wird die vorgegebene Zeit überschritten, kann damit gerechnet werden, dass sich die Gesamtdauer des Projekts um diese Zeitspanne verlängert. Somit kann frühzeitig auf die veränderten Situation eingegangen werden und Folgen wie einem verzögertem Auslieferungstermin eventuell entgegengewirkt werden. Weitere Folgen wie der Druck, eines nicht einzuhaltenden Fertigstellungstermin in Folge einer falschen Kostenschätzung, belastet auch das Arbeitsklima innerhalb des Unternehmens und kann zu Spannungen mit der Führungsetage führen. 5

7 2.3 Zeilen der Warnung Die Software Kosten- und Aufwandsabschätzung ist keine exakte Wissenschaft, weil sich zu viele Einflussfaktoren wie die Technik, die Arbeitsumgebung, die Personen selbst und natürlich die Politik von vornherein nicht konstant rational verhalten. Dies kann zu einem unvorhergesehenen Kostenanstieg oder einem nicht einplanbaren Mehraufwand führen - oder am wahrscheinlichsten zu beidem. Es ist zu bedenken, dass die Kostenabschätzung für Zeilen Code nicht vergleichbar ist mit der Kostenabschätzung der Produktion von Klappstühlen Gründe dafür sind unter anderem: Elementare Anweisungen (DSI) sind keine Fließbandware - ganz abgesehen davon, dass das Produkt nicht über die Anzahl an elementaren Anweisungen an Qualität gewinnt, oder das gewünschte Produkt ausmacht. Das Schreiben von Software benötigt neben der Kreativität der Programmierer auch deren Kooperation - ein Faktor, der von vornherein nur äußerst schwer einschätzbar ist. Für die Abschätzung von Softwareprojekten kann man erst auf vergleichsweise bescheidene Erfahrungswerte zurückgreifen. Es fehlt die Quantität an dokumentierten Experimenten an Hand derer Synergien hergestellt werden können. Heute betrachtet man ein Software Kostenabschätzungsmodell als gut einsetzbar, wenn es die tatsächlichen Softwareentwicklungskosten mit einer Toleranz von 20% korrekt angibt - in 70 % der Fälle. Vorausgesetzt es wird für das Projekt das richtige Modell gewählt. Das Intermediate und das Detailed COCOMO, die noch ausführlich besprochen werden, entsprechen diesen Vorgaben Schritte bis zum eigenen Aufwandabschätzungsmodell Die Interessen eines Unternehmens sind am besten aufgehoben, wenn sie selbst ihr eigenes Aufwandsabschätzungsmodell entwickelt Das hier präsentierte Modell bietet einen generellen Ansatzpunkt - firmenspezifische Daten müssen allerdings darüber hinaus entsprechend festgelegt werden. Für die Entwicklung eines Aufwandsabschätzungsmodell müssen diese 6 Schritte vollzogen werden. 1. Es muss eine Liste über potentielle / wichtigste Aufwandskosten (cost drivers) festgelegt werden 2. Für jeden Aufwand- und Kostenfaktor muss ein skalierendes Modell festgelegt werden. 3. Ein Aufwandsabschätzungsmodell ist auszuwählen. 6

8 4. Das Projekt gilt es zu bewerten, abzuschätzen und die Teilprojekte untereinander zu vergleichen. 5. Die Qualität der Abschätzung ist an Hand von Projekten aus der Geschichte zu evaluieren. 6. Das Modell gehört in festgeschriebenen Intervallen entsprechend angepasst und bewertet Die Kostenfaktoren - Cost Drivers Bei der Schätzung der Projektkosten gilt es die wichtigsten Kostenfaktoren (cost drivers) besonders zu betrachten. Zu diesen zählen die Variablen, die, die Anzahl der, für das Projekt aufzuwendenden Säcke an Geld, beeinflussen. Diese Kostenfaktoren können von Projekt zu Projekt variieren. Die Gewichtung des einzelnen Kostenfaktors hängt weitgehend von dem verwendetem Aufwandsabschätzungsmodell ab. Der für das COCOMO Modell zentrale Kostenfaktor ist die Größe des Softwareprodukts - der weitgehend als einer der wichtigsten cost drivers zählt. Aus diesem Grund eine nähere Betrachtung. Welche Bedeutung hat die Größe eines Softwareprodukts? Sie ist wie bereits erwähnt einer der bedeutendsten Kostenfaktoren bei der Entwicklung von Software. Sie ist das schwächste Glied der Abschätzungsprozesskette. Es benötigt ihrer Extrabetrachtung, wenn eine Organisation ihr eigenes Aufwandsabschätzungsmodell entwickelt Wie groß wird mein Projekt? - Size Estimation Function Points (FPs) ist eine Metrik, die von Albrecht und Gaffney entwickelt wurde. Damit man Function Points zur Schätzung von Softwareprojekten verwenden kann, werden sogenannte historische Daten benötigt. Das heißt es müssen bei vergangenen Projekten, von denen Aufwand und Dauer bekannt sind, die Function Points gezählt werden. Daraus ermittelt man dann die Zahl X = Aufwand / FPs. Bei neuen Projekten zählt man nun die Function Points und multipliziert sie mit X: Aufwand = X * FPs. Ausgangspunkt sind die zu implementierenden Funktionen, auf die im Folgenden genauer eingegangen wird. Zählen und Gewichten Es werden fünf unterschiedliche Funktionsklassen unterschieden: Eingaben Daten oder Kontrollinformationen, die von außerhalb der Systemgrenzen kommen Ausgaben Daten oder Kontrollinformationen, die an außerhalb der Systemgrenzen gesendet werden 7

9 Anwenderdateien Gruppe logischer Daten oder Kontrollinformationen, die von der Anwendung verwaltet werden. Referenzdaten Gruppe logischer Daten oder Kontrollinformationen, die extern gespeichert sind (nicht von der Anwendung verwaltet werden). Abfragen Elementarer Prozess, der aus Ein-Ausgabe-Kombination besteht (über die Systemgrenzen hinweg), die die Suche nach Daten umfasst. Christian Viehmann Kostenschätzung Die Gewichtung der Funktionen erfolgt nach folgender Tabelle: Die einzelnen Funktionen werden auch jeweils nach vorgegebenen Richtlinien in einfache, mittlere und komplexe Funktionen unterteilt. Mittels dieser Tabelle wird dann die Gewichtung vorgenommen: Beschreibung einfach mittel komplex Gesamt Eingaben * 3 = * 4 = * 6 = Ausgaben * 4 = * 5 = * 7 = Anwenderdateien * 7 = * 10 = * 15 = Referenzdaten * 5 = * 7 = * 10 = Abfragen * 3 = * 4 = * 6 = UFP (Total Unadjusted Function Points) Einflussfaktoren Die Gesamtsumme, Einflussfaktoren also die UFP wird nun durch 14 Einflussfaktoren korrigiert. Der Einfluss jedes Faktors wird von Die 0 bis vorläufigge 5 gewichtet. Gesamtsumme, Das heißt: 0 = kein dieeinfluss, unadjusted..., 5 function = sehr starker points Einfluss. (UFP), wird nun durch 14 Einflussfaktoren korrigiert. Der Einfluss jedes Faktors wird von 0 bis 51. gewichtet. Data Communications Das heißt: 0 = kein Einfluss,..., 5 = sehr starker Einfluss. Daten werden über Kommunikationseinrichtungen empfangen oder gesendet Distributed Data Communications Data Processing... Daten werden über Kommunikationseinrichtungen liegen empfangen verteilt oder gesendet Daten Schnelle Antwortzeiten wichtig Daten liegen verteilt 3. Performance 2. Distributed Data Processing Heavily Used Configuration 3. Performance... Schnelle Antwortzeiten wichtig Stark belastetes System Transaction Heavily Used Rate Configuration... Stark belastetes System Hohe Transaktionsrate On-line Transaction Data Entry Rate... Hohe Transaktionsrate Dateneingabe erfolgt online End On-line User Efficiency Data Entry... Dateneingabe erfolgt online Online Dateneingabe ist dialogorientiert 7. End User Efficiency... Online Dateneingabe ist dialogorientiert 8. On-line Update 8. Wartung On-lineerfolgt Update online... Wartung erfolgt online 9. Complex Processing Komplexe Datenverarbeitung 10. Reusability 8 Wiederverwendung 11. Installation Ease Vereinfachen der Installation 12. Operational Ease Vereinfachen der Bedienung 13. Multiple Sites Anwendung ist bei mehreren Lokationen zu installieren

10 9. Complex Processing... Komplexe Datenverarbeitung 10. Reusability... Wiederverwendung 11. Installation Ease... Vereinfachen der Installation 12. Operational Ease... Vereinfachen der Bedienung 13. Multiple Sites... Anwendung ist bei mehreren Lokationen zu installieren 14. Facilitate Change... Änderungsdienste vereinfachen Summe: Total Degree of Influence... Die Adjusted Function Points (AFP) ergeben sich dann aus: AFP = UFP * (0,65 + 0,01 * Total Degree Of Influence) In der Literatur findet man häufig nur den Begriff Function Points (FP). Damit sind meist AFP gemeint. Der Adjustment Faktor (0,65 + 0,01 * Total Degree Of Influence), hat minimal den Wert 0,65 und maximal den Wert 1,35. Die Unadjusted Function Points werden also im Extremfall noch um 35% nach oben beziehungsweise unten korrigiert. Um nun endgültig auf die Anzahl der Codezeilen (LOC) zu kommen müssen die AFP noch mit der programmspezifisch typischen Anzahl von LOC pro Function point multipliziert werden: Angenommen ein Ada Programm benötigt 70 LOC pro Function Point (siehe Tabelle). Bei einer allfälligen Anzahl von Fuction Points, AFP = 164, wird diesem Programm eine Anzahl von LOC = vorausgesagt (Size = FP * 70 = 164 * 70 = LOC). Diese Tabelle gibt Durchschnittswerte an: Sprache Anweisungen pro FP Assembler 320 C 150 Pascal 90 Modula-2 70 Ada83 70 OO-Languages 30 Fourth Generation Languages 20 Function Points sind nicht so bekannt wie COCOMO und werden seltener verwendet. Allgemein kann man sagen: Das Vertrauen in FPs bezüglich der Abschätzung der Größe von Softwareprojekten ist nicht so groß wie das in CO- COMO für die Aufwandsabschätzung dieser. 9

11 2.4.3 Das Aufwandabschätzungsmodell Abschätzungsmodelle basieren auf Messung von Charakteristiken und Eigenschaften (wie zum Beispiel: Projektkosten, Projektdauer, Größe des Teams, benötigter Speicherplatz...), erfolgreicher, bereits abgeschlossener, Projekte. Die erhaltenen Daten werden interpretiert, und bilden die Grundlage für die beschreibenden Formeln, die Modelle. Die Tatsache, dass diese Formeln aus erfolgreichen Projekten der Vergangenheit stammen, fördert die Hoffnung, dass mit ihrer Hilfe eine Vorhersage getroffen werden kann. Im Großen und Ganzen werden Softwareprojekte grob in 2 Klassen unterteilt: Kleine Projekte (Small Projects): Die Messungen bei kleinen und Projekten mittlerer Größe ergaben folgende Formel: AUFWAND = a GRÖSSE + b Hier ist der resultierende Aufwand eine lineare Funktion der Größe des Projekts (für gewöhnlich Anzahl der Zeilen Code). Dieses Modell funktioniert, bei vernünftig gewählter Teamgröße, bei kleinen Teams mit 2 bis 3 Personen. Für größere Teams nimmt die Genauigkeit der Vorhersagen durch diese Formel mit der Anzahl der Mitglieder ab. Große Projekte (Large Projects): Projekte, die eine Teamgröße von mehr als 3 Personen benötigen verhalten sich entsprechend der 2. Formel: AUFWAND = a GRÖSSEb Bei dieser Formel wächst der Aufwand nicht mehr linear, sondern exponentiell (bei b 1). Mit der Größe des Produkts nimmt hier die Produktivität (Größe / Aufwand) ab. Dies bezeichnet man als diseconomy of scale. Wie es dazu kommt Relativ gesehen wird mehr Pruduktdesign benötigt um effiziente Parallelaktivitäten von mehreren Programmieren sicher zu stellen. 2. Es, wird relativ gesehen, mehr Aufwand für die Evaluation der Voraussetzungen und für die Verifikation der Design-Spezifikationen benötigt 3. Auch mit einer klar definierten Spezifikationen brauchen mehrer Programmierer bei großen Projekten, relativ, mehr Zeit für Kommunikation und Fragen betreffend die Interfaces. 4. Für das Zusammenfügen der einzelnen Programmteile und die Integration in das Produkt wird, relativ, mehr Aufwand benötigt. 5. Relativ wird mehr Zeit in ausführliches Testen investiert und zur Beurteilung (Verifikation) des Softwareprodukts. 6. Es ist relativ gesehen mehr Aufwand von Nöten um ein großes Projekt zu managen. Wie viele andere Kostenschätzugsverfahren verwendet auch das COCOMO Modell die oben angegebene Formel zur Aufwandsabschätzung für die Entwicklungvon Software (dazu später noch mehr). 10

12 3 Ansätze der Kostenabschätzung für Softwareprojekte Zur Kostenabschätzung stehen folgende Methoden zur Verfügung: Algorithmische Modelle Algorithmische Modelle bedienen sich einer oder mehrerer mathematischer Formeln mit Hilfe derer sie eine Schätzung als Funktion von bestimmten Kostenfaktoren (cost drivers) erstellen. Ein Beispiel dafür ist die Wiederverwendbarkeit von Programmteilen. Die zwei bekanntesten Vertreter algorithmischer Modelle sind: COCOMO von Barry Boehm und Function Points von Albrecht. Expertenumfrage Bei dieser Methode werden mehrere Experten befragt. Sie erstellen die Kostenschätzung aufgrund ihrer Erfahrung und ihres Wissens. Dies geschieht indem entweder eine Sitzung veranstaltet wird, während der ein Konsens erreicht werden soll, oder man nutzt Verfahren, wie die Delphi- Methode, das darauf abzielt einen Konsens folgendermaßen zu erzielen: Die Experten bleiben untereinander anonym, um persönliche Faktoren auszuschließen. Eine Monitorgruppe hat die Aufgabe die Meinungen der Experten einzuholen indem sie versucht durch Befragung dieser zu einem Ergebnis zu kommen. Die Expertenumfrage wird häufig genutzt, um eine algorithmische Schätzung zu prüfen. Analogie Bei dieser Methode werden Erfahrungen aus mehreren, ähnlichen Projekten aus der Vergangenheit für die Schätzung des aktuellen herangezogen. Dadurch kann die Kostenabschätzung von großen Teilen des Projekts mit hoher Genauigkeit erfolgen. Parkinsons Gesetz Das Parkinson sche Gesetz besagt: Work expands to fill the available volume. Man geht also von einem festen Projektrahmen aus und füllt diesen mit Inhalt. Zur Verdeutlichung dient auch folgendes Beispiel von Barry Boehm: Diese Flugzeugsteuerung muss auf eine Wort-Maschine passen. Deshalb wird die Größe ungefähr Wörter betragen. Die Steuerung muss in 18 Monaten fertig sein und es sind gerade 10 Mitarbeiter verfügbar, um an dem Projekt zu arbeiten. Also beträgt der Aufwand circa 180 Staff-Months. Price-To-Win Ausgehend von einer Ausschreibung schätzt man einen Preis, mit dem man wahrscheinlich den Zuschlag erhält. Dadurch gewinnt man sehr wahrscheinlich eine große Anzahl an Projektausschreibungen, allerdings sind budgetäre Probleme und die daraus resultierende Unzufriedenheit des Kunden eine ebenso wahrscheinliche Konsequenz. Obwohl es eine unseriöse Methode ist, wird sie häufig genutzt. Der Grund dafür ist, dass 11

13 der Kunde meist nicht zwischen einer fundierten und einer price-to-win Schätzung unterscheiden kann und deshalb häufig das billigere Angebot wählt. Bottom-Up Hierbei wird jede Komponente separat geschätzt und die Einzelergebnisse zu einer Gesamtschätzung addiert. Top-Down Diese Methode der Kostenschätzung beruht auf den Eigenschaften des Gesamtprojekts. Danach wird der Schätzwert auf die unterschiedlichen Komponenten aufgeteilt. Diese Methode wird oft in Verbindung mit einer der anderen vorgestellten Methoden genutzt. 4 Grundlegendes - der COCOMO Prolog 4.1 Nützliches - Metriken Im Zusammenhang mit Kostenschätzung sind folgende Metriken von Bedeutung, die zur Verständlichkeit des folgenden Inhalts beitragen sollen: Der Aufwand (Die Zeit, die ein Mitarbeiter alleine für das Projekt benötigen würde) wird in SM (Staff-Months) = 152 Man-Hours nach [Boehm 1981] gemessen. Die Projektdauer (Die Zeit, die ein Projekt mit mehreren Mitarbeitern dauert) bezeichnet man mit Mo (Months) oder mit TDEV(Time for Development). Die Größe eines Softwareprogramms misst man meist in: LOC (Lines Of Code) LOC bezeichnet die Zeilenanzahl des Quelltextes inklusive Kommentaren. Zeilen mit 2 Anweisungen werden als eine LOC gezählt. Die DLOC enthalten nur die an den Kunden ausgelieferten Zeilen. Das heißt hier werden von den LOC noch Zeilen, zum Beispiel für Testrahmen oder Prototypen, abgezogen. DSI (Delivered Source Instructions) nach [Boehm 1981]. Bei DSI werden nur elementare Anweisungen gezählt. Kommentare werden nicht gezählt, Zeilen mit 2 Anweisungen als 2 DSI. 4.2 Allgemeine Einführung zu COCOMO Bevor es möglich ist in die Welt des COCOMO endgültig vorzudringen sollen folgende Fragen noch geklärt werden: Welche Anweisungen gelten als delivered source instructions (DSI)? - aus gegebenem Anlass zur Wiederholung... 12

14 Welche Staff-Months beinhaltet die Schätzungen? Welche Phasen sind in development enthalten? Projekte welcher Eigenschaften können mit Hilfe des Modells abgeschätzt werden? 1. Die DSI - delivered source instructions, die, wie bereits erwähnt einen bedeutenden Anteil der Kosten (sg. cost drivers) ausmachen sind folgendermaßen definiert: Es entsprechen nur dem Kunden als Teil des Produkts gelieferte Zeilen Code als DELIVERED(si). Somit fällt jeglicher Aufwand für Testen und andere Unterstützungssoftware aus dieser Definition hinaus. (d)source(i) code, beinhaltet jeglichen von dem Team produzierten Code. Code von Applikationsgeneratoren ist kein Teil davon. unter (ds)instructions versteht man Zeilen Code oder sg. card images. Deklarationen entsprechen dieser Definietion, Kommentare sind davon ausgeschlossen. 2. Die Abschätzungen des COCOMO beziehen sich ausschließlich auf die Periode zwischen Beginn der Designphase und dem Ende der Integration und Testphase. Die Kosten- und Zeitabschätzungen von anderen Phasen werden separat ermittelt. 3. Unter einem COCOMO Staff-Month (SM) versteht man 152 Stunden Arbeitszeit. Diese Festlegung basiert auf Erfahrungswerte aus der Praxis. COCOMO nimmt keine Abschätzung bezüglich der Arbeitskosten vor. Der Grund dafür ist, dass die Arbeitskosten von Organisation zu Organisation zu stark variieren. Abgesehen davon ist SM eine stabilere Einheit als Dollar. Es besteht allerdings die Möglichkeit nach der Schätzung der SM auf das Ergebnis, mittels Durchschnittswerten, verschiedene Umrechnungen SM zu Dollar durchzuführen. Das Ergebnis kann für die verschiedenen Phasen aufgespaltet werden mit Berücksichtigung auf die für diese Projektphase benötigten Fachkräfte und ihre Bezahlung. Zum Beispiel ist in der Anfangsphasen eines Projekts (Analyse- und frühe Designphase) der erfahrenere Teil der Belegschaft, mit höheren Gehältern, stärker involviert, währenddessen die jungen Kräfte, mit einem geringeren Einkommen in späteren Phasen des Projekts (detailliertes Design, Programmieren und Testen). Aus diesem Grund sind die frühen Phasen finanziell aufwendiger als die Folgenden. 4. Das COCOMO Modell geht davon aus, dass das Management des Projekt sowohl von Seiten der Entwickler wie auch des Kunden gut ist. 5. Das COCOMO Modell nimmt an, dass die Anforderungsspezifikationen nach der Anforderungsphase nicht grundlegend geändert werden. Eine si- 13

15 Technical Approach: COCOMO Baseline gnifikante Änderung sollte eine Modifikation des Kostenschätzungsmodells nach sich ziehen. Figure 1 shows a top-level black box description of COCOMO. It is an open model, in that: 6. Das Detailed COCOMO betrachtet die Kostenfaktoren phasenabhängig. All of Basic its COCOMO relationships und Intermediate and algorithms COCOMO are publicly hingegen nicht, available; ausgenommen zur Unterscheidung von Entwicklung und Wartung. All of its interfaces are public, well-defined, and parametrized, so that complementary preprocessors (function point or other size estimation 5models), COCOMO post-processors - constructive (project planning cost and model control tools, project dynamics models, risk analyzers), and higher level packages (project management packages, product negotiation aids), can be combined straightforwardly with COCOMO. Software product size estimation Software product, process, platform and personnel attributes Software reuse, maintenance, and increment parameters Software organization s project data COCOMO Software development, maintenance cost and schedule estimates Cost, schedule distribution by phase, activity, increment COCOMO recalibrated to organization s data Figure COCOMO 1. COCOMO in einer Grafik Black Box Overview 5.1 Die Geschichte - wie es dazu kam The 5.1.1original Der Mann COCOMO hinter model COCOMO was -calibrated Barry W. to Boehm 56 project data points in 1978, validated Barry Boehm on 7 new ist der project Mann, data der points hinter COCOMO, in 1979, and sowie published COCOMOin 2.0the steht. book, Software Engineering Folgend eine Economics kurze Biographie (by Barry über Boehm, Barry W. Prentice-Hall) Boehms öffentliches in Wirken: COCOMO is used Barry as the Boehm standard erhielt model 1957 im for Zugesoftware seines Mathematikstudiums life cycle cost estimation in Harvard den by the U.S. Army, Bachelor NATO, and of Art numerous (B.A.). corporations. Vier Jahre darauf absolvierte er den Master of Science (M.S.) und 1964 den Doctor of Philosophy (Ph.D.) ebenfalls an der Annual Universität COCOMO von Kalifornien users' ingroup Los Angeles meetings (UCLA). have Vonbeen 1989 held bis 1992 since arbeitete called er fürcocomo/ das US Verteidigungsministerium Software Cost Estimation als DirektorForums). des DARPA At (Defense these meetings, a 1985 (they are now number Advanced of corroborations, Research Projects recalibrations, Agency) - Information and Science improvements and Technology of the Office reported (ITO) und and als discussed. Direktor des DDR&E These meetings Software and have Computer also identified Technology a candidate model have been Office. In den Jahren zwischen 1973 und 1989 wirkte Barry Boehm für TRW agenda of improvements for aligning COCOMO with 1990's 's software (Produktion und Design von Automobil - und Luftfahrtprodukten sowie IT) practices. mit demthe Höhepunkt, next section der Ernennung discusses zum the Chef top der candidate Wissenschaftsabteilung model improvements der in the COCOMO Defense Systems 2.0 technical Group. agenda. Sein Schaffen The following für die Randsection Corporation summarizes von 1959 bis the COCOMO 2.0 program's planned sequence of activities for pursuing the technical agenda. 14 3

16 1973, gipfelte in der Berufung zum Head of the Information Sciences Department. Während 1955 un 1959 arbeitete er als Programmanalytiker bei General Dynamics. Seine aktuelle Forschungstätigkeit beschäftigt sich mit Software Prozessmodellen, Anforderungen für Software Engineering, Software Architekturen, Software Metriken sowie Kostenabschätzungsmodellen, Software Engineering Umgebungen, und wissensbasiertem Software Engineering. Sein bekanntester Beitrag in diesem Bereich ist das Constructive Cost Model (COCOMO (1981) und COCOMO 2.0 (2000)). Weiters zeichnet er sich für das Spiral Model of the software process, dem Theory W (win-win) approach for software management and requirements determination und für zwei fortgeschrittene Software Engineering Umgebungen: der TRW Software Productivity System und der Quantum Leap Environment verantwortlich. Seine wissenschaftlichen Tätigkeiten spiegeln sich in zahlreichen Beiträgen für viele Wissenschaftsmagazine, wie zum Beispiel dem IEEE Transactions on Software Engineering, IEEE Computer, IEEE Software, ACM Computing Reviews, Automated Software Engineering, Software Process, und Information and Software Technology wieder. Er übernahm den Vorsitz des AIAA Technical Committee on Computer Systems, des IEEE Technical Committee on Software Engineering und war Mitglied des Governing Board of the IEEE Computer Society. Aktuell steht er dem Air Force Scientific Advisory Board s Information Technology Panel sowie dem Board of Visitors for the CMU Software Engineering Institute vor. Ihm wurden unter anderem das Gastlektorat der USSR Academy of Sciences (1970), der AIAA Information Systems Award (1979), der J.D. Warnier Prize for Excellence in Information Sciences (1984), der ISPA Freiman Award for Parametric Analysis (1988), der NSIA Grace Murray Hopper Award (1989), der Office of the Secretary of Defense Award for Excellence (1992), der ASQC Lifetime Achievement Award (1994), und der ACM Distinguished Research Award in Software Engineering (1997) verliehen Die Intention für COCOMO - der SE Ansatz Software Kostenabschätzung ist das Verbindungsglied zwischen den Konzepten und Techniken der wirtschaftlichen Analyse und den Eigenheiten der Welt des Software Engineering. Es fällt schwer eine Kosten-Nutzen Analyse über Software, eine break-even Analyse oder eine make-or-buy Entscheidung für Software zu treffen ohne eine klare Möglichkeit der Kostenabschätzung für diese Software zu haben und deren Sensibilität zu verschiedenen Produkten und Projekten sowie zu Umweltfaktoren zu kennen. Mit Hilfe von Abschätzungsmethoden ist ein wichtiger Schritt in Richtung gutes Softwaremanagement getan, das einen wichtigen Grundstein für erfolgreiche Software darstellt. Wird auf ein solches Kostenabschätzungsmodell verzichtet, zeigte die Erfahrung, werden häufig folgende Probleme auftreten: Mitarbeiter bei dem Softwareprojekt haben keine fundierte Basis um dem Projektmanager, dem Kunden oder den Händlern mitzuteilen, dass das veranschlagte Budget und der Zeitplan nicht realistisch sind. Dies führt 15

17 zu optimistischen Versprechungen, für die Softwareentwicklung, in deren Folge zu Kompromissen in sämtlichen Produktbereichen (wie bei der Leistung), unvermeidbarem Zeitdruck und darüber hinaus zu Dumpingpreisen für Softwareprodukte. Den Softwareanalysten fehlt die Grundlage für realistische hardware-software trade-off Analysen während der Designphase des Systems. Daraus kann ein Design resultieren, bei dem die Hardwarekosten niedrig sind, allerdings mit der Folge, dass die Softwarekosten umso höher steigen. Projektmanager können nicht planen, wie lange eine Softwarephase dauert und mit welchem Aufwand sie verbunden ist. Weshalb es nicht möglich ist festzustellen, ob der Fortschritt des Projekts planmäßig ist. Das heißt, dass von Beginn an die Softwareentwicklung außer Kontrolle läuft 5.2 Das COCOMO Das COnstructive COst MOdel (COCOMO) ist ein Beispiel für ein algorithmisches Modell (regression model) zur Kosten- und Aufwandschätzung von Software Diese Methoden verwenden eine Basisformel mit Parameter, die abhängig von Daten aus vergangenen Projekten und aktuellen Projektcharakteristiken festgelegt werden. Das COCOMO Modell ist das bekannteste und akzeptierteste Modell zur Kosten- und Aufwandschätzung von Software. Die zugrundeliegende Formel gewichtet die Größe des Projekts sehr stark ( size-driven model ), weshalb die Fähigkeit des Projektmanagers zu einem sehr frühen Zeitpunkt die Größenordnung des Projekts richtig einzuschätzen von großer Bedeutung ist. Aus diesem Grund wird das COCOMO Modell häufig in Verbindung mit einem der Größenabschätzungsverfahren, wie Function Points, verwendet. COCOMO existiert in einer hierarchischen Struktur, in der die Detailiertheit und Genauigkeit von Stufe zu Stufe zunimmt. Zuallererst steht das Basic COCOMO. Es ist für den Großteil der Softwareprojekte anwendbar: Seiner Abschätzung folgen Softwareprojekte kleiner und mittlerer Größe in einer bekannten Software Entwicklungsumgebung. Basic COCOMO ist konzipiert für eine schnelle, frühe aber grobe Abschätzung der Softwarekosten. Die Genauigkeit ist begrenzt, weil Faktoren wie Unterschiede in der Hardware, Qualität des Personals und dessen Erfahrung, die Verwendung moderner Hilfsmittel und andere Projektattribute mit bekanntem Einfluss keine Berücksichtigung finden Intermediate COCOMO inkludiert diese Faktoren in die Kostenabschätzung. Detailed COCOMO trägt dem Einfluss dieser Faktoren Rechnung und beurteilt sie abhängig von den Projektphasen, für die sie von Bedeutung sind Die drei Projektmodi - Deklaration der Größe und Art des Projekts Für das COCOMO Modell ist der Projektmodus ( development mode ) einer der wichtigsten Faktoren. Er trägt bedeutend zu der Projektdauer und den 16

18 Projektkosten bei. Deshalb wird jedes Projekt einem der 3 Projektmodi zugerechnet: Organic Mode. Semidetached Mode Embedded Mode Um den Aufwand und die Entwicklungszeit abschätzen zu können verwendet COCOMO für alle 3 Projektmodi die selbe Formel, allerdings mit einer anderen Bewertung der Koeffizienten. Aus diesem Grund ist es notwendig zu wissen in welchen Projektmodi das Projekt einzureihen ist. 1. Organic Mode: Relativ kleines Projekt (kleiner als DSI) Stabile Entwicklungsumgebung Jeder Mitarbeiter kennt das gesamte Projekt Das Projekt ist änlich zu bereits entwickelten Produkten, und bedarf keiner großen Innovationen. Der Großteil der mit dem Projekt betrauten Personen konnten während ihrer bisherigen Tätigkeit in der Organisation in ähnlichen Projekten ausreichend Erfahrungen sammeln. Diese Personen können dafür sorgen, dass der Kommunikationsüberschuss zu Beginn des Projekts in Grenzen gehalten wird. Die Festlegung der Spezifikation und der Schnittstellen erfolgt problemlos ebenso die Abstimmung der Anforderungen. Falls das Softwareprodukt nach Korrespondenz mit den anfänglichen Anforderungen einer Überarbeitung bedarf, kann generell eine Modifikation der Spezifikation ausgehandelt werden, die einfacher zu entwickeln ist. Das Basic COCOMO im organic mode verwendet zur Aufwandsabschätzung und zur Abschätzung der Projektdauer folgende Formeln: SM = 2.4 (KDSI) 1.05 TDEV = 2.50 (SM) Semidetached Mode: Mittelgroßes Projekt (zwischen und DSI) Jeder Mitarbeiter besitzt Spezialwissen bezüglich der Entwicklung. Das Team ist, was die Erfahrung der Mitglieder betrifft, nicht homogen. Das Entwicklerteam ist nicht eingespielt 17

19 Das Basic COCOMO im semidetached mode verwendet zur Aufwandsabschätzung und zur Abschätzung der Projektdauer folgende Formeln: SM = 3.0 (KDSI) 1.12 TDEV = 2.50 (SM) 0.35 Bei diesem Projektmodus sind die Charakteristiken des Projekts in der Mitte zwischen organic mode und embedded mode. In der Mitte kann in zweierlei Richtungen interpretiert werden: Die dem semidetached mode zurechenbaren Projekte sind von mittlerem Level, oder sie bestehen aus einer Mixtur aus den Charakteristiken des organic und embedded mode. 3. Embedded Mode: Großes Projekt (über DSI) Noch stärkere Arbeitsteilung, z.b.: nur kleine Anzahl von Analytikern und großes Entwicklerteam Bei diesem Projektmodus ist ein Projekt durch straffe und unflexible Strukturen und ebensolche Anforderungen an die Schnittstellen gekennzeichnet. Das Produkt muss in einem stark aneinander gekoppeltem Komplex aus Hardware, Software und Protokollen sowie operierenden Prozeduren funktionieren. Im embedded mode steht grundsätzlich keine Möglichkeit zur Verfügung Änderungen an der Software über die Modifikation der Anforderungen oder Spezifikation der Schnittstellen durchzuführen. Es benötigt mehr Aufwand um Änderungen durchzuführen und Festzuschreiben. Projekte im embedded mode führt ihr Weg meist durch unbekanntes Terrain zu einer größeren Ausdehnung, als sie beispielweise Projekte des organic mode erreichen. Deshalb wird zu Beginn, ein kleineres Team aus Analysten engagiert, um das Projekt nicht in Kommunikationsüberfluss ertrinken zu lassen.wenn das Produktdesign des Projekts im embedded mode abgeschlossen ist, gilt es eine möglichst hohe Anzahl an Programmierern parallel mit dem detaillierten Design, dem Code schreiben und Testen zu beauftragen. Anderenfalls würde das Projekt bis zur Fertigstellen mehr Zeit in Anspruch nehmen. Dieses Vorgehen zeigt sich in Spitzen in der Personen-Beschäftigungskurve bei embedded mode Projekten und führt zu höheren Aufwänden im Vergleich zu Projekten im organic mode, die sich im selben Entwicklungsstadium befinden. Das Basic CO- COMO im Embedded mode verwendet zur Aufwandsabschätzung und zur Abschätzung der Projektdauer folgende Formeln: SM = 3.6 (KDSI) 1.20 TDEV = 2.50 (SM)

20 Beispiel: Eine große Firma, die Chemikalien erzeugt, plant ein neues Computerprogramm zu entwickeln, das das Handling der Rohmaterialien vereinfachen soll. Dieses Projekt wir von einer Abteilung in der Firma durchgeführt. Die Programmierer und Analysten haben bereits Erfahrung auf diesem Gebiet durch die Entwicklung ähnlicher Programme über mehrere Jahre. Eine Studie legt die Größe des Projekts grob mit DSI fest. Dieses Projekt ist ein gutes Beispiel für ein organic mode Softwareprojekt. Zur Abschätzung werden hier die Formeln des Basic COCOMO organic mode verwendet: Aufwand: SM = 2.4 (32) 1.05 = 91 Staff-Months. Produktivität: DSI / 91 SM = 352 DSI / SM. Projektdauer und Zusammenstellung der Belegschaft: Wenn eine Aufwandsabschätzung gemacht ist, die Anzahl der Staff-Month feststeht, muss ein Manager feststellen, wie groß sein Team sein soll. Diese Festlegung bestimmt auch die voraussichtliche Dauer des Projets. Jedoch sei noch einmal darauf hingewiesen, dass ein größeres Team nicht proportional auf die Projektdauer umlegbar ist. Mehr Mitarbeiter erschweren die Kommunikation untereinander und diese erhöhte Komplexität dokumentiert sich in langsameren Vorankommen bei dem Projekt. Bei der Annahme, dass die Abstimmung zwischen zwei Programmieren 5% der Arbeitszeit betrage [Zelkowitz 78] und die Produktivität eines Programmierers 5000 Codezeilen/Jahr, entsteht für ein Projekt mit einem geplantem Umfang von Codezeilen (das in 2 Jahren fertiggestellt werden soll) folgendes Problem: Teamgröße Produktivität eines Programmierer Produktivität des Teams LOC/Jahr 9500 LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr Unter den gegebenen Voraussetzungen kann ein Team von 8 Personen den geforderten Termin (2 Jahre) einhalten. Eine Aufstockung des Teams auf 9 oder 10 Personen kann eine geringfügige Verringerung (max. 2 Monate) der Projektdauer bewirken. Eine Teamgröße die darüber hinausgeht führt zu einem Rückgang der Gesamtleistung (ab 12 Personen). Die zweite Formel des COCOMO Modell dient der Abschätzung der Projektdauer und bedient sich der Aufwandsabschätzung des Projekts (SM). Für das obige Beispiel mit geschätzten 91 SM folgt: 19