Skip to Content

Wiki source code of Bewertung

Version 19.1 by Marco Grawunder on 2026/08/25 15:50
Show last authors
1 [[image:Main.Organisatorisches.WebHome@softwareprojekt_logo_transparent.png||alt="SoftwareprojektLogo.png" data-xwiki-image-style-alignment="end" height="136" width="309"]]
2
3 {{error}}
4 **Prüfungsanmeldung:**
5
6 * Natürlich muss man sich für das Software Projekt wie für jedes andere Modul auch über Stud.IP für die Prüfung anmelden!
7 * Die Anmeldung erfolgt i.d.R. bis Mitte Dezember und es gibt eine Ankündigung dazu, meistens auch eine Erinnerung, aber nicht garantiert.
8 * Da eine Nachmeldung immer mit extremen Aufwand für alle Beteiligten verbunden ist, werden keine Nachmeldungen mehr akzeptiert. Wer sich nicht rechtzeitig für die Prüfung anmeldet, kann leider nicht teilnehmen!
9 * Kurzer Hinweis: Im zweiten Semester verschwindet die Prüfung in der persönlichen Prüfungsübersicht (weil Anmeldung im ersten Semester). Das ist normal, da die Prüfungen immer semesterweise gezählt werden.
10 {{/error}}
11
12 {{toc/}}
13
14 = Aufwand =
15
16 Das Softwareprojekt umfasst insgesamt **9 Kreditpunkte**. Bei einem Richtwert von **25–30 Arbeitsstunden pro Kreditpunkt** entspricht dies einem Gesamtaufwand von ungefähr **225–270 Stunden pro Person** über die gesamte Veranstaltung.
17
18 {{info}}
19 Die Stundenzahl ist eine **Planungs- und Orientierungsgröße**, kein Bewertungsschema. Eine hohe Zahl gebuchter Stunden führt nicht automatisch zu einer besseren Bewertung. Entscheidend sind unter anderem Qualität, Schwierigkeit, Verantwortung und Ergebnis der geleisteten Arbeit.
20 {{/info}}
21
22 Der Umfang der Aufgabenstellung ist bewusst so gewählt, dass Priorisierung notwendig ist. Ziel ist nicht, alle denkbaren Funktionen umzusetzen, sondern den verfügbaren Aufwand sinnvoll auf die wichtigen Anforderungen zu verteilen. Die Gruppengröße wird bei der Bewertung der Gruppenleistung berücksichtigt; eine kleinere Gruppe muss daher nicht automatisch denselben Gesamtumfang wie eine größere Gruppe erreichen.
23
24 Die Arbeitszeit sollte möglichst kontinuierlich über das Projekt verteilt werden. Erfahrungsgemäß entstehen besonders vor Präsentationen und Abgaben Belastungsspitzen, wenn notwendige Arbeiten zu lange aufgeschoben werden.
25
26 Die dokumentierten Arbeitszeiten dienen insbesondere dazu,
27
28 * die Arbeitsverteilung innerhalb der Gruppe sichtbar zu machen,
29 * Über- oder Unterlast frühzeitig zu erkennen,
30 * individuelle Beiträge nachvollziehen zu können und
31 * Schätzungen und tatsächlichen Aufwand vergleichen zu können.
32
33 = Bewertung: Gruppennote =
34
35 Die folgenden Dinge gehen in die Gruppennote ein (gültig ab Start WS 2019, bei allen anderen gilt Inhalt der Präsentation):
36
37 * Produkt, d.h. Software und zugehörige Dokumentation wie JavaDoc, Installationsanleitung, Wartungsanleitung (ca. 50 %)
38 * Testen inkl. Dokumentation (ca. 10%)
39 * Software Entwurfsdokumente: Anforderungsanalyse und Entwurfsbeschreibung (ca. 20%)
40 * Vorgehen und Arbeiten im Team (Scrum Prozess), Kommunikation, Projektmanagement (ca. 10 %)
41 * Präsentationen/Abnahme (ca. 10 %)
42 * **Natürlich fließt dabei die Gruppengröße auch in die Bewertung ein.**
43
44 **Hinweis: Die Dokumentation kann dabei typischerweise in einem einzelnen Dokument in unterschiedlichen Kapiteln erfolgen. Siehe auch [[Anforderungen Dokumentation>>doc:Main.Dokumentation.WebHome||anchor="HAnforderungen:Dokumentation"]]**
45
46 = Kriterien für Gruppennoten =
47
48 Im Folgenden findet sich eine Übersicht über die Kriterien, die für die Gruppenbewertung herangezogen werden. Die Kriterien sind dabei nach den unterschiedlichen Teilzielen geordnet.
49
50 == Dokumente: Anforderungsdefinition und Analyse bzw. Entwurf ==
51 {{expandable summary="Dokumente: Anforderungsdefinition und Analyse bzw. Entwurf"}}
52
53 **Grundsätzliche Kriterien**
54
55 * Aufbau
56 * Struktur
57 * Nachvollziehbarkeit
58 * Vollständigkeit
59 * Konsistenz
60 * Grammatik, Rechtschreibung und Sprache
61 * Präzision der Darstellung
62 * Begründungen von Entscheidungen
63
64 **Kriterien für einzelne Diagramme**
65
66 **Anwendungsfälle**
67
68 * Sind alle Akteure (Aufgaben/Rechte) identifiziert und benannt?
69 * Lässt sich jede Anforderung einer Gruppe von Akteuren zuordnen?
70 * Sind alle Anforderungen in Form von Anwendungsfällen dokumentiert?
71 * Ist das Anwendungsfalldiagramm übersichtlich und aussagekräftig? Stimmt es mit den Anwendungsfällen überein (Konsistenz)?
72 * Ist die Benennung der Anwendungsfälle intuitiv verständlich?
73 * Sind die Beschreibungen der Anwendungsfälle ausreichend/vollständig (Analysemodell/Prototyp)?
74 * Sind alle nichtfunktionalen Anforderungen dokumentiert?
75
76 **Klassendiagramme**
77
78 * Ist für jede Anforderung klar, welche (Eingabe-)Daten notwendig sind und welche (Ausgabe-)Daten entstehen?
79 * Sind alle in den Anwendungsfällen benötigten Objekte auch im Klassendiagramm enthalten?
80 * Werden alle Objekte auch tatsächlich von Anwendungsfällen benötigt?
81 * Gibt es Widersprüche zwischen Attributen im Klassendiagramm und in den Anwendungsfällen?
82 * Liegen für alle Klassen verständliche Beschreibungen vor?
83 * Gibt es eine sinnvolle Einteilung in Grenz-, Entitäts- und Steuerungsobjekte?
84 * Wird das MVC-Pattern korrekt umgesetzt?
85 * Sind die Namen für die Objekte sinnvoll gewählt?
86 * Fehlen Assoziationen? Gibt es zu viele? Stimmen die Multiplizitäten?
87 * Wie lesbar ist das Klassendiagramm?
88 * Wie gut sind die Namen im Klassendiagramm gewählt?
89 * Wie gut wird die Vererbung eingesetzt?
90
91 **Sequenzdiagramme**
92
93 * Werden die Sequenzdiagramme richtig eingesetzt? (Nutzer ~-~-> Grenzobjekte ~-~-> Steuerungsobjekt)
94 * Können die Sequenzdiagramme als Basis für die weiteren Schritte dienen?
95 * Führen die Interaktionen im Sequenzdiagramm auch zu einer Änderung im Modell?
96 * Sind die Interaktionen im Sequenzdiagramm möglich, d.h. gibt es ggf. passende Assoziationen und Methoden im Klassendiagramm?
97 * Gibt es Widersprüche zum Klassendiagramm?
98
99 **Speziell auf den Entwurf bezogen**   
100
101 * Werden die Entwurfsziele genannt und gut motiviert, d.h. vor allem gegenüber anderen Entwurfszielen gewichtet?   
102 * Wie gut ist die Systemzerlegung in Module bzgl.  
103 ** Kopplung: Wie häufig kreuzen Assoziationen die Modulgrenzen?   
104 ** Kohäsion: Wie gut passen die Klassen eines Moduls zusammen? Wie viele Klassen enthält ein Modul? Müssten weitere Untermodule gebildet werden?   
105 * Wie gut wird eingegangen auf:  
106 ** Abbildung auf Hardware-/Softwarekomponenten   
107 ** Management von persistenten Daten   
108 ** Zugriffskontrolle und Sicherheit   
109 ** Globaler Kontrollfluss   
110 ** Randbedingungen   
111 * Sind die Subsystemdienste ausreichend beschrieben?  
112
113 **Glossar**   
114
115 Wie gut ist das „dokumentenübergreifende" Glossar?   
116 {{/expandable}}
117
118 == ==
119
120 == Produkt ==
121
122 **Quellcode allgemein**   
123
124 * Wie gut ist der Code nachvollziehbar?   
125 * Wie gut ist der Code erweiterbar?   
126 * „Riecht" der Code? (Fowler) u.a.:  
127 ** Redundanter Code/Magic Numbers   
128 ** Unklarer Zweck   
129 ** Zu viele Kommentare, Große Methoden/Klassen, Switch Statements, wenige Schnittstellen   
130 * Sinnvolle Verwendung der Vererbung (Siehe auch Analyse)   
131 * In wieweit stimmt der Quellcode mit dem Entwurf überein?   
132 * Wurde das MVC/P-Muster konsequent weiterverfolgt?   
133 * Wie sieht es mit anderen Mustern aus?   
134 * Welche werden eingesetzt?   
135 * Weitere Dokumente   
136 * Benutzerhandbuch   
137 * Wartungs-/Installationshandbuch   
138
139 **Prototyp**   
140
141 * Werden die Regeln und allgemeinen zu Semesterbeginn genannten notwendigen Anforderungen vollständig und korrekt umgesetzt?   
142 * Werden optionale Anforderungen umgesetzt? Wenn ja, wie gut?   
143 * Wie sieht es mit nichtfunktionalen Umsetzungen aus?  
144 ** Robustheit   
145 ** Bedienbarkeit   
146 ** Nachvollziehbarkeit   
147 ** Spielspaß   
148 ** Sicherheit   
149 * Wie originell ist die Adaption?   
150 * Wie gut sind das Design und die GUI?   
151
152 **Testen**   
153
154 * Welche Arten von Tests liegen vor?  
155 ** JUnit   
156 ** Manuelle Tests   
157 ** Integrations-/Endtests   
158 * Wie gut sind die Tests dokumentiert?   
159 * Wie gut decken die Tests den Code ab?   
160 * Wie gut sind die Tests gewählt?   
161 * Wurden Code-Reviews durchgeführt?   
162 * Wie gut sind die dokumentiert?   
163
164 **Projektmanagement/Vorgehen und Arbeiten im Team**   
165
166 * Wie gut wurde der Scrum Prozess umgesetzt?
167 ** Sprints
168 ** Backlog
169 ** Sprintlog
170 ** Planung
171 ** Review
172 ** Retrospektive
173 * Gibt es dokumentierte Meilensteine?   
174 * Gibt es eine dokumentierte Planung von Aufgaben mit Zuordnungen zu Personen?   
175 * Wurde ein Projekttagebuch geführt in das alle Änderungen der Planung eingetragen wurden?   
176 * Wie wird kommuniziert?   
177 * Protokolle der Treffen und Kontrolle der Einhaltung der Festlegungen?   
178 * Umgang mit Problemen/Konflikten?   
179 * Gibt es Maßnahmen, wenn die Arbeit im Team nicht funktioniert?   
180 * Wird die Arbeit klar und gerecht verteilt?   
181 * Welche Tools werden eingesetzt? Werden diese auch sinnvoll verwendet?
182
183 == Präsentationen ==
184
185 **Allgemeines zum Vortrag**   
186
187 **Aufbau/Gliederung:**   
188
189 (++) Logisch, klar erkennbar, systematisch, folgerichtig   
190
191 (~-~-) Sprunghaft, unsystematisch, zusammenhangslos   
192
193 **Qualität**   
194
195 (++) Wesentliche Informationen und Zusammenhänge   
196
197 (~-~-) wenige Substanz, zusammenhanglos   
198
199 **Rechtschreibung**   
200
201 (~-~-) Fehler bei Rechtschreibung und Grammatik   
202
203 **Korrektheit**   
204
205 (++) Gesamte Präsentation inhaltlich korrekt, keine faktischen Fehler   
206
207 (~-~-) Der Inhalt ist verwirrend und enthält mehrere faktische Fehler   
208
209 **Quantität**   
210
211 (++) angemessen   
212
213 (~-~-) zu kurz/zu lang, zu viele/zu wenige Informationen   
214
215 **Sachwissen**   
216
217 (++) souveräner Vortrag, bei Nachfragen flexible Reaktionen möglich, kompetente Antworten   
218
219 (~-~-) Vortrag meist abgelesen, bei Nachfragen schnell aus dem Konzept zu bringen, unsicher   
220
221 **Sprachliche Qualität**   
222
223 **Welche der folgenden Aspekte wurden betrachtet:**   
224
225 * Struktur der Gruppe   
226 * Konzepte/Ideen: Hier sind Begründungen und Motivation sowie die Betrachtung von Alternativen wichtig   
227 * Projektmanagement   
228 * Testen   
229 * Einblicke in die Software   
230 * Präsentation eines Prototyps. Hier sind Moderation spezielle Szenarien sehr hilfreich   
231 * Dokumentation von Problemen/Fehlern   
232 * Allgemeine Reflexion über sich selbst (die Gruppe) und das Projekt   
233
234 **Weitere Aspekte**
235
236 * Sind die Schwerpunkte gut gesetzt?   
237 * Verhältnismäßigkeit von verbrauchter Zeit und inhaltlicher Bedeutung?   
238 * Wurden wichtige Aspekte mit der entsprechenden Tiefe behandelt?   
239 * Wie interessant wurde die Vorstellung gestaltet? Wie war der allgemeine Ablauf, das ganze drum herum? 
240 * Wie verständlich wurden die Inhalte präsentiert? Zielgruppenkonformität?   
241 * Wie waren die Anlagen/Handouts etc. gestaltet?   
242 * Sind auf der DVD alle bewertungsrelevanten Unterlagen vorhanden und zum Zeitpunkt der Abnahme aktuell?   
243 * Diskussion/Reaktion auf Fragen
244
245 = Bewertung: Einzelnote =
246
247 {{info}}
248 **Wichtig:** Die Zahl der gebuchten Stunden ist **kein direktes Bewertungskriterium für die Note**. Sie ist ein Indikator für Arbeitsumfang und Arbeitsverteilung. Für die Einschätzung werden insbesondere Inhalt, Qualität, Schwierigkeit, Verantwortung und Nachvollziehbarkeit der individuellen Beiträge betrachtet.
249 {{/info}}
250
251 * Gruppensitzungen (Anwesenheitspflicht!)
252 ** Das SWP ist massiv auf Zusammenarbeit ausgerichtet. Aus diesem Grund muss ich leider eine Anwesenheit verlangen
253 ** Wer drei mal **unentschuldigt** fehlt, kann nicht mehr erfolgreich bestehen. Wer sechs mal **entschuldig** fehlt, kann ggf. nach einem Gespräch bei mir weiter teilnehmen.
254 ** Regelmäßige und aktive Beteiligung
255 ** Jeder muss mindestens einen Kurzvortrag gehalten haben (z.B. Einzelaufgabe oder Präsentation eines Untergruppenkonzeptes)
256 * [[Einzelleistungen und Einzelaufgabe>>doc:Main.Projektarbeit.WebHome||anchor="HIndividuelleVerantwortungsbereicheundEinzelaufgaben"]]
257 ** Regelmäßige Erstellung von Software und Dokumenten (Test, Präsentation von Ergebnissen, Einhaltung von Standards/Richtlinien, …), Engagement, Moderation
258 ** im Rahmen des Projekts, u. a. Projektplanung
259 ** **WICHTIG**: Sorgen Sie dafür, dass Ihre **Leistung identifizierbar** ist,
260 *** d.h. Commits sollten auch im zentralen Repository landen (der Branch muss ja nicht gemergt werden) und beim Pairprogramming sollte sich auch der Comittende ändern. Nur dabeizusitzen ist keine bewertbare Leistung!
261 *** Buchen Sie sinnvoll Ihre Stunden. Verwenden Sie möglichst wenige "unspezifische" Buchungen wie Gruppensitzung (wenn hier z.B. gemeinsam entwickelt worden ist) und Organisatorisches.
262 *** Auch wenn es im Bitbucket eine Darstellung der Menge der Commits gibt, ist dies alleine kein Bewertungskriterium. Es wird immer geschaut, was war **Inhalt des Commits**, d.h. wie umfangreich und wie komplex war die zu lösende Aufgabe. Es ist für die Tutoren nicht schön, wenn sie hunderte von "Scheincommits" durchgehen, die offensichtlich nur gemacht werden, um die Commit-Anzahl zu erhöhen!
263 * Stundenbuchungen
264 ** Um die Arbeitslast möglichst transparent zu machen und im Idealfall auch gleichmäßig zu verteilen, ist es notwendig, die Stunden, die gemacht werden entsprechend zu buchen.
265 ** Dabei sollte JEDE Tätigkeit, die in Zusammenhang mit der Veranstaltung steht, also auch alle Vorlesungen und Gruppensitzungen, auch gebucht werden. Dabei gehen wir natürlich davon aus, dass nur tatsächliche Zeiten gebucht werden, d.h. wenn man gar nicht zur VL geht oder die geplante 90 Minuten-Sitzung nur 30 Minuten gedauert hat, muss das entsprechend berücksichtig werden.
266 ** Die Stundenbuchungen dienen den Tutoren auch für die Einschätzungen. Dabei ist natürlich zum einen der Umfang relevant, aber auch, was gemacht worden ist. Deswegen bitte möglichst wenig auf allgemeine Tasks buchen (Beispiel: Man hat eine gemeinsame Programmiersitzung gemacht, dann nicht "Programmiersitzung" buchen, sondern auf die konkreten Tickets, die man bearbeitet hat).
267 ** Krankheitsbedingte Fehlzeiten sollten in einem gesonderten Ticket dokumentiert werden,.
268 ** Stundenbuchungen sind Vertrauenssache, allerdings können (bewusst) falsche Buchungen als Täuschungsversuch gesehen werden!
269 * [[Kriterien Einzelnote>>doc:Main.Bewertung.WebHome||anchor="HKriterienfFCrEinzelnote"]]
270 * Es gibt im Laufe der Zeit 4 Einschätzungen (Einzelleistungen) zur Orientierung: **Wenn eine Einschätzung davon F ist und es keine guten Gründe (→ Gespräch mit mir) dafür gibt, kann das Modul nicht mehr bestanden werden**.
271 * Die Einschätzung bezieht sich dabei auf die **Gruppengesamtleistung**:
272 ** **Ü**: Die Leistung liegt über der durchschnittlichen Leistung der Gruppe. Dies kann dabei sowohl knapp drüber, als auch deutlich darüber liegen. Gespräche mit dem Tutor können hier helfen.
273 ** **D**: Die Leistung liegt in etwa auf Gruppenniveau
274 ** **U**: Die Leistung ist schlechter als das Gruppenniveau. Dies kann dabei knapp, als auch deutlich darunter liegen. Gespräche mit dem Tutor können hier helfen.
275 ** **N**: Die Leistung ist nicht mehr ausreichend, aber es gibt eine letzte Warnung. Normalerweise gibt es keine zwei N im SWP. Gedacht ist diese Einschätzung für Fälle, in denen man sieht, dass grundsätzlich das Potential für eine erfolgreiche Teilnahme vorhanden ist, dieses Potential aber gerade nicht abgerufen wird.
276 **F**: Die Leistung ist ungenügend. Eine erfolgreiche Teilnahme am Modul ist i.d.R. nicht mehr möglich. I.d.R. wird es nicht sofort ein F geben, wenn die Leistung aber so ungenügend ist, dass keine erfolgreiche Teilnahme zu erwarten ist, kann es aber sofort ein F geben. Dies kann auch als Hinweis verstanden werden, dass man die eigenen Fähigkeiten, die grundlegend für das SWP sind, noch einmal an anderer Stelle trainieren sollte.
277 * Hinweise, um Missverständnisse vorzubeugen:
278 ** Die Einschätzungen werden **durch die Tutoren** auf der Basis von dokumentierten Leistungen und dem Verhalten in den Gruppensitzungen vorgenommen und mit mir abgesprochen.
279 ** Wer mit seiner Einschätzung nicht einverstanden ist, kann dies natürlich zunächst mit dem Tutor klären. Sollte hierbei keine Einigung erfolgen können, sollte es ein klärendes Gespräch mit mir geben, dafür dann bitte überprüfbare Nachweise mitbringen.
280 ** **Die Einschätzung ist keine Note**, sondern beschreibt nur die Leistung **im Vergleich zum Rest der Gruppe** (Ü,D,U). Wenn die Leistung nicht mehr ausreichend ist, gibt es i.d.R. als "Warnung" ein N und wenn es keine deutliche Verbesserung der Leistung gibt ein F.
281 ** In letzter Zeit kommt bei N/F Einschätzungen hin und wieder der Satz "//Aber ich habe doch was getan!//". Dazu sei als Analogie das Bestehen einer Klausur angeführt. Hier muss ja auch i.d.R. mindestens 40% (hin und wieder auch 50%) der Klausuraufgaben korrekt bearbeitet werden. Da fällt man also auch durch, selbst wenn man was getan hat. Das gleiche gilt für das Softwareprojekt. Aus diesem Grund sind Einschätzungen N/F auch nicht direkt miteinander vergleichbar, da hier eine immense Spanne abgedeckt wird.
282 ** Die Tendenz der Einschätzungen ist wichtig! Es wird i.d.R. eine bessere Note geben, wenn sich die Leistung verbessert und eine schlechtere, wenn sich die Leistung verschlechtert, d.h. z.B. N,U,D,D führt zu einer besseren Note als D,D,U,N
283 ** Da die Einschätzungen keine Noten sind, findet auch keine "Durchschnittsberechnung" am Ende statt. Es wird zur Ermittlung der finalen Note noch einmal über das gesamte Projekt geschaut und die Leistung der einzelnen Mitglieder miteinander verglichen. Die Zwischeneinschätzungen sind dabei zwar ein wichtiger Indikator, aber nicht alleine aussagekräftig.
284 ** Noten folgen **keiner mathematischen Rundungslogik**! Wenn die Gruppennoten bspw. eine 2,2 ist und man genau auf dem Durchschnitt liegt, wird die Endnote i.d.R eher eine 2,3 sein. Man kann das leicht auf Prozente in einer Klausur übertragen:  Wenn 80% für das Erreichen einer 2,0 notwendig sind, dann wären 79% zwar sehr dicht dran, aber trotzdem nur eine 2,3, da die Grenze für die bessere Note nicht überschritten worden ist.
285 ** [[Aufwand SWP>>doc:Main.Bewertung.WebHome||anchor="HAufwand"]], d.h. 225h – 270h (man rechnet 25-30 h pro KP). Wenn man das ganze durch vier teilt, ist man beim ungefähren Anteil pro Bewertungszeitraum: 56,25 - 67,5 h. Wenn man hier jetzt 20% abzieht ist man bei mindestens 45 h pro Bewertungszeitraum. Darunter gibt es in der Regel ein N.
286 ** Es ist **nicht** so, dass automatisch alle mit einem D die Gruppennote bekommen. Grundsätzlich ist das natürlich die Idee, funktioniert aber nur, wenn die Leistung auch im Wesentlich von allen Personen der Gruppe erbracht worden ist. Es gibt aber hin und wieder Fälle, in denen **wenige Einzelpersonen** das Ergebnis sehr nach vorne bringen. Diese Einzelpersonen bekommen dann oft ein Ü und andere, die schlechter sind ein D. In solchen Fällen, ist es so, dass man mit dem D i.d.R. eine schlechtere Note als die Gruppennote bekommen wird. Auf diese Weise soll verhindert werden, dass sich Personen darauf **ausruhen** können, dass ein sehr guter (kleinerer) Teil der Gruppe massiv das Ergebnis bestimmt.
287
288 = Kriterien für Einzelnote =
289
290 |(% colspan="3" %)**Mitarbeit und Individualleistung**
291 |Hat die Person ausreichend selbstständig programmiert
292 (auch: sinnvolle Commit-Messages, Kommentare, …)?|+ OOOOO -|
293 |Hat die Person ausreichend Dokumentation
294 (u.a. Diagramme, JavaDoc) geleistet?|+ OOOOO -|
295 |Hat die Person ausreichend Qualitätssicherung (u.a. Tests) geleistet?|+ OOOOO -|
296 |Wie komplex ist die geleistete Arbeit?|1-10|
297 |Welche wesentlichen Aufgaben und Bestandteile
298 hat die Person für das Projekt beigesteuert?|Freitext|
299 |Welche Qualität haben die verfassten Protokolle (verständlich, Gliederung, …)?|Freitext|
300 | | |
301 |(% colspan="3" %)**Beteiligung in der Sitzung**
302 |Wie gut ist die Qualität der Beiträge?|+ OOOOO -|
303 |Wie häufig ist die Beteiligung (Quantität)?|+ OOOOO -|
304 |Werden eigene Ideen und Vorschläge eingebracht?|+ OOOOO -|
305 |Weitere Bemerkungen (nicht zuhören, andere nicht ausreden
306 lassen, Nebengespräche, …):|Freitext|
307 | | |
308 |(% colspan="3" %)**Moderation**
309 |Gibt es eine sinnvolle Tagesordnung?|Ja/Nein|
310 |Wird (mindestens am Ende) nach weiteren Tagespunkten gefragt?|Ja/Nein|
311 |Geht der Moderator auf Anregungen und Wünsche der Gruppe ein?|Ja/Nein|
312 |Kommt der Protokollant mit bzw. achtet der Moderator darauf?|Ja/Nein|
313 |Achtet der Moderator auf die Zeit?|+ OOOOO -|
314 |Unterstützt der Moderator die Gruppendiskussion
315 (immer nur ein Thema gleichzeitig, wird jede Diskussion mit einem
316 Ergebnis abgeschlossen, werden Störungen beseitigt,
317 werden komplexe Diskussionen strukturiert, ...)?|Freitext|
318 | | |
319 |(% colspan="3" %)**Verlässlichkeit**
320 |Werden die eigenen Aufgaben erledigt? Werden persönliche Deadlines eingehalten bzw. 
321 werden Probleme rechtzeitig kommuniziert?|+ OOOOO -|
322 |Ist die Person in der Sitzung anwesend
323 (bzw. entschuldigt abwesend) und pünktlich?|+ OOOOO -|
324 |Hält sich die Person an Gruppenstandards und Vereinbarungen?|+ OOOOO -|
325 | | |
326 |(% colspan="3" %)**Soziale Kompetenz**
327 |Zeigt die Person Kommunikationsbereitschaft?|+ OOOOO -|
328 |Legt die Person Sachlichkeit an den Tag?|+ OOOOO -|
329 |Ist die Person kritikfähig (konstruktiv Kritik geben und annehmen)?|+ OOOOO -|
330 |Wird versucht, andere Personen / die Gruppe mit einzubeziehen?
331 Oder versucht die Person, Probleme "auf eigene Faust" zu lösen?|+ OOOOO -|
332 | | |
333 |(% colspan="3" %)**Stundenbuchungen**
334 |Wie viele Stunden hat die Person für das Projekt gearbeitet?|Zahl|
335 |Stimmt das Verhältnis von gebuchten Stunden u. geleisteter Arbeit?|+ OOOOO -|
336 |Wie ist die Qualität der Stundenzettel an sich
337 (pünktlich, vollständig, nachvollziehbar, …)?|Freitext|
338 | | |
339 |(% colspan="3" %)**Entwicklung**
340 |Wie hat sich die Person über den Verlauf
341 des Bewertungszeitraums entwickelt?|Freitext|
342 | | |
343 |(% colspan="3" %)**Kurzvortrag**
344 |Thema des Kurzvortrags:| |
345 |Wird der Bezug des Themas zum Projekt hergestellt?|+ OOOOO -|
346 |Wurde die Zeit (~~ 10 Minuten) sinnvoll genutzt?|+ OOOOO -|
347 |Wurde der vermittelte Inhalt verständlich aufbereitet?|+ OOOOO -|
348 |Sind Folien (falls verwendet) gut lesbar (und durchnummeriert)?|+ OOOOO -|
349 |Werden die Inhalte erklärt und nicht nur von Folien abgelesen?|+ OOOOO -|
350 |Ist der Vortrag sinnvoll gegliedert?|+ OOOOO -|
351 |Wird das Thema kritisch betrachtet, Vor- u. Nachteile beleuchtet,...?|+ OOOOO -|
352 |Wird die vorgestellte Theorie auch praktisch angewendet
353 bzw. die Praxis gezeigt?|+ OOOOO -|
354
355 = Bewertungszeiträume =
356
357 **sind jeweils sieben Wochen: Die VL-freie Zeit kann genutzt werden, um "Bonus" zu sammeln.**
358
359 1. Start des Semesters bis Ende erste Dezemberwoche (oder so, dass es 7 Wochen sind)
360 1. bis Ende des Semesters
361 1. 01.04. - Ende der Woche in der der 21.05. ist (oder so, dass es 7 Wochen sind)
362 1. bis Ende des Semesters