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

Daten

Diese LVA wird nicht mehr von dieser Person angeboten, ist ausgelaufen, oder läuft aus und befindet sich daher nur noch zu historischen Zwecken im VoWi.

ECTS	6
Sprache	English, Deutsch
Abkürzung	ASE
Links	tiss:183243, tiss:188910

Zuordnungen

Masterstudium Business Informatics
Masterstudium Medizinische Informatik
Masterstudium Software Engineering & Internet Computing

Mattermost: Channel "advanced-software-engineering" • Register • Mattermost-Infos

Inhalt

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

• 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

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

Prüfung, Benotung

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

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

Zeitaufwand

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

• Materialien

Tipps

• 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.
• (WS20): Wir hatten Prof. Biffl als Betreur. Bei den hier vorhandenen Meinungen könnte man glauben, dass er sehr streng beim MR-3 benotet. Bei uns war das nicht der Fall. Er war auch freundlich zu uns. Beim MR-1/2 hatte er Einwände/Verbesserungsvorschläge, die aber durchaus sehr sinnvoll waren.
• Uns hat es sehr geholfen, eine CI/CD pipeline mit formatting checks, linting, und tests zu haben, nachdem doch sehr viel code geschrieben wird, und man, speziell wenn man iterativ arbeitet, code doch mehrmals bearbeiten muss.

Verbesserungsvorschläge / Kritik

• Redmine ist einfach nur mühsam zu verwenden. (Seit zumindest 2020SS wird GitLab verwendet, das geht recht gut, speziell wenn man sich damit bereits auskennt)
• 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.
• 2020WS: Der Einstiegstest war sehr einfach, ich habe mir im Vorhinein ein Java Template zusammengeschustert, mit dem ich das ganze ich IIRC unter 50 Minuten lösen konnte, und auch unser damals unerfahrenstes Teammitglied hat den Test dann im Retake geschafft. Das Problem war iterativ, man mustte einen Client schreiben der von einem Server Problembeschreibungen runterlädt, das Problem löst, und dann die Lösung wieder hochlädt. Es hat sich um eine 2D Fläche gedreht, auf der Punkte waren, und man musste jedes mal feststellen, welche Punkte unter Einbezug gewisser Bedinungen erreicht werden konnten.
• 2021SS: Der Einstiegstest war doch relativ hart. Von etwa 60 Leuten die angetreten sind (Laut Anmeldedaten auf Reset) kamen (nach letztem ersichtlichen Stand auf Reset) 5 Gruppen zustande mit á 5 oder 6 Personen. Testszenario war fast ident zu dem vom 2020SS mit 4 (oder 3 am Nachtragstermin) Stages wo ein zunehmend komplexeres Problem zu lösen war und mittels POST request die jeweiligen Lösungen der Testszenarien zurück an den TU Server schicken von den man die Problemstellung zuvor erhalten hat. Datenbanken musste man keine aufsetzen, lediglich GET und POST requests in den man sich das PDF mit der Problemstellung und die einzelnen Testinstanzen geholt hat und eben die Lösungen zurückgegeben hat. Es konnte nur eine Stage nach der anderen abgeschlosen werden und 100% der Testszenarien mussten richtig sein zum Bestehen des Einstiegstests. Zu empfehlen ist eine Programmiersprache zu wählen die sich kurz fast (weniger zu schreiben) und ut und schnell integrierbare externe Packages oder Libraries anbietet die eventuelle Probleme löst ohne diese selber implementieren zu müssen. Beispiel dafür wäre der 1. Testtermin im SS2021 wo man einen Dijkstra Algorithmus implementieren musste. Mit einer entsprechenden externen Library war man da natürlich um einiges schneller und weniger fehleranfällig, als wenn man den Algorithmus selbst implementieren musste und auf Edge-Cases testen muss. Es zahlt sich aus im Vorhinein sich eine Struktur zu überlegen wie man die Stages löst und wie man die GET und POST requests anordnet. Oft können Code Teile von früheren Stages für spätere Stages wiederverwendet werden und es zahlt sich damit aus sich bei der 1. Stage ein ordentliches Konzept zu überlegen, spart Zeit und Nerven in späteren Stages. Es waren etzwa 60 bis 150 Testszenarien pro Stage und es wurden auch Edge Cases der Algorithmen abgefragt. Die Angaben waren nicht immer sofort verständlich auch weil sie meist auf den PDFs Beispiele für die Kommunikation zwischen TU Server und der eigenen Implementierung zeigen die zwar das generelle Problem beschreiben, aber meist einen wesentlich simpleren Fall darstellt als die tatsächlichen Testszenarien und damit oft Edge-Cases erst beim Testen ersichtlich werden und dementsprechende Anpassungen in der Implementierung verlangen. Genau lesen hilft!

