Formalien

Um die regelmäßige Teilnahme und Mitarbeit am Softwarepraktikum nachweisen zu können müssen folgende Voraussetzungen erfüllt sein:

Voraussetzungen

Gruppentreffen

Das Gruppentreffen findet einmal pro Woche (d.h. 1x pro Sprint) zu einem gemeinsam mit dem Tutor vereinbarten Termin statt. Es dauert 2h und es besteht Anwesenheitspflicht.

Hier soll geklärt werden:

1. Scrum Meeting / Daily Scrum (max. 15min)
   • Was wurde seit dem letzten Meeting gemacht?
   • Was wird bis zum nächsten Meeting gemacht?
   • Was für Probleme gibt es, die die aktuellen Aufgaben behindern?
2. Sprint Review (max. 30min)
   • Product Owner sagt, was fertig und was nicht fertig ist.
   • Team zeigt, was alles fertig geworden ist und beantwortet Fragen zum Fortschritt.
   • Team erklärt dabei, was es für Probleme gab und wie diese gelöst worden sind.
   • Product Owner erklärt den aktuellen Stand des Product Backlogs und speziell Änderungen an der Aufwandsabschätzung.
3. Sprint Planning (max. 60min)
   • Was wird im nächsten Sprint gemacht? Product Backlog anschauen, von oben nach unten (PO sollte es geordnet haben). An die Recurring Tasks denken.
   • Wer erledigt von den ausgewählten Dingen was (Arbeitsverteilung)?
4. Sprint Retrospective (max. 15min)
   • Diskutieren, was im letzten Sprint im Hinblick auf Menschen, Beziehungen, Prozesse, Tools gut bzw. schlecht gelaufen ist.
   • Wo muss etwas verändert oder verbessert werden, damit besser gearbeitet werden kann?
   • Plan erstellen, wie diese Änderungen im nächsten Sprint umgesetzt werden können.

Wiederkehrende Aufgaben

Während des Semesters sind die folgenden wiederkehrenden Aufgaben zusätzlich zu den anderen Aufgaben jede Woche zu erledigen:

• Product Owner (ab Woche 2)
  • Pflegen und Anpassen von Requirements und User Stories im Product Backlog.
  • Verfeinern von Requirements zu User Stories.
  • Requirements nach Entwicklungsreife ordnen.
  • Gruppentreffen vorbereiten (was ist fertig, wie war die Aufwandsabschätzung).
• Architektur (ab Woche 3)
  • Schnittstellen definieren
  • Architekturbeschreibungen pflegen
  • Einhaltung der Architektur sicherstellen
• Qualitätssicherung (ab Woche 6)
  • Code auf Clean-Code Richtlinien prüfen.
  • Code Reviews vorbereiten
  • ReSharper Konformität herstellen

Kontinuierliche Mitarbeit

Kontinuierliche Mitarbeit wird belegt durch hinreichend viel messbare Aktivität, also Commits im SVN-Repository und im Trac bearbeitete Tasks. Außerdem muss die verbrauchte Zeit und Restzeit in den Tasks im Trac angegeben werden. Sollten Sie in mehreren Sprints nicht mitarbeiten, verlieren Sie die Zulassung zum Softwarepraktikum.

Nicht-Erfüllung

Sollten Sie diese Vorausetzungen nicht erfüllen, verlieren Sie die Zulassung zum Softwarepraktikum. Im Detail:

• Sie können bis zu 2x nicht kontinuierlich mitarbeiten Beim 3. Mal verlieren Sie die Zulassung.
• Sie können 1x nicht beim Gruppentreffen erscheinen. Beim 2. Mal verlieren Sie die Zulassung.

Ausnahmen (z.B. bei Krankheit) sind durch die jeweils gültige Prüfungsordnung geregelt.

Benotung

Jeder Student erhält eine Abschlussnote, die sich aus zwei Teilen, die jeweils zu 50% einfließen, zusammen setzt:

1. Endprodukt
   • Entspricht das Produkt den Anforderungen?
   • Ist das Produkt fehlerfrei (d.h. finden wir bei der Abnahme keine Fehler)?
   • Ist die Softwarequalität "gut"? Die Softwarequalität wird wöchentlich gemessen.
2. Einzelleistung
   • Wurde die zugeteilte Arbeit erfolgreich erledigt?
   • Pro Woche sind max. 5 Punkte zu erreichen
   • Aus der Summe der Punkte ergibt sich die Teilnote für die Einzelleistung.

Ist eine der beiden Teilnoten 5.0 (nicht bestanden), so ist die Abschlussnote 5.0 (nicht bestanden).

Sonstige Regeln

Abgaben

Für alle Abgaben gilt, dass der jeweilige Abgabezeitpunkt eingehalten werden muss. Abgaben, die zu einem späteren als dem von uns angegebenen Zeitpunkt abgegeben werden, werden nicht berücksichtigt! Die letztmöglichen Abgabezeitpunkte stehen in der Roadmap.

Wir unterscheiden bei der Abgabe drei Typen von Artefakten:

