TU Wien:Software Engineering Projekt PR (Biffl)

Daten

Zuordnungen

Bachelorstudium Informatik	Modul Software Engineering Projekt (Enge Wahl)
Bachelorstudium Wirtschaftsinformatik	Modul WIN/SEP - Software Engineering Projekt (Pflichtfach)
Bachelorstudium Medieninformatik und Visual Computing	Modul Software Engineering Projekt (Pflichtfach)
Bachelorstudium Medizinische Informatik	Modul Software Engineering Projekt (Pflichtfach)
Bachelorstudium Software & Information Engineering	Modul Software Engineering Projekt (Pflichtfach)

Inhalt

noch offen, bitte nicht von TISS/u:find oder Homepage kopieren, sondern aus Studierendensicht beschreiben.

Ablauf

noch offen

Benötigte/Empfehlenswerte Vorkenntnisse

Benötigte Vorkenntnisse:

• Java

Empfohlene Vorkenntnisse:

• Angular
• Rest API
• JPA
• Umgang mit GitLab
• Automatisierte Tests im Backend (das Backend wird in Java geschrieben)

Vortrag

Es gibt Tutorien bei denen die Basics erklärt werden, die man für die LVA benötigt, zum Beispiel: das Software Architektur Modell welches verwendet wird, wie man testet, Rest API und noch vieles mehr.

Übungen

noch offen

Prüfung, Benotung

2025S: Es gibt keine Prüfung, es gibt 3 Management Reviews und beim Letzten und Wichtigsten, dem MR3 wird die fertige Software präsentiert, dabei muss jeder erklären was er oder sie gemacht hat. Bei Stefan Biffl wird man dann zusätzlich noch nach einem Design Pattern gefragt aus der Liste der Design Pattern, die man als Gruppe ausgearbeitet hat. Jedes Gruppenmitglied muss 2 Design Patterns ausarbeiten, man wird aber nicht über die eigenen gefragt und es kann auch sein, dass er etwas anderes fragt, bei uns musste die erste die dran war DTOs erklären. Er meinte dann DTOs seien ein Design Pattern und sie müsse jetzt keines aus der Liste mehr erklären.

Dauer der Zeugnisausstellung

2025S; 26.06.2025; 26.7.2025; 4 Wochen

Zeitaufwand

Für die Gruppenphase sollte man ca. 120-180 Stunden einplanen, wenn man ein sehr gut haben möchte.

Unterlagen

noch offen

Tipps

Wichtige Tipps wenn man Prof. Biffl in QSE als Betreuer hat:

• Er ist sehr "Wirtschaftsorientiert", was bedeutet, dass ihm User Studies und die Frage nach Zielgruppen und Vermarktung des Projekts sehr wichtig sind. Man sollte immer argumentieren können warum das Projekt am Markt Erfolg haben kann bzw. welche Nutzer es wahrscheinlich und aus welchen Gründen verwenden würden.
• Er legt sehr viel Wert auf ein hübsches Frontend was gut auf die "User Experience" achtet. Niemals etwas löschen ohne, dass es ein "Bestätigungs-Pop-Up" oder ein gut sichtbares "Rückgängig" gibt.
• Bei den MRs will er immer selbst durch das Frontend klichen. Hier unbedingt viele Testdaten einfügen, damit das Programm nicht leer ist und er nicht erst irgendwas anlegen muss um herumzuprobieren.
• Es lohnt sich bei ihm nicht für die MRs viel Zeit in Präsentationen zu stecken, weil ihm die Folien relativ wurscht sind und er sie teilweise gar nicht sehen will. Haben sollte man aber trotzdem immer eine und die Folien sollten auf jeden Fall nummeriert sein.
• Jedes Gruppenmitglied sollte bei MR2 und MR3 unbedingt einen etwas aufwendigeren und selbst geschriebenen Testcase herzeigen und erklären können.
• Wenn jeder für das MR3 zwei Design Patterns ausarbeiten soll, lässt er sich von jedem ein Design Pattern erklären, was jemand anderer aus der Gruppe ausgearbeitet hat. D.h. jeder muss alle Design Patterns der anderen erklären können. Wenn man ihm ein Design Pattern erklärt, fragt er sehr gerne, welche Design Patterns vom Prinzip ähnlich sind und warum.
• Es ist sehr wichtig, dass man bei jedem Feature was man ihm vorstellt argumentieren kann, warum dieses Feature aus einer wirtschaftlichen Perspektive gebraucht wird.
• Er bringt sehr viele Ideen ein und man muss eine Balance finden, genug von seinem Input zu Implementieren und sich gleichzeitig nicht durch das Einplanen zu vieler Features zu überfordern oder sich das Projekt "wegnehmen zu lassen".
• Es kann bei ihm so wirken, als würde er das Projekt oder Ideen schlecht finden, denn er lobt wenig und kritisiert viel, was er aber nicht böse oder als zwingende Änderungsvorgabe meint, sondern als Verbesserungsvorschlag.

