|
|
| (31 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 und aktiv daran teilnehmen. 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
| | |
| #* Um das Endprodukt zur Bestimmung der entsprechenden Teilnote zu bewerten, stellen wir uns die folgenden Fragen.
| | === Endprodukt === |
| #* 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.
| | Um das Endprodukt zur Bestimmung der entsprechenden Teilnote zu bewerten, betrachten wir die folgenden Kriterien: |
| #** Wir prüfen, ob das Spiel in sich abgeschlossen ist (d.h. ob Funktionalität aus impliziten Anforderungen wie [[UsabilityForGames|Usability]] fehlt). | | |
| #** Wir prüfen, ob Grafik und Sound zueinander passen.
| | * Features: Wie gut ist das [[GDD]] umgesetzt (siehe auch [[GDD#Relevanz für die Benotung]]) und erfüllt das Spiel die [[Anforderungen]]? |
| #* Ist das Produkt fehlerfrei?
| | * 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 die einzelnen Funktionen Fehler enthalten (z.B. fehlerhaftes Pathfinding, Fehler bei der Auswahl von Spielobjekten, etc.).
| | * Usability: Wurden die Regeln zur Usability gut umgesetzt? Ist das Erscheinungsbild einheitlich? |
| #** Wir prüfen, ob das Spiel Laufzeitfehler enthält (z.B. Abstürze, Überläufe, etc.).
| | * Spaß: Macht das Spiel Spaß? |
| #* Sind die Softwarequalitätsanforderungen erfüllt?
| | * 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 Compiler-Warnungen oder Fehler enthält.
| | |
| #** 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.
| | === Aufgabenorientierte Leistung === |
| #** 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.
| |
| # Aufgabenorientierte Leistung
| |
| #* Für aufgabenorientierte Leistungen kann jede Woche eine bestimmte Anzahl von Punkten von jedem einzelnen Teilnehmer erreicht werden.
| |
| #* Die genaue Anzahl pro Woche erreichbaren Punkte wird durch die Art der Aufgaben, die in der Woche zu erledigen sind, bestimmt.
| |
| #* In jeder Woche sind Punkte für Einzelleistung, sowie Punkte für Artefaktabgaben - in Wochen, in denen Sie [[:Kategorie:Artefakte|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 [[DoD|Definition of Done]] erledigt''' wurde. Bitte beachten Sie dazu den Punkt [[Ablauf#Aufgabe_schwieriger_als_gedacht|Aufgabe schwieriger als gedacht]] im [[Ablauf]].
| |
| #*** Sind Aufgaben in einer Woche nicht im Sinne der [[DoD|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 [[: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.
| |
| #*** 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 [[GDD]]s '''sinnvoll strukturiert''' und '''leicht verständlich''' ist und den '''[[Abgabe#Dokumente|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 '''[[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 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.
| |
| #*** Wird eine der Artefaktabgaben mit '''0 Punkten''' bewertet, führt dies zur Teilnote 5.0 (nicht bestanden) für die aufgabenorientierte Leistung.
| |
| #* 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.
| |
| #* 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, dass das Softwarepraktikum bestanden wird.
| |
|
| |
|
| 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 == |
