Modulhandbuch

Elektrotechnik/Informationstechnik plus (EI-plus)

Software Engineering

Empfohlene Vorkenntnisse

Programmierkenntnisse in C, C++ oder andere Programmiersprache

Lehrform Vorlesung/Labor
Lernziele / Kompetenzen

Die Studierenden haben einen breiten Überblick über Methoden und Werkzeuge für das Software Engineering erhalten. Nach Abschluss des Moduls sind die Absolvent*innen in der Lage das passende Vorgehensmodell zu wählen und einen kompletten SW-Entwicklungsprozess systematisch und strukturiert durchzuführen

Dauer 1
SWS 4.0
Aufwand
Lehrveranstaltung 60h
Selbststudium / Gruppenarbeit: 60h
Workload 120h
ECTS 4.0
Voraussetzungen für die Vergabe von LP

K60 und LA. Das Labor ist unbenotet, muss aber m. E. attestiert sein.

Modulverantwortlicher

Prof. Dr.-Ing. Elke Mackensen

Empf. Semester 6
Haeufigkeit jedes Jahr (SS)
Verwendbarkeit

Zweiter Studienabschnitt Studiengänge EI

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