Veranstaltungen
|
Software Engineering für Embedded Systems
Art |
Vorlesung |
Nr. |
EMI875 |
SWS |
2.0 |
Lerninhalt |
Software-Engineering-Vorgehensmodelle:
- Definition SW - Engineering
- Definiton SW – Entwicklungsprozesse
- Übersicht Vorgehensmodelle
Sequentielle Entwicklungsprozesse:
- Phasen eines sequentiellen SW-Entwicklungsprozesses
- Rollen in einem Software-Entwicklungsprozess
- Wasserfallmodell
- V-Modell/V-Modell-XT
Inkrementelle Entwicklungsprozesse:
- iterativ (formal, agil)
- evolutionär (Prototyping)
Eingebettete Systeme
- Grundsätzlicher Aufbau (Software und Hardware)
- Allgemeine Aufgaben und Einsatz
- Spezifische Anforderungen
Requirements Engineering:
- Ermittlung der Anforderung
- Lastenheft / Pflichtenheft
Design-Phasen:
- Einführung in UML, Übersicht der wichtigsten UML-Designelemente
- Design von Eingebetteten Systemen (Entwurfsmuster, MDD, TDD, FFD, HAL)
Realisierungsphase:
- Systematisches Vorgehen
- Handwerkszeuge
- Kodierrichtlinien
- Implementierungshilfen
- Automatische Dokumentengenerierung
Test-Phase:
- Verifikation / Validierung
- Testkategorien / Testarten
- Kontinuierliche Integration
- Test-Tools
|
Literatur |
- Balzert, H.,Lehrbuch der Software-Technik, Band 1, 3. Auflage, Heidelberg, Spektrum, 2009
- Sommerville, I., Software Engineering , 9. Auflage, München, Pearson Studium, 2012
- Berns K., Schürmann B., Trapp M., Eingebettete Systeme: Systemgrundlagen und Entwicklung eingebetteter Software , Wiesbaden, Vieweg+Teubner, 2010
|
Labor Software Engineering
Art |
Labor |
Nr. |
EMI876 |
SWS |
2.0 |
Lerninhalt |
Das Labor wird an 6 Laborterminen durchgeführt und dient der praktischen Übung zu den theoretisch vermittelten Kenntnissen der Vorlesung.
Als Projektorganisation wird das agile Projektmanagement-System Scrum verwendet. Die Studierenden lernen die Verwendung von Epics, Features, Storys und Tasks als Strukturierungs-Werkzeuge kennen. Der/die Dozent*in fungiert dabei als Scrum-Master (Hilfestellung bei der Projektdurchführung) und Stakeholder (Abnahme der Scrum-Ergebnisse) für die Gruppen. An jedem Labortermin soll ein kompletter Sprint durchgeführt werden.
Ein mögliches Szenarium für einen Entwicklungsauftrag könnte wie folgt aussehen: Die Geschäftsleitung stellt aufgrund von Kundenanfragen und einer Markanalyse eine Aufgabe an die Entwicklungsabteilung. Dies könnte beispielsweise die Entwicklung eines neuartigen Temperaturdatenloggers mit Messwertaufnahme, -speicherung und –darstellung sein.
Labordurchführung:
1. Labortermin (Konzeptphase): - Sammlung der UseCases, - Erstellung eines Konzepts: Lasten und Pflichtenheft, - Erstellung eines Scrums: Epic, Feature, Story,Backlog.
2. Labortemin (Designphase): - Erstellung eines Grob-Entwurfs (in UML), - Verwendung von Komponenten-, Sequenz- und Aktivitätsdiagrammen.
3. Labortermin (Implementierungsphase 1): - Inbetriebnahme der Entwicklungs- und Testumgebung, - Erstellung von Unit-Test, - automatische Generierung der Dokumentation im Single-Source-Prinzip (z.B. Doxygen).
4. Labortermin (Implementierungsphase): - Erstellung Sprint 1: Tasks (ein Sprint entspricht einem Labornachmittag bzw. der Zeit zwischen zwei Laboren), - Erfüllung der Task: Implementierung, Dokumentation (Doxygen), Test (Unit-Tests), - Sprint-Ende: Vorführung der Ergebnisse, lauffähiges Projekt. Bedingung: SW ist lauffähig, getestet, dokumentiert.
5. Labortermin (Implementierungsphase): - Erstellung Sprint 2: Tasks (ein Sprint entspricht einem Labornachmittag bzw. der Zeit zwischen zwei Laboren), - Erfüllung der Task: Implementierung, Dokumentation (Doxygen), Test (Unit-Tests), - Sprint-Ende: Vorführung der Ergebnisse, lauffähiges Projekt. Bedingung: SW ist lauffähig, getestet, dokumentiert.
6. Labortermin (Implementierungsphase): - Erstellung Sprint 3: Tasks (ein Sprint entspricht einem Labornachmittag bzw. der Zeit zwischen zwei Laboren), - Erfüllung der Task: Implementierung, Dokumentation (Doxygen), Test (Unit-Tests), - Sprint-Ende: Vorführung der Ergebnisse, lauffähiges Projekt. Bedingung: SW ist lauffähig, getestet, dokumentiert.
Am Ende des 6. Labortermins, ist die Aufgabe komplett erstellt, dokumentiert und getestet. Es erfolgt eine Überprüfung gegen das Lastenheft durch den Stakeholder und eine Freigabe für den Anwender.
Die Labortage 4, 5 und 6 werden durch ein „Continuous-Integration-Process” (CI) dargestellt. D.h. Versionsstände der Software werden in einem Versionsverwaltungsprogramm (z.B. git) gespeichert und in einem automatischen Build- und Test-Prozess auf Qualität geprüft. |
Literatur |
- Balzert, H., Lehrbuch der Software-Technik, Band 1, 3. Auflage, Heidelberg, Spektrum, 2009
- Sommerville, I., Software Engineering , 9. Auflage, München, Pearson Studium, 2012
- Berns K., Schürmann B., Trapp M., Eingebettete Systeme: Systemgrundlagen und Entwicklung eingebetteter Software, Wiesbaden, Vieweg+Teubner, 2010
- Chris Rupp, Stefan Queins & die SOPHISTen:UML 2 glasklar : Praxiswissen für die UML-Modellierung, 4. Auflage, Hanser-Verlag, 2012
- Boris Gloger, Scrum – Produkte zuverlässig und schnell entwickeln, 5. Auflage, Hanser-Verlag, 2016
|
|