TU Wien:Software Engineering und Projektmanagement PR (Biffl)

Aus VoWi
Wechseln zu: Navigation, Suche

Im Rahmen der Studienplanänderung 2011 der Technischen Universität Wien wurde "Software Engineering und Projektmanagement LU" in "Software Engineering und Projektmanagement PR" umbenannt. Die beiden LVAs sind daher äquivalent.

  • Studierende der TU, die im WS11 oder später mit ihrem Studium begonnen haben, können nur die LVA mit neuem Titel, sofern sie noch nach dem "Studienplan" ein Pflicht-/Wahlfach ist, für ihren Abschluss verwenden.
  • Studierende der TU, die bereits vor dem WS11 inskribiert waren, müssen genau eine dieser beiden LVAs absolvieren.

Für Details siehe auch FAQ Studienplan 2011.



Daten[Bearbeiten]

Inhalt[Bearbeiten]

Üben von Software Engineerung und Projektmanagement anhand eines kleinen Projektes in der Gruppe.

Ablauf[Bearbeiten]

Die LVA besteht aus 1) der Eingangsphase 2) der Gruppenphase. Die Eingangsphase wird vom INSO und QSE gemeinsam abgehalten. Für die Gruppenphase könnt ihr eine Institutspräferenz abgeben, letztendlich werden die Gruppen aber entsprechend auf die Institute aufgeteilt.

Eingangsphase[Bearbeiten]

Die Eingangsphase (dessen positiver Abschluss Voraussetzung für die Gruppenphase ist) absolvierst du alleine und besteht aus

  • Einstiegstest zu UML und Architekturdesign (proforma Anmeldung, nach dem Test wird auf jeden Fall ein Zeugnis ausgestellt)
  • Diversen Tutorials (ohne Anwesenheitspflicht aber sehr zu empfehlen!)
  • Einzelbeispiel
    • Eigenständig ein kleines Verwaltungs-Programm in Java und mit Hilfe von HSQLDB implementieren.
    • Unit Tests
    • Dokumentation (Beschreibung mit Klassendiagrammen und Use-Case-Diagrammen)
  • Abgabegespräch
    • Live Test (40 Minuten Zeit um kleine Programmieraufgaben zu lösen)
    • Abgabegespräch (Ein Tutor schaut sich deine Dokumentation und deine Lösung für das Einzelbeispiel an)

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. Genaueres siehe #Prüfung

Gruppenphase (QSE)[Bearbeiten]

Für eine Beschreibung der Gruppenphase am INSO siehe TU Wien:Software Engineering und Projektmanagement PR (Grechenig)

In der Gruppenphase arbeiten 5-6 Personen in einem Team an einem Projekt. Die Teamzusammenstellung ist grundsätzlich frei wählbar, seid ihr allerdings weniger als 5, werden Gruppen zusammengelegt oder leere Plätze aufgefüllt. Auch das Projekt ist generell frei wählbar, wenn das Institut euren Projektvorschlag annimmt. Grundsätzlich nicht angenommen werden Spiele, Web-Applikationen oder verteilte Systeme. Als alternative gibt es das vom Institut vorgeschlagene Projekt "MP3 Player".

Während der gesamten Gruppenphase steht euch ein zugeteilter Tutor (je nach Wunsch) mehr oder weniger intensiv und hilfreich zur Seite.

Vorgaben[Bearbeiten]

Am QSE gibt es einige Vorgaben bezüglich der Technologien. Zu verwenden sind:

  • Maven
  • git
  • Redmine als PM tool (wird inkl. git repository vom Institut zur Verfügung gestellt)
  • Spring (Dependency Injection)

Nicht erlaubt sind OR-Mapper jeglicher Art (Hibernate, JPA, ...). Datenbankanbindung muss also komplett selbst implementiert werden.

