TU Wien:Software Engineering und Projektmanagement PR (Grechenig)

Daten

Vortragende	Thomas Artner• Andreas Ehringfeld• Thomas Grechenig
ECTS	6
Alias	Software Engineering and Project Management (en)
Letzte Abhaltung	2021W
Sprache	Deutsch
Abkürzung	SEPM
Mattermost	software-engineering-und-projektmanagement • Register • Mattermost-Infos
Links	tiss:183241, eLearning

Zuordnungen

Bachelorstudium Wirtschaftsinformatik
Bachelorstudium Data Engineering & Statistics
Bachelorstudium Medieninformatik und Visual Computing
Bachelorstudium Medizinische Informatik
Bachelorstudium Software & Information Engineering

Inhalt

Üben von Software Engineerung und Projektmanagement anhand eines kleinen Projektes in der Gruppe. Verwendung von Frameworks, Schichtenarchitektur, Ticket-Verwaltungssystemen.

Ablauf

Ganz am Anfang musste ein Test zu UML und SQL absolviert werden, der von INSO und QSE gemeinsam abgehalten wurde. Dabei konnte man eine Präferenz zu einem Institut (für Einzelbeispiel und Gruppenphase) angeben, der dann nicht immer entsprochen wurde. In der Solophase muss jede Person einzeln ein einfaches, auf einer Datenbank basierendes Programm in Java (unter Verwendung von HSQL) implementieren und auch dazugehörige Dokumentation (Beschreibung mit Klassendiagrammen und Use-Case-Diagrammen) produzieren. Dazu gibt es ein Tutorial, das sich an Neulinge in Java-GUI-Programmierung und JDBC richtet. Nur wer diese Phase positiv übersteht, kommt in die Gruppenphase.

Die Einzelphase wird an sich auch mit Punkten benotet, ob diese Punkte dann wirklich in die Benotung einfließen ist von Institut und Auftraggeber abhängig, in meinem Fall hat sich bei der Endbenotung niemand mehr für die damaligen Punkte interessiert.

In der Gruppenphase arbeiten 5 bis 6 Personen in einem Team an einem Projekt. Die Teams kann man grundsätzlich frei wählen, als Projekt ist die "Ticketline" vorgegeben (Gerüchten zufolge wird sich dies bald ändern), wobei man zwischen einer Kassa- und einer Webshopapplikation wählen kann. Wer denkt, dabei wird nur programmiert, liegt falsch, mit Dokumentation wird viel Zeit verbracht. Das Projekt durchläuft die klassischen Phasen des Softwaredesigns: Analyse, Entwurf, Implementation und Testen (wobei die Analyse bereits durchgeführt wurde, das Anforderungsdokument liegt bereits vor). Dabei übernehmen die Gruppenmitglieder spezielle Rollen. Es gibt einen Teamkoordinator, einen technischen Architekten, einen Testkoordinator und eventuell deren Stellvertreter.

Während der Gruppenphase steht einem ein zugeteilter Tutor (je nach Wunsch) mehr oder weniger intensiv und hilfreich zur Seite. Es müssen bei fünf Reviews diesem die bisher erstellten Dokumente und Programmprototypen vorgeführt werden. Man erhält dann Feedback für die nächsten Reviews.

