Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

1 Vorlesung "Software-Engineering" zVorige Vorlesung yFortsetzung Projektphasen und Vorgehensmodelle yLastenheft yEinfache Verfahren zur Aufwandsschätzung.

Ähnliche Präsentationen


Präsentation zum Thema: "1 Vorlesung "Software-Engineering" zVorige Vorlesung yFortsetzung Projektphasen und Vorgehensmodelle yLastenheft yEinfache Verfahren zur Aufwandsschätzung."—  Präsentation transkript:

1 1 Vorlesung "Software-Engineering" zVorige Vorlesung yFortsetzung Projektphasen und Vorgehensmodelle yLastenheft yEinfache Verfahren zur Aufwandsschätzung zHeute: yFortsetzung: Verfahren zur Aufwandsschätzung yKombination von Schätzverfahren Prof. Ralf Möller, TUHH, Arbeitsbereich STS

2 2 Methoden zur Kosten- und Terminschätzung zBeispiel: yEs soll ein Software-Produkt mit geschätzten LOC realisiert werden yDurchschnittliche Produktivität pro Mitarbeiter: LOC/Jahr [HP, Grady 92]  6 Mitarbeiterjahre werden benötigt  Arbeiten 3 Mitarbeiter im Team zusammen, so werden 2 Jahre bis zur Fertigstellung benötigt. z Faustregeln yEine durchschnittliche Software-Entwicklung liefert ungefähr 350 Quellcodezeilen (ohne Kommentare) pro Ingenieurmonat. yDabei umfasst die Ingenieurzeit alle Phasen von der Definition bis zur Implementierung.

3 3 Einflussfaktoren der Aufwandsschätzung (3) zZusätzlicher Faktor: Produktivität yWird von vielen verschiedenen Faktoren beeinflusst yDie Lernfähigkeit und Motivation der Mitarbeiter ist entscheidend. zBrooksches Gesetz: „Adding manpower to a late software project makes it later“

4 4 Einflussfaktoren der Aufwandsschätzung (4) zEntwicklungsdauer ySoll die Zeit verkürzt werden, dann werden mehr Mitarbeiter benötigt. yMehr Mitarbeiter erhöhen den Kommunikationsaufwand im Entwicklungsteam. yDer höhere Kommunikationsanteil reduziert die Produktivität. yKann die Entwicklungsdauer verlängert werden, so werden weniger Mitarbeiter benötigt.

5 5 Aufwandsschätzung: Analogiemethode (2) zBei hoher Übereinstimmung kann der bekannte Aufwand unverändert übernommen werden zFaustregel: ySoftware-Entwicklung mit weitgehender Übernahme von existierender Software benötigen ungefähr 1/4 der Zeit von Neuentwicklungen zNachteile der Analogiemethode yintuitive, sehr globale Schätzung auf der Basis individueller Erfahrungen ykeine Nachvollziehbarkeit der Schätzergebnisse

6 6 Analogiemethode (2) zBeispiel: Analogiemethode yabgeschlossenes Produkt: Pascal-Compiler: 20 MM yzu entwickelndes Produkt: Modula-2-Compiler? x20% neue Konstrukte x50% des Codes wiederverwendbar x50% müssen überarbeitet werden ySchätzung x50% leicht modifiziert: 1/4 von 10 MM = 2,5 MM x50% völlige Überarbeitung: 10 MM x20% zusätzliche Neuentwicklung hoher Komplexität: 4 MM * 1,5 (Komplexitätszuschlag) = 6 MM xSchätzung Modula-2: 18,5 MM.

7 7 Aufwandsschätzung: Relationsmethode (1) zDas zu schätzende Produkt wird direkt mit ähnlichen Entwicklungen verglichen. zAufwandsanpassung erfolgt im Rahmen einer formalisierten Vorgehensweise. zFür die Aufwandsanpassung stehen Faktorenlisten und Richtlinien zur Verfügung. zBeispiel: zWerte geben an, in welcher Richtung und wie stark die einzelnen Faktoren den Aufwand beeinflussen. Programmiersprache PL/1 = 100 COBOL = 120 ASSEMBLER = 140 Programmiererfahrung 5 Jahre= 80 3 Jahre= Jahr = 140 Dateiorganisation sequentiell = 80 indexsequentiell = 120

