Informationen zum Softwaretechnik-Projekt WS 2017/18

08.09.2017 - 1 -

Rentschler / Ewertz TINF16C_Projektarbeiten_Info_0v2 Software Engineering I

Informationen zum Softwaretechnik-Projekt WS 2017/18

1. Verfahrensanweisungen ...................................................................................... 2

1.1. Ziel ....................................................................................................................... 2

1.2. Rahmenbedingungen ........................................................................................ 2

1.3. Bewertung .......................................................................................................... 2

1.4. Aufgabenstellung .............................................................................................. 3

1.5. Präsentationen ................................................................................................... 5

1.6. Präsentationen ................................................................................................... 5

1.7. FAQ ...................................................................................................................... 9

2. Projektthemen 2017/2018 ................................................................................... 10

2.1. IODD-Viewer ..................................................................................................... 11

2.2. Weiterentwicklung PROFINET Explorer ....................................................... 12

2.3. Erweiterung SmartTester mit html5-GUI ...................................................... 13

2.4. Anbindung SmartTester an TestLink ............................................................ 14

2.5. UML2C – Code Generator ............................................................................... 15

08.09.2017 - 2 -


1. Verfahrensanweisungen

1.1. Ziel

Das Software-Projekt soll Ihnen erste Erfahrungen hinsichtlich des Entwurfs, der Implementierung und der Qualitätssicherung von Software im Großen geben. Dies umfasst die Phasen Analyse, Design, Implementierung bis zum Test im unten abgebildeten Top-Down-Entwicklungsprozess nach einem Phasenmodell. Es sollen die in den Vorlesungen besprochenen Techniken zur Anwendung kommen.

1.2. Rahmenbedingungen

Gruppen zu 5-6 Studenten.

Jeder im Team hat eine bestimmte Rolle und die zugehörigen Aufgaben. Die Rollen, die Sie benötigen sind:

o Projektleiter o Produktmanager o Leitender Entwickler o Testmanager o Technische Dokumentation

Jeder im Team muss zusätzlich für mindestens ein Programmmodul die Verantwortung inkl. Implementierung übernehmen.

Die Teamsitzungen müssen in einer fortlaufenden Protokolldatei dokumentiert werden, welche Beschlüsse, Status und Ergebnisse darstellt.

1.3. Bewertung

Die Note ergibt sich aus folgender prozentualer Verteilung der Bewertung der Gruppenarbeit:

2/3 kollektive Leistung für die Implementierung, Entwicklungsdokumentation und Präsentation

1/3 individuelle Leistung des Einzelnen in seiner Rolle und für sein verantwortliches Modul.

08.09.2017 - 3 -


1.4. Aufgabenstellung

Zuerst die allgemeine Aufgabenstellung. Einzelne Hinweise zu Inhalten und Tipps folgen danach und werden dann auch bei Bedarf ergänzt. Aufgabe im 3. Semester: Analysephase VL-Wochen 1-6

1. Bilden Sie Gruppen zu 5-6 Studenten und verteilen Sie Rollen wie beschrieben. Diese Gruppen bleiben für das Semester 3 und 4 bestehen.

2. Suchen Sie sich eines der ausgegebenen Projekte aus oder erläutern Sie in einem etwa einseitigen Steckbrief, welches Projekt Sie verwirklichen wollen.

3. Systematisieren Sie die Anforderungen und ergänzen Sie ggf. zusätzliche Kundenanforderungen, die sich im Gespräch mit dem Projectbuyer (Dozenten) ergeben, in einem CRS.

4. Erstellen Sie eine Projektplanung für Ihr Team. Verplanen sie maximal 180 Stunden pro Teammitglied (inklusive Administration und Dokumente schreiben)

5. Erstellen Sie einen einfachen (!) Business Case (BC), indem Sie von einer fiktiven kommerziellen Auftragsentwicklung ausgehen.

Achten Sie auf die in der Vorlesung behandelten Punkte zum Thema Requirements Engineering und Systemanalyse. Versuchen Sie, in Ihrer Gruppe durch Reviews zu gut spezifizierten Anforderungen und den geeigneten Modellierungstechniken zu kommen. Designphase VL-Wochen 7-11

