Software Engineering (SE)

Transkript

1 Software Engineering (SE) 3) Planungsphase Prof. Dr. Anja Metzner Hochschule Augsburg, Fakultät für Informatik Kontakt: Studiengang WiBac 4 (Stand: ), Hochschule Augsburg, 2014

2 Gliederung 1. Übersicht Planungsphase 2. Lastenheft 3. Aufwandsschätzung 4. Risikomanagement 2

3 1. Übersicht Planungsphase Grundsätzliche Vorgehensweise 1. Ist-Aufnahme Beschreibung des momentanen Systems und dessen Zustand (Ist-Aufnahme) 2. Ist-Analyse Wie ist der Zustand des momentanen Systems, kann das System verbessert werden und wenn ja wo? Schwachstellenanalyse Wo sind Änderungen notwendig? 3

4 1. Übersicht Planungsphase Grundsätzliche Vorgehensweise 3. Verbesserungsvorschläge Sammlung von Lösungsalternativen Grobe Beschreibung wie die Veränderungen aussehen sollen Beschreibung wie die Veränderungen herbeigeführt werden können 4. Soll-Konzept Auswahl einer Alternative Formales Modell momentanen Zustands Formales Modell der geplanten Alternative Spezifikation: Lastenheft 4

5 1. Übersicht Planungsphase 5

6 1. Übersicht Planungsphase Aufgaben 1. Voruntersuchung Ist-Aufnahme und Ist-Analyse, Verbesserungsvorschläge, Soll-Konzept, Festlegung der prägnantesten Anforderungen 2. Machbarkeitsstudie Untersuchung der Realisierbarkeit, Prüfung auf Abdeckung Standard-SW, Verfügbarkeitsprüfung von Ressourcen, Risikoanalyse 3. Produktplanung Auswählen des Produkts, Trendstudien, Marktanalysen, Integration von Forschungsergebnissen, Kundenanfragen/-analysen 4. Projektplanung Projektplan: Aufwandsschätzung mit Kosten-, Ressourcen- und Terminplan 6

7 1. Übersicht Planungsphase Schriftliche Ergebnisse 1. Voruntersuchung: Lastenheft 2. Machbarkeitsstudien : Studien 3. Produktplanung: Studien, Risikoanalyse 4. Projektplanung: Kosten-, Termin- u. Ressourcenplan Beteiligte Auftraggeber Projektleiter Anwendungsspezialist Fachlicher Entwickler 7

8 2. Lastenheft Lastenhefterstellung in der Planungsphase Verfeinerung in Definitionsphase zum Pflichtenheft Unterschiede? Lastenheft: Auftraggebersicht Pflichtenheft: Auftragnehmersicht Vertragsgegenstand ist das (verfeinerte) Pflichtenheft Vorgehensweise Outside-in: Zuerst Systemumgebung modellieren, dann Systeminterna modellieren Inside-out: Zuerst Systeminterna modellieren, dann Systemumgebung modellieren 8

9 2. Lastenheft Aufgabe Zusammenfassung aller fachlichen Basisanforderungen Produktbeschreibung aus Sicht des Auftraggebers Beschreibung des WAS nicht des WIE Stakeholder Auftraggeber, Projektleiter, Anwendungsspezialist, fachlicher Entwickler Sprache Verbale Schrift, Diagramme, Graphiken Nummerierung jeder Anforderung Beispiel: siehe weitere Vorlesungsunterlagen 9

10 Einschub Projektmanagement Gantt-Diagramm (Ablaufplan) 10

