Software Engineering. Prof. Dr. Stefan Enderle NTA Isny

Transkript

1 Software Engineering Prof. Dr. Stefan Enderle NTA Isny

2 3 Software Entwicklungsprozesse

3 Softwareentwicklung Systematisches Vorgehen wichtig Zeitlicher Ablauf durch Vorgehensmodell Meist grundlegender Aufbau: Analyse Entwurf Implementierung Test Übergreifend: Projektmanagement Qualitätssicherung A Analyse PM Projektmanagement E Entwurf I Implem. QS Qualitätssicherung T Test

4 Softwareentwicklung Aufbau auch für Wartung denkbar: Problem A Analyse PM Projektmanagement E Entwurf I Implem. QS Qualitätssicherung T Test Produkt A Analyse PM Projektmanagement E Entwurf I Implem. QS Qualitätssicherung T Test Wartung

5 3.1 Vorgehensmodelle Vorgehensmodell = Strategie zur Durchführung eines Projektes Auch Makroprozesse, da nur der Gesamtprozess betrachtet wird (nicht die einzelnen Schritte). Bisheriger Ansatz enthält weder Abfolge noch Abhängigkeiten! PM Projektmanagement A Analyse E Entwurf I Implem. T Test Verschiedene Vorgehensmodelle denkbar QS Qualitätssicherung

6 Build and Fix Cycle Einfachstes Vorgehen: Problem als Idee Entwurf passiert im Kopf Implementierung und Test so lange, bis eigene Qualitätsansprüche erfüllt sind. Bei Änderungswünschen im Betrieb erfolgt direkte Änderung durch den Programmierer Keinerlei Dokumentation Keine Stuktur (Analyse, Entwurf,...) Alle Schritte durch einen Programmierer Qualität kann hoch sein! Wartung/Änderung nur durch Programmierer Industrieller Einsatz riskant

7 Software Life Cycle Pomberger, Blaschek Software Engineering 1993 Strukturiertes Vorgehen! Starrer Ablauf: Anforderungen Analyse Entwurf Implementierung Test Inbetriebnahme Wartung Spätere Änderungen nur als neues Projekt möglich Änderungen während der Entwicklung nicht möglich

8 Software Life Cycle

9 Wasserfallmodell Fast gleicher Ablauf: Anforderungen Analyse Entwurf Implementierung Test Betrieb Rückwärtsschritt auf direkten Vorgänger möglich Aber keine Überlappung! OK, wenn alle Mitarbeiter gleichzeitig an einem Arbeitsschritt arbeiten können (kleine Arbeitsgruppe). Bei großen Gruppen aufgrund unterschiedlicher Qualifikation der Mitarbeiter unmöglich.

10 Wasserfallmodell

11 V Modell 6 Phasen: Anforderungsanalyse Systementwurf Entwurf und Implementierung der Module Modultest Systemintegration Systemabnahme Letzte 3 Phasen bilden Tests für erste 3 Phasen: Modultest testet Implementierung einzelner Module Systemintegration prüft Korrektheit des Systementwurfs Systemabnahme prüft Erfülltheit der Anforderungen

12 V Modell Sicht = Produkte einer Schicht + Tests

13 V Modell Statt Sicht wird auch Modell verwendet: Anwendermodell: Anforderungsanalyse Systemspezifikation Abgenommenes System Architekturmodell: Technische Spezifikation evtl. Teilsystemspezifikation Getestete Teilsysteme Getestetes System Implementierungsmodell: Modulspezifikation Getestete Module

14 V Modell Bewertung: V Modell strukturiert Ablauf ähnlich dem Wasserfallmodell (Sequenzielle Abfolge von Phasen) Fortschritt: Zusammengehörigkeit von Produkten und Tests Anfälligkeit für Fehler in früheren Phasen bleibt Wird sehr oft verwendet! (Öffentliche Projekte)