1. Erstellen Sie das Pflichtenheft (SRS), in dem das System aus Black-Box-Sicht definiert und modelliert wird.

2. Modellieren Sie das System aus White-Box-Sicht und erstellen Sie die Architekturspezifikation (SAS). Leiten Sie die zu implementierenden Module daraus ab und weisen Sie diese als Arbeitspakete den Teammitgliedern zu.

3. Updaten Sie die Projektplanung. Versuchen Sie dabei, die Aufgaben zu parallelisieren und beachten Sie Abhängigkeiten zwischen Arbeitspaketen.

4. Jedes Team präsentiert die Ergebnisse in einer 20minütigen Präsentation mit anschließender 10minütiger Verteidigung (üblicherweise letzte Vorlesung).

Abzugeben sind zwei Tage vor dem Präsentationstermin folgende Dokumente in elektronischer Form (PDF und Basisformat):

CRS, BC, SRS, SAS, Projektplan

Sitzungsprotokolle

Präsentation Hinweis: Üblicherweise gibt es in Projekten eine „Baseline“. Auf dieses Dokument wird verzichtet.

08.09.2017 - 4 -


Aufgabe bis Ende des 4. Semesters: 1. Implementieren Sie das System, testen Sie Ihr Modul und erstellen Sie dazu die

Moduldokumentation (MOD). 2. Erstellen Sie Systemtestpläne (STP) und führen Sie diese Tests durch. Dokumentieren

Sie die Ergebnisse in einem Systemtestreport (STR). 3. Finalisieren Sie alle abzugebenden Dokumente. 4. Jedes Team präsentiert seine Ergebnisse in einer 20minütigen Präsentation mit

anschließender 10minütiger Verteidigung.

Abzugeben sind zwei Tage vor dem Präsentationstermin sämtliche Projektdokumente in elektronischer Form (PDF und Basisformat):

CRS, BC, SRS, SAS, Projektplan, MODs, STP, STR, Benutzer Manual, Projektpräsentationen, Protokolle.

Am Tag der Präsentation sind die finalen Dokumente auf DVD abzugeben (2 Kopien).

08.09.2017 - 5 -


1.5. Präsentationen

Allgemeines

Zeitvorgabe (möglichst genau) 20 min

Etwa 10 min Fragen

Sie dürfen selbst entscheiden, wer und wie viele präsentieren.

Da Sie sehr viele Informationen in 20 Minuten darstellen müssen, überlegen Sie sich genau, was Sie sagen wollen und welche Informationen auf die Folien kommen. Planen Sie daher zur Vorbereitung der Präsentation ausreichend Zeit ein (30 min bis 1h pro Folie!).

Präsentation 1 - BC/CRS/SRS/SAS Inhalt :

Teamvostellung mit Bild und Aufgabe (1 Folie)

Vorstellung des Projektes (Master Usecase)

Darstellung des Funktionsumfangs, Beschreibung der funktionalen und nichtfunktionalen Anforderungen sowie Entscheidung darüber, ob Mandatory oder Desired

Business Case (1 Folie)

Erläutern Sie Ihre Vorgehensweise und verwendete Tools.

Zeigen sie wie sie Modularisiert haben und wie der Projektplan aussieht.

Beschreiben Sie die Systemarchitektur und die Modularisierung (Top Down)

Zeigen Sie Lösungen aus der SAS (zum Beispiel Paketformat, Anbindung an Java, ERD …).

Bei Bedarf können Sie auch schon Prototypen vorstellen.

Präsentation 2 - STP/STR/Produkt Präsentation/Selbstkritik

1.6. Präsentationen

Allgemeines

Für die meisten Dokumente haben Sie Vorlagen auf dem FTP. Diese geben das allgemeine Gliederungsschema vor.

Sie können eigene Vorlagen und Designs verwenden, Sie sollten aber die Gliederung weitgehend beibehalten.

Diese Vorlagen sind sehr allgemein. Es kann also sein, dass Sie nicht zu allen Punkten, die erwähnt sind, etwas zu schreiben haben.