Projektablauf[Bearbeiten]

  • Projektvorschlag und -auftragsphase (Ihr schreibt einen Projektvorschlag der angenommen oder abgelehnt wird, und auf Basis dessen einen Projektauftrag)
  • Wöchentliche Jour fixe Termine mit eurem Tutor
  • Zu drei Management Review Terminen, präsentiert ihr dem euch zugewiesenen Univ. Assistenten euer Produkt, beim letzten Termin werdet ihr von ihm auch benotet.

Wer denkt, dabei wird nur programmiert, liegt falsch, mit Dokumentation wird die meiste Zeit verbracht. Das Projekt durchläuft die klassischen Phasen des Sofwaredesigns: Analyse, Entwurf und Implementation. Testen und Qualitätssicherung sollten zu diesen Phasen parallel laufen (etwa mit Test-Driven Development). Während die klassischen Phasen der Softwareentwicklung aufgrund der Rahmenbedingungen der LU durchlaufen werden, wird versucht agile Methoden wie SCRUM einzusetzen. Das bedeutet wiederum das während der Implementierung, Use-Cases und nicht Komponenten an die Gruppenmitglieder verteilt werden. Jedes Gruppenmitglied programmiert also einen Use Case bzw. ein "Feature" statt eine Komponente wie z.B. "Datenbank" oder "GUI".

Dabei übernehmen die Gruppenmitglieder spezielle Rollen. Es gibt einen Teamkoordinator, einen Systemarchitekten, einen Dokumentationsverantwortlichen, einen Testverantwortlichen und eventuell deren Stellvertreter. Jede dieser Rollen ist mit sog. horizontalen und vertikalen Verantwortlichkeiten behaftet. Normalerweise denkt jeder gleich an die Horizontalen Verantwortlichkeiten. Z.B. Als Team-Koordinator(TK) hat man die Aufgabe über den Projektstatus bescheid zu wissen, also zu wissen "wie weit" die Gruppe ist. Woher weiß man aber wie weit die Arbeit im Team fortgeschritten ist? Die anderen Gruppenmitglieder haben nämlich in ihrer vertikalen Rolle die Aufgabe Stundenlisten und andere Projektmanagement Artefakte zu führen, welche die horizontale Rolle des TK's erst ermöglichen. Der TK kann also z.B. aufgrund der Stundenlisten von anderen Gruppenmitgliedern beurteilen "wie weit" die Gruppe ist.

Sommersemester 2008: Die in der Gruppe einzunehmenden Rollen waren Projektleitung, Technische Architektur, Infrastruktur, GUI Design, Dokumentation und Testen. Allerdings wurde mehrmals betont und Wert darauf gelegt, dass jeder alles machen muss. Die Arbeit wurde also auf komponentenbasis aufgeteilt und jeder musste seine Komponente selbst designen, programmieren, dokumentieren und testen. Die Gruppenarbeit ist weit aus anspruchsvoller als das Einzelbeispiel, daher rächt es sich, wenn man sich beim Einzelbeispiel versucht durchzuschummeln. Design Pattern - Prüfungen gab es keine. Es hilft aber sehr, sich über das DAO-Pattern (Data Access Object) im Klaren zu sein. Dieses war der Schwerpunkt der diessemestrigen Projektarbeit.

Architectural Review[Bearbeiten]

Gegen Ende wird ein Gruppenmitglied zu einem Gespräch eingeladen, bei dem der Code durchgegangen wird. Dazu muss der oder die Eingeladene einen guten Überblick über die Architektur haben.

SS 2011: Es gab keine Prüfungen während des Semsters und auch nur ein Treffen (Tester). In der letzten Semsterwoche gab es ein Abgabegespräch über das gesamte Projekt, zu dem eine Person pro Gruppe 48h zuvor zufällig(?) ausgewählt wurde. Das sorgte für Stress und Diskussionen, war aber halb so schlimm.

SS 2015: Die Person, die zum Architectural Review erscheinen muss, wird nicht mehr zufällig ausgewählt, sondern von der Gruppe bestimmt.

Benötigte/Empfehlenswerte Vorkenntnisse[Bearbeiten]

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.

