Vorlesung Software-Engineering I

Transkript

1 Vorlesung Software-Engineering I im 3. und 4. Semester 11. Retrospektive Was lief gut? Was können wir verbessern? sto/public/modulplaene/t2inf2003.pdf SW-Engineering I Qualifikationsziele und Kompetenzen Die Studierenden kennen die Grundlagen des Softwareerstellungsprozesses. Sie können eine vorgegebene Problemstellung analysieren und rechnergestützt Lösungen entwerfen, umsetzen und dokumentieren. Sie kennen die Methoden der jeweiligen Phasen und können sie anwenden. Sie können Lösungsvorschläge für ein gegebenes Problem konkurrierend bewerten und korrigierende Anpassungen vornehmen. Die Studierenden können sich mit Fachvertretern über Problemanalysen und Lösungsvorschläge, sowie über die Zusammenhänge der einzelnen Phasen austauschen. Sie können einfache Softwareprojekte autonom entwickeln oder bei komplexen Projekten effektiv in einem Team mitwirken. Sie können ihre Entwürfe und Lösungen präsentieren und begründen. In der Diskussion im Team können sie sich kritisch mit verschiedenen Sichtweisen auseinandersetzen und diese erläutern. Sie bewerten die eingesetzten Technologien und schätzen ihre Folgen ab. Die Studierenden können sich selbsständig in Werkzeuge einarbeiten. Sie verbinden den Softwareentwicklungsprozess mit Techniken des Projektmanagement und beachten während des Projekts Zeit- und Kostenfaktoren. 3

2 Vorlesungsrückblick Vorlesung: Gruppenarbeit: Tool: 01 Einführung Produktkarton PPT 02 Vorgehensmodelle ConceptMap yed 03 Anforderungserhebung ProductBacklog EXCEL 04 Systematischer ti Architekturentwurf t Modularisierung i yed, EXCEL Schätzverfahren 05 Basiskonzepte (Sichten) Lastenheft Word 06 Datensicht ERM, DataDictionary yed, EXCEL 07 Abläufe Abläufe yed (BPMN) 08 Benutzeroberfläche GUI-Entwurf Pencil, yed 09 Dokumentation Offene-Punkte-Liste EXCEL 10 Präsentation Dokumentation PPT, PDF 11 Rückblick Retrospektive EXCEL 4 01-Einführung: Phasenmodell der Software-Entwicklung Vorgehensmodell // Beschreibung der Abarbeitung der Phasen Idee Auftrag Abnahme Bugfixes Analyse Spezifikation Entwurf Implementierung Test Einführung Wartung Auslauf Lastenheft Pflichtenheft Umsetzungs- Test- Dokumentation Entwurf Plan Dokumentation 5

3 01-Einführung: Software-Engineering, warum? Definitionen: Software: immateriell, nicht greifbar schnell änderbar => komplex, aufwändig, teuer in der Erstellung Engineering: Ingenieurmäßiges Vorgehen praxisgerecht, bewährt => formalisiert, nachvollziehbar, zielgerichtet => (vollständig, berechenbar, vorhersagbar) Ziel: Erfolgreich bessere Software erstellen! Sehr gute Arbeit! Aber sollten wir hier vielleicht nicht noch ein wenig detaillierter werden? 6 01-Einführung: schädliches Multitasking Typischer Projektstatus: Typischer Projektverlauf : Ergebnis Plan: Prj.1 Prj.2 Prj.3 Kosten Zeit Ist: Prj.1 Prj.2 Prj.3 Prj.1 Prj.2 Prj.3 Prj.1 Prj.2 Prj.3 Termin überschritten, Ergebnis noch nicht erreicht, aber noch Geld (Kosten)übrig. Mehrere Projekte werden parallel bearbeitet. Folge: keines der Projekte wird zum geplanten Termin fertig. Wo wird diese Erkenntnis schon anerkannt? Agile Techniken -> Fokussierung Projekt-Management -> CCPM (Engpassmanagement) Gesunder Menschenverstand bzw. eigene Erfahrung 7

4 01-Einführung: Der Abgrund zwischen Anwender und Programmierer Fachabteilung IT-Abteilung Problemdomäne Lösungsdomäne? Ideen, Beschreibungen, Prozesse, Dokumente, Hierarchien, Personen, Zuständigkeiten, Lastenheften, Pflichtenheften, Dokumentation, Abläufe, Objektzusammenhänge, Statusübergänge, Datenbanken, Technologien, UML, Sourcecode, 8 01-Einführung: Domänen und ihre Sprachen oder: vom Problem zur Lösung Modell Problem Lösung Programm Die reale Welt mit der Domäne der Fachabteilung Das Modell der Domäne Domänenspezifische Sprache (DSL) Die Problembeschreibung Im Kontext der Domäne Lastenheft Der Lösungsentwurf zur Abdeckung des Problems Pflichtenheft Die Umsetzung des Lösungsentwurfs Sourcecode Problemdomäne Lösungsdomäne 9

