TU Wien:Software Engineering Projekt PR (Artner)

Daten

Vortragende	Thomas Artner• Barbara Tappeiner
ECTS	6,0
Alias	Software Engineering Project (en)
Letzte Abhaltung	2024S
Sprache	Deutsch
Mattermost	software-engineering-projekt • Register • Mattermost-Infos
Links	tiss:194149

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

Jegliche Erfahrung mit Angular und/oder Spring Boot spart viel Zeit bei der Einarbeitung, besonders für die Einzelphase.

Vortrag

noch offen

Übungen

noch offen

Prüfung, Benotung

noch offen

Dauer der Zeugnisausstellung

noch offen

Zeitaufwand

noch offen

Unterlagen

noch offen

Tipps

Sammlung von diversen Tipps für die Einzelphase

Für die Einzelphase sind ~40h vorgesehen, was ohne Vorerfahrung und nur mit dem gegebenen Tutorium einfach nicht machbar ist.

Mit Informatik-HTL Erfahrung ist es möglich, die Einzelphase fast fehlerfrei in unter 40h zu implementieren. Es folgen ein paar Tipps, die vielleicht helfen können, wenn diese Erfahrung nicht da ist.

So gut wie alle dieser Tipps sind unabhängig von Technologie und Projektumfeld, sind also grundsätzlich in jedem Projekt anwendbar, einige können auch während der Gruppenphase hilfreich sein.

Zeiteinteilung/Wo fange ich an?

Es zahlt sich aus, auch für die Einzelphase eine kurze Aufwandsschätzung am Anfang zu betreiben.

Öffne das Angabedokument, lies alle User Stories von oben nach unten und schätze ab wie viel Zeit welche User Story in Anspruch nehmen wird. (Das ist keine exakte Wissenschaft und sogar Projektmanager mit jahrelanger Erfahrung scheitern routinemäßig daran, es geht hier nur darum eine Relation zu bekommen was wie lange dauern wird, hier können statt Stunden auch Story Points genommen werden)

Wichtig: Ignoriere bei deiner Abschätzung die "Story Points" die ggf. in der Angabe vorkommen, denke lediglich nach wie du etwas ungefähr umsetzen würdest und schätze basierend darauf.

Mit dieser Schätzung kannst du dir die Zeit einteilen, wann du an welchem Teil des Projekts arbeiten willst. Plane dir grobe Blöcke ein, wann du welchen dieser Teile abschließen willst:

• Einarbeitung (Anschauen der Technologien, Durchgehen der Angabe und Herausfinden welcher Teil wo liegt und was macht)
• Umsetzung der User Stories (Lege ein klares Datum fest, das du als "Feature Freeze" siehst - a.k.a wann dein Projekt alle Funktionen haben soll - und halte dich daran. Dieses Datum sollte nicht weniger als 2 Wochen vor Abgabetermin sein.)
• Verifizierung der User Stories und Tech Stories (nach dem Feature Freeze, Details siehe Abschnitt "Userstories und Techstories verifizieren")
• Nachbesserungen

Ob du während, vor oder nach der Implementierung testen willst ist Frage deiner Präferenz.

Beginne nach (oder während) der Einarbeitung möglichst mit der kleinsten User Story, die keine Abhängigkeiten zu anderen hat (bspw. Löschen eines Objekts) um mit der Umsetzung davon einen Überblick über die Programmarchitektur zu erhalten.

Es gibt keine Bonuspunkte

Die harte Realität in diesem Projekt ist, dass es nur Punkteabzüge gibt wenn etwas nicht passt, nicht aber mehr Punkte wenn etwas besser ist als gefragt.

Was dieser Punkt sagen will ist, dass du wenn in einer Techstory 10 Tests gefragt sind exakt (und exakt!) 10 Tests schreibst. Die Zeit die du in einen 11ten Test stecken würdest stecke lieber in die Verbesserung/Stärkung der anderen Tests oder gar in andere User/Techstories.

Bei Unklarheiten nachfragen

Ich persönlich hatte keine Zeit dafür, es zahlt sich aber aus bei jeglichen Unklarheiten in der Angabe nachzufragen. Das kann Punkte bedeuten oder Implementierungszeit sparen, besonders wenn man eine Vorgabe einer Userstory falsch deutet.

Userstories und Techstories verifizieren

Optimalerweise prüfst du wenn du mit einer User Story fertig bist ob deine Implementierung exakt mit der Spezifikation übereinstimmt.

Nach dem Feature Freeze, wenn du alles implementiert hast was du implementieren wolltest, verifizierst du alle User- und Techstories.

