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

Aus VoWi
Wechseln zu: Navigation, Suche

Daten[Bearbeiten]


Inhalt[Bearbeiten]

Entwicklung eines Software-Systems für einen realen Kunden in einem Projektteam mit etwa 4-6 Personen. Das zu entwickelnde System darf keine reine CRUD-Anwendung sein, sondern muss "Advanced Software Engineering"-Elemente beinhalten.

WS17: Zumindest beim INSO ist es nicht notwendig, einen "realen Kunden" zu haben.

Ablauf[Bearbeiten]

SS2016:

  • Entry Exam: Um zur LVA zugelassen zu werden, muss ab SS2016 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 umfasste eine kleine Programmieraufgabe, welche in 4 Stunden im Informatiklabor gelöst werden musste. Zur Verfügung standen: Internet, Eclipse, IntelliJ, Java 1.8, Python, PHP und C++. Als Aufgabe musste ein REST-Client mit ein paar Use-Cases implementiert werden. Ob GUI oder CLI bzw. der Aufbau des Programmcodes waren egal. Der Test gilt als bestanden, wenn alle Use-Cases funktionsfähig sind.
  • 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: Beschriebung, vorgeschlagene Features, Domain Model, Tech-Architektur, Konkurrenzprodukte, Projektrisiken.
  • Project Proposal Presentation: Ein paar Tage nach dem Einreichen des Proposals, wird dieser gegenübern 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 ggb. Konkurenzprodukt 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.

Benötigte/Empfehlenswerte Vorkenntnisse[Bearbeiten]

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

Prüfung, Benotung[Bearbeiten]

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

Zeitaufwand[Bearbeiten]

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).

Unterlagen[Bearbeiten]

Tipps[Bearbeiten]

  • 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).

Verbesserungsvorschläge / Kritik[Bearbeiten]

  • Redmine ist einfach nur mühsam zu verwenden.
  • Vor allem in den ersten Meetings anfang Semester 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." -.-