Ausfüllhinweise im Dokument bei Finalisierung bitte löschen.

Erlaubte Sprachen sind Deutsch und Englisch. Ablage der Dokumente Bitte verwenden Sie für die Abgaben folgendes Ablageschema. Denken Sie an die Versionierung der Dateien. Team_x_Projektname\CRS_BC\

08.09.2017 - 6 -


Team_x_Projektname\SRS_SAS\

Team_x_Projektname\STP_STR\

Team_x_Projektname\MOD\

Team_x_Projektname\MANUAL\

Team_x_Projektname\SOURCE\

Team_x_Projektname\EXECUTABLE\

Team_x_Projektname\PROJECTMGMT\PROTOCOLS\

Team_x_Projektname\PROJECTMGMT\PLANS\

Team_x_Projektname\PRESENTATIONS\

Format der Dateinamen z.B. TINF13D_CRS_Team_x_0v1 , TINF13D_MOD_Team_x_Modulname.0v1 Es sollten am Schluss alle Dokumente aus Semester 3 und 4 enthalten sein (wichtige Versionen der Dokumente). Alle finalen Dokumente bitte im Originalformat UND als PDF.

08.09.2017 - 7 -


Einzelne Dokumente / Items

CRS Zweck: Beschreibt die Kundenwünsche Umfang: 5 -10 Seiten Vorlage: Ja Methoden:

Strukturierte Anforderung (Schablone), Fließtext, Skizzen der Oberfläche, Use Cases, Anwendungsfälle, Geschäftsvorfälle, … .

Inhalt: Siehe Vorlage

BC HINWEIS! Wird sehr reduziert!!! Infos in der VL Zweck: Betrachtung der wirtschaftlichen Aspekte und Projektrisiken. Max. 5 Seiten (eher weniger) Vorlage: Nein Methoden:

Voll / Teilkosten Rechnung, Verfahren zur Risikoanalyse, . .. .

Inhalt: Definition und Abgrenzung : - Beschreibt das Projekt und die Intension - Warum stecke ich da Zeit rein

Kostenrechnung: - Fixe Kosten und Kosten für die einzelnen Arbeitspakete und

Phasen. Monetäre Vorteile:

- Wie verdiene ich Geld damit? - Wie sieht die Vermarktung aus?

Nicht monetäre Vorteile z.B. : - Kann ich meine Technologievorsprung behaupten /ausbauen. - Kann ich anderweitig Umsätze generieren kann. - Kann ich meine Markstellung behaupten /ausbauen.

Risikoanalyse: - Welche Risiken bestehen? - Wie sind diese zu bewerten? - Wie kann ich Risiken mindern, vermeiden oder sind sie

tolerierbar? Hinweise In die Kostenrechnung und die Risikoanalyse sollten Sie die meiste Zeit

investieren. Wir betrachten die anderen Bereiche nur am Rande.

SRS Zweck: Beschreibt den Leistungsumfang und fixiert das Feature-Set (Black-Box) 10 -15 Seiten Vorlage: Ja Methoden:

Strukturierte Anforderung (Schablone), Fließtext, Skizzen der Oberfläche, Prototypen, Use Cases, Ablaufdiagramme,… .


08.09.2017 - 8 -


SAS Zweck: Beschreibt die konzeptionelle Lösung des Gesamtsystems (Grey-Box,

White-Box) 5 -15 Seiten Vorlage: Ja Methoden:

Komponenten-, Klassen-, Kommunikations-, Ablauf- und Sequenzdiagramme, ERM, Datenmodelle, … .


Sitzungsprotokolle Zweck: Dokumentiert Ihre Projektaktivitäten Umfang: 10 - 15 Zeilen Status pro Sitzung

1 Sitzung pro Woche Vorlage: Nein Methoden: Inhalt: Status der Arbeiten, Probleme, Beschlüsse Hinweis: Es reichen fortlaufende Protokolle als Kapitel in einer einzelnen Datei.