11 Während der Projektplanung wird das Projekt in Aufgaben unterteilt Jede Aufgabe wird bezüglich ihres Aufwands, ihrer Zeit und ihrer Kosten geschätzt (Soll-Ist) Regelmäßige Soll-Ist Analysen sind wichtig Beispiel: Anforderung_nr: 433 Aufgabe_nr: 23 Funktion: UserLogin() Aufwand: 2 Personen Zeit: a` 2 Manntage Kosten: 8h*2Personen*2Tage* 80Euro/h = 2560 Euro 11

12 Gesamtkosten Projekt bestehen hauptsächlich aus HW-, SW-Kosten, Wartung Reisekosten, Schulungskosten Personalkosten SW-Entwicklerkosten Raumkosten (Heizung, Beleuchtung, Miete) Supplementäres Personal: techn. Personal, Sekretärinnen,... Kommunikationskosten (Netze, ,...) Kosten für zentrale Einrichtungen: Druckereidienste Sozialversicherungen (SV, KV, Mitarbeiterzuwendungen, Renten...) 12

13 Produktivität Analogie Fertigungssystem: Produktivität = produzierte Stückzahl / Anzahl für die Produktion erforderlichen Personenstunden Produktivität in SW-Systemen unterliegt anderen Regeln Unterschiedliche Problemlösungen möglich SW hat Performance- bzw. Effektivitätsunterschiede die nicht mit obiger Formel berechnet werden können Maße für SW-Produktivität Größenspezifische Maße: LOC (Lines ofcode), Anzahl gelieferter Objektcodeanweisungen, Anzahl Seiten der Dokumentation Funktionsspezifische Maße: Function Points, Object Points 13

14 Einflussfaktoren auf die Produktivität Erfahrungen im Anwendungsgebiet Kenntnisse ermöglichen effektive SW Entwicklung Prozessqualität Verwendetes Vorgangsmodell Projektgröße Beispiel: große Projekte erfordern mehr Kommunikation Techn. Unterstützung Gute Hilfstools Arbeitsumgebung Persönliches Wohlbefinden 14

15 LOC Probleme Keine Standards zur Zählung vorhanden Programmiersprachenabhängig Ausführliche Programmierung versus komprimierter Programmierung Datendeklarationen Leerzeilen Aussagekraft? Guter oder schlechter Code nicht unterscheidbar Produktivitätsvergleiche zwischen Systemen sind nur mit Vorbehalten durchführbar 15

16 Function Points Albrecht (1979), Gaffney 1983) Sprachunabhängig Produktivität zwischen Systemen kann verglichen werden Ein FP wird pro Personenmonat erzeugt Eignet sich für Ein- und Ausgabeorientierte Datenverarbeitungssysteme Gesamtanzahl Function Points = Messung der Anzahl von Externen Ein- und Ausgaben Benutzerinteraktionen Externe Schnittstellen Vom System verwendete Dateien 16

17 Function Points Gewicht: Jede Funktion hat Komplexitätswert (z.b. einfach 1 bis komplex 10) UFC: Unadjusted Function Point Count UFC= Σ(Anzahl der Häufigkeit der Funktion * Gewicht) Weitere Faktoren die mit UFC multipliziert werden können Grad verteilte Verarbeitung Ausmaß Wiederverwendbarkeit Leistungsfähigkeit... Folge: subjektive Schätzung AVC: Durschnittliche Codegröße einer Programmiersprache Codegröße = AVC * Anzahl Function Points 17

18 Function Points (Balzert, Lehrbuch SW-Technik, S.86) 18

19 Object Points Banker et al. (1992) Einsetzbar wenn 4GLs oder vergleichbare Sprachen eingesetzt werden Schätzmodell COCOMO2 verwendet Ops OP!= Klassen OP = Anzahl der angezeigten Bildschirmmasken (einfache =1 OP, komplexe=3 OPs) Anzahl erzeugter Berichte (einfache =2 OP, komplexe=8 OPs) Anzahl der 3GL Module (höhere Programmiersprache), die zur Ergänzung des 4GL Codes entwickelt werden müssen (1 Modul = 10 Ops) Einfacher zählbar als Function Points 19

20 Probleme bei Maßen mit Volumen/Zeit Nicht-funktionale Eigenschaften der SW werden nicht berücksichtigt Zuverlässigkeit, Wartungseigenschaften, Verbesserung von Code,... Wiederverwendung wird nicht berücksichtigt Sie setzen voraus: Mehr = Besser Manager sollten daher geschult werden und vorsichtigen Umgang mit diesen Maßen pflegen 20

21 Schätzverfahren Algorithmisches Aufwandsmodell * LOC/Projektkosten Expertenbeurteilung Mehrere Schätzungen werden gemittelt oder sich auf eine geeinigt Analogieschätzung Kosten analog zu abgeschlossenem ähnlichen Projekt schätzen Parkinsons Gesetzt Arbeit dehnt sich immer so aus, dass sie genau die Zeit braucht, die man für sie erübrigen kann. Kosten = verfügbare Ressourcen und Lieferfrist Price to win Kosten = Kunden-Budget 21

22 Algorithmisches Aufwandsmodell Kann durch Analyse der Kosten und Merkmale abgeschlossener Projekte entstehen Schätzung der Kosten aufgrund Projektgröße Anzahl SW-Designer, SW-Entwickler Prozess- und Produktfaktoren Exponentialfaktor Kosten steigen nicht linear mit Projektumfang Multiplikatoren können Merkmale berücksichtigen Merkmale des Produkts Entwicklungsplattformen Prozess- und Personenmerkmale (z.b. Erfahrungsgrade) 22

23 Allgemeine Formel für Softwarekosten Aufwand = A * Größe B * M (Kitchenham 1990) A: konstanter Faktor für Unternehmenseigene Praktiken und Art der SW Größe: Schätzung der Größe LOC, Function Points oder Object Points B: Aufwand für übergroße Projekte und liegt zwischen 1,0..1,5 M: Multiplikator und setzt sich aus einer Kombination von Prozess-, Produkt- und Entwicklungsmerkmalen zusammen 23

24 Unsicherheit der Schätzung (Sommerville, SE, S.529 aus Boehm et al. 1995) 24

25 Das (algorithmische) COCOMO-Modell 81 COCOMO (engl. Constructive Cost Model) Basiert auf Erfahrungen Wasserfall-Modell und Neuentwicklung der SW Drei-Stufen-Modell 1. Grunddaten (grobe Schätzung) (Boehm, 1981) 2. Verbesserung durch Projekt- und Prozessmultiplikatoren 3. Einzel-Schätzung für verschiedene Projektphasen Frei verfügbar (Public Domain), gut dokumentiert Wird häufig verwendet 25

26 Das (algorithmische) COCOMO-Modell 81 (Boehm, 1981) KDSI: Kilo Lines of Delivered Source Instructions PM: Aufwand in Personenmonaten Projektkomplexität Formel Einfach PM=2,4*(KDSI) 1,05 *M Mittel PM=3,0*(KDSI) 1,12 *M Komplex, Eingebettet PM=3,6*(KDSI) 1,20 *M 26

27 Das (algorithmische) COCOMO-2 Komplexere und detailliertere Schätzung Basiert auf Verschiedene Vorgehensmodelle und Verfahren (z.b. Prototyp, Komponenten, 4GLs) Stufen sind mit Vorgängen im SW-Prozess verbunden ->frühe Schätzungen möglich Drei-Stufen-Modell 1. Frühe Prototypstufe: Größenschätzung mit Object Points 2. Frühe Entwurfsstufe: Systemanforderung abgeschlossen; Größenschätzung mit Function Points 3. Stufe nach Architekturenwurf: Genaue Schätzung 27

28 Teufelsviereck (Sneed, 1983) 28

29 4. Risikomanagement Risikokategorien Projektrisiken: Zeitplan, Ressourcen Personalveränderungen, Managementveränderungen, Nichtverfügbarkeit von HW/SW, Änderung von Anforderungen, Verzögerungen, Unterschätzung des Umfangs Produktrisiken: Qualität, Leistung Änderung von Anforderungen, Verzögerungen, Unterschätzung des Umfangs, schlechte CASE-Tools, unzureichende Hilfsmittel Wirtschaftliche Risiken: Auswirkung auf Unternehmen Technologieveränderungen, Konkurrenz 29

30 4. Risikomanagement Risikoerkennung Risikoanalyse Risikoplanung Risikoüberwachung Liste potentieller Risiken Priorisierte Liste pot. Risiken Risikovermeidungsplan, Notfallplan Risiko Bewertung 30

31 Lernziel 1. Was sind die Aufgaben und Ergebnisse der Planungsphase? 2. Welche Schätzverfahren gibt es für den Aufwand einer SW? 3. Was sind Ziele des Risikomanagements? 31