Formalien

Aus Das Sopra Wiki
Wechseln zu: Navigation, Suche

Zulassungsvoraussetzungen

Um die regelmäßige Teilnahme und Mitarbeit am Softwarepraktikum nachweisen zu können müssen folgende Voraussetzungen erfüllt sein. Ausnahmen (z.B. bei Krankheit) sind durch die jeweils gültige Prüfungsordnung geregelt.

Gruppentreffen

Sie müssen am Gruppentreffen anwesend sein. Das Gruppentreffen findet einmal pro Woche (d.h. 1x pro Sprint) zu einem gemeinsam mit dem Tutor vereinbarten Termin statt. Es dauert ca. 2h.

Sie können 1x beim Gruppentreffen abwesend sein. Beim 2. Mal verlieren Sie die Zulassung.

Kontinuierliche Mitarbeit

Sie müssen kontinuierlich mitarbeiten. Kontinuierliche Mitarbeit wird durch hinreichend viel messbare Aktivität während eines Sprints belegt, d.h. Commits im Git-Repository und in Gitea bearbeitete Items. Außerdem muss die verbrauchte Zeit und Restzeit in den Tasks in Gitea angegeben werden.

Sie können in bis zu 2 Sprints nicht kontinuierlich mitarbeiten. Beim 3. Mal verlieren Sie die Zulassung.