8 8 Relationsmethode (2) z Beispiel (Fortsetzung): yEin neues Produkt soll in PL/1 realisiert werden xDas Entwicklungsteam hat im Durchschnitt 3 Jahre Programmiererfahrung xEs ist eine indexsequentielle Dateiorganisation zu verwenden. yZum Vergleich: Entwicklung... xdie im Assembler programmiert wurde xeine sequentielle Dateiorganisation verwendete xvon einem Team mit 5 Jahren Programmiererfahrung erstellt wurde yGeht man davon aus, dass alle 3 Faktoren den Aufwand gleichgewichtig beeinflussen, dann ergibt sich folgende Kalkulation: xAssembler zu PL/1: 140 zu 100 = 40 Punkte Einsparung x5 Jahre zu 3 Jahre: 80 zu 100 = 20 Punkte Mehraufwand xsequentiell zu indexsequentiell: 80 zu 120 = 40 Punkte Mehraufwand yEs ergibt sich ein Mehraufwand von 20 Punkten.

9 9 Aufwandsschätzung: Multiplikatormethode (1) yDas zu entwickelnde System wird soweit in Teilprodukte zerlegt, bis jedem Teilprodukt ein bereits feststehender Aufwand zugeordnet werden kann (z.B. in LOC). yDer Aufwand pro Teilprodukt wird meist durch Analyse vorhandener Produkte ermittelt. yOft werden auch die Teilprodukte bestimmten Kategorien zugeordnet wie xSteuerprogramme xE/A-Programme xDatenverwaltungsroutinen xAlgorithmen usw. yDie Anzahl der Teilprodukte, die einer Kategorie zugeordnet sind, wird mit dem Aufwand dieser Kategorie multipliziert. yDie erhaltenen Werte für eine Kategorie werden dann addiert, um den Gesamtaufwand zu erhalten. yAuch „Aufwand-pro-Einheit-Methode“ genannt.

10 10 Aufwandsschätzung: Multiplikatormethode (2) zZunächst werden Faktoren festgelegt, die für die Schätzung relevant sind. zSie sind subjektiv (z.B. Qualifikation des Personals) oder objektiv (z.B. verwendete Programmiersprache) zu bewerten. zDen Faktorausprägungen sind Werte zugeordnet. zDie Werte aller Faktoren werden nach einer vorgegebenen mathematischen Formel verknüpft und ergeben dann den Gesamtaufwand.

11 11 Aufwandsschätzung: Multiplikatormethode (3) yDurch Korrelationsanalysen wird ermittelt, welche Faktoren welchen wertmäßigen Einfluss auf den Gesamtaufwand haben. ySolche Analysen müssen mit einer großen Anzahl von abgeschlossenen Entwicklungen und einer Vielzahl von Faktoren durchgeführt werden. yDie Faktoren, die die höchste Korrelation besitzen, werden zu einer Gleichung zusammengefasst. yDer zu jedem Faktor gehörende Koeffizient repräsentiert die Stärke des Einflusses auf den Gesamtaufwand. yDer Aufwandsfaktor repräsentiert den Einfluss des jeweiligen Faktors auf den Gesamtaufwand. yAls parametrische Gleichung würde sich ergeben: xLOC bewertet = LOC Steuerprogramme *1,8 + LOC E/A-Programme *1,5 + LOC Datenverwaltung *1,0 + LOC Algorithmen *2.

12 12 Aufwandsschätzung: Multiplikatormethode (4) zBeispiel: zDie Aufteilung eines zu schätzenden Produkts in Teilprodukte hat folgendes ergeben: zKategorie Teil-Summe Aufwands-LOC produkteLOCfaktor bewertet zSteuerprogramm 1*500 LOC500 1,8900 zE/A-Programme1*700+2* ,52550 zDatenverwaltung 1*800+2* ,01300 zAlgorithmen 1*300+5* ,01600 zSumme6350

13 13 Aufwandsschätzung: Multiplikatormethode (5) zBewertung yEs ist eine umfangreiche, empirische Datensammlung und -auswertung erforderlich, um die zu berücksichtigenden Faktoren unternehmensspezifisch zu bewerten. yDie Koeffizienten müssen permanent überprüft werden, um den technischen Fortschritt zu berücksichtigen.