5 02-Vorgehensmodelle: Liste ausgesuchter Vorgehensmodelle Versuch und Irrtum: Cowboy Coding Inkrementell: Wasserfallmodell V-Modell (XT) Inkrementell Iterativ Agile Iterativ: Spiralmodell Rational R l Unified Process (RUP) Agile SW-Entw. (Scrum/XP/Kanban) Besondere Ausprägungen: Prototyping Modellgetriebene SW-Entwicklung (MDD) Feature-Driven-Development (FDD) Test-Driven-Development (TDD) 10 4C s 03-Anforderungserhebung: Typen von Anforderungen 1. Funktionale Anforderungen Anwendungsfälle Benutzeroberfläche Reports, Daten 2. Nicht Funktionale Anforderungen Antwortzeiten Zuverlässigkeit Benutzbarkeit 3. Rahmenbedingungen g Kosten, Termin Infrastruktur Sonstige Vorgaben, Standards Lastenheft Achtung: Abhängigkeiten/Wechselwirkungen sind zwischen den Anforderungs-Typen möglich! Anwendungsfall Anforderung Anforderung Anforderung Rahmenbedingung Anforderung 11

6 02-Anforderungserhebung: Veränderung von Anforderungen im Projektverlauf Quelle: OOSE Schätzverfahren: Dilbert: Aufwandsschätzung LinesOfCode FunctionPoints StoryPoints PersonenTage/Monate/Jahre Oracel, Poker, Wetter Ich mache einen Projektplan um die Ressourcen einzuteilen damit wir unsere Software ändern können. Also ich mache solche Änderungen in 10 Sekunden Fertig! Gute Arbeit! Aber ich wollte doch nur den Projektplan machen Wetter von Gestern 13

7 Ich steh da vor der weißen Tafel, wie fange ich an? 04-Systematischer Architekturentwurf: Zwiebelmodell wie weit gehe ich da? Theoretisch vom System bis zur Klasse möglich Gastdozenten : Gesamtsystem Markus Völter Michael Stal Sub-Systeme Komponenten Als Architekt gehe ich nur über drei Ebenen. (Nicht bis in unendliche Details abtauchen!) => Architektur vs. Design Basiskonzepte: SW-Architektur - Sichten auf das Produkt Abläufe: Daten: Zustände: Entwurf Umsetzung Hierarchien: 06-Datensicht (ERM,DD): 07-Abläufe (BPMN): 08-GUI: Module/Strukturen: 15

8 09-Dokumentation: Idee -> Übersicht -> Anforderungen -> Software-Architektur Konzept-Map: -> Themengruppen, Zusammenhänge Anforderungsliste: -> Anwendungsfälle Anforderungen, Ideen Produktkarton: -> Zielgruppe, Leistungsmerkmale SW-Architektur: -> Umsetzungsentwurf Module, Daten, GUI, Abläufe, Funktionen Dokumentation: Architektur-Review OPL offene Punkte -Liste Problem Lösungsvorschlag Wir treten einen Schritt zurück und betrachten nochmal das Ganze. Sind wir noch auf dem richtigen Weg? 17

9 09-Dokumentation: Architektur-Dokumentation Übersichtspräsentation (View) Generelles Vorgehen: von der Übersicht zur Detaillierung Dokumentation (Print) 18 and Aufwa Zeit Gruppenarbeit: Software-Engineering I - Gruppenarbeit Modul 1 Team 1: Projekt 1 Modul 2 Team 2: Modul 3 Team 3: Modul 1 Team 4: Projekt 2 Modul 2 Team 5: Modul 3 Team 6: Projekt 3 Modul 1 Team 7: Modul 2 Team 8: 19

10 11-Retrospektive: Vereinfachte Punktbewertung Die Bewertung erfolgt anhand den Phasendokumente wie Lasten-/Pflichtenheft, SW-Architektur unter Anwendung der entsprechenden Methoden und Darstellungen Retrospektive: Inhaltsübersicht Software-Engineering I - Noten Die Vorlesung dauert 2 Semester (3. und 4. Semester) Es gibt nur eine Note über beide Semester (1 benotete Prüfungsleistung) g) 3. Semester: Test (30 Min.) 15% Vorgehensmodelle Projektarbeit 35 % Anforderungen und Software-Architektur 4. Semester: Test (30 Min.) 15% Basistechniken (UML) Projektarbeit 35% Umsetzungsentwurf, t Test-Management & TDD, Implementierung und Abnahme 21