15 Spiralmodell Soll Projektrisiken begrenzen Jeweils 4 Phasen, die mehrmals durchlaufen werden können: Zielbestimmung: Bestimmen der genauen Ziele und Produkte des Durchlaufs Risikoanalyse: Bewertung der Ziele (und Alternativen) unter Berücksichtigung von Restriktionen. Finden von Risiken und ggfs. Lösungsstrategien. Beispiele: Umfragen, Prototypen, Simulation Produkterstellung: Vorgesehene Produkte werden erstellt Planung nächste Phase: Basierend auf Review der Produkte wird nächster Zyklus geplant

16 Spiralmodell Eine mögliche Ausprägung mit 4 Durchläufen: Letzter Zyklus erst nach Entfernen aller Risiken Systemerstellung z.b. durch eingebettetes Wasserfall oder V Modell

17 Spiralmodell

18 Spiralmodell Bewertung: Für sehr große Projekte Anzahl Durchläufe ergibt sich erst während des Projektes Dadurch Kosten und Zeitplanung schwierig Sehr erfahrener Projektleiter nötig

19 Inkrementelles Modell Bei Wasserfall und V Modell: Abgeschlossene Analyse Voraussetzung für Entwurf und Implementierung. D.h., alle Anforderungen müssen restlos geklärt sein. Kunde bekommt am Ende fertiges System als Ganzes Bei großen Projekten evtl. mehrere Jahre Wartezeit für Kunden evtl. Änderung der Anforderungen aufgrund langer Laufzeit Sofortige Änderung nach Auslieferung oder Einschränkung für Kunden Idee: Bei ausreichender Anzahl Anforderungen wird mit Entwurf und Implementierung gestartet Schrittweise Erweiterung bei weiteren Anforderungen