14 14 Aufwandsschätzung: Prozentsatzmethode zAus abgeschlossenen Entwicklungen wird ermittelt, wie der Aufwand sich auf die einzelnen Entwicklungsphasen verteilt hat. zBei 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, zoder man führt eine detaillierte Schätzung einer Phase durch und schließt hieraus dann auf den Gesamtaufwand. zKann bereits frühzeitig eingesetzt werden, wenn der Aufwand für mindestens eine Phase durch den Einsatz einer anderen Methode bestimmt wurde.

15 15 Bewertung zKeine der aufgeführten Basismethoden allein ist ausreichend. zJe nach Zeitpunkt und Kenntnis von aufwandsrelevanten Daten sollte die eine oder andere Methode eingesetzt werden. zFür frühzeitige, grobe Schätzungen müssen die yAnalogie- yRelations- und yProzentsatzmethode eingesetzt werden. zSind die Einflussfaktoren während der Entwicklung dann genauer bekannt, dann sollten die genaueren Methoden, wie die yMultiplikatormethode Verwendung finden.

16 16 Aufwandsschätzung: COCOMO-Methode (1) zCOnstructive COst MOdel von B. Boehm entwickelte Sammlung von Schätzmodellen zModell 1 (Basisversion): zModell 2 (Zwischenversion): yzusätzliche Berücksichtigung von kostenbeeinflussenden Faktoren zModell 3 (Detailversion): yzusätzliche Berücksichtigung der unterschiedlichen Projektphasen, Verteilung des Aufwandes auf die Projektphasen

17 17 Aufwandsschätzung: COCOMO-Methode (2) zUnterscheidung von 3 Projektkategorien zur Anpassung der Kennzahlen: yEinfache Projekte x(vertraute Systemumgebung, große Erfahrung, wenige Schnittstellen) yMittelschwere Projekte yKomplexe Projekte x(enge Verzahnung mit Systemumgebung, zahlreiche Schnittstellen, geringe Erfahrung)

18 18 COCOMO-Methode: Basisversion (1) zBerechnung des Aufwandes:

19 19 COCOMO-Methode: Basisversion (2) zBerechnung der Entwicklungszeit:

20 20 Aufwandsabschätzung - Aufgabe Aufgabe: Es soll eine einfache Online-Anwendung erstellt werden. Für die abgeschlossene Definitions- und Entwurfsphase wurden 15 MM benötigt. Erfahrungswerte:Definitionsphase18% Entwurfsphase19% Realisierung53% Einführungsphase10% zFragen: zAufwand der gesamten Entwicklung in MM? y zRestaufwand /-dauer? zBenötigte Teamgröße ?

21 21 Aufgabe: Es soll eine einfache Online-Anwendung erstellt werden. Für die abgeschlossene Definitions- und Entwurfsphase wurden 15 MM benötigt. Erfahrungswerte:Definitionsphase18% Entwurfsphase19% Realisierung53% Einführungsphase10% Aufwandsabschätzung - Lösung z Fragen: z Aufwand der gesamten Entwicklung in MM? y(15 MM * 100) /37 = 40,54 MM z Restaufwand /-dauer? yGesamtaufwand – Aufwand für Planung und Entwurf (40,54 MM – 15 MM) = 25,54 MM opt. Dauer = 2,5 * ,35 gleich ca. 8 Monate z Benötigte Teamgröße ? y25,54 / 8 = 3,2 gleich ca. 3 Mitarbeiter

22 22 COCOMO-Methode: Zwischenversion (1) zBerechnung des Aufwandes:

23 23 COCOMO-Methode: Zwischenversion (2) z14 Kosteneinflussfaktoren zBerücksichtigung von Produkt-, Rechner-, Personal- und Projektmerkmalen zEinordnung in Kategorien 'sehr gering', 'gering', 'normal', 'hoch', 'sehr hoch' und 'extrem' zZuordnung von Faktorenwerten zu Kategorien (Tabelle) zMultiplikative Verknüpfung zAktuelle Weiterentwicklung zu COCOMO II

