Formalien: Unterschied zwischen den Versionen

Aus Das Sopra Wiki
Dietsch (Diskussion | Beiträge)
Keine Bearbeitungszusammenfassung
Greitschus (Diskussion | Beiträge)
Keine Bearbeitungszusammenfassung
Zeile 10: Zeile 10:
* Welche Probleme sich seit dem letzten Treffen ergeben haben und wie man sie lösen kann.
* Welche Probleme sich seit dem letzten Treffen ergeben haben und wie man sie lösen kann.
* Was bis zum nächsten Treffen erreicht werden soll.
* Was bis zum nächsten Treffen erreicht werden soll.
=== Reporting ===
Jedes Gruppenmitglied muss wöchentlich (genauer Termin/Zeitraum nach Vereinbarung mit dem Tutor) Reports über seine aktuellen Aufgaben und Probleme an die [[Mailinglisten|Mailingliste der Gruppe]] schicken.
Die Mail muss dieser [[Report|Report-Vorlage]] entsprechen.
Die Anzahl der notwendigen Reports pro Woche richtet sich nach Zustand und Fortschritt Ihres Projekts (entweder 1, 2, oder 3-mal) und wird Ihnen durch Ihren Tutor beim Gruppentreffen mitgeteilt. Den ersten Report sollten Sie in Woche 1 schreiben.
Es ist ausdrücklich erlaubt, leere Reports abzusenden (wenn seit dem letzten Report nichts gemacht wurde).


=== Kontinuierliche Mitarbeit ===   
=== Kontinuierliche Mitarbeit ===   
Durch Ihre Reports, Ihre Commits zum SVN-Repository und durch die im Gruppentreffen erstellte Aufgabenverteilung im Trac haben Sie die Gelegenheit, Ihre kontinuierliche Mitarbeit im Projekt zu zeigen. Sollten Sie in mehreren [[Sprint]]s nicht mitarbeiten, verlieren Sie die Zulassung zum Softwarepraktikum.
Durch Ihre Commits zum SVN-Repository, durch die im Gruppentreffen erstellte Aufgabenverteilung im Trac und durch Ihre Bearbeitung der Tasks im Trac zeigen Sie Ihre kontinuierliche Mitarbeit am Projekt. Sollten Sie in mehreren [[Sprint]]s nicht mitarbeiten, verlieren Sie die Zulassung zum Softwarepraktikum.


=== Nicht-Erfüllung ===  
=== Nicht-Erfüllung ===  
Sollten Sie diese Vorausetzungen nicht erfüllen, verlieren Sie die Zulassung zum Softwarepraktikum. Im Detail:  
Sollten Sie diese Vorausetzungen nicht erfüllen, verlieren Sie die Zulassung zum Softwarepraktikum. Im Detail:  
* Sie können bis zu 3x keinen Report schreiben. Beim 4. Mal verlieren Sie die Zulassung.
* Sie können bis zu 2x nicht kontinuierlich mitarbeiten Beim 3. Mal verlieren Sie die Zulassung.  
* 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.  
* Sie können 1x nicht beim Gruppentreffen erscheinen. Beim 2. Mal verlieren Sie die Zulassung.  

Version vom 16. April 2013, 13:23 Uhr

ACHTUNG: Noch nicht aktuell für SS2013

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

Voraussetzungen

Gruppentreffen

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

Hier soll geklärt werden:

  • Was seit dem letzten Treffen erreicht wurde.
  • Welche Probleme sich seit dem letzten Treffen ergeben haben und wie man sie lösen kann.
  • Was bis zum nächsten Treffen erreicht werden soll.

Kontinuierliche Mitarbeit

Durch Ihre Commits zum SVN-Repository, durch die im Gruppentreffen erstellte Aufgabenverteilung im Trac und durch Ihre Bearbeitung der Tasks im Trac zeigen Sie Ihre kontinuierliche Mitarbeit am Projekt. 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.

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.

Bei einer Präsentation gelten folgende Regeln:

  1. Es soll immer nur das Spiel (d.h. der aktuelle Stand) gezeigt werden.
  2. Es dürfen keine Folien gezeigt werden.
  3. Die gesamte Gruppe muss anwesend sein.
  4. Die Präsentation darf maximal 10min mit nachfolgenden 5min Fragen dauern.

Sonderregelung für Präsentation 1 (Präsentation des Spielekonzepts, Woche 5, Siehe Roadmap):

  • Bei dieser - und nur bei dieser - Präsentation dürfen Folien gezeigt werden.
  • Beantworten Sie bei dieser Präsentation vor allem die folgenden drei 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ß?
  • Diese Präsentation darf maximal nur 10min mit nachfolgenden 5min Fragen dauern.

Bei der finalen Präsentation muss Ihr Spiel im Vollbildmodus gezeigt werden.

Wir werden im entsprechenden Raum (siehe Roadmap) alles Nötige für die Sound-Ausgabe des Spiels bereitstellen. Bitte beachten Sie auch die technischen Hinweise auf Virtuelles Treffen.

Hinweis: Ihre Gruppe wird jeden Termin vor einer zufällig zusammengestellten Auswahl an anderen Gruppen aus dem Kurs präsentieren, 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 Einleitung ihres Vortrags abzuholen.