TU Wien:Advanced Software Engineering PR (Grechenig, Biffl)

From VoWi
Jump to navigation Jump to search
Similarly named LVAs (Resources):

Daten[edit]

ECTS 6
Department Forschungsbereich Information & Software Engineering
Language English, Deutsch
Abbreviation ASE
Links tiss:183243, tiss:188910 , Mattermost-Channel
Zuordnungen
Master Business Informatics Wahlmodul ISE/EXT - Information Systems Engineering Extension
Master Medizinische Informatik Wahlmodul Informationsverarbeitung
Master Software Engineering & Internet Computing Pflichtmodul Advanced Software Engineering

Mattermost: Channel "advanced-software-engineering"RegisterMattermost-Infos

Inhalt[edit]

Entwicklung eines Software-Systems für einen "realen Kunden" in einem Projektteam mit etwa 4-6 Personen. "Realer Kunde" bedeutet, dass es theoretisch einen Kunden für das System geben könnte, das System muss also einen klaren Nutzen aufweisen. Das zu entwickelnde System darf keine reine CRUD-Anwendung sein, sondern muss "Advanced Software Engineering"-Elemente beinhalten.

Am einfachsten ist, wenn man eine Verwaltung von irgendwelchen Dingen (z.B. Lager oder Mitarbeiter) als verteilte Applikation mit Client in HTML/JavaScript (evtl. Angular o.ä.) und Server in Java mit Spring entwickelt. Der Aufwand für solche Anwendungen ist gut planbar und eher überschaubar. Für den Advanced-Aspekt kann man versuchen, ein in AlgoDat behandeltes Problem hineinzubekommen und einen Algorithmus dafür zu implementieren. Also z.B. eine effiziente Aufteilung von Artikel auf Lagerplätzen oder von Mitarbeitern auf Schichten.

Ablauf[edit]

  • Entry Exam: Um zur LVA zugelassen zu werden, muss seit SS 2016 ein verpflichtender Eingangstest absolviert werden. Im Vergleich zu früher müssen nun alle Teilnehmer (auch Personen mit BA-Abschluss von der TU) diesen Test durchführen. Der Test umfasst eine kleine Programmieraufgabe, die in 4 Stunden im Informatiklabor in einer beliebigen Programmiersprache gelöst werden muss. Zur Verfügung stehen: Java 11, Python 3, PHP 7, Node 8, vim, emacs, IntelliJ IDEA, pyCharm, Atom, VS Code, geany. Als Aufgabe muss ein REST-Client mit ein paar Use-Cases implementiert werden. Ob GUI oder CLI bzw. der Aufbau des Programmcodes ist egal. Der Test gilt als bestanden, wenn alle Use-Cases funktionsfähig sind. Dies wird mit Hilfe von automatisierten Tests überprüft. Die Testumgebung kann in TUWEL einige Tage vorher heruntergeladen werden, damit man sich mit dieser vorher vertraut machen kann. Außerdem darf man in TUWEL selbstgeschriebenen Code hochladen, auf den man dann während des Tests Zugriff hat.
  • Kickoff: Erstes Meeting mit dem Tutor. Quasi ein Kennenlernen der Gruppe, falls das nicht schon passiert ist. Ansonsten gibt es hier die ersten Informationen zum anfänglichen Ablauf der LVA. Die Projektidee kann dem Tutor vorgestellt werden.
  • Project Proposal: Bis Ende 2. Semesterwoche muss ein Projektvorschlag eingereicht werden. Dieser umfasst: Beschreibung, vorgeschlagene Features, Domain Model, Tech-Architektur, Konkurrenzprodukte, Projektrisiken.
  • Project Proposal Presentation: Ein paar Tage nach dem Einreichen des Proposals, wird dieser gegenüber zwei Stud.Ass. vorgestellt. Dauer: 15 Minuten
  • Project Contract: Bis Ende 4. Semesterwoche muss ein Projektvertrag eingereicht werden. Dieser umfasst: aktuelle Situation, Beschreibung, Zielgruppe, Funktionale Anforderungen, "Iceberg-List" (eine Art Backlog), Nichtfunktionale Anforderungen, Domain Model, Work-Breakdown-Structure, Milestones definieren, Nicht-Ziele, Projektrisiken,...
  • Management-Review 1 (MR-1): Findet ungefähr in der 5. Semesterwoche statt. Erstes Treffen mit dem Prof. des jeweiligen Instituts zusammen mit dem Tutor. Projektidee wird dem Prof. vorgestellt. Dieser erweitert dann ggf. den technischen und/oder nicht-technischen Umfang.
  • Internal-Review 1 (IR-1): Findet zwischen MR-1 und MR-2 statt. Der aktuelle Stand der Applikation wird einem projektfremden Tutor gezeigt, welcher dann Feedback zum Code, Tests und Projektmanagement gibt. Das Ganze hat kaum bis keinen Einfluss auf die Note, sondern soll lediglich dem Team wertvolles Feedback geben.
  • Management-Review 2 (MR-2): Findet etwa mittig zwischen MR-1 und MR-3 statt. Ziel ist es mindestens 40% der funktionalen Anforderungen umgesetzt zu haben. Des Weitern muss der implementierte Code durch Unit/Integration/UI-Tests ergänzt sein. Als Richtwert wurden von uns etwa >40 Tests pro Person bis Projektende verlangt. Zum Ablauf: jedes Teammitglied muss je ein interessantes Feature vorführen und im Anschluss evtl. Code + Tests dazu zeigen.
  • Internal-Review 2 (IR-2): Findet zwischen MR-2 und MR-3 statt. Identisch zu IR-1.
  • Management-Review 3 (MR-3): Findet am Semesterende statt. Ziel ist es die restlichen funktionalen Anforderungen umgesetzt zu haben. Im Grunde läuft das MR-3 ähnlich zum MR-2 ab. Zusätzlich möchte der Prof. Eigenschaften der Applikation sehen, welche "advanced" sind, bzw. sich von einem ggf. Konkurrenzprodukt abheben.
  • ASE-Day: Findet am Semesterende statt (aber nicht zwangsläufig nach dem MR-3). Alle ASE-Gruppen stellen ihre Projekte kurz vor. Inhalt der Präsentationen: Projektidee, Technologie+Herausforderungen, Projektmanagement+Herausforderungen, Screenshots der Anwendung.