• 2022SS: Gleiche Struktur wie 2021SS und wieder ein harter Test. Ich kann die erwähnten Tipps wirklich nur betonen. Ich persönlich habe es erst mit dem Retake geschafft und war bei weitem nicht der einzige der noch einmal antreten musste. Die Sinnhaftigkeit eines solchen Einstiegstests für ein Pflichtfach ist mir absolut nicht klar. Sie nennen es "Rest API" doch im Endeffekt schickt man nur die simpelsten GET und POST requests hin und her. Die wirkliche Schwierigkeit ist die Aufgaben zu kapieren und zu implementieren wo man aber wegen der zeitlichen Einschränkung als Ottonormalprogrammierer wahnsinnig schlechten Code hinfetzt (hauptsache es läuft) und jegliche Programmierprinzipien über Bord wirft (aus Dont Repeat Yourself wird Repeat Everything). Wäre die Aufgabe einfach in einem Zeitraum von 48 Stunden zu implementieren könnte man sich zumindest auch Gedanken über die Struktur machen.
  • Dieses Semester wares Graphentheorieprobleme und beim Retake 2D-Probleme. Ich habe nichts gegen Einstiegstest. Leider prüft der Einstiegstest bei dieser Pflichtlva, wie gut man die Probleme anhand der ausbaufähigen Angaben versteht und schnell löst. Wenn man die Angabe falsch interpretiert oder einen falschen Ansatz hat, bleibt man bei einer Stage stecken und verliert schnell Zeit. Retroperspektiv waren die Beispiele sehr einfach zu lösen, wenn man einmal die Angaben verstanden hat und sich eine saubere Lösung überlegt hat (natürlich hat man dann auch kein Zeitdruck). Mein Tipp: ein Template in einer Sprache, die man gut beherrscht, zu wählen, wo es auch viele mathematische und algorithmische Libraries gibt. Das Program sollte dann auch schnell ausführbar sein, damit ihr nicht unnötig Zeit verschwendet. Weiters sollte das Template so aufgebaut sein, dass ihr schnell Lösungen programmiert. Also sollte das Template vielen Softwareengineeringprinzipien widersprechen (Reusability, understandability, maintainability,...). Meiner Meinung sollte es auch die Möglichkeit geben, zusätzlich zum Einstiegstest, ein kleines Programmierprojekt zu realiseren und in einem Abgabegespräch das Projekt zu erklären. Dadurch hat man auch Zeit, ein sauberes Projekt aufzusetzen (Anforderungsanalyse, Saubere Architektur, Unittests, Dokumentation,...). Bzw. sollte es schon reichen, wenn man eine gewisse Anzahl von Instanzen gelöst hat. Wie schon gesagt, dieser Einstiegstest, wo man 100% spiegelt nicht die Anforderungen für diese LVA wider.
• 2022S: der Einstiegstest war für mich in ca 2 Stunden lösbar, nachdem ich am Wochenende das Demo-Beispiel genutzt habe um eine Template zu erstellen; das Demobeispiel war auch nützlich um eine effektive Vorgehensweise für den eigentlichen Test zu finden - aus meiner Perspektive: statt einer Ad-Hoc Lösung für die noch relativ harmlose Stage 1 gleich einen soliden Algorithmus wählen (rückblickend hätte man z.B. das Demo-Beispiel, das nach 2020S klingt, als graphentheoretisches Problem auffassen können), grundlegende Testfälle lokal überprüfen, und noch vor dem Test alles, was mit dem Test-System zu tun hat (REST-Endpoints, Tokens etc.) automatisieren. Im konkreten 2022S-Beispiel ging es um Wege in einem gerichteten Graphen (aber halt in mehr Text verpackt); für Stage 1 war nur die Existenz eines Weges zu ermitteln, aber gleich mit Dijkstra den/einen kürzesten Weg zu finden hat sich nicht sonderlich überraschend in den Stages danach ausgezahlt. Ich empfehle, die Lösung jeder Stage als abgeschlossen zu betrachten, also z.B. nach Stage 1 nicht den Code zu adaptieren um damit Stages 1+2 lösen zu können, sondern stattdessen mit copy/paste eine separate Lösung für Stage 2 zu bauen.

Materialien

Neues Material hinzufügen

2

• 2023-entry-retake-stage1.pdf (details)
• 2023S-entry-retake-stage3.pdf (details)
• 2023S-entry-retake-stage4.pdf (details)

E

• Entry Exam 2019S
• Entry Exam 2017W.pdf (details)
• Entry Exam 2016S.pdf (details)