PM Dokumente Zweck: Projektplanung Umfang: PSP, GANTT Vorlage: Nein Methoden: Siehe PM VL Inhalt: Siehe PM VL

08.09.2017 - 9 -


1.7. FAQ

F: Woher kommen die Projektvorschläge? A: Die Projektvorschläge wurden von den Dozenten erstellt und sind meist in deren fachlicher Anwendungsdomäne angesiedelt. Das ermöglicht zusätzlichen Know-How-Transfer im Rahmen der Projektarbeit. F: Was soll dieses Angebot mit dem Open-Source Projekt? A: Um die Wertigkeit der Projektarbeit zu steigern, wird angeregt, diese im Rahmen von Open-Source-Projekten abzuhandeln. Das hat folgende Vorteile:

- Die Studenten können später in Ihrem Lebenslauf auf Mitarbeit an einem veröffentlichten Open-Source-Projekt verweisen.

- Die Dozenten könne die Software von nachfolgenden Studenten-Jahrgängen weiterentwickeln lassen (siehe rechliche Hinweise weiter unten).

Beispiel: http://studium.dhbw-stuttgart.de/informatik/studierendenprojekte/multicastor/ F: Muss ich alle auch optionalen Features implementieren? A: Es besteht kein Zwang, alle optionalen Requirements zu implementieren, wenn die Aufwände zu groß werden. Sie sind angehalten, eine realistische Umfangsabschätzung der Projektaufgabe durchzuführen, die der eigenen Leistungsfähigkeit im zur Verfügung stehenden Zeitrahmen entspricht. Features die wir in der SRS als Mandatory vereinbart haben, dürfen nicht ohne Grund fehlen. Es hat sich als Vorteil erwiesen optionale Features in der Hinterhand zu haben. Rechtliche Hinweise

- Die erstellte Software ist ihr geistiges Eigentum. Sie haben das Vollkommene und alleinige Nutzungsrecht.

- Die Dozenten werden den Source-Code nicht ohne ihr Einverständnis weiterverwenden.

- Bei Veröffentlichung bzw. Offenlegung (z.B. in einem Open-Source-Projekt) sind sie selbst für die Einhaltung entsprechender Lizenzrechte verantwortlich.

http://studium.dhbw-stuttgart.de/informatik/studierendenprojekte/multicastor/

08.09.2017 - 10 -


2. Projektthemen 2017/2018

Team 1: Team 2: Team 3: Team 4:

08.09.2017 - 11 -


2.1. IODD-Viewer

Es soll ein einfaches Tool entwickelt werden, mit dessen Hilfe „IO-Link Device Descriptions“ (IODDs) eingelesen, interpretiert und visuell ansprechend angezeigt werden können. Der Benutzer soll schreibbare Parameter verändern können. Die so geänderte IODD soll anschließend regelkonform mit aktualisierter Versionsnummer und Checksumme abgespeichert werden können. http://io-link.com/de/Download/Download.php?thisID=8 Die Realisierung soll in html5 und JavaScript erfolgen. Die Veröffentlichung als Open-Source-Projekt wird angestrebt. Das Projekt ist von Anfang an entwicklungsbegleitend in der TestLink-Installation auf dem DHBW-Server zu dokumentieren: http://it-testlink.dhbw-stuttgart.de/testlink1.9/login.php Alle Dokumentation ist englischsprachig zu erstellen. Diese Aufgabe ist gut geeignet für Leute mit Interesse an Automatisierungstechnik und IO-Link. Der Entwurf einer benutzerfreundlichen html5-GUI und XML-Interpretation steht im Vordergrund.

http://io-link.com/de/Download/Download.php?thisID=8

08.09.2017 - 12 -


2.2. Weiterentwicklung PROFINET Explorer