• Die Hausaufgabe,
• Dokumente (GDD und Dokumentation zu Ihrem Programm)
• Programme (für das eigentliche Spiel).

Hausaufgabe

Die Abgabe der Hausaufgabe ist direkt auf der Hausaufgaben-Seite beschrieben.

Der Programmier-Teil der Hausaufgabe muss als komplettes Projektverzeichnis (inclusive des Verzeichnis mit der entsprechenden *.sln datei) abgegeben werden. Sie sollten dazu einfach das Projekt in das Gruppenrepository unter /abgabe/hausaufgabe/<username>/ comitten.

Dokumente

Das GDD, sowie eine Readme (Tastenbelegung, Hinweise auf Cheats und Debugtasten) und Screenshots zu ihrer Programmabgabe sind Dokumentartefakte.

Erstellung

• Zur Erstellung des GDDs dürfen Sie beliebige Textverarbeitungsprogramme (Word, LaTeX, ...) verwenden.
• Achten Sie vor allem auf Effizienz. Wenn Sie sich zuerst LaTeX beibringen müssen, um ein gut aussehendes GDD schreiben zu können, sollten Sie eventuell eher zu einem WYSIWYG-Editor greifen.

Zeit und Ort

Dokumente müssen bis zum Abgabezeitpunkt (siehe Roadmap) im Gruppen-Repository im release Branch im jeweiligen Pfad vorhanden sein. Beachten Sie hierbei die Hinweise zum Arbeiten mit mehreren Branches:

• Die Hausaufgabe unter /abgabe/hausaufgabe/<benutzername>/
• Das GDD unter /abgabe/gdd/gruppe<nummer>-<spielname>.pdf
• Das GDD (final) unter /abgabe/gdd/final/gruppe<nummer>-<spielname>.pdf
• Die Screenshots und Readme zu ihrem Spiel (beta) unter /abgabe/programm/beta
• Die Screenshots und Readme zu ihrem Spiel (final) unter /abgabe/programm/final

Form der Abgabe

Wir akzeptieren NUR GDD-Abgaben im .pdf-Format. Außerdem muss jedes Dokument ein Deckblatt mit folgenden Angaben haben:

• Die Gruppennummer,
• die Namen der Studenten der Gruppe,
• das Datum der Erstellung und
• der Name des Tutors.

Beachten Sie für die GDD-Abgaben unbedingt den Abschnitt Relevanz für die Benotung im GDD-Artikel.

Programme

Die Abgabe ihres (finalen und beta) Programms wird automatisch vom Jenkins gemacht (die letzte fehlerfrei bauende Version des release Branches vor dem Abgabezeitpunkt). Sie müssen lediglich zu jeder Abgabe mindestens drei Screenshots des Programms im entsprechenden Verzeichnis ihres Repositories hochladen (siehe oben). Die Screenshots der finalen Abgabe müssen im Vollbildmodus gemacht werden. Falls es Cheats oder Debug-Tasten - d.h. Tastenkombinationen, mit denen bestimmte Aktionen durchgeführt werden können, die eigentlich nicht möglich sein sollten - im Spiel gibt, kann zusätzlich zur Abgabe ein Textdokument (README) abgegeben werden, in welchem die Tastenkombinationen aufgeführt und erklärt sind.

Präsentationen

An unseren Präsentationsterminen (siehe Roadmap) haben Sie die Möglichkeit (bzw. müssen Sie) Ihren aktuellen Stand sowohl uns als auch Ihren Kommilitonen vorstellen. Die Präsentationen finden in Form einer Postersession statt.

Bei allen drei Präsentationen geht es darum, den aktuellen Stand des Spiels zu zeigen, sie sollten also:

• Ein Poster oder einige Blätter dabei haben, die die Idee ihres Spiel zusammenfassen (Handlung, Mechaniken, etc.). Beantworten Sie hier vor allem folgende Fragen:
  • Worum geht es im Spiel? Das heißt insbesondere auch: Wie gewinnt man? Wie verliert man?
  • Was ist die zentrale Spielmechanik?
  • Warum macht das Spiel Spaß?
• Ab der zweiten Präsentation müssen Sie einen Laptop/Computer (und passende Eingabegeräte) aufbauen, damit der Stand ihres Spiels live ausprobiert werden kann. (Für jede Gruppe wird entsprechend ein Stehtisch und Strom verfübar sein).
• Die gesamte Gruppe muss für die dauer der Veranstaltung anwesend sein.
• Die Präsentation geht jeweiles über den vollen in der Roadmap beschrieben Zeitslot.

Bei der finalen Präsentation muss Ihr Spiel im Vollbildmodus laufen und aus einem release-build gesartet werden.

Hinweis: Bei jedem Termin werden eventuell andere Personen an Ihrem Spiel interessiert sein, die d.h. die Zuschauer haben unter Umständen noch nie etwas von Ihrer Spielidee gehört! Bitte versuchen Sie auch diese Teilnehmer durch eine geeignete Materialien abzuholen.