20 Gute Reaktion auf verändernde Anforderungen durch hochmodulare Systemarchitektur Inkrementelles Modell Eigenschaften (Balzer '89): Stufenweise Entwicklung Steuerung durch Erfahrung der Entwickler und des Kunden mit wachsendem Produkt Wartung = Erstellung einer neuen Version Gut geeignet, wenn Kunde Anforderungen noch nicht überblickt oder diese nicht formulieren kann Vorantreiben der Entwicklung durch Code. Lauffähige Programmteile als Hauptinteresse. Installation von Systemteilen beim Kunden möglich: Erfüllen von Teilen der Anforderungen

21 Inkrementelles Modell Auslieferung in mehreren Builds Alle Entwickler erweitern parallel ihre Modelle

22 Inkrementelles Modell Bewertung: Haupt Rikiso: Systemarchitektur für verändernde Anforderungen nicht mehr geeignet. Idee: Alle Anforderungen, die Systemarchitektur beeinflussen können, müssen vor erstem Entwurf bekannt sein. Projektleiter mit Erfahrung!

23 3.2 Mikroprozesse Arbeitsschritte und Tätigkeiten Besprochene Vorgehensmodelle: Build and Fix Cycle Software Life Cycle Wasserfallmodell V Modell Spiralmodell Inkrementelles Modell Steht das Vorgehen fest, so muss der Projektleiter allen Mitarbeitern die konkreten Tätigkeiten vorgeben. Meist standardisiert im Software Entwicklungsprozess des Unternehmens. Evtl. Erweitern / Weglassen durch Projektleiter

24 Arbeitsschritte Typische Arbeitsschritte in der Entwicklung: Analyse Entwurf Implementierung Test Jeder Arbeitsschritt besitzt unterschiedliche Sicht auf den Gegenstand des Projekts (Kundensicht / techn.sicht) Weitere Arbeitsschritte Inbetriebnahme und Wartung Projektmanagement Arbeitsorganisation Qualitätsmanagement

25 Arbeitsschritte detaillierter Analyse Gespräch mit Kunden Ermitteln der Anforderungen an System Beschreiben der Anforderungen (z.b. in objektorientiertem Systemmodell) Grobe Projektplanung für Realisierung Entwurf Technische Planung des Systems Treffen von Vorbereitungen Erstellen des Testplans (Korrekte Funktion + Anforderungen)

26 Arbeitsschritte detaillierter Implementierung Umsetzung des Entwurfs in einer Programmiersprache Erstellung eines lauffähigen und lieferbaren Systems (Erstellung von Modulen + Integration) Test Korrektheit des Systems in Bezug auf Technik Korrektheit des Systems in Bezug Kundenanforderungen

27 Arbeitsschritte detaillierter Inbetriebnahme und Wartung Inbetriebnahme des Systems (Installation, Start, Einweisung) Beheben von auftretenden Fehlern Klein Projekte für weiteren Änderungen der Anforderungen Projektmanagement Garantie des korrekten Projektablaufs nach oben Teambildung Planung von Tätigkeiten Kontrolle von Tätigkeiten Organisation und Koordination von Tätigkeiten

28 Arbeitsschritte detaillierter Arbeitsorganisation Konkrete Zuteilung von Arbeit an Mitarbeiter Berücksichtigung von Fähigkeiten, Verfügbarkeiten (aktuell) Qualitätsmanagement Prüfen der Einhaltung von Qualitätskriterien Stetige Verbesserung des Entwicklungsprozesses

29 Tätigkeiten und Aktivitäten Arbeitsschritte bezogen sich auf mehrere Rollen Tätigkeiten Arbeit einer Rolle innerhalb eines Arbeitsschrittes Gegenstand von konkreten Arbeitsaufträgen durch Gruppen oder Projektleitung Aktivität Kleinste Arbeitseinheit kann von einer Person durchgeführt werden Eine Tätigkeit besteht i.a. aus mehreren Aktivitäten

30 Tätigkeiten und Aktivitäten Beispiel: Arbeitsschritt Test Tätigkeiten der Rolle Tester Tätigkeiten können weiter unterteilt werden Aktivitäten

31 Zusammenfassung

32 3.3 Produkte Produkte = überprüfbares Resultat eines Projekts Mehr als ausführbares Applikation! Wichtig zu Beginn eines Projektes Welche Produkte werden erstellt? In welchen Merkmalsausprägungen?

33 Produktmerkmale Zweck: Der Zweck des Produkts muss klar sein. (Bsp: Anforderungsanalyse: Verstehen des Kundenwunsches Schulung: Weiterbildung / Festigung / Überprüfung) Zielpublikum: Kunde / Projektgruppe / Management Ausdrucksform unterschiedlich Granularität unterschiedlich Umfang unterschiedlich

34 Produktmerkmale Art: Dokument Technisches Produkt (auch Software) Leistung (durch Person) Detailgrad: Abhängig von Zielpublikum Zu genau: viel Aufwand bei der Erstellung Zu ungenau: Anfälligkeit für Fehler/Unklarheiten

35 Reifestufen: Produktmerkmale

36 Produktmerkmale Abnahmekriterien: Abnahmekriterium pro Produkt Wenn OK, wird das Produkt in dieser Form verwendet Bei Dokumenten: Übergang von Vorschlag zu Version Referenzen: Bezug auf andere Produkte (Produktversionen) Zeitpunkt der Erstellung: Abhängig vom Projekt Bsp: Testplan kann während Analyse, Entwurf oder Implementierung erstellt werden

37 Typische Produkte

38 Grundlagen für Software Projekte Begriffe: Begriffe der Software Entwicklung Begriffe der Anwendungs Domäne Dokumentationsrichtlinien: Aufbau (Titelblatt, Inhaltsverzeichnis, Kapitel,...) Aussehen (Schrift, Absätze, Tabellenformat,...) Format, Datentyp (Papier, PDF) Dokumentationsstruktur: Standarddokumente pro Projekt (Anforderunsanalyse, Tagesbericht, Testplan,...)

39 Grundlagen für Software Projekte Produktvorlagen: Hilfe für Neuerstellung von Produkten Änderungsmanagement: Beschreibung der Mechanismen, die bei Änderung von Produkten gestartet werden müssen Versionsmanagement: Benennung von Versionen Archivierungsdauer von Versionen

40 Grundlagen für Software Projekte Archivierungssystem: Speicherung und Wiederfinden von Produkten Meist Verantwortlicher für Archivierung Geeignete Werkzeuge Konventionen für Namen, Verzeichnisse,... Checklisten: Überprüfung der Produkte durch Ersteller Übereinkunft zwischen Ersteller und Prüfer