Des weiteren würde ich dringend empfehlen sich mit Java-GUI Gestaltung mit Swing (ohne GUI-Editor) und mit JUnit zu befassen, da das Einzelbeispiel beides voraussetzt und wenn man sich erst einarbeiten muss in die Technologien wird die Zeit schon sehr knapp. Außerdem sollte man die Vorlesung Datenbanksysteme VU absolviert haben, damit man ein ungefähres Verständnis von JDBC vorweisen kann.

Vortrag[Bearbeiten]

Keiner, die gleichnamige VO ist zum Verständnis und Absolvieren der LU auf gar keinen Fall notwendig, der Einführungsvortrag zu den verwendeten Technologien ist aber auf jeden Fall zu empfehlen!

Prüfung[Bearbeiten]

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 und/oder der Gruppe benotet. 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.

Zusatz [aus Tutorensicht]: Der letzte Satz stimmt, solange man sich an die Vorgaben des Tutors und des Assistenten hält und eine Software ablieftert, die halbwegs mit den anfänglichen Anforderungen übereinstimmt. Es ist keine Seltenheit, dass einzelne Gruppenmitglieder negativ beurteilt werden, auch dass ganze Gruppen negativ abschließen bzw. abbrechen (weil klar ist, dass sie es nicht schaffen werden) kommt 1-2-mal pro Semester vor. (üblicherweise hat SEPM 15-20 (SS) bzw. 25-30 (WS) Gruppen pro Institut).

Zusatz (WS 2010/11): Am INSO ist der Aufwand nicht sehr hoch. Die größte Hürde ist wirklich die Einzelphase. Ich habe ein Gut (U2) bekommen, mit höchstens 8 Stunden Aufwand pro Woche. Ich würde auf jeden Fall das INSO empfehlen, weil hier schon ein Grundgerüst (TLCore) vorhanden ist und man nur einzelne UseCases implementieren muss. Man kann sich also wirklich auf das Projektmamagement und das Implementieren konzentrieren.

Zusatz [aus Tutorensicht]: Der Aufwand ist auch am QSE nicht höher, der reale Unterschied liegt bei den verwendeten Technologien und der Vorgabe des Projekts. [QSE: Entweder eigene Idee oder MP3-Player; Inso: Ticketline]

Weiter Meinung(SS 2011): INSO war sehr angenehm. QSE kann ich nicht beurteilen. Man hört aber leider gar nichts positives. Ein Freund von mit hats am QSE gemacht. Seine Worte: "Wenn man eine Herausforderung braucht, dann machs beim QSE". Am INSO hab ich 120 Stunden investiert. Ein großzügiger TL Core ist vorgegeben. Beim QSE muss man alles von Grund auf programmieren. Ein anderer Bekannter war am QSE schon fertig mit seiner Arbeit, die dann sehr gelobt wurde. Doch sie konnten ihm am Ende kein Zeugnis ausstellen, weil sie ein falsches Framework verwendet haben(früh bemerkt...). Sie haben dann im Sommer programmieren müssen.

Weiter Meinung II (SS 2011): Hab die Übung am QSE gemacht (unsere Gruppe wurde entgegen unserer Präferenz dem QSE zugeteilt) und wurde nach dem anfänglichem Schock positiv überrascht. Ich habe wirklich viel gelernt, sowohl Tutorin als auch Assistent waren sehr angenehm und die Note passt auch. Allerdings waren es pro Person schon ca. 200 Stunden, die in die Übung reingesteckt wurden. Das mit dem falschen Framework kann ich fast nicht glauben, da bei uns betont wurde, dass es auf die Technologien und nicht auf spezifische Frameworks ankommt.