Das Tool "Profinet Explorer" ist ein unter Open-Source entwickeltes Programm zur Kommunikation mit PROFINET-IO-Geräten. https://sourceforge.net/projects/profinetexplorer Die Applikation enthält noch einige Fehler und Implementierungslücken, die im Rahmen des Projektes beseitigt werden sollen. Gewünscht ist insbesondere die Kommunikation mit angeschlossenen IO-Link-Geräten (siehe IO-Link-Profinet-Integrationsspezifikation). Ausserdem sind Usability-Verbesserungen zu untersuchen und ggf. umzusetzen. Vergleichbare Applikationen sind: Siemens PST (https://support.industry.siemens.com/cs/document/19440762) Indu-Sol ServiceTool (https://www.indu-sol.com/support/downloads/software/) IFAK PNIO Explorer (https://profinet-tools.ifak.eu/de/pnio_explorer) Folgender Projektumfang soll bearbeitet werden:

1. Durchführung eines Systemtests und Vergleichstests mit o.a. ähnlichen Applikationen zur Erfassung von Fehlern, Implementierungslücken und Usability-Schwächen des "Profinet Explorers".

2. Erarbeitung von Verbesserungsvorschlägen aus obiger Analyse. 3. Umsetzung der ausgewählten Fehlerbehebungen, Funktionserweiterungen

und Usability-Verbesserungen. 4. Erstellung eines Benutzerhandbuchs.

Die Realisierung soll auf Basis des bestehenden Open-Source-Projekts in C# erfolgen. Die Veröffentlichung der Verbesserungen in dem Open-Source-Projekt wird angestrebt. Hierzu ist der Maintainer des Projekts zu kontaktieren. Das Projekt ist von Anfang an entwicklungsbegleitend in der TestLink-Installation auf dem DHBW-Server zu dokumentieren: http://it-testlink.dhbw-stuttgart.de/testlink1.9/login.php Alle Dokumentationen sind englischsprachig zu erstellen. Diese Aufgabe ist gut geeignet für Leute mit Interesse an Automatisierungstechnik. Der Entwurf einer benutzerfreundlichen GUI und das Feldbusprotokoll PROFINET, das Sensoranbindungsprotokoll IO-Link sowie XML-Interpretation der Gerätebeschreibungsdateien (GSDML, IODD) steht im Vordergrund. Die PROFINET-Spezifikationen und Testgeräte werden vom Dozenten zur Verfügung gestellt.

https://sourceforge.net/projects/profinetexplorer/?source=directory

https://support.industry.siemens.com/cs/document/19440762

https://www.indu-sol.com/support/downloads/software/

https://profinet-tools.ifak.eu/de/pnio_explorer

08.09.2017 - 13 -


2.3. Erweiterung SmartTester mit html5-GUI

Das freie Testautomatisierungsframework "SmartTester" erlaubt die komfortable Verwaltung und Ausführung von Testautomatisierungsskripten in verschiedenen Sprachen wie TCL, LUA, Python oder STAX. ausserdem unterstützt "SmartTester" den sog. Daten- und Schlüsselwortgetriebenen Ansatz.

Siehe https://sourceforge.net/projects/smarttester/

"SmartTester" ist bisher als getrennte Server und Client-Instanz jeweils in JAVA implementiert. Im Rahmen dieses Projekts soll der JAVA-Client ersetzt werden durch eine browserbasierte html5-GUI, die per Webzugriff auf den JAVA-Server aufgerufen werden kann. Bei dieser Aufgabe steht der Entwurf einer benutzerfreundlichen GUI, eines Workflows und html5-Programmierung mit JavaScript im Vordergrund. Interessant ist auch die Horizonterweiterung durch die Implementierung eines WEB-Servers in JAVA.

https://sourceforge.net/projects/smarttester/

08.09.2017 - 14 -


2.4. Anbindung SmartTester an TestLink