Benotung

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

  1. Endprodukt
    • Um das Endprodukt zur Bestimmung der entsprechenden Teilnote zu bewerten, stellen wir uns die folgenden Fragen.
    • Entspricht das Produkt den Anforderungen?
      • Wir prüfen, ob unsere Anforderungen und die Anforderungen, die Sie zusätzlich im GDD aufgestellt haben, erfüllt sind.
      • Wir prüfen, ob das Spiel in sich abgeschlossen ist (d.h. ob Funktionalität aus impliziten Anforderungen wie Usability fehlt).
      • Wir prüfen, ob Grafik und Sound zueinander passen.
    • Ist das Produkt fehlerfrei?
      • Wir prüfen, ob die einzelnen Funktionen Fehler enthalten (z.B. fehlerhaftes Pathfinding, Fehler bei der Auswahl von Spielobjekten, etc.).
      • Wir prüfen, ob das Spiel Laufzeitfehler enthält (z.B. Abstürze, Überläufe, etc.).
    • Sind die Softwarequalitätsanforderungen erfüllt?
      • Wir prüfen wöchentlich ob Ihr aktueller Stand Compiler-Warnungen oder Fehler enthält.
      • Wir prüfen wöchentlich ob Ihr aktueller Stand ReSharper Warnungen oder Fehler (mit Ausnahme der in den Randbedingungen der Anforderungen erlaubten Fehler) enthält.
      • Wir prüfen in der finalen Version auf Compiler bzw. ReSharper (ohne Ausnahmen) Warnungen oder Fehler.
    • Wird eine Teilmenge dieser Fragen nicht mit einem eindeutigen "Ja" beantwortet, gibt es Abzüge in der Note für das Endprodukt.
  2. Aufgabenorientierte Leistung
    • Für aufgabenorientierte Leistungen kann jede Woche eine bestimmte Anzahl von Punkten von jedem einzelnen Teilnehmer erreicht werden.
    • In jeder Woche sind Punkte für Einzelleistung, sowie Punkte für Artefaktabgaben - in Wochen, in denen Sie Artefakte abgeben müssen - zu erreichen. Die genaue Aufteilung ist wie folgt:
      • Einzelleistung
        • Pro Woche sind max. 5 Punkte für das Erledigen der zugeteilten Arbeit zu erreichen.
        • 5 Punkte werden dann erreicht, wenn die im Gruppentreffen zugeteilte Arbeit erfolgreich im Sinne der aktuell gültigen Definition of Done erledigt wurde. Bitte beachten Sie dazu den Punkt Aufgabe schwieriger als gedacht im Ablauf.
        • Sind Aufgaben in einer Woche nicht im Sinne der Definition of Done erledigt, führt dies zu Abzügen bei den Punkten. Abzüge richten sich anteilig an Größe, Art und Menge der jeweiligen nicht erledigten zugeteilten Aufgaben aus.
        • Die Abgabe der Hausaufgabe in der ersten Woche wird ebenfalls mit max. 5 Punkten bewertet.
      • Punkte für Artefaktabgaben
        • In Wochen, in denen Artefakte abgegeben werden, erhält jeder Teilnehmer zusätzlich zu den Punkten für die Einzelleistung bis zu 10 Punkte, die für die Qualität der abgegebenen Artefakte vergeben werden.
        • Da es sich bei Artefaktabgaben um Gruppenabgaben handelt, erhalten alle Gruppenmitglieder dieselben Punkte:
          • Bei Beta-Abgaben von GDD, Architektur und Programm können max. 5 Punkte erreicht werden.
            • Wir prüfen, ob die Betaversion des GDDs sinnvoll strukturiert und leicht verständlich ist und den Abgabekriterien entspricht. Außerdem prüfen wir, ob Spielidee, Alleinstellungsmerkmal und das grundlegende Konzept des Spiels hinreichend formuliert wurden.
            • Wir prüfen, ob die Betaversionen der Komponenten- und Klassendiagramme sinnvoll strukturiert und leicht verständlich sind und den Abgabekriterien entsprechen.
            • Wir prüfen, ob die Betaversion des Programms lauffähig ist und den Abgabekriterien entspricht.
          • Bei Final-Abgaben von GDD und Architektur können max. 10 Punkte erreicht werden.
            • Wir prüfen, ob die finale Version des GDDs sinnvoll strukturiert, leicht verständlich und vollständig ist, sowie den Abgabekriterien entspricht.
            • Wir prüfen, ob die finale Version der Architektur sinnvoll strukturiert, leicht verständlich und vollständig ist, sowie den Abgabekriterien entspricht.
          • Die finale Abgabe des Programmes (Endprodukt) wird nach den in Punkt 1. genannten Kriterien gesondert bewertet.
    • Es lassen sich somit im Verlauf des Softwarepraktikums insgesamt 65 Punkte für Einzelleistung und 35 Punkte für Artefaktabgaben, in Summe also 100 Punkte für aufgabenorientierte Leistungen erreichen.
    • Es können zusätzlich 5 Bonuspunkte für eine ausgefallene und/oder kreative Spielidee erreicht werden (werden nach Woche 4 vergeben).
    • Aus der Summe der Punkte ergibt sich die Teilnote für aufgabenorientierte Leistungen.
    • Eine Summe von weniger als 70 Punkten für aufgabenorientierte Leistungen führt in jedem Fall zur Teilnote 5.0 (nicht bestanden). 70 Punkte garantieren jedoch nicht das Bestehen des Softwarepraktikums.

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

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 spätestmöglichen Abgabezeitpunkte stehen in der Roadmap.

Wir unterscheiden bei der Abgabe zwei Typen von Artefakten:

Dokumente

Das GDD, das Komponentendiagramm und das Klassendiagramm sind Dokumente.

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.
  • Erstellen Sie ein UML Komponentendiagramm und Klassendiagramm. Achten Sie darauf, dass alle nötigen Assoziationen eingezeichnet sind und es keine "Inseln" von Komponenten oder Klassen gibt, die nicht mit dem Rest der Architektur verbunden sind.

Zeit und Ort