Meinung (SS 2015): Übung am QSE bei Prof. Biffl, Arbeitsaufwand war exorbitant über den 6 ECTS, Betreuungsverhältnis eher mau (trotz wöchtenlicher Treffen mit dem Tutor, der sich aber eher weniger für das ganze zu Interessieren schien), Prof. Biffl wirkte recht herablassend und schob auch den einen oder anderen sexistischen Kommentar gegenüber unseren weiblichen Teammitgliedern. INSO wäre wohl besser gewesen. EDIT von jemanden der INSO gemacht hat: War genau der selbe Scheiss (minus vielleicht der sexistischen Kommentare, hab aber weder am Institut noch in einer Gruppe dort eine Frau gesehen). Der Arbeitsaufwand ist in dem PR einfach zu hoch. Wer kein Team von Leuten hat, die das schon mal in einem professionellen Umfang gemacht haben, wird die meiste Zeit damit verbringen, irgendwelche Quirks von Java Bibliotheken zu zähmen (inklusive Bugs die außerhalb eines Stackoverflow Artikels nirgendwo dokumentiert sind), während ausschließlich Ergebnisse (also "der Projektfortschritt") bewertet werden. Nachfragen beim Tutor wurde meistens "auf die nächste Stunde" verschoben, Antworten kamen dann nie. So eine wichtige LVA, so schlampig in einen 6 ECTS Kurs gequetscht! Sollte auf 9 oder 12 ECTS und mindestens 2 verschiedene Kurse aufgeteilt werden!

Anmerkung: Beim INSO gab es im SS 2017 Betreuung durch eine Tutorin.

Literatur[Bearbeiten]

Online-Tutorials zu Maven, Spring Framework,.. sind hilfreich.

Zeitaufwand[Bearbeiten]

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!

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 80-100 (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. 100-150 Stunden (eher kleines Projekt, oder große Gruppe) bis 200 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 200+ Stunden-Kandidaten sind.

Es ist notwendig diese Zeit aufzuteilen und mehrmals pro Woche etwas für das Projekt zu arbeiten. Insbesondere berufstätige Studenten werden hiermit vielleicht ein Problem haben. Man behindert andere Gruppenmitglieder wenn immer nur am Tag vor der Deadline die Arbeit angefangen wird (Es muss Zeit für Reviews bleiben).

SS14: Unsere Gruppe hatte einen Gesamtaufwand von 750 Stunden für das Projekt, und ich muss dazu sagen, dass niemand wirkliche praktische Erfahrung hatte. Von denen hatte der Teamkoordinator 170, alle anderen zw 100-130 und das schwächste Glied um die 70, wenn man die Einzelphase miteinbezieht dann lagen schon alle über den geplanten 150 Stunden. Dennoch muss ich sagen, dass es sich wirklich lohnt, hier viel hineinzubuttern, man lernt in jedem Bereich dieses Projektes so viel.

S2018: Einzelphase: Zeitaufwand ist angegeben mit:

  • Einarbeitung in die Technologien des Einzelbeispiels: 8 Stunden
  • Implementierung Einzelbeispiel: 20 Stunden

Mit 80h (unfertig) liege ich da etwas drüber, von Kolleg_innen habe ich bis jetzt Werte bis zu 110h gehört.

andere Meinung zur Einzelphase SS2018: Mit 85h hatte ich alles implementiert (Einarbeitungsdauer in die Technologien ist hierbei schon drin). Weiters muss erwähnt werden, dass bei mir eine Jahre lange Programmierabstinenz vorlag, was zu einem erhöhten Einarbeitungsbedarf führte. (~10h). Die 20h+8h sind aber natürlich ein unerreichbares Ziel. Von KollegInnen habe ich teilweise von Implementierungszeiten von bis zu 130h gehört. Fortsetzung nach Gruppenphase (26.06.2018): Für die Gruppenphase brauchte unser 6-Mann Team insgesamt 350h.

ad 2018) Die 28h sind unerreichbar. Bin ein relativ guter Programmierer und auch in Übung (war davor auch in einer HTL Zweig Informatik) und hatte einen Zeitaufwand von ~60 Stunden. Dabei war die Lösung aber keineswegs fertig, sehr schlampig und unsauber (interessiert nach dem Abgabegespräch eh niemanden mehr ;-)). Wenn ich das halbwegs vernünftig gemacht hätte, hätte ich mit mindestens 80 Stunden gerechnet. Es wurde von der LVA Leitung später auch (mündlich bei der Besprechung zur Gruppenphase) zugegeben (nachdem sich einige im TUWEL Forum beschwert haben), dass der Zeitaufwand "etwas" größer war. Dafür (zumindest am QSE) wurde die Gruppenphase etwas verkürzt. Dort hatten wir dann einen vorgeschriebenen Zeitaufwand von 80h.

