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

noch offen

Vortrag

noch offen

Übungen

noch offen

Prüfung, Benotung

noch offen

Dauer der Zeugnisausstellung

noch offen

Zeitaufwand

noch offen

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

noch offen

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.

Materialien

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