Vorlesung "Software-Engineering" Rainer Marrone, TUHH, Arbeitsbereich STS Vorige Vorlesung Einführung in die durch Software-Engineering gelösten Probleme Charakterisierung von Software-Qualität Heute Überblick: Aufgaben und Phasen der Softwareentwicklung Projektphasen und Vorgehensmodelle 1
Projektmanagement Aufgaben und Phasen der Softwareentwicklung Projektplan, Meilenstein Prozeßmodelle (auch Vorgehensmodelle genannt) Wasserfall-, V-, Prototypen-, Evolutionäres-, Inkrementelles-, Spiralmodell, Unified Process, Lernziele Prozeßnotation, -modell und -plan unterscheiden können. Hauptaufgaben beim Prozeßmanagement wiedergeben können. Prozeßmodelle wiedergeben können. 2
Projektablauf Individualsoftware Auftraggeber Anfrage (Analyseauftrag) Auftragnehmer Anforderungsermittlung Angebot (Leistung, Preis) Auftrag Produkt (AG) Abnahme, Bezahlung Wartung, Support (AN) Schwerpunkt Standardsoftware Kunde Bezahlung SW-Hersteller Customer Services Entwicklung Produkt s.o. Support 3
SW-Engineering als kooperative Aktivität (1) Aufgaben überlappen sich! Arbeitsaufteilung größerer Software-Entwicklungsteams in verschiedene Ebenen: Programmierung: Programmierer, Entwickler, Kodierer, Datenbank- Administrator (DBA), Mediendesigner,... Implementierung und Anpassung von Komponenten Softwarearchitektur: Software- / System-Architekt Analyse und Design Definition von Komponenten und Protokollen Projektmanagement: Projekt-, Gruppen- und Abteilungsleiter Anforderungsermittlung Kostenplanung, Ressourcenverteilung Projektplanung und Controlling Gruppenkommunikation und Führung technische Kompetenz Abstraktions- und Kommunikationsfähigkeiten betriebswirtschaftliche und soziale Kompetenz 4
Von Handarbeit zur Ingenieursdisziplin Historisch: implizite, informelle, anonyme, zufällige SW-Architekturen Projekt- und Produktgetrieben Ziel: Erhöhung der Produktivität und Planungssicherheit großer Softwareprojekte durch explizite, formale, benannte und geprüfte Vorgehensweisen: Verbesserte Kommunikation im Projekt-Team Erhöhtes Wissen am Ende der Software-Engineering-Ausbildung Verfügbarkeit eines Katalogs von Vorgehensmodellen (Handbuchartiges Wissen; vgl. Knuth / Sedgewick bei Algorithmen) (Formale Modelle zum Testen, Verifizieren, Nutzen und Messen von Modellen). Hindernisse Altsysteme ( legacy ), bestehendes (veraltetes) Wissen, Personal, Organisation,... Schneller Fortschritt der Technik und Anwendungen Status: Software-Engineering als sich entwickelnde extrem flexible Informatik-Disziplin, die sich sogar dem Reifegrad der Standard- Ingenieursdisziplinen annähert. 5
Evolution einer Ingenieursdisziplin wissenschaftlich fundierte Produktionstechnik vorgegebene Produktionsmittel Handarbeit Kommerz professionelle Ingenieursdisziplin Mary Shaw 96 Talentierte Amateure Intuition und brute force Zufälliger Fortschritt Fallweiser Austausch Benutzung vorhandener Materialien Herstellung für Benutzung statt Verkauf Erfahrene Handwerker Etablierte Verfahren Pragmatische Verbesserungen Ökonomische Aspekte: Kosten und Materialien Handarbeit für den Verkauf Ausgebildete Profis Analyse und Theorie Fortschritt basiert auf Wissenschaft neue Anwendungen durch Analyse Markt-Segmentierung und Produktvielfalt 6
Phasen der Softwareentwicklung Planungsphase Lastenheft Vorgaben und Rahmenbedingungen aus der Planungsphase vage, verschwommene, unzusammenhängende, unvollständige,widersprüchliche Anforderungen Definitionsphase Definitionsprozeß Produkt-Definition Entwurfsphase vollständige, konsistente, eindeutige und durchführbare Produktanforderungen Prüfung gegen Produkt- Definition Produkt-Entwurf Implementierungsphase Programme Abnahme & Einführungsphase Installiertes Produkt Legende: Phase Phasenergebnis Weitergabe von Teilprodukten aus [Balzert] 7
Aufgaben beim Software-Projektmanagement Erstellung eines Projektplans Auswahl einer Prozeßnotation Auswahl eines Prozeßmodells Planung Organisation Definitionen Software-Entwicklungsprozeß: Aktivitäten, Methoden und Verfahren zur Entwicklung und Überprüfung von Software. Planung: Planung ist Entscheiden im voraus, was zu tun ist, wie es zu tun ist, wann es zu tun ist und wer es zu tun hat. [~ Koontz, O Donnell 72] 8
Begriffe der Prozeßmodellierung 3 Abstraktionsebenen Planung Projektplan Wird für jedes konkrete Software-Projekt erstellt (Projektleiter). Beispiel: Projektkalender, Gantt-Chart konkretisiert Prozeßmodell Generelles Vorgehen (z.b. einer Firma) zum Entwickeln eines Software-Produkts. Auch: Vorgehensmodell. Beispiel: Wasserfall-Modell, Evol. Modell Organisation beschreibt Prozeßnotation Sprache zur Spezifikation des Ablaufs von Software-Entwicklungen. Beispiel: UML 9
Making a Gantt chart Step 1 list the tasks in the project 10
Making a Gantt chart Step 2 add task durations 11
Making a Gantt chart Step 3 add dependencies (which tasks cannot start before another task finishes) 12
Notes The arrows indicate dependencies. Task 1 is a predecessor of task 2 i.e. task 2 cannot start before task 1 ends. Task 3 is dependent on task 2. Task 7 is dependent on two other tasks Electrics, plumbing and landscaping are concurrent tasks and can happen at the same time, so they overlap on the chart. All 3 can start after task 4 ends. Painting must wait for both electrics and plumbing to be finished. Task 9 has zero duration, and is a milestone 13
Making a Gantt chart Step 4 find the critical path The critical path is the sequence of tasks from beginning to end that takes the longest time to complete. It is also the shortest possible time that the project can be finished in. Any task on the critical path is called a critical task. No critical task can have its duration changed without affecting the end date of the project. 14
MS Project can work out the critical path for you! The length of the critical path is the sum of the lengths of all critical tasks (the red tasks 1,2,3,4,5,7) which is 2+3+1+1.5+2+1 = 10.5 days. In other words, the minimum amount of time required to get all tasks completed is 10.5 days The other tasks (6,8) can each run over-time before affecting the end date of the project 15
The amount of time a task can be extended before it affects other tasks is called slack (or float). Task 6 can take an extra day and a half before it affects the project s end date, so each has 1.5 day s slack. 16
Prozeßmodelle Prozeßmodell definiert: durchzuführende Aktivitäten Definition der Teilprodukte Fertigstellungskriterien Mitarbeiterqualifikationen Verantwortlichkeiten und Kompetenzen Standards, Richtlinien, Methoden und Werkzeuge Hier verwendete Notation: Boxes and Arrows Aktivität führt zu geht ein Produkt häufig auch ohne Produkte (Dokumente) dargestellt 17
Naives SWT-Grundmodell: Code & Fix Grundmodell aus den Anfängen der Softwaretechnik: Code & Fix code Prg. fix Schreibe ein Programm. Finde und behebe die Fehler im Programm. Nachteile Fehlerbehebung strukturiert Programm so um, daß weitere Fehlerbehebungen und die Weiterentwicklung immer teurer werden. Entwurfsphase wird nötig. Selbst gut entworfene Software wird von den Benutzern oft nicht akzeptiert. Definitionsphase vor dem Entwurf wird nötig. Fehler sind schwer zu finden, da Tests schlecht vorbereitet und Änderungen unzureichend durchgeführt wurden. Separate Testphase wird nötig. Folge: Entwicklung einer Reihe von besseren Modellen. 18
Vorgehensmodelle Vereinfachte Beschreibung eines Softwareprozesses Abstraktion eines tatsächlichen Prozesses Kombinierbar innerhalb des Softwareprozess Softwarespezifikation Softwareentwurf und implementierung Softwarevalidierung Weiterentwicklung von Software 19
Vorgehensmodelle im Überblick Wasserfallmodell V-Modell Prototypmodell Evolutionsmodell Spiralmodell (Rational) Unified Process 20
Das Wasserfallmodell (1) System- Anforderungen Software- Anforderungen Weiterentwicklung des stufenorientierten Modells Sukzessive Stufen der Entwicklung mit Rückkopplung Analyse Entwurf Royce 1970 Codierung Test Betrieb 21
Das Wasserfallmodell (2) Charakteristika Aktivitäten sind in der richtigen Reihenfolge und vollen Breite durchzuführen Am Ende jeder Aktivität steht ein Dokument (dokumentgetriebenes Modell) Entwicklungsablauf ist sequentiell, vorhergehende Aktivität muß beendet werden, bevor die nächste beginnt Orientiert am Top-down-Vorgehen Einfach, verständlich, wenig Managementaufwand Benutzerbeteiligung nur in der Definitionsphase Nachteile Notwendige Kurskorrekturen nicht frühzeitig erkennbar Sequentialität nicht immer nötig Gefahr, daß Dokumente wichtiger als das System werden Risikofaktoren werden u.u. zu wenig berücksichtigt 22
Das V-Modell (1) Erweiterung des Wasserfall-Modells, das Qualitätssicherung integriert Verifikation und Validation werden Bestandteile des Modells Are we building the product right? Verifikation: Überprüfung der Übereinstimmung zwischen Software- Produkt und seiner Spezifikation Are we building the right product? Validation: Eignung bzw. Wert eines Produkts bezogen auf seine Einsatzzweck 23
Das V-Modell (2) Anforderungs- Definition Anwendungsszenarien Abnahmetest Grobentwurf Testfälle Systemtest Feinentwurf Testfälle Integrationstest Boehm 1979 Modul- Implementierung Testfälle Modultest Entwickelt ab ~1990 für Bundeswehr und später für weitere Behörden (Bundesverwaltung). Submodelle für Systemerstellung (SE), Qualitätssicherung (QS), Konfigurationsmanagement (KM) und Projektmanagement (PM). Ursprünglich für eingebettete Systeme entwickelt. 24
Das V-Modell: Bewertung (3) Vorteile Integrierte, detaillierte Beschreibung von Systemerstellung, Qualitätssicherung, Konfigurationsmanagement und Projektmanagement Generisches Vorgehensmodell Gut geeignet für große Projekte Nachteile Unkritische Übernahme der Konzepte, die für eingebettete Systeme entwickelt wurden, für andere Anwendungstypen Software-Bürokratie bei kleinen & mittleren Projekten Ohne CASE-Unterstützung nicht handhabbar 25
Das Prototypen-Modell (1) Probleme traditioneller Modelle: Auftraggeber / Endbenutzer können oft Anforderungen nicht vollständig / explizit formulieren. Dies ist aber in klassischen Definitionsphasen nötig! Kooperation zwischen Anwendern und Entwicklern endet mit der Definitionsphase: Entwicklungsabteilungen ziehen sich nach Definitionsphase zurück und präsentieren erst nach Fertigstellung das Ergebnis; wünschenswerte Koordination zum Lernen von den jeweils anderen unterbleibt Oft existieren unterschiedliche Lösungswege, die besser experimentell erprobt werden und mit dem Auftraggeber diskutiert werden können. Manche Anforderungen lassen sich theoretisch nicht garantieren (z.b. Echtzeitanforderungen). Vor dem Abschluß der Definitionsphase muß also ggf. einiges ausprobiert werden. Das Überzeugen des Auftraggebers von der prinzipiellen Durchführbarkeit oder Handhabung einer Idee während der Akquisitionsphase wird nicht unterstützt (Folge für Verantwortungsteilung, Mittelfluss, etc). 26
Das Prototypen-Modell (2) Begriffsbestimmung Software-Prototyp: (im Gegensatz zum Begriff in anderen Ingenieursdisziplinen) Ein Software-Prototyp...... ist nicht das erste Muster einer großen Serie (beliebig kopierbar, Massenfertigung)... ist keine Simulation, sondern zeigt ausgewählte Eigenschaften des Zielprodukts im praktischen Einsatz (vgl. z.b. Windkanal oder Architekturmodell)... dient zum Klären von relevanten Anforderungen oder Entwicklungsproblemen.... dient als Diskussionsbasis für Entscheidungen.... dient zu experimentellen Zwecken und Sammeln von praktischen Erfahrungen. Vorgehensweise: prototyping 27
Das Prototypen-Modell (3) nach Balzert Arten von Software-Prototypen: Demonstrationsprototyp: Dient zur Auftragsakquisition; verschafft Eindruck, wie das Produkt aussehen kann. Wichtig: Wird später weggeworfen! Prototyp im engeren Sinne: Wird parallel zur Modellierung des Anwendungsbereiches erstellt, um Aspekte der Benutzungsschnittstelle oder Teile der Funktionalität zu veranschaulichen. Dient zur Analyse. (Exploratives Prototyping) Labormuster: Dient zur Beantwortung konstruktionsbezogener Fragen und Alternativen. (Experimentelles Prototyping) Pilotsystem: Dient nicht nur zur experimentelle Erprobung oder Veranschaulichung, sondern ist schon Kern des Produkts. Unterscheidung zwischen Prototyp und Produkt verschwindet später. Die Weiterentwicklung erfolgt in Zyklen unter Beteiligung der Benutzer. Es ist ein wesentlich sorgfältigerer Entwurf nötig, da dieser Prototyp später weiterbenutzt wird! Benutzerdokumentation wird ebenfalls nötig. (Evolutionäres Prototyping) Prototyp Pilot Produkt 28
Das Prototypen-Modell (4) Ein fertiges Software-Produkt besteht aus vielen Komponenten und Ebenen. Unterscheidung zwischen horizontalen und vertikalen Prototypen: Benutzungsoberfläche horizontaler Prototyp Anwendung horizontaler Prototyp Netzanbindung Datenhaltung Systemsoftware vertikaler Prototyp vertikaler Prototyp 29
Das Prototypen-Modell: Bewertung Vorteile: Reduktion des Entwicklungsrisikos durch frühzeitige/stärkere Rückkopplung. Sinnvoll in andere Prozeßmodelle integrierbar. Prototypen sind durch geeignete Werkzeuge schnell erstellbar. Rapid Prototyping Nachteile Höherer Entwicklungsaufwand. Gefahr, daß ein Wegwerf -Prototyp nicht weggeworfen wird. Prototypen werden oft als Ersatz für Dokumentation angesehen. 30
Das evolutionäre/inkrementelle Modell Beobachtung: Software-(Weiter) Entwicklung unterliegt Änderungen Lernen zwischen Entwicklern und Anwendern nötig, da Veränderungen im technischen und Einsatzkontext stattfinden sich durch den Einsatz des Systems neue Anforderungen ergeben Systementwicklung in Ausbaustufen, inkrementelle Entwicklung, Prototyping Herstellung Systemgestaltung Projektetablierung Revisionsetablierung Projektabschluß Einsatz Entwickleraufgabe Pflege Nutzung Nutzeraufgabe Systemspezifikation Software- Realisierung Entwickleraufgabe Umfeld- Vorbereitung Nutzeraufgabe System- Version 31
Erweiterung: Das Spiralmodell (1) Das Spiralmodell ist eigentlich ein Modell höherer Ordnung Für jedes (Teil-)Produkt sind zyklisch vier Schritte zu durchlaufen: Schritt 1: Identifizierung der Ziele des Teilprodukts (Leistung, Funktionalität, Anpaßbarkeit,...) Alternative Möglichkeiten zur Realisierung des Teilprodukts finden. Randbedingungen bei verschiedenen Alternativen finden Schritt 2: Evaluierung der Alternativen unter Berücksichtigung aller Alternativen Identifizieren und ggf. Überwinden von Risiken (durch Prototypen, Simulation,...) Schritt 3: Abhängig vom Risiko wird ein Prozeßmodell festgelegt (oder eine Kombination). Anwendung des Modells Schritt 4: Planung des nächsten Zyklus, Überprüfung der nächsten 3 Schritte im nächsten Zyklus, Einverständnis mit Beteiligten sichern. 32
Das Spiralmodell (3) 1 2 Boehm, Barry: A Spiral Model of Software Development and Enhancement. ACM SIGSOFT Software Engineering Notes, August 1986; 4 3 Boehm, Barry: A Spiral Model of Software Development and Enhancement. IEEE Computer, Vol.21, Ausg. 5, Mai 1988, pp 61-72. 33
34
35
Unified Process Inception: festlegen der Geschäftsziele und des Umfangs des Projekts. Elaboration: sammeln detaillierter Anforderungen, Analyse und Design auf höhere Ebene. Basisarchitektur und Plan für die Umsetzung. Construction: iterativ und inkrementell Jede Iteration resultiert in Prototypen die Produktqualität haben und die Teilmengen der Anforderungen implementieren. Transition: beta testing, performance tuning und Benutzertraining. Inception Elaboration Construction 1 2 3... Transition 36
Erster Schritt: Inception - Konzeptionalisierung Inception kann unterschiedliche Formen haben: Unterhaltung am Kaffeeautomat...... oder eine komplette Machbarkeitsstudie. Währender der inception phase wird das Geschäftsmodell definiert: Berechnung was das Projekt kostet. Abschätzung des Gewinns. Initiale Analyse ist notwendig damit der Umfang und die Größe des Projekts abgeschätzt werden können. Inception sollte höchstens einige Tage dauern und ermitteln ob es sich lohnt in die nächste Phase zu gehen. Sollen wir das Projekt weiter bearbeiten? 37
Zweiter Schritt: Elaboration - Entwurf Startet nach der go-ahead Vereinbarung. Es existieren i.d.r. nur vage Anforderungen: We are going to build the next generation customer support system for the Watts Galore Utility Company. We intend to use objectoriented technology to build a more flexible system that is more customer oriented - specifically, one that will support consolidated customer bills. Es muss ein bessers Verständnis des Problems erarbeitet werden : Was genau soll realisiert werden? Wie soll es realisiert werden? Welche Technologie soll verwendet werden? Elaboration bedeutet auch die Risiken des Projekts genau zu analysieren: Welche Umstände können zur Entgleisung führen? 38
Elaboration: System Analyse Rationale: Das Beheben und Auffinden von Fehlern nach der Auslieferung ist 100 mal teurer als während der Analyse oder innerhalb der Design Phase. Ziel der Analyse ist es ein Modell dessen was das System tun soll zu entwickeln. Sollte Informationen enthalten, die verstehen läßt was die Software in einer realen Umgebung leisten soll. Der Benutzer sollte das Analysemodell verstehen können. Die Analysephase liefert die Basis die Designphase. Die Analyse liefert die Anforderungen und die Definition der realen Umgebung(en) in der die Software existieren wird. Object-oriented analysis forces a seamless development process with no discontinuities because of continuous refinement and progressing from analysis through design to implementation. 39
Analyse: Actors, Steps, Deliverables Kundenanforderungen Entwickleranforderungen Problemanalyse Problem statement Prioritäten des Manager Model Design Repräsentiert durch Texte Spreadsheets Diagramme... 40
Design: Actors, Steps, Deliverables Problem statement Repräsentiert durch Domänenwissen Benutzer Interviews Real-world Erfahrungen Model Design z.b. UML Diagramme Use Cases Classes Interactions Packages States Activities... 41
Analyse: Erfassen von Anforderungen Identifizen typischer Use Cases/Anwendungsfälle des Zielsystems. Ein typischer Use Case im Kontext von Datenbanken: liste alle Kunden die ein bestimmtes Prokukt bestellt haben liste meine Top 10 Kunden Mahnbriefe sollen automatisch versandt werden Ein Entwickler antwortet mit Kostenschätzungen: Die Top 10 Kundenliste kann in einer Woche entwickelt werden. Die Mahnbrieffunktion dauert einen Monat. Use case 3 Use case 2 Use case 1 Der Kunde/Benutzer und der Entwickler einigen sich auf Prioritäten. 42
Elaboration: Planung Zuordnung der Use Cases zu Iterationsschleifen und Definition der Abgabetermine. Kunde weist den Use Cases Prioritäten zu. Entwicker analysiert architekturelle Risiken. Konzentration of technolgisch schwierige Use Cases. Entwickler muss sich den Risiken der Teminplanung bewußt sein. Abschätzung der Dauer jeder Iteration Berücksichtigung aller Schritte: Analyse, Design, Coding, Tests, Integration und Dokumentation.! Die Schätzungen sollten der Entwickler und nicht der Manager leisten. 43
UP: Iterationen Jede Iteration ist ein Projekt. Use case 1 Integration Use case 2 Demonstration Testing Testing Use case 3 Use case 4 Analysis Design Design Coding Coding Debugging Use case 5 Iteration 5 Iteration 4 Iteration 3 Iteration 2 Iteration Use Case driven system increments Innerhalb jeder Iteration durchläuft man Analyse, Design, Coding, Debugging, Integration und Demonstration der realisierten Use Cases duch eine Prototyp. 44
Transition Phase - Produktübergabe Freigabe des Produkts an die Benutzer Überprüfung des Qualitätslevels Auslieferung, Training,Einsatzunterstützung, Wartung Liefert:Release Milestone 45
RUP ist eine Instanz von UP RUP ist eine Instanz von UP 46
Wdhlg.: Zeitaufwand je nach Entwicklungsphase 47
Konsequenz Erfahrungsgemäß hohe Kosten bei Änderungen in späten Phasen rechtfertigen hohen Aufwand in frühen Phasen zur Vermeidung von späteren Änderungen Einfluß auf vorgeschlagene klassische Vorgehensmodelle Aber: Kostenreduktion durch aufwendiges Vorgehen in frühen Phasen umstritten These: Änderungen sind kaum vermeidbar Durch neue Vorgehensweisen soll Änderungsflexibilität erhalten bleiben 48
Weitere Ansätze Extreme Programming Agile Modeling Software Product Lines Component-Oriented Software Engineering Model-Driven Archicture... Wir greifen einige dieser Themen etwas später wieder auf. 49