Dauer der Zeugnisausstellung[Bearbeiten]

noch offen

Tipps[Bearbeiten]

  • Das Tutorial zum Einzelbeispiel unbedingt besuchen. Wenn möglich aufnehmen, da einem dort ein idealer Start zur schichtenübergreifenden Implementierung vorgezeigt wird.
  • 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.
  • Besucht das Scrum-Tutorial, da bis zum 1. IR primär nur Agilo-Docs zu erstellen sind bzw. die Sprintplanung durchzuführen ist.
  • 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, es können durchaus auch die Stunden für Meetings notiert werden, aber es sollten keinesfalls falsche Sachen auf der Stundenliste stehen! Durchschnittlich sollte jeder auf 150 - 200 Stunden kommen.
  • Als Anfänger (speziell User Interface..) beginnt rechtzeitig mit Literaturrecherche und Büffeln.
  • Unterm Semester gibt es immer wieder gezielte Tech-Vortraege und "Experten"-Treffen fuer die Gruppen, Hinschauen lohnt ! (hat mich damals vor einer undurchfuehrbaren Projektidee bewahrt)
  • Es ist wichtig, sich jede Woche in der Gruppe zu treffen, Projekt aufteilen(Tickets in Redmine erstellen) und am meisten ist es wichtig, dass sich jeder halbwegs verantwortlich für das Projekt fühlt. Die Rollen sagen nur aus, dass sich derjenige darauf mehr fokusieren soll, aber nicht, dass wenn ich zB. ein BuildManager bin, dass ich alles so liegen lassen kann und mir es wurscht ist, was mit der Projekt passiert. Des Weiteren empfehle ich frühe Deadlines zu setzen und nicht einen Tag vor'm Meilenstein fertig zu werden. Erspart viel Stress und man lernt auch, nicht alles auf den letzten Drucker zu erledigen, hat mMn nur Nachteile.

Verbesserungsvorschläge / Kritik[Bearbeiten]

Ganz klar zu wenig Zeit vorgesehen für so eine wichtige LVA! Ich kenne kaum jemanden, der unter 150 Stunden brauchte, oft 200+! Man muss ja den "Vorbereitungsteil" auch mitrechnen und der alleine kann schon 50+ Stunden ausmachen. Ich weiß nicht, ob es da intern einen Streit unter den Professoren gab, aber die Stundeneinteilung ist einfach nicht nachvollziehbar. Dieses PR sollte auf mindestens 2 LVAs aufgeteilt werden und mindestens 9 ECTS wert sein!

Statt des "Einführungsteils", der einfach eine unterbetreute Übung + Computer-Prüfung ist, sollte klar der Organisationsvorgang geübt werden. Es gibt zwar eine SEPM VO, die besteht aber größtenteils aus theoretischen ISO-Definitionen, die für Großfirmen gedacht sind. Das SCRUM-Tutorial aus dem PR ist eine 1.5 Stunden Vorlesung. Es wird nur einmal kurz erklärt, wie korrektes Testen funktioniert, obwohl Tests so zentral für das Projekt (und die Prüfung) sind! Das ist im Prinzip die gesamte "Vorbereitung" auf die Übung! Normalerweise bildet die VO eine adäquate Basis für die Übung, das ist hier sicher nicht der Fall!

Es ist nicht nachvollziehbar, warum die TU die Softwareentwicklung für Informatik-Studien so schlampig lehrt!