24 24 Aufwandsschätzung: Function Point-Methode (1) zAllen J. Albrecht (Ausarbeitung nach Balzert, 00) zAusgangspunkte: yAufwand hängt vom Umfang und vom Schwierigkeitsgrad des neuen Produktes ab yUmfang wird nicht in Lines of Code (LOC) ausgedrückt, sondern direkt aus den Anforderungen abgeleitet zVorgehen yZuordnung jeder Produktanforderung in eine von fünf Kategorien

25 25 Die 7 Schritte der Function-Point Methode 1.Kategorisierung jeder Produktanforderung Eingabedaten, Abfragen, Ausgabedaten, Datenbestände, Referenzdaten 2.Klassifizierung jeder Produktanforderung einfach, mittel, komplex 3.Eintrag in Berechnungsformular 4.Bewertung der Einflussfaktoren 5.Berechnung der bewerteten Function Points (FP) 6.Ermitteln des Personalaufwands aus einer FP-PM (Personenmonaten)-Kurve oder Tabelle 7.Aktualisierung der empirischen Daten als Schätzgrundlage für Folgeprojekt

26 26 1. Kategorisierung der Produktanforderungen (1) z Kategorien y Ermittelt pro Funktion im Lastenheft y Erfordert Identifikation und Bewertung der Einzelfunktionen

27 27 1. Kategorisierung der Produktanforderungen (2) zBeispiel: z/LF 20/: „Benachrichtigung der Kunden (Anmeldebestätigung, Abmeldebestätigung, Änderungsmitteilungen, Rechnung, Werbung)“ yDiese Anforderung ist der Kategorie „Ausgabedaten“ zuzuordnen yDa es sich um 5 verschiedene Ausgaben handelt, wird im folgenden von 5 Ausgaben ausgegangen.

28 28 2. Klassifizierung der Produktanforderungen zEinordnung der Anforderungen in eine der Klassen „einfach“, „mittel“ oder „komplex“ zBeispiel:Klassifizierung der Datenbestände einer Funktion zKriteriumeinfachmittelkomplex Anzahl unterschiedl >10 Datenelemente Eingabeprüfungformalformalformal logischlogisch DB-Zugriff Ansprüche an die Bedienerführunggeringnormalhoch Hauptschwierigkeit!

29 29 3. Eintrag in Berechnungsformular z3. Schritt z4. Schritt zBerechnung der Gewichtung IBM- Werte = E3 = E2 /

30 30 4. Bewertung der Einflussfaktoren zDie Einflussfaktoren beziehen sich auf die Anwendung als Ganzes und nicht auf einzelne Funktionen oder Funktionspunkte. zEs wird nicht nur das bloße Vorliegen eines Zustandes bewertet, sondern sein Einfluss auf die Entwicklung. zAlternative Ansätze für Bewertung der Einflussfaktoren: Ansatz Anzahl der FaktorenBewertungs- Faktor Einflussbewertung spanne ynach Albrecht14 Faktoren(0... 5) ( ) / 1,64 ynach IBM 7 Faktoren( / ) ( ) / ,7 ynach IFPUG14 Faktoren(0... 5) ( ) / ,65 ynach Hürten7 Faktoren(-2,5%... 2,5%) -30%... 30% (*) (-5%... 5%) (*) Auswirkung der Einflussfaktoren in Prozent der Function Points

31 31 5. Berechnung der bewerteten Function Points zE1 = Summe der Kategorien zE2 = Summe der 7 Einflüsse zDie Summe der Einflussfaktoren (ein Wert zwischen 0 und 60) ändert den Function Point-Wert um +/- 30 % Bewertete Function Points = E1 * ( E2 / ,7 )

32 32 6. Ablesen des Aufwands in MM zProduktivität nimmt bei großen Projekten ab  nicht-linearer Zusammenhang Wertepaare (FP, PM) aus abgeschlossenen Entwicklungen des eigenen Unternehmens Aufwand FP

33 33 7. Aktualisierung der empirischen Daten zNach der Beendigung einer mit der Function Point- Methode geschätzten Entwicklung ist das neue Wertepaar FP  tatsächliche PM zu verwenden, um die bestehende Kurve zu aktualisieren.