Stand: SS 2019

Benötigte/Empfehlenswerte Vorkenntnisse[edit]

  • Praktische Erfahrung im Programmieren. Vorzugsweise auch im Team.
  • Erfahrung bzw. Bereitschaft zum Projektmanagement
  • SEPM

Prüfung, Benotung[edit]

Die Benotung basiert hauptsächlich auf den drei Management-Review-Meetings. Der Prof bzw. Assistent entscheidet nach Abschluss von MR-3 über die Note und teilt diese dem Team im Anschluss mit.

Dauer der Zeugnisausstellung[edit]

SS 2019 (Grechenig): Zwei Wochen nach dem MR3.

Zeitaufwand[edit]

Zeitaufwand variiert je nach Team und Softwaresystem. In unserem Fall (SS2016, QSE), war der Aufwand zwischen 150 und 250 dokumentierten Stunden pro Person. Das war vor allem auf zusätzliche Anforderungen seitens des Prof. aber auch mangelhafte Organisation der LVA zurückzuführen (z.B. Agenda und Termine der verschiedenen Meetings wurden schlecht und spät kommuniziert).

Andere Meinung: Mit einer guten Gruppe kommt man pro Person mit den 150 Stunden auf jeden Fall aus. Im Vergleich zu SEPM ist der Zeitaufwand auch niedriger, nicht zuletzt weil kein Einstiegsbeispiel zu absolvieren ist.

Unterlagen[edit]

