W05 Bewertung
Versionsverlauf.
- 2025-02-04 erste Version
- 2025-02-10 Projektbeschreibung klargestellt
- 2025-02-10 Bewertung für AGs weiter ausformuliert.
- 2025-02-18 Formatierung AG Text angepasst, AG link verkürzt.
- 2025-02-20 Informationen aus dem FAQ übernommen.
Änderungen und Klarstellungen sind weiterhin möglich.
Punkteverteilung
- 50% AGs
- 50% Begleitveranstaltung
- ~10% Spezifikationsdokument
- ~10% Abschlussvortrag
- ~30% Projektarbeit (Projektdokumentation)
In Ausnahmefällen (Streit im Team oder mit AGs, Betrugsversuche, langanhaltende Krankheitsfälle, ...) behält sich die Projektorganisation das Recht vor von der Punkteverteilung abzuweichen.
Abgabeformate
Abgaben erfolgen als PDF. Es ist kein Format vorgegeben, wählt etwas das für euer Team einfach zu erstellen ist. Achtet auf allgemeine Leserlichkeit. Seitenangaben rechnen sich um als 1 Seite entspricht 400-500 Worten (dies entspricht typischen Templates, weicht euer Template davon ab Zählt bitte die Wörter damit eure Abgabe nicht zu lang wird). Graphiken sind explizit erwünscht und zählen nicht zum Seitenlimit. Seitenlimits sind ein hartes Maximum. Kürzere Texte, die alles Wichtige enthalten, sind oft besser als das Maximum voll auszunutzen.
Benotung durch AGs
Die Benotung im Teamprojekt Softwareentwicklung ist schwierig in ein exaktes Schema zu fassen, da jedes Projekt und jedes Team unterschiedlich ist. Wichtig ist, dass der gesamte Prozess und nicht das Endergebnis bewertet wird. Auch wichtig ist, dass die Bewertung für das Team nicht überraschend ist, Probleme sollten frühzeitig kommuniziert werden.
Wir bitten sie das Team auf einer Skala von 0 bis 100 zu bewerten. Dabei entspricht 49 Punkte oder weniger einem „5.0 nicht bestanden“.
Berücksichtigen Sie bei der Bewertung bitte folgende Punkte.
- Projektablauf:
- Hat die Kommunikation mit dem Team gut funktioniert?
- Waren die regelmäßigen (2 wöchentlichen) Treffen gut vorbereitet und organisiert?
- Wurde regelmäßig Fortschritt vorgestellt und wurden neue Anforderungen umgesetzt?
- Ist das Team gut mit sich eventuell wandelnden Anforderungen umgegangen?
- Ist das Team mit auftretenden Problemen professionell umgegangen? Konnten produktive Lösungen gefunden werden?
- Software:
- Entspricht das Produkt ihren Vorstellungen? (nach eventuellen Anpassungen der Vorstellungen während des Projektes)
- Ist erwartete Funktionalitäten umgesetzt? (nach eventuellen Anpassungen der Erwartungen während des Projektes)
- Gibt es zusätzliche Funktionen? (Positiv, wenn ja, aber nie Negativ)
- Falls nicht alles umgesetzt werden konnte, ist das Team sinnvoll auf ihre Priorisierungswünsche eingegangen?
- Gibt es ausreichend Dokumentation zum Weiterverwenden oder Weiterentwickeln?
- Haben sie vertrauen in die Qualität der Software?
Wenn sie bei den meisten (sagen wir 9 von 11, etwa 80%) der obigen Punkte mit „Ja/Gut“ Antworten würden sind 100 Punkte als Bewertung angemessen.
Falls das Team regelmäßig an den Meetings teilgenommen hat, auch wenn nicht immer gut vorbereitet, und Anforderungen bearbeitet hat, sodass am Ende zumindest minimale nutzbare Software entstanden ist, sollte das Team nicht durchfallen (50+ Punkte).
Für Ergebnisse dazwischen überlassen wir die genaue Gewichtung der obigen Punkte ihnen. Gewichten sie ihre Bewertung danach, was sie dem Team als besonders wichtig kommuniziert haben. Ganz grob könnte jeder der 11 obigen Kriterien etwa 5 Punkte mehr in der Bewertung sein, ausgehend von 55 Punkten für die ausreichende Teilnahme am Projekt.
Typisches Beispiel für 100 Punkte wäre: Das Team hat bei jedem Treffen Fortschritt gezeigt. Anforderungen mit Akzeptanzkriterien entsprechen ihren wünschen. Es gibt zwar nicht erfüllte Anforderungen, aber die Grundfunktionalität der Software ist vorhanden, und das Team hat einen klaren Plan gehabt wie man den ursprünglichen Plan was umgesetzt wird an die Realität anpassen kann.
Typische Beispiele für Teams die durchfallen (weniger als 50 Punkte):
- Das Team ist zu den meisten (mehr als 2 von 3) Meetings nicht erschienen, oder war dabei total unvorbereitet und hat keinerlei Fortschritt gezeigt.
- Es wurde zwar Software entwickelt, aber nicht nach ihren Anforderungen.
- Das Team hat am Anfang einen Plan erstellt, aber ist dann 3 Monate verschwunden und hat zwar etwas abgegeben das irgendwie dem ursprünglichen Plan entspricht, aber doch nicht so ist wie sie es sich vorstellen.
Berücksichtigen Sie bei der Bewertung auch gerne, wenn das Projekt besonders schwer oder einfach war, falls sie dies Beurteilen können (z.B. durch vorherige Erfahrungen mit ähnlichen Studierendenprojekten). Berücksichtigen Sie dabei aber bitte auch, dass es für die Studierenden oft viel schwieriger ist sich in unbekannte Projekte einzuarbeiten als Sie das erwarten würden. Wenn sie sich eine „Standard Webanwendung“ gewünscht haben, aber das Team keine Vorerfahrung mit Webanwendung hat, soll dies nicht übermäßig als Nachteil ausgelegt werden. Wohingegen natürlich schon erwartet werden kann, dass das Team die reichlich vorhandene Dokumentation zu solchen Anwendungen im Internet nutzt, und sich in das Thema einarbeitet.
Projektdokumentation
Abgabe bis Ende Februar.
Die Projektdokumentation ist ein schriftlicher Beleg, dass der Softwareentwicklungsprozess ordentlich durchgeführt wurde. Behauptungen in diesem Dokument werden durch die Teambegleitungen geprüft.
Das Dokument sollte sich in die Folgenden drei Kapitel unterteilen. Abweichungen sind möglich aber unüblich.
Den Hauptteil der Bewertung macht die Beschreibung des Entwicklungsprozesses. Die Projektbeschreibung und das Fazit gehen in den „Gesamteindruck“ des Dokuments ein. Gute Reflektion über das Projekt im Fazit kann eventuell andere schwächen in der Gesamtbewertung ausgleichen.
Projektbeschreibung (maximal 2 Seiten)
Dient dazu, um einen Überblick über das Projekt zu gewinnen, sodass die Projektdokumentation für die Projektorga verständlich ist ohne das Projekt zu kennen.
- Aktualisierte Inhalte der Projektbeschreibung im Spezifikationsdokument
- Vision, wenn nötig Domänenbeschreibung, Architekturdiagram, (Ist-/Sollzustand hier nicht mehr nötig)
- Siehe Projektbeschreibung (maximal 1 Seite)
- + Beschreibung/Überblick über Hauptfunktionalitäten (eventuell mit Vergleich zum Ist-/Sollzustand)
- Bewertungsschema für TBs: Fehlen Teile des Projektes oder sind falsch oder unübersichtlich dargestellt? Wenn nein, keine Beanstandung.
Entwicklungsprozess (maximal 4 Seiten)
Der Entwicklungsprozess ist der Hauptteil eurer Note. Beschreibt, was ihr getan habt, worauf ihr stolz seid. Gebt Beispiele, fügt Screenshots ein, helft der Projektorga einen schnellen Überblick über das zu bekommen, was ihr in dem Semester getan habt.
- Konzentriert euch auf „interessante“ Punkte.
- Gab es signifikante Ereignisse, die das Projekt gefährdet haben? Wie seid ihr damit umgegangen?
- Bewertungsschema für TBs: Alle folgenden Punkte sollten vom Dokument adressiert werden. Alles, was vom Dokument adressiert wird (auch zusätzliche Punkte) sollte plausibel der Wahrheit entsprechen.
Anforderungen?
- Wie wurden Anforderungen gesammelt? (verwendete Software?)
- Was war die Art und der Umfang der Anforderungen? Wie sieht eine typische Anforderung im Projekt aus (Beispiele, Screenshots)
- Wie war der Prozess zwischen euch und dem AG um Anforderungen zu erstellen?
- Wie gute waren eure Zeitschätzungen? Wenn nicht gut, woran lag es?
- Konntet ihr mehrere Anforderungen pro Iteration erfüllen? Wenn nein warum nicht?
- Konntet ihr nach den wünschen des AG priorisierte Anforderungen bearbeiten?
- War das Anforderungsmanagement nützlich für euch? Warum, warum nicht?
Qualitätssicherungsmaßnahmen?
- Tests
- Was/wie wird getestet?
- Woher wisst ihr, und wie stellt ihr sicher, dass ihr relevante Dinge testet?
- Wie viel Arbeit macht euch die Testsuite?
- Werden Fehler gefunden?
- Wie wird auf Fehler reagiert?
- Codereviews
- Wie habt ihr die Reviews durchgeführt? Wie sah ein typisches Review aus?
- Was habt ihr in den Reviews geprüft? Checkliste?
- Waren die Codereviews den Aufwand wert? Warum, warum nicht?
- Pair Programming
- Wie habt ihr das Pair Programming durchgeführt?
- Welche Anforderungen wurden in Paaren bearbeitet?
- Gab es weiter Qualitätssicherungsmaßnahmen?
- Wieso wurden diese gewählt?
- Waren sie hilfreich?
Fazit (maximal 1 Seite)
- Wie war die Erfahrung für euch?
- Was habt ihr als positiv oder negativ wahrgenommen.
- am Projekt
- an der Projektarbeit
- am Team
- der Zusammenarbeit mit den AGs
- den Qualitätssicherungsmaßnahmen
- Was hat euch geholfen das Projekt zu entwickeln, was stand euch im Weg?
- Was würdet ihr in der Zukunft wieder so oder anders machen?
- Bewertungsschema für TBs: Fehlen im Fazit Problemen die Aufgetreten sind (und nicht vorher schon beschrieben wurden)? Ist es klar geschrieben? Falls nein, dann keine Beanstandung.
Abschlussvortrag
- 40 Minuten Blöcke a 3 Teams
- 6 min Vortrag + 6 min Fragen
- PDF Slides, einheitlicher Präsentationscomputer
- 2 Personen tragen vor
- die anderen 3 beantworten Fragen
- Aufteilung wer Präsentiert wird vor Ort entschieden
- Jedes Teammitglied bereitet halben Vortrag vor
- Vortrag in 2 Teil A und Teil B aufteilen
- 2 Teammitglieder bereiten Teil A vor
- 3 Teammitglieder bereiten Teil B vor
Vortragsszenario: Euer Team wird im Rahmen einer Budgetneuverteilung evaluiert. Es ist eure Aufgabe mich zu überzeugen:
- Warum ist euer Projekt wichtig? (2 min)
- Was an eurem Prozess ermöglicht euch weiterhin gute Software zu liefern? (3 min)
- Prozessorganisation?
- Qualitätssicherungsmaßnahmen?
- Was würdet ihr mit mehr Budget/Zeit machen? Prozessverbesserungen (1 min)
Fragen werden sich auf euren Prozess und insbesondere die Qualitätssicherungsmaßnahmen fokussieren. Ziel ist es, dass wir einen Überblick bekommen wollen, ob ihr euer Projekt repräsentieren könnt, und ob alle Teammitglieder beteiligt waren.
- Bewertungsschema:
- Wurde das Projekt gut Motiviert?
- Ist die Projektentwicklung klar organisiert?
- Wurden angemessene Qualitätssicherungsmaßnahmen durchgeführt?
- Waren alle Teammitglieder am Vortrag und den Fragen beteiligt?
- Würde weiteres „Budget“ sinnvoll eingesetzt werden? Insbesondere wie wird anhaltende Qualität gewährleistet?
Beispiele
Wie fällt man durch?
- Keine Abgabe (oder absurd)
- Spezifikationsdokument, Projektdokumentation, Abschlussvortrag
- Teambegleitungen haben keine Indizien auf:
- Projektmanagement
- Anforderungen
- Tests
- Code Reviews
- Pair Programming
- Mehr als 4 Wochen unerwartet nicht erreichbar
Wie bekommt man eine sehr gute Note?
- Gute Abgaben:
- Spezifikationsdokument: enthält alle Punkte
- Abschlussvortrag: verkauft euren Prozess gut
- Projektdokumentation: Eigene Gedanken zu sinnvollem Prozess
- Teambegleitung hat guten Eindruck:
- Projektmanagement sinnvoll
- Anforderungen wurden gesammelt
- Testsuite sinnvoll
- Code Reviews regelmäßig durchgeführt
- Pair Programming durchgeführt
FAQ
Wie verhält es sich mit Verwendung von Grafiken innerhalb von Präsentationen bzw. der Projektdokumentation?
Generell gelten im BP (wie auch in allen anderen Lehrveranstaltungen dieses Fachbereichs) die Grundregeln der Wissenschaftsethik -- auf der Infoseite des Fachbereichs zu diesem Thema finden sich auch Hinweise und weiterführende Links zum korrekten Zitieren, die bei allen Abgaben einzuhalten sind hier.
Für nur im Rahmen von internen Präsentationen verwendeten Bildern reichen dabei Links, welche die Bildquelle angeben. Bedenkt aber das ganze Folien, Beispiele, oder ähnliches übernehmen nur in bestimmten Ausnahmefällen akzeptabel ist. Insbesondere dürfen Architekturdiagramme oder ähnliches nicht einfach übernommen werden. Im Zweifelsfall erstellt an eure eigenen Graphiken.
Ist die Größe der Abgabe der Projektdokumentation als Datei festgelegt?
Moodle erlaubt keine Dateien >20MB. Solltet ihr diese Größe überschreiten müsst ihr die zu großen Inhalte extrahieren und anderweitig verfügbar machen. Kontaktiert hierzu bitte eure TBs.
Wie sollen wir die Nachweise über die durchgeführten QS-Maßnahmen dokumentieren, wenn wir diese beispielsweise in GitHub gepflegt haben?
Stellt bitte sicher das eure TB Einsicht in eure Prozesse hat, und dokumentiert den Prozess in der Projektdokumentation.
Müssen die Dokumente neben der Projektdokumentation ein bestimmtes Dateiformat einhalten?
Bitte nur Standardformate abgeben. Das bedeutet hauptsächlich: .pdf .txt .jpg .png und .html ohne externe Inhalte.
Referenzen
Rundung von Noten aus den APB
Allgemeine Prüfungsbestimmungen der (7. Novelle)
§ 25 Bildung und Gewichtung der Noten
4) Zur Berechnung der Modulnote mit dem BWS „Standard“ werden die ersten drei Dezimalstellen hinter dem Komma berücksichtigt; alle weiteren Stellen werden ohne Rundung gestrichen. Daraus ergeben sich folgende Notenstufen:
1,0 bis 1,199 = 1,0 (sehr gut) 1,2 bis 1,599 = 1,3 (sehr gut) 1,6 bis 1,899 = 1,7 (gut) 1,9 bis 2,199 = 2,0 (gut) 2,2 bis 2,599 = 2,3 (gut) 2,6 bis 2,899 = 2,7 (befriedigend) 2,9 bis 3,199 = 3,0 (befriedigend) 3,2 bis 3,599 = 3,3 (befriedigend) 3,6 bis 3,899 = 3,7 (ausreichend) 3,9 bis 4,099 = 4,0 (ausreichend) ab 4,1 = 5,0 (nicht bestanden)
Punktetabelle
Die verwendete Punktetabelle ist:
Note Punkte
-----------------------
1.0 95 – 100
1.3 90 – 94
1.7 85 – 89
2.0 80 – 84
2.3 75 – 79
2.7 70 – 74
3.0 65 – 69
3.3 60 – 64
3.7 55 – 59
4.0 50 – 54
5.0 0 – 49