You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 62 Next »

Hier im wesentlichen die selben Dinge beachten wie TA 5: Zwischenpräsentation (mit Ausnahme der letzten vier Spiegelstriche (wink) ), aber die Darstellung sollte auf das ganze Jahr bezogen sein, d.h. nicht nur zurück bis zur letzten Präsentation, d.h. sollte u.U. auch Dinge enthalten, die bereits in einer der Zwischenpräsentationen gesagt wurden. Es ist auf jeden Fall eine Demo notwendig!

Und zusätzlich:

  • d.h. hier auch die wichtigen Konzept, Ideen und Modelle vorstellen
  • In der Demo die Registrierung nicht mehr zeigen.
  • Screenshots zur Erklärung der wesentlichen Komponenten (bitte hier keine Mockups mehr oder Vorher/Nachherdarstellungen)
  • Die Qualitätssicherung:
    • Projektmanagement
    • Testen
  • allgemeiner Rück- und Ausblick, aber bitte keinen detaillierten Rückblick auf einzelne Sprints (In Sprint 1 haben wir ... In Sprint 2 haben wir ...)
  • 60-90 Minuten, typischerweise im OFFIS U61/U64
  • Alle Mitglieder der Gruppe müssen da sein! Es besteht Anwesenheitspflicht.

Hinweise:

  • Die Demo sollte i.d.R. mit dem Server auf einem Rechner in der ARBI (z.B. Dümmer) erfolgen.
  • Ich habe eine ganze Menge an Präsentationen. Ich kann mich nicht immer an alles vorher erinnern (wink)
  • Die Präsentierenden sollten (im Unterschied zu TA 5: Zwischenpräsentation) besser vorne stehen. Dann kann ich unabhängig vom Sitzplatz sowohl die Person als auch die Folien anschauen.

Abgabe:

  • Bitte: vor der Abnahme die Präsentation als PDF schon einmal in dem Cloud-Ordner hochladen.
  • Dokumente (als PDF!  Die wichtigen zusammen in einem Ordner)
    • Die Dokumentation darf als Export aus dem Confluence generiert werden.
  • Der Quellcode
    • braucht nicht abgegeben werden, da er ja in Bitbucket vorhanden ist.
    • muss sich mit Maven automatisiert bauen lassen! Auch die Tests müssen darüber ausführbar sein.  Es muss EIN zentrales Maven-Script geben, welches andere verwendet.
    • Wichtig! Ich schaue mir nur den Quellcode im MASTER-Branch an, ggf. also auf jeden Fall vor der Abgabe noch einmal in den Master mergen!
  • Protokolle, Präsentationen, …
  • zusätzlich (!) virtuelle Maschine (VMWare (mit VMWarePlayer abspielbar!), VirtualBox)
    • mit vollständig eingerichtetem lauffähigem Server für mich zum Testen (mit Hinweise zur Verwendung, z.B. mit Readme auf Desktop)
    • ohne Abhängigkeiten nach außen (E-Mail, Datenbank, etc.!). Die DB darf hauptspeicherbasiert sein. 
    • VM sollte den Gruppennamen enthalten
    • keine Dokumente in der VM "verstecken"!
    • Es sollte direkt in der VM spielbar sein. (ggf.  muss also auch ein Browser installiert sein. Keinen Zugriff mit einem externen Browser!)
    • Die VM sollte nicht zu groß sein! Linux statt Windows kann hier schon viel helfen (wink)
    • BITTE die VM testen. Insbesondere ob auch alles funktioniert!
    • Es ist erlaubt, die VM in ein Multi-Volume-Archive zu verpacken, falls es Probleme mit dem Upload gibt.
    • Kein Docker, da ich auch meinen Rechner vor der VM absichern muss (Sonst müsste ich einen zusätzlichen Rechner dafür nutzen ... DSGVO)
  • 10 Minuten-Video
    • mit Präsentation des Endproduktes (z.B. mit HyperCam),
    • bitte mit Ton
    • Fokus bitte auf das Spiel
    • Registrierung, Chat, Besonderheiten außerhalb des Spiels etc. max 1 Minute
    • Bitte mit mehreren Spielern spielen
    • Spezielle Spielsituationen (gemäß Regeln) sollten extra dargestellt werden um zu zeigen, wie die Software damit umgeht
    • Damit auch die anderen Gruppen sehen können, was in den anderen Gruppen gemacht worden ist, werden die Videos im Anschluss aller Präsentationen veröffentlicht

Verwendung der Uni-Cloud (https://cloud.uol.de). Dort bitte alles  zur Verfügung stellen. Dafür haben Sie von mir eine Freigabe erhalten. Bitte die Dateien möglichst nicht komprimieren aber möglichst insgesamt nicht mehr als 15 GB verwenden. Bei Problemen mit dem Upload darf die VM auch aufgeteilt werden.

Hinweise:

  • Der Termin für die finale Abgabe ist immer der Tag, an dem die letzte Präsentation der letzten Gruppe (siehe Stud.IP) stattfindet, es darf aber auch während der Präsentation abgegeben werden (smile). Die von mir versendeten Shares verfallen aus Gründen der Gerechtigkeit um 0:00 Uhr am Tag nach der letzten Präsentation der letzten Gruppe. Also am besten nicht bis zur letzten Minute warten.
  • Der Upload in die Cloud ist innerhalb des Uni-Netzes i.d.R. deutlich schneller.
  • Es kann passieren, dass es deutlich länger mit dem Upload dauert, wenn alle gleichzeitig hochladen ...
  • Falls es noch deutliche Unterschiede zwischen dem Stand der in der Präsentation vorgestellt wurde und der Abgabe gibt, bitte noch einmal explizit dokumentieren!
  • Es sollte in der Gruppe immer jemand danach die Zeit ansprechbar sein und ggf. Dokumente, bei denen es Probleme mit dem Upload gegeben hat, hochladen können.
  • Der Upload müsste auch mit dem Nextcloud-Sync-Tool erfolgen können, falls es Probleme mit der Web-Version gibt.
  • Änderungen am Git-Code sind nach der Abgabe natürlich ebenfalls nicht mehr zulässig.


  • No labels