Uni Wien:Softwareentwicklung UE (Engelbrecht)

Aus VoWi
Wechseln zu: Navigation, Suche

Daten[Bearbeiten]

Inhalt[Bearbeiten]

Ziele[Bearbeiten]

  • Im Rahmen einer Gruppenarbeit soll ein größeres Softwareprojekt realisiert werden. Dabei werden die Themen Anforderungsanalyse und Use-Case Modellierung, Design, Implementierung und Softwaretesting behandelt. Zur Unterstützung werden CASE-Tools eingesetzt, Modellierung und Design basiert auf UML.

Aufgaben[Bearbeiten]

  • Einzelaufgabe: 10 simple JAVA-Einführungsbeispiele (ähnlich EPROG)
    • Diese Beispiele helfen für die nachfolgende Übung recht wenig (voraussichtlich wird es nächstes Jahr etwas komplexere Beispiele als Vorbereitung zur Teamaufgabe geben
  • Teamaufgabe: Planung und Realisierung einer Social Network Plattform mit Beziehungsgraphen
    • Realisierung in Java unter Verwendung von Servlets und JSPs
    • Verwendung von Versionsverwaltung (SVN), Case-Tools und Entwicklungsumgebung (Eclipse)
    • Projektphasen sollen (theoretisch) nach dem Prinzip des Unified-Process in Iterationen und Workflows je Iteration durchgeführt werden.
      • Projektvorschlag
      • Anforderungsanalyse
      • Design (Iteration1)
      • 1. Prototyp und Testfälle
      • Use-Case-Modell (Iteration2)
      • Design (Iteration2)
      • 2. Prototyp und Anwendungsfälle
      • Endpräsentation

Artefakte[Bearbeiten]

Folgende Artefakte sollen im Rahmen des SW-Entwicklungsprozesses der Teamaufgabe produziert werden:

  • Projektbeschreibung
  • Use-Case-Diagramm
  • Sequenzdiagramme
  • (Analyse-)Klassendesign
  • Sourcecode
  • Deployment - & Komponentendiagramm
  • Projekttagebuch

Ablauf[Bearbeiten]

  • In den ersten Einheiten passiert nicht viel. Einige stellen die gelösten JAVA-Beispiele vor und erhalten einen Präsentationspunkt, der am Ende bei der Argumentation über die Notenvergabe relevant sein kann (oder auch nicht)
  • Es gibt ein Servlet-Tutorial, ein SVN-Tutorial bei denen am Ende ein funktionierender Tomcat, ein funktionierendes Servlet und beim SVN-Tutorial ein funktionierendes Commit/Update nachgewiesen werden sollte. (Anwesenheitspflicht)
  • Die Teamaufgabe soll in 3er-Gruppen gelöst werden. Entwicklungsprozesse und Outcomes sollen in einer eigens erstellten Projekthomepage dokumentiert und niedergelegt werden.
  • In den späteren Einheiten stellt jedes Team die Resultate der Abgaben vor (ca. 10 Minuten). Sonst passiert meistens nichts, außer dass Hinweise auf die Tests gegeben werden.
  • Es gibt relativ am Anfang und relativ am Ende des Semesters einen Test.
    • Wer bei einem Test negativ ist, darf nächstes Jahr wiederkommen (wird also negativ beurteilt).
    • Test1: Java-Grundlagen, ExceptionHandling, ...
    • Test2: Servlet-Grundlagen, Klassen-&Sequenzdiagramm-Grundlagen

Vorwissen[Bearbeiten]

Voraussetzungen (gültig für Studienplan 521)[Bearbeiten]

Dadurch ist impliziert:

Vorkenntnisse[Bearbeiten]

  • Wenn man Objektorientiertes Programmieren (vorzüglich Java) schon mal hatte, tut man sich um Einiges leichter und kann dann auch bei der Funktionalität des SW-Projekts beeindrucken
  • Wie bei jeder Teamarbeit, jedoch aufgrund des hohen Aufwandes der Teamaufgabe besonders wichtig: Teammanagement und Glück, dass man aktive und fähige Teampartner erwischt

Zeitaufwand[Bearbeiten]

  • Die einführenden JAVA-Beispiele sind kein Problem (vgl. Materialien).
  • Die Teamaufgabe kann je nachdem, welche Note man will, durchaus umfangreich werden und den regulären ECTS-Aufwand übersteigen. Es kann oft schon ein zeitintensives Unternehmen sein (dass einer meiner Teamkollegen bis zum Ende nicht fertiggebracht hat), Eclipse und Tomcat zum Laufen zu bringen.

Übungsleiter[Bearbeiten]

  • Im SS08 standen zur Auswahl: Benkner, Engelbrecht, Köhler, Mehofer

Engelbrecht[Bearbeiten]

  • Hat eine amüsante Art zu reden, zu erklären, zu kritisieren
  • Wird mies gelaunt, wenn es darum geht, am Fenstertag in der Uni zu sitzen, weil Studenten es nicht nötig fanden, ihre Abgabefristen (Prototyp) einzuhalten.
  • Lässt bei der Benotung mit sich reden, wenn man gut argumentieren kann und die Argumente tatsächlich wahr sind ^^
  • Vom Hörensagen ist mir bekannt, dass Herr Engelbrecht auch bei der Beurteilung der einzelnen Abgabepräsentationen wesentlich freundlicher und konstruktiver argumentiert als Herr Köhler.

Benkner[Bearbeiten]

  • Bitte Beurteilen

Köhler[Bearbeiten]

  • Bitte Beurteilen

Mehofer[Bearbeiten]

  • Bitte Beurteilen


Benotung (Engelbrecht)[Bearbeiten]

  • Sieht man davon ab, dass von Anfang an nicht ganz klar war, welche Funktionalität die Social Network Plattform bieten muss, kann man sagen, dass die Benotung prinzipiell fair war
  • Es wird meiner Einsicht nach nicht unbedingt der Einezlbeitrag jedes Mitglieds genau unter die Lupe genommen, sondern wenn das Projekt gut ist, ist die Beurteilung der einzelnen Mitglieder auch gut - modifiziert durch die Leistungen beim Test und den Präsentationspunkten der simplen Java-Beispiele.

Wo gibts Hilfe?[Bearbeiten]

  • Es steht kein LV-Forum oder Äquivalentes zur Verfügung, damit die Studenten sich austauschen können (das ändert sich angeblich nächstes Jahr).
  • Die LV-Leiter stehen per Mail zur Verfügung.
  • Im Informatik-Forum gibt es viele kompetente Leute.

Tipps[Bearbeiten]

  • Dokumentiert euren Aufwand relativ genau auf eurer Homepage mit, sonst habt ihr am Ende keine Zahlen, mit denen ihr belegen könnt, wie viel Zeit ihr investiert habt.
  • Bei der Endpräsentation LOC (Lines of Code), Zeitaufwand, Revisionszahlen etc. parat haben.
  • Haltet die Use-Case-Diagramme und Use-Case-Realisierungen relativ einfach und übersichtlich.
  • Informiert euch evt. schon vorab über den Unified Process, über Analyseklassen, über Patterns, über Servlets und JSP, da dies enorm hilfreich sein kann, wenn man während der ersten Phasen des Projekts schon etwas Ahnung davon hat.
  • IMHO sollte man die Vorlesung zuerst machen und erst im nächsten Semester die Übung dazu, denn dann hat man den theoretischen Rahmen (Unified Process, OO-Konzepte, SW-Qualitätsabschätzung, ...) kennengelernt und kann dann versuchen, ihn praktisch umzusetzen. Was wir gemacht haben, war eher ein blindes designen und entwickeln, das bei einem echten SW-Projekt nicht vorkommen sollte. Dafür weiß man nach der Übung, was man das nächste Mal besser machen könnte - und das ist auch viel wert.