11 Vollständig Größtenteils Rudimentär nicht behandelt 10-Retrospektive: Lehrinhalte SW-Engineering I Vorgehensmodelle Phasen des SW-Engineering und deren Zusammenhänge Analyse: Lastenheft Spezifikation: Pflichtenheft, Geschäftsprozesse, SA, Methoden zur Repräsentation von Algorithmen, Datenmodellen, Funktionsweisen, Zustands- und Regelabhängigkeiten Entwurf: SW-Architekturen, Systementwurf, Schnittstellenentwurf, Klassendiagramme Implementierung und Test Codierrichtlinien und Codequalität, Testarten und Testdurchführung, Installation und Einführung Wartung und Pflege Phasenspezifische werden die verschiedenen Arten der Dokumentation behandelt. Labor Ein komplexes Problem wird als Projekt mit allen Phasen von den Studierenden erarbeitet und dokumentiert. 23 Vollständig Größtenteils Rudimentär nicht behandelt 10-Retrospektive: Kenntnisse und Fertigkeiten Software-Engineering I Struktur und Inhalt von Lasten- und Pflichtenheften kennen Verfahren zur Aufwandsschätzung kennen Basiskonzepte (Funktionen, Daten, Abläufe) kennen (Strukturierte Analyse (SA) anwenden) Use Cases erstellen UML Diagramme kennen Entity-Relationship (ER) Diagramme kennen Data Dictionary (DD) erstellen Kontrollstrukturen kennen Entscheidungstabellen kennen Zustandsautomaten kennen Testverfahren kennen (Grundlagen der Software-Ergonomie kennen) Grundlagen der Dokumentation kennen 24

12 11-Retrospektive: Was fehlt: von Anforderungen zu Aufgaben (Umsetzung) Anforderungen (Produkt-Backlog): Epics User Story s funktionale Anforderungen nicht funktionale Anforderungen Aufgaben (Sprint-Backlog): Aufgaben Entwürfe Umsetzungen Tests Dokumentation 1 Beispiel Schätzverfahren Planungspoker Anwendungsfall 1 Aufgabe 1 <Aufwand> Aufgabe 2 <Aufwand> Aufgabe n <Aufwand> Ausleihvorgang Umsetzungsentwurf Ausleihvorgang 0,5 PT Maske Ausleihvorgang umsetzen 1,0 PT Aufruf aus Ausleihliste umsetzen 0,5 PT Test des Ausleihvorgang 0,5 PT Dokumentation der Umsetzung 0,5 PT 25 Retrospektive Warum sollen wir das machen, was ist das Ziel? Wir wollen aus abgeschlossenen Projekten lernen. Ziel ist die kontinuierliche i Verbesserung des Projektablaufs. Inhalt der Retrospektive: 1. Was lief gut? (Was haben wir gelernt und umgesetzt?) 2. Was könne wir verbessern? (Was wollen wir beim nächsten mal besser machen?) Dokumentation: Typ Beschreibung Anmerkung / Vorschlag Wer/bis wann/status t Gut Klare Anforderungen UserStory s im PBL - Ver- Status der Module unklar Kanban-Schulung nächstes Semester bessern 26

13 Projektarbeit: Ablagesysteme 27 DHBW-Soft Projekt-Vision: Internet-of-Things/Industrie 4.0 Cloud DB Funktionen GSM-Modem Maps-Anwendung SIM-Flat GPS- Empfänger CPU- Modul Sensoren Aktoren 28

14 DHBW-Soft aktuelle Aufträge 1. Alm 4.0: Verwaltung von Kühen auf einer Alm-Weide, mit Standort, Laufwege, und Wohlbefinden. (Agrarprojekt der Regierung für I4.0 in der Landwirtschaft) 2. Stadt-Auto: Online-Buchungssystem für Elektro-Autos. mit Verfügbarkeitsanzeige und Langzeitbuchung. Berücksichtigung von Aufladestationen und Restreichweite. (Stadtprojekt der Kommunen für I4.0) 3. IoT Framework: Framework für die einfache Erstellung von Anwendungen im Rahmen von Internet der Dinge und Industrie 4.0. Servicedienste, Speicherdienste, Verarbeitungsdienste. (internes Infrastruktur-Projekt) 29 Projekt-Review 49

15 Highlights und Flops Höhepunkte: Besuch der Kunden Systematischer Architekturentwurf (Völter/Stal - Architektourpodcast) Gruppenarbeit (3 Projekte = 20 Studenten) Framework-Projekt Projektpräsentationen Verbesserungen: Einheitliches Dokumenten-Ablagesystem Projektabwicklung mit Scrum + Kanban Zwischenpräsentationen 50 Dozentenbewertung 51

16 Ausblick SWE I im 4. Semester Umsetzungsentwurf Test-Management Implementierung Dokumentation Abnahme Prof. Alexander K. Dewdney Spektrum der Wissenschaft, Computer Kurzweil, 1998; 52 Fragen: 53