Tipps[edit]

  • Die Project-Proposal-Presentation war in unserem Fall relativ sinnlos und hatte keinen weiteren Einfluss auf die LVA. Das dort erhaltene Feedback zu unserem Projekt hätte den ohnehin schon großen Projektumfang sichtlich gesprengt.
  • Für QSE und Prof. Biffl: Es muss (meistens) eine Art Kundenumfrage durchgeführt werden, um festzustellen inwiefern die zu entwickelnde Anwendung den zukünftigen Anwendern (!= Auftraggeber) von Nutzen ist. Für uns kam dies relativ überraschend im MR-1 und hat einen ohnehin schon knappen Zeitplan noch weiter belastet. Achtung: falls ihr eine spezielle Zielgruppe habt, kann das Gestalten und Durchführen einer Umfrage relativ aufwendig sein.
  • MR-1: Prof. Biffl hat eine sehr dominante Art ein Meeting zu führen. Bereitet euch darauf vor, Entscheidungen mit Nachdruck und guten Argumenten zu verteidigen. "... Aber der Auftraggeber will es so" ist kein gültiges Argument.
  • Klärt im Vorfeld ab, wie viele Tests pro Person zu schreiben sind.
  • Wir haben es nicht geschafft den kompletten Funktionskatalog bis zum MR-3 fertigzustellen. Da unsere Anwendung dennoch einen abgeschlossenen Eindruck machte und relativ robust war, hatte dies keine negativen Auswirkungen auf unsere Note. (Dennoch sollte es das Ziel sein den Katalog abzuarbeiten. Hier im Zweifelsfall mit dem Tutor sprechen).
  • Die LVA beim INSO absolvieren hat im Vergleich zum QSE den Vorteil, dass die Benotung bzw. Kontrolle bei den MRs ein Assistent übernimmt.

Verbesserungsvorschläge / Kritik[edit]

  • Redmine ist einfach nur mühsam zu verwenden.
  • Vor allem in den ersten Meetings am Anfang des Semesters muss das Projektteam die Idee mit relativ viel Nachdruck verteidigen. Ich empfand dabei den Umgang mit dem Studierenden sehr unprofessionell, da seitens die Argumente seitens der LVA doch sehr populistisch aufgetragen wurden. Mit MR-2 und MR-3 wurde das dann besser.
    • Beispiel: Im MR-1: "Eure Anwendung ist eh bloß CRUD". Später im MR-2: "Oh, eure Anwendung ist doch relativ komplex" -.-
    • Beispiel: Project-Proposal-Meeting: LVA: "Macht noch Feature XY dazu." - Wir: "Der Auftraggeber will XY aber nicht" - LVA: "Doch, der will das so." -.-
  • 2020S: Der Einstiegstest war unverhältnismäßig schwierig. Innerhalb von 4 Stunden musste man ein Projekt (Rest-Schnittstelle, Datenbank-Verbindung) aufsetzen und ein absolut nicht triviales algorithmisches Problem lösen. Da es so gut wie niemand geschafft hat, wurde die Arbeitszeit auf 4 Stunden und 45 Minuten verlängert. Auch nach dieser Zeit waren nur sehr wenige erfolgreich. Man hat nur bestanden, wenn alle 60 der 60 automatisierten Tests erfolgreich waren. Ich kenne keine andere Prüfung, bei der man 100% erreichen muss, um positiv zu sein. Für einen Einstiegstest ist so etwas unglaublich und meiner Meinung nach nicht akzeptabel. Der Retake am nächsten Tag war deutlich einfacher und schaffbar. Eine Vorbereitung ist unmöglich, da schließlich irgendein beliebiges Problem kommen könnte. Kurzbeschreibung des Problems beim Einstiegstest (2020S): Gegeben ist eine Gleichung, bestehend aus Ziffern, +, - und =, z.B. 4-1=1+2. Die Ziffern werden durch 7 Sticks repräsentiert (wie bei einer digitalen Anzeige). Das Ziel ist es, gültige Gleichungen zu erstellen, in dem man Sticks an eine andere Position verschiebt, sodass neue gültige Ziffern entstehen (entweder innerhalb einer Ziffer oder auf eine andere Ziffer, nicht jedoch die Rechenzeichen). Nachdem genau ein Stick verschoben wurde, entsteht eine neue Gleichung (Tiefe 1). Nun kann wieder in Stick verschoben werden -> weitere Gleichung (Tiefe 2). Die maximale Tiefe (n) ist Teil der Angabe. Die gesuchte Lösung beinhaltet alle möglichen gültigen Gleichungen, die aus der gegebenen Gleichung durch Verschieben von Sticks in maximal n Schritten erreicht werden, zusammen mit der minimalen Tiefe für die jeweilige Gleichung. Also wenn dieselbe Gleichung zwei Mal erreichbar ist, ein Mal in 3 und ein Mal in 5 Schritten, so ist nur die erste Variante (3 Schritte) anzugeben. Die Angabe wird über eine Rest-Schnittstelle eingelesen und in einer Datenbank zusammen mit den Lösungen persistiert.