Dokumente müssen bis zum Abgabezeitpunkt (siehe Roadmap) im Gruppen-Repository im jeweiligen Pfad commited werden beachten Sie hierbei die Hinweise zum Arbeiten mit mehreren Braches:

  • Die Hausaufgabe unter /abgabe/Hausaufgabe/<PoolaccountKürzel>/
  • Das GDD (beta) unter /abgabe/GDD/beta/gruppe<nummer>-<spielname>.pdf
  • Das GDD (final) unter /abgabe/GDD/final/gruppe<nummer>-<spielname>.pdf
  • Das Komponentendiagramm und Klassendiagramm (beta) unter /abgabe/Architektur/beta/gruppe<nummer>-<spielname>-(klassendiagramm|komponentendiagramm).pdf
  • Das Komponentendiagramm und Klassendiagramm (final) unter /abgabe/Architektur/final/gruppe<nummer>-<spielname>-(klassendiagramm|komponentendiagramm).pdf
  • Achten Sie darauf, dass die Dateinamen keine Sonderzeichen (Umlaute o.ä.) enthalten.

Form der Abgabe

Wir akzeptieren NUR Dokumente im .pdf-Format. Außerdem muss jedes Dokument ein Deckblatt mit

  • Gruppennummer, den Namen der Studenten in der Gruppe,
  • dem Datum der Erstellung,
  • und dem Namen des Tutors

enthalten.

Grafiken in der Architekturabgabe müssen Vektorgrafiken sein (z.B. aus Visual Studio mit "Print as PDF").

Programme

Zeit und Ort

Programme müssen sich zum Abgabezeitpunkt (siehe Roadmap) im dafür vorgesehenen Verzeichnis im Gruppen-Repository commited werden beachten Sie hierbei die Hinweise zum Arbeiten mit mehreren Braches.

  • Das Programm (beta) unter /abgabe/Programm/beta/gruppe<nummer>-<spielname>.zip
  • Das Programm (final) unter /abgabe/Programm/final/gruppe<nummer>-<spielname>.zip
  • Achten Sie darauf, dass die Dateinamen keine Sonderzeichen (Umlaute o.ä.) enthalten.

Projektentwicklung

Das Projekt selbst muss während der Entwicklungsphase im Verzeichnis /src/Projekt/ entwickelt werden, damit die automatische Generierung unserer Sekundärdienste (Doxygen, Jenkins, Sonar, ...) ohne Probleme funktioniert.

Form der Abgabe

Hausaufgabe

Die Hausaufgabe muss als komplettes Visual Studio Projekt abgegeben werden. Sie sollten dazu einfach das Projekt in das Gruppenrepository unter /abgabe/Hausaufgabe/<username>/ comitten.

Programm

Alle Programme müssen in einer ausführbaren Form abgegeben werden.

Spiele müssen als ein Paket (z.B.: Zip-Archiv) abgegeben werden. Darin müssen alle zur Ausführung notwendigen Dateien enthalten sein (z.B.: das Verzeichnis "Content" und alle nötigen DLLs). Geben Sie keinen Quellcode ab.

Außerdem müssen jeder Abgabe des Programms mindestens drei Screenshots des Programms beiliegen. 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 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 15min 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 das Alleinstellungsmerkmal?
    • Warum macht das Spiel Spaß?
  • Diese Präsentation darf maximal nur 10min dauern.

Beachten Sie dabei, dass der Beamer im Präsentationsraum nur bei einer Auflösung von 1024x768 (oder einer Auflösung mit gleichem Verhältnis) ein gutes Bild liefert. Entweder zeigen Sie Ihr Spiel im Fenstermodus oder es muss diese Auflösung unterstützen. Bei der finalen Präsentation muss Ihr Spiel im Vollbildmodus gezeigt werden.

Außerdem befindet sich am Beamer im Präsentationsraum nur ein VGA-Anschluss. DVI- und HDMI-Anschlüsse werden nicht unterstützt.

Wir werden im entsprechenden Raum (siehe Roadmap) alles Nötige für die Sound-Ausgabe des Spiels bereitstellen.

Bitte melden Sie sich rechtzeitig, falls Sie nicht die für die Präsentation erforderliche Hardware besitzen (d.h. kein geeignetes Notebook). Wir werden dann einen der Poolrechner organisieren.