Lege dir dafür 2-3 Stunden zurecht (die IMO auch in die Arbeitsstundenliste aufgenommen werden sollten), öffne die Angabe und dein Projekt und gehe jede User Story und jede Tech Story Zeile für Zeile genau durch. Das dauert lange und kann monoton werden, ist aber wichtig wenn du ausreichend Punkte erreichen willst. Wenn du in dieser Suche etwas findest, was eine User oder Techstory verletzt, notiere es dir (ich empfehle direkt im GitLab Repository ein Issue zu erstellen) und verifiziere weiter alles. In der Zeit in der du Stories validierst schreibst du keinen Code, egal wie trivial er ist oder ob es nur ein Tippfehler ist, um nichts zu übersehen. Du erstellst nur Issues oder Notizen.

Wenn du mit der Verifizierung fertig bist hast du einen Haufen Issues vor dir, die du dann reihenweise abarbeitest und ausbesserst. Wenn alle abgearbeitet sind fängst du wieder von oben an, bis du das ganze Dokument durchgegangen bist und nichts mehr gefunden hast.

"Wehre dich" beim Abgabegespräch

Dieser Punkt ist sehr direkt aber meiner Meinung nach auch mitunter der Wichtigste - Beim Abgabegespräch kann man einfach Punkte "beschützen", wenn die eigene Lösung richtig ist.

Nimm am Besten einen Laptop, Tablet oder die ausgedruckte Angabe mit und halte die User und Techstories während des Gesprächs bereit.

Wenn du dir in deiner Lösung sicher bist und beim letzten Punkt genug Zeit investiert hast sollte dein Projekt fast allen User-/Techstories entsprechen. Wenn dir für etwas Punkte abgezogen werden was nicht so in der Spezifikation steht merke es an, egal ob es trivial wirkt. Für Hardcore-Projektmanagement-Menschen: Du kannst das Abgabegespräch als Projektabnahme, die Punkte als Geldbetrag und den/die Tutor*in als Auftraggeber sehen.

So gut wie niemand wird bei einem genauen Abgabegespräch alle Punkte erhalten, irgendetwas (richtiges!) lässt sich in jedem Projekt finden. Manchmal wollen Tutor*innen allerdings Punkte abziehen, die so nicht spezifiziert waren, was du direkt einbringen kannst (egal wie "logisch" etwas zu sein scheint - wenn es nicht spezifiziert ist war es nicht Teil der Aufgabe).

(Dieser Punkt ist keine Anweisung respektlos oder arrogant daherzukommen, hier geht es um sachliche Diskussion der Requirements!)

Git und die Commit History

Eine häufige Angst die ich mitbekommen habe ist dass etwas in der Commit History nicht passt, dass falsche Files auf Gitlab gepusht werden, etc. Was folgt sind ein paar Tipps bezüglich Git, die dabei helfen können:

• Die erste Git-Hürde ist der Initial Commit. Kopiere das gegebene Projekttemplate in einen Ordner und führe git init aus. Danach gehst du die Liste der Untracked Files (git status, oder einfach in der IDE deiner Wahl) durch und fügst alle Files von Hand hinzu, die gepusht werden sollen. Alle anderen Files fügst du in ein .gitignore-File ein. Nun sollte bei git status alles grün sein. Jetzt führst du das Programm aus. Alle Files die nun als Untracked angezeigt werden kannst du (höchstwahrscheinlich) im .gitignore-File eintragen. Wenn bei git status keine Untracked Files mehr angezeigt werden kannst du den Initial Commit erstellen.
• Commits allgemein (üblicherweise ausgenommen dem Initial Commit) sollten einem Format folgen, das in der Angabe angedeutet wird. Dein Ziel ist unter Einhaltung der Regeln jeden Commit so zu erstellen, dass er in einer Liste aller Commits im Normalfall nicht auffällt. Du kannst die Commitliste vor einem Push mittels git log --oneline anzeigen.
• Wenn du dir anfangs mit Git unsicher bist, arbeite die erste Woche einfach lokal (d.h. kein git push). Falls du einen Fehler machst, eine Commitmessage falsch schreibst, etc. hast du dann noch immer die Option das auszubessern. Sobald etwas gepusht ist gibt es meistens kein Zurück. Spätestens gegen Halbzeit der Einzelphase solltest du dir allerdings sicher genug sein, direkt zu pushen.

Highlights / Lob

noch offen

Verbesserungsvorschläge / Kritik

noch offen

Materialien

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