Highlights / Lob

Die LVA ist eine gute Vorbereitung, wenn man später in der Software Entwicklung arbeiten möchte, da man hier als Team gemeinsam lernt wie man zusammen eine größere Software schreibt. Auch den Umgang mit Git (und den resultierenden Problemen wie Merge Conflicts) in der LVA als Gruppe zu lernen ist sicher angenehmer, als in einem Unternehmen, auch wenn es dennoch mehr oder weniger learning bei doing bleibt.

Verbesserungsvorschläge / Kritik

• Der geschätzte Zeitaufwand von 40h für das EInzelbeispiel sind ein absoluter Witz. Ohne Vorkenntnisse sich durch HTML, CSS, JavaScript, Angular, Typescript, Bootstrap und SpringBoot zu kämpfen schafft man kaum unter 40h. DIe Einzelaufgabe wird dadurch einfach nur viel Gerate und copy-paste auf bereits bestehendem Code. Lernen wird man bei nicht viel. Die LVA sollte man in 2 Fächer mit jeweils 6 ECTS teilen und die Technologien von Grund auf beigebracht bekommen.
• Die Angaben zur geschätzten Zeit, die man für die Einzelphase im Schnitt braucht, könnten nicht ferner von der Realität sein. Auf Nachfrage einer Person im Höhrsaal wurde uns vom Prof gesagt, dass man mit mind. 15 Stunden rechnen kann, einige Leute aber auch 25 brauchen können. Ich kenne Leute von der HTL, die so etwas schon ein paar Mal gemacht haben und so um die 40h gebraucht haben, habe aber auch von Leuten ohne viel Vorerfahrung gehört, die 100h+ reingesteckt haben. Ich persönlich hatte neben EP1/2 nicht viel/keine Vorerfahrung und hab es mit ca. 80h Aufwand nicht geschafft. Das soll aber nicht heißen, dass es nicht möglich ist. Es haben genug Leute angegeben, dass sie 30-40h gebraucht haben und davon hatten sicher einige ebenso wenig Vorkenntnisse. Wenn man noch nichts mit HTML, TypeScript, Spring Boot, Angular zu tun hatte, wird es meiner Meinung nach sehr schwierig unterhalb der 40h zu bleiben. Wenn man alles selber machen möchte, ohne Vorkenntnisse und ohne ChatGPT, nur mit Google und Docs lesen, dann sollte man 100h+ einplanen. Es wäre überhaupt am besten, wenn man sich im Februar/September vor dem Semester, in dem man SEP machen möchte, ausführlich mit dem Tech Stack beschäftigt. Idealerweise holt man sich eine Angabe und Template zur Einzelphase aus dem Semester davor und versucht es so gut es geht selber zu bearbeiten. Das ist hauptsächlich an die Personen gerichtet, die frisch von EP1/2/PP kommen. Je nachdem sollte man sich das Semester entsprechend einteilen.

Materialien

Diese Seite hat noch keine Anhänge, du kannst aber neue hinzufügen.