Die freie Testmanagement-Lösung „Testlink“ (http://teamst.org) bietet umfassende Werkzeugunterstützung für den Software-Qualitätssicherungsprozess, vom Requirements-Management über Testfallmanagement, Testprojektmanagement und Bugtracking bis hin zum Reporting. Testlink verfügt über ein Feature zum Export und Import von Testprojekten/Testsuiten mittels eines XML-Formats. Das freie Testautomatisierungsframework "SmartTester" erlaubt die komfortable Verwaltung und Ausführung von Testautomatisierungsskripten. "SmartTester" soll zu "TestLink" interoperabel gemacht werden, indem die von "SmartTester" erzeugten Reportdateien in "TestLink" einlesbar sein sollen. Hierzu ist das von TestLink zur Verfügung gestellte Interface zu analysieren und ggf. zu erweitern. Das Reportdateiformat des "SmartTester" soll bei Bedarf ebenfalls entsprechend angepasst werden. Als Beispielprojekt für den funktionierenden Austausch soll für den "Smart Tester" selbst in "TestLink" ein Testprojekt und einige zugehörige Automatisierungsskripte aufgesetzt werden. Das Projekt ist von Anfang an entwicklungsbegleitend in der TestLink-Installation auf dem DHBW-Server zu dokumentieren: http://it-testlink.dhbw-stuttgart.de/testlink1.9/login.php Alle Dokumentation ist englischsprachig zu erstellen (Beispiele finden sich hier: http://mantis.testlink.org/view.php?id=5296). Usability-Verbesserung sowie Entwurf und Umsetzung einer Testautomatisierung einer bestehenden Software sind die Hauptaspekte bei dieser Arbeit. Man kann hier viel über Methoden und Werkzeuguntertüstzung zum Thema Requirements Engineering, Testmanagement und Testautomatisierung lernen

http://teamst.org/

http://mantis.testlink.org/view.php?id=5296

08.09.2017 - 15 -


2.5. UML2C – Code Generator

Ein Codegenerator ist ein computergestütztes Werkzeug für die Softwareentwicklung. Er übersetzt Modelle, die in UML, Struktogrammen oder einer anderen formalen Sprache erstellt wurden, in die Programmiersprache (C, C++, JAVA, …) der gewählten Zielplattform. Er erzeugt schnell und fehlerfrei Quellcode, der danach mit anderen Programmteilen zu einem übersetzbaren Programm verbunden wird. In diesem Projekt soll ein Codegenerator entwickelt werden, der C-Code aus Klassen- und Zustandsdiagrammen erzeugt, die mit einem UML-Tool erstellt wurden. Alternativ können als UML-Tool "Enterprise Architect" (EA) von SPARX Systems (http://www.sparxsystems.com/products/ea/downloads.html) oder "Software Ideas Modeler" verwendet werden (https://www.softwareideas.net/) Die Anbindung des Codegenerators an das UML-Tool soll über XML-Dateiexport und -import (XMI-Format) erfolgen. Der erzeugte Code soll unter beliebigen Betriebssystemen verwendet werden können. Als Grundlage kann evtl. eines der folgenden Open-Source-Projekte verwendet werden: https://sourceforge.net/projects/modeldrivencode/ http://sourceforge.net/projects/uml2stm4cpp/ http://sourceforge.net/projects/douml/ Das Tool soll primär kommandozeilenbasiert funktionieren, damit es aus anderen Tools (UML, IDE) aufgerufen werden kann, aber auch eine benutzerfreundliche Konfigurations-GUI für das Tool könnte entwickelt werden, um die Parameter für die Build- Umgebung einzustellen. Als Demonstrationsapplikation soll modellbasiert ein einfacher Netzwerk-Protokollautomat lauffähig übersetzbar entworfen werden, d.h. auf den Empfang bestimmter Netzwerkpakete wird jeweils eine entsprechende Antwort versendet. Als Beispielprojekt kann hierfür die System-Management-Zustandsmaschine von "IO-Link wireless" als EA-Projekt zur Verfügung gestellt. Bei Verwendung des "Software Ideas Modeler" müssen diese dort importiert werden. Bei dieser Aufgabe stehen Einarbeitung in ein UML-Tool, Entwurfpatterns, Softwarearchitektur und XML-Strukturen im Vordergrund. Und auch ein wenig Testdriverprogrammierung für die Demoapplikation.

http://www.sparxsystems.com/products/ea/downloads.html

https://www.softwareideas.net/

https://sourceforge.net/projects/modeldrivencode/

http://sourceforge.net/projects/uml2stm4cpp/

http://sourceforge.net/projects/douml/

Documents

Informationen zum Softwaretechnik-Projekt WS 2017/18