SS2018: Auch dieses Semester war "Ticketline" die Aufgabe für das Projekt. In den 9 Wochen, die die Gruppenphase bei uns dauerte hatten wir eine Tutorin zur Seite, mit der wir uns wöchentlich trafen um den Projektstatus zu besprechen. Dabei wurden allgemeine und technische Fragen beantwortet. Zu Beginn des Projekts waren wir etwas überfordert uns mussten und einmal mit der Technik (Maven, Spring, etc.) vertraut machen. Auch das Planen des Projekts war keine leichte Aufgabe, da von uns noch niemand in einer Gruppe programmiert hatte, jedoch fanden wir uns nach 2 Wochen mit leichten Anlaufschwierigkeiten relativ gut zurecht. Der Aufwand für die Features sollte nicht unterschätzt werden und man sollte wirklich schauen, dass man das Projekt von Beginn an gut plant und sich auf jeden Fall 1-2 Wochen Reserve vor Ende einplant um auch rechtzeitig fertig zu werden. Während des Projekts verwendet man das freie Ticketverwaltungssystem Redmine und SCRUM (siehe Vorlesung). Am besten ist es, wenn man seine Gruppenmitglieder bereits kennt und jeder ein gewisses Maß an Motivation mitbringt um nicht irgendwen mitschleifen zu müssen. Insgesamt haben wir für das ganze Projekt gut 980 Stunden investiert, wobei uns gesagt wurde, dass dies schon die obere Grenze darstellt. Zu der Zeit zählen alle Tutorentreffen, Meetings, Programmierstunden und sonstige Arbeit, wie das Erstellen von Dokumentationen und Präsentationen. Außerdem haben wir die Features etwas über das erforderliche Maß hinaus gestaltet. So viel Arbeit muss man aber bei Weitem nicht reinstecken, wenn man nur positiv sein möchte.

Benötigte/Empfehlenswerte Vorkenntnisse

Benötigt: Grundlagen der Programmkonstruktion VU, Datenmodellierung VU, sehr empfehlenswert: Objektorientierte Modellierung VU, Objektorientierte Programmiertechniken VU

Wer hier noch keine Kenntnisse über User-Interfaces und Programmdatenbankzugriffe besitzt (was im Allgemeinen die Regel ist, wenn man keine dementsprechende LVA im Studienplan hat und privat nicht allzuviel programmiert) sollte sich allerspätestens in den zwei Wochen, die man für die Solorunde hat, darin einarbeiten.

Es ist auf jeden Fall von Vorteil, wenn man zumindest 1-2 Personen dabei hat die eventuell schon mehr Programmiererfahrung mitbringen, als sie bis zum 4. Semester gelehrt wird. Jedoch ist das Projekt auch sonst schaffbar.

Vortrag

Keiner, die gleichnamige VO ist zum Verständnis und Absolvieren des PR nicht notwendig, kann aber - gerade bei den Reviews durch den Assistenten - helfen.

Beurteilung

Eine Person vom Institut, die während des Projekts den "Auftraggeber" spielt, ist für die Benotung eigentlich zuständig, oft wird aber in Übereinkunft mit dem Tutor benotet. Es gibt zwei Reviews durch diesen; eines in der Mitte des Projekts und eines am Ende (mit Notenvergabe). Je nach Auftraggeber werden Gruppennoten oder verschiedene Noten für jedes einzelne Gruppenmitglied verteilt. Im Allgemeinen ist die Benotung sehr mild, die größte Hürde der LV liegt darin, die Einzelphase zu überstehen.

Wenn man Mario Bernhart als Assistent zugeteilt bekommt, ist es ein Muss für ein "sehr gut", zu erraten, wie er sich eine Kassen- bzw. Webshopapplikation vorstellt und seine Applikation danach zu designen. Die Beurteilung am Ende erfolgt in Absprache mit dem Tutor für jedes Gruppenmitglied einzeln. Beim letzten Review werden den Teilnehmern auch Theoriefragen und Fragen zu Dokumenten, die von anderen Personen verfaßt wurden, gestellt, die bei Nicht- oder Falschbeantwortung zu einer schlechteren Benotung führen können.

Dauer der Zeugnisausstellung

Semester	Management Review 3 am	Zeugnis erhalten am	Dauer
2009S			ca. 2 Monate
2016S	29.06.2016	02.08.2016	ca. 5 Wochen
2020S	25.06.2020	27.07.2020	ca. 4 Wochen

Literatur

Online-Tutorials zu Hibernate, ... sind hilfreich.

Zeitaufwand

Hoch! Am Beginn des Projekts muss ein Zeitplan erstellt werden. Da 1 ECTS 25 Arbeitsstunden übers Semester entspricht werden bei diesem Zeitplan dann für die 6 ECTS der LV jedem Studierenden etwa 150 Arbeitsstunden zugemessen. Im Endeffekt liegt der Zeitaufwand aber doch unter den 150 Stunden pro Semester, was einem subjektiv aber noch immer weit mehr vorkommt als für andere LVs mit 4 SWS/6 ECTS!