34 34 1.Schritt: Kategorisierungfür jedeAnforderung EingabedatenAbfragenAusgabedatenDatenbeständeReferenzdaten Produktanforderungen einfach mittel komplex einfach mittel komplex einfach mittel komplex einfach mittel komplex einfach mittel komplex 2.Schritt: Klassifizierungjeder Anforderung Eingaben Abfragen Ausgaben Datenbestände Referenzdaten  3.Schritt:Eintrag derjeweiligen Anzahlindas Berechnungs- formularund Ermittlungder unbewertetenFPs 4.Schritt: Bewertungder Einflußfaktoren Einflußfaktoren0bis60 FPs  30% 5.Schritt: Berechnungder bewertetenFPs 6.Schritt:Ablesen desAufwandes MM FP 7.Schritt: Aktualisierungder Wertepaare,Neu- berechnungder Aufwandskurve Wertepaare»FPsAufwand«aus abgeschlossenenEntwicklungen Aufwand Zusammenfassung

35 35 Die Function Point-Methode: Voraussetzungen zEine Bewertung kann erst dann durchgeführt werden, wenn die Projektanforderungen bekannt sind. zEine Bewertung sollte von Mitarbeitern durchgeführt werden, die ein ausreichendes Wissen über die Anforderungen haben. zBei der Bewertung muss die gesamte Anwendung / Projektanforderung betrachtet werden. zDie Projektanforderungen sollten nicht besonders minuziös zergliedert werden, sondern die gesamte Anwendung muss im Blickfeld stehen. zBeim Einsatz dieser Methode ist sehr streng darauf zu achten, dass das Anwendungsprojekt aus Sicht des Benutzers betrachtet wird. zUnternehmensspezifische Schulung und Vorgabe von Beispielen, damit die Wirkung individueller Schätzungen (Klassifizierung und Bewertung der Einflussfaktoren) minimiert werden. zDer Ist-Aufwand muss für die Nachkalkulation ermittelbar sein.

36 36 Die Function Point-Methode: Vorteile (1) zProduktanforderungen, nicht LOC als Ausgangspunkt zAnpassbarkeit an verschiedene Anwendungsbereiche (Änderung der Kategorien) zAnpassbarkeit an neue Techniken (Änderung der Einflussfaktoren und der Einflussbewertung) zAnpassbarkeit an unternehmensspezifische Verhältnisse (Änderung der Einflussfaktoren, der Einflussbewertung und der Klassenfaktoren pro Klasse)

37 37 Die Function Point-Methode: Vorteile (2) zVerfeinerung der Schätzung entsprechend dem Entwicklungsfortschritt (iterative Methode) yBeispiel 1. Schätzung auf der Grundlage des Lastenheftes 2. Schätzung auf der Grundlage des Pflichtenheftes 3. Schätzung nach Erstellung des formalen Modells zErste Schätzung bereits zu einem sehr frühen Zeitpunkt möglich (Planungsphase) zFestgelegte methodische Schritte zLeicht erlernbar zBenötigt nur einen geringen Zeitaufwand zGute Transparenz zGute Schätzgenauigkeit zWerkzeugunterstützungen verfügbar

38 38 Die Function Point-Methode: Nachteile zEs kann nur der Gesamtaufwand geschätzt werden. Eine Umrechnung auf einzelne Phasen muss mit der Prozentsatzmethode erfolgen. zIn der Originalform von Albrecht personalintensiv und nicht automatisierbar zZu stark funktionsbezogen zQualitätsanforderungen werden nicht berücksichtigt zMischung von Projekt- und Produkteigenschaften bei den Einflussfaktoren.

39 39 Anhang: Die IBM-Kurve: FP -> MM

40 40 Kernphasen der Software-Entwicklung zProblemanalyse und Planung zSystemspezifikation zEntwurf zImplementierung zIntegration und Test zWartung

41 41 Zusammenfassung, Kernpunkte zTechniken zur Aufwandsabschätzung zEinfache Methoden zKombination von einfachen Methoden yCOCOMO yFunction Point-Methode

42 42 Was kommt beim nächsten Mal? zFortsetzung der Diskussion der Phasen zSystemspezifikation


Herunterladen ppt "1 Vorlesung "Software-Engineering" zVorige Vorlesung yFortsetzung Projektphasen und Vorgehensmodelle yLastenheft yEinfache Verfahren zur Aufwandsschätzung."

Ähnliche Präsentationen


Google-Anzeigen