Formalien: Unterschied zwischen den Versionen

Aus Das Sopra Wiki
← Zum vorherigen Versionsunterschied
VisuellWikitext
Greitschus (Diskussion | Beiträge)
Bürokraten, sopra, sopra17, sopra18, sopradozenten, soprapre17, sopra|sopra, sopra|soprapre17, Administratoren
2.329 Bearbeitungen
Langenfeld (Diskussion | Beiträge)
Bürokraten, sopra, sopra17, sopra18, sopradozenten, soprapre17, Administratoren
1.252 Bearbeitungen
 
(37 dazwischenliegende Versionen von 6 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
__TOC__
{{TOCRight}}


== Zulassungsvoraussetzungen ==  
== 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.
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 ===
=== 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.
 
{{BA|LeonH| Wie ist diese regelung im digitalen semester umzusetzten?}}
{{BA|Vincent| Naja, wie im normalen Semester auch. Das "anwesend" nachzuprüfen ist halt schwer. Aber wer im Treffen nix sagt, nicht sichtbar ist ect. ist halt nicht da.}}
 
Sie müssen am Gruppentreffen anwesend sein. Das Gruppentreffen findet einmal 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.
Sie können 1x beim Gruppentreffen abwesend sein. Beim 2. Mal verlieren Sie die Zulassung.
Zeile 10: Zeile 14:
=== Kontinuierliche Mitarbeit ===   
=== Kontinuierliche Mitarbeit ===   
Sie müssen ''kontinuierlich'' mitarbeiten.  
Sie müssen ''kontinuierlich'' mitarbeiten.  
Kontinuierliche Mitarbeit wird durch hinreichend viel ''messbare'' Aktivität während eines [[Sprint]]s belegt, d.h. [[Subversion#Working_Copy_commiten|Commits]] im [[Subversion|SVN]]-Repository und im [[Trac]] bearbeitete [[Item]]s. Außerdem muss die verbrauchte Zeit und Restzeit in den Tasks im Trac angegeben werden.
Kontinuierliche Mitarbeit wird durch hinreichend viel ''messbare'' Aktivität während eines [[Sprint]]s belegt, d.h. durch


Sie können in bis zu 2 [[Sprint]]s nicht kontinuierlich mitarbeiten. Beim 3. Mal verlieren Sie die Zulassung.
* [[Git#Commit|Commits]] im [[Git|Git]]-Repository und 
* Aktivität (Tickets, Kommentare, etc.) in [[Gitea]].
 
Sie können in bis zu 2 [[Sprint]]s nicht mitarbeiten. Beim 3. Mal verlieren Sie die Zulassung.
 
Zusätzlich müssen Sie im Durchschnitt pro Sprint Aufgaben mit einer geschätzten Arbeitszeit ([[ETC]]) von 7 Stunden erfolgreich abschließen. 
 
Um die Fähigkeit zur kontinuierlichen Mitarbeit zeitnah herzustellen, muss jede Teilaufgabe der Hausaufgabe (insbesondere die Programmieraufgabe) sinnvoll bearbeitet werden. Nicht abgeben der Hausaufgabe führt zum sofortigen Verlust der Zulassung.  


== Benotung ==
== Benotung ==
Jeder Student erhält eine Abschlussnote, die sich aus zwei Teilen, die jeweils zu 50% einfließen, zusammensetzt:
Jeder Student erhält eine Abschlussnote, die sich aus zwei Teilen, die jeweils zu 50% einfließen, zusammensetzt. Ist eine der beiden Teilnoten 5.0 (nicht bestanden), so ist die Abschlussnote 5.0 (nicht bestanden).
# Endprodukt
 
#* Entspricht das Produkt den Anforderungen?
=== Endprodukt ===
#** Wir prüfen, ob unsere [[Anforderungen]] und die Anforderungen aus dem [[GDD]] erfüllt sind.
 
#** Wir prüfen, ob das Spiel in sich abgeschlossen ist (d.h. ob Funktionalität aus impliziten Anforderungen wie [[UsabilityForGames|Usability]] fehlt).
Um das Endprodukt zur Bestimmung der entsprechenden Teilnote zu bewerten, betrachten wir die folgenden Kriterien:
#** Wir prüfen, ob Grafik und Sound zueinander passen.
 
#* Ist das Produkt fehlerfrei?
* Features: Wie gut ist das [[GDD]] umgesetzt (siehe auch [[GDD#Relevanz für die Benotung]]) und erfüllt das Spiel die [[Anforderungen]]?
#** Wir prüfen, ob die einzelnen Funktionen Fehler enthalten (z.B. fehlerhaftes Pathfinding, Fehler bei der Auswahl von Spielobjekten, etc.).
* Artefakte: Wie gut war die Qualität der abgegebenen Artefakte (finales [[GDD]], finale Architektur, Codequalität, Buildfehler, Abstürze beim finalen Spiel)
#** Wir prüfen, ob das Spiel Laufzeitfehler enthält (z.B. Abstürze, Überläufe, etc.).
* Usability: Wurden die Regeln zur Usability gut umgesetzt? Ist das Erscheinungsbild einheitlich?
#* Sind die Softwarequalitätsanforderungen erfüllt?
* Spaß: Macht das Spiel Spaß?
#** Wir prüfen '''wöchentlich''' ob Ihr aktueller Stand Compiler-Warnungen oder Fehler enthält.
* Techdemo: Wie viele Spielobjekte welcher Art können in welchem Environment mit wie vielen durchschnittlichen FPS interagieren? Wie stabil läuft die Techdemo?
#** Wir prüfen '''wöchentlich''' ob Ihr aktueller Stand [[Resharper|ReSharper]] Warnungen oder Fehler (mit Ausnahme der in den [[Anforderungen#Randbedingungen|Randbedingungen der Anforderungen]] erlaubten Fehler) enthält.
 
#** Wir prüfen in der finalen Version auf Compiler bzw. [[Resharper]] (ohne Ausnahmen) Warnungen oder Fehler.
=== Aufgabenorientierte Leistung ===
#* Wird eine Teilmenge dieser Fragen nicht mit einem eindeutigen "Ja" beantwortet, wird dies zu einer negativen Korrektur der Note für das Endprodukt führen.
# Einzelleistung
#* Wir prüfen, ob die im Gruppentreffen zugeteilte Arbeit erfolgreich im Sinne der aktuell gültigen [[DoD|Definition of Done]] erledigt wurde. Bitte beachten Sie dazu den Punkt [[Ablauf#Aufgabe_schwieriger_als_gedacht|Aufgabe schwieriger als gedacht]] im [[Ablauf]].
#* Pro Woche sind max. 5 Punkte für das Erledigen der zugeteilten Arbeit zu erreichen.
#* In Wochen, in denen [[:Kategorie:Artefakte|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:
#** Bei Beta-Abgaben von [[GDD]], Architektur und Programm können max. 5 zusätzliche Punkte erreicht werden.
#*** Wir prüfen, ob die Betaversion des [[GDD]]s '''sinnvoll strukturiert''' und '''leicht verständlich''' ist und den '''[[Abgabe#Dokumente|Abgabekriterien]]''' entspricht. Außerdem prüfen wir, ob '''Spielidee und Konzept''' hinreichend formuliert wurden.
#*** Wir prüfen, ob die Betaversionen der Komponenten- und Klassendiagramme '''sinnvoll strukturiert''' und '''leicht verständlich''' sind und den '''[[Abgabe#Dokumente|Abgabekriterien]]''' entspricht.
#*** Wir prüfen, ob die Betaversion des Programms '''lauffähig''' ist und den '''[[Abgabe#Programme|Abgabekriterien]]''' entspricht.
#** Bei Final-Abgaben von [[GDD]] und Architektur können max. 10 zusätzliche Punkte erreicht werden.
#*** Wir prüfen, ob die finale Version des [[GDD]]s '''sinnvoll strukturiert''', '''leicht verständlich''' und '''vollständig''' ist, sowie den '''[[Abgabe#Dokumente|Abgabekriterien]]''' entspricht.
#*** Wir prüfen, ob die finale Version der Architektur ''sinnvoll strukturiert'', ''leicht verständlich'' und ''vollständig'' ist, sowie den '''[[Abgabe#Dokumente|Abgabekriterien]]''' entspricht.
#** Die finale Abgabe des Programmes (Endprodukt) wird nach den in Punkt 1. genannten Kriterien '''gesondert''' bewertet.
#** Jedes Gruppenmitglied erhält '''dieselben Punkte''' für Artefaktabgaben. Das heißt, wird die Beta-Version des GDDs zum Beispiel mit 3 Punkten bewertet, erhält jedes Gruppenmiglied diese 3 zusätzlichen Punkte für die entsprechende Woche, zusätzlich zu den erreichten Einzelpunkten.
#* 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).
* Pro [[Sprint]] bekommt jeder Studierende 5 Punkte
** Ist im Sprint Review eine Aufgabe nach [[DoD|Definition of Done]] nicht abgeschlossen, werden anteilig Punkte abgezogen (beachte [[Ablauf#Aufgabe_schwieriger_als_gedacht|Aufgabe schwieriger als gedacht]]).
* Aus der Summe der Punkte ergibt sich die Teilnote für aufgabenorientierte Leistungen.


== Abgaben ==
== Abgaben ==

Aktuelle Version vom 29. Oktober 2024, 11:15 Uhr

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 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. durch

  • Commits im Git-Repository und
  • Aktivität (Tickets, Kommentare, etc.) in Gitea.

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

Zusätzlich müssen Sie im Durchschnitt pro Sprint Aufgaben mit einer geschätzten Arbeitszeit (ETC) von 7 Stunden erfolgreich abschließen.

Um die Fähigkeit zur kontinuierlichen Mitarbeit zeitnah herzustellen, muss jede Teilaufgabe der Hausaufgabe (insbesondere die Programmieraufgabe) sinnvoll bearbeitet werden. Nicht abgeben der Hausaufgabe führt zum sofortigen Verlust der Zulassung.

Benotung

Jeder Student erhält eine Abschlussnote, die sich aus zwei Teilen, die jeweils zu 50% einfließen, zusammensetzt. Ist eine der beiden Teilnoten 5.0 (nicht bestanden), so ist die Abschlussnote 5.0 (nicht bestanden).

Endprodukt

Um das Endprodukt zur Bestimmung der entsprechenden Teilnote zu bewerten, betrachten wir die folgenden Kriterien:

  • Features: Wie gut ist das GDD umgesetzt (siehe auch GDD#Relevanz für die Benotung) und erfüllt das Spiel die Anforderungen?
  • Artefakte: Wie gut war die Qualität der abgegebenen Artefakte (finales GDD, finale Architektur, Codequalität, Buildfehler, Abstürze beim finalen Spiel)
  • Usability: Wurden die Regeln zur Usability gut umgesetzt? Ist das Erscheinungsbild einheitlich?
  • Spaß: Macht das Spiel Spaß?
  • Techdemo: Wie viele Spielobjekte welcher Art können in welchem Environment mit wie vielen durchschnittlichen FPS interagieren? Wie stabil läuft die Techdemo?

Aufgabenorientierte Leistung

  • Pro Sprint bekommt jeder Studierende 5 Punkte
  • Aus der Summe der Punkte ergibt sich die Teilnote für aufgabenorientierte Leistungen.

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.

Abgerufen von „https://sopranium.de/index.php?title=Formalien&oldid=10999“