Ich habe hier andere Erfahrungen gemacht. Die Einzelphase hat bei mehreren Personen in etwa 60 Stunden und die Gruppenphase 160-180 Stunden ausgemacht.

Die Bemerkung aus dem VoWi zur alten Software Engineering 1 LU lautet so:

Man sollte dafür allermindestens 5 Stunden pro Woche einplanen, Teamkoordinator und Softwarearchitekt generell noch weit mehr. Da man in dieser LVA eine Stundenliste mit seinen Arbeitsstunden führen muss, merkt man, wieviel Zeit man eigentlich reininvestiert. Aus eigener Erfahrung und aus Berichten von Kollegen reichen die investierten Stunden in das Projekt einer Person (die zu einer positiven Note führen!) von 40 (Mitläufer, die kaum etwas im Projekt machen) bis über 250 Stunden (beschäftigt sich das ganze Semester über mit fast nichts anderem als der Übung). Üblicherweise kann man, wenn man in einem guten Team ist, am Ende für jeden mit ca. 60-80 Stunden (eher kleines Projekt, oder große Gruppe) bis 100-150 Stunden (umfangreiches Projekt, kleine Gruppe) rechnen. Wie oben aber schon erwähnt, fällt üblicherweise deutlich mehr Aufwand auf Teamkoordinator und technischen Architekten, die dann auch die 250+ Stunden-Kandidaten sind.

Anderer Beitrag: In unserer Gruppe haben wir in etwa 18 Stunden pro Woche in das Projekt investiert, wobei wir sehr viele Dinge gemacht haben, die eigentlich so nicht notwendig waren. Außerdem zählen hier auch alle Gruppenmeetings und dergleichen dazu. Entgegen der Behauptung oben war es bei uns mit den Stunden relativ ausgegelichen und der Teamkoordinator und Software-Architekt mussten nicht deutlich mehr Stunden machen als der Rest der Gruppe.

Tipps

• Massive und sehr empfehlenswerte Liste an Tipps: TU Wien:Software Engineering und Projektmanagement PR (Biffl)#Tipps
• Macht diese LVA mit Bekannten, es gibt nichts Schlimmeres, als einer unfähigen Gruppe zugeteilt zu werden oder einer, mit der man sich nicht versteht.
• Für Git-Neulinge: Git-Tutorial besuchen und/oder vor dem Coden ordentlich mit Git auseinandersetzen
• Besucht das Scrum-Tutorial - Grund: Agilo!!! (Wenn man diese Software noch nicht kennt bzw. sie noch nie verwendet hat)
  • SS2015: Agilo wird nicht mehr verwendet
• Plant genug Zeit für die LVA ein, die besagten Wochenstunden reichen wie gesagt bei weitem nicht!
• Seit nicht bescheiden beim Aufschreiben eurer Stundenliste. Ihr könnt davon ausgehen, dass andere Gruppenteilnehmer ordentlich Stunden aufschlagen werden zu der reellen Zeit, die sie verbraucht haben. Wenn ihr spart, seid ihr am Ende die Dummen, auch wenn ihr reell mehr oder genauso viel gearbeitet habt.
  • Übertreibt dabei aber nicht.
  • Wenn ihr in einem ordentlichen Team seid, dann seid einfach ehrlich. Das macht auch die Arbeit für den Koordinator einfacher, Aufgaben gerecht zu verteilen.
• Als Anfänger (speziell User Interface..) beginnt rechtzeitig mit Literaturrecherche und Büffeln.

Verbesserungsvorschläge / Kritik

• Es wird sehr viel Zeit mit dem Implementieren von Features benötigt, das ein gutes Strukturieren und Planen derselben eventuell nachrangig ist. Dies sollte mMn etwas mehr Gewicht haben, da es ja Software-Engineering und Projektmanagement heißt.

Materialien

Neues Material hinzufügen

2

• 2021S Notizen zur Validierung

E

• Einzelphase Feedback 2021S.pdf (details)