Skip to Content

Wiki source code of Bewertung

Last modified by mgrawunder on 2025/09/11 13:05
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 {{toc/}}
4
5
6 = Aufwand =
7
8 * SWP hat 3+6 KP (wobei 1 KP ca 30 h sind)
9 ** (ca.) 90 h + 180 h = 270 h pro Person
10 ** bei 10 Personen pro Gruppe: 10*270 h = 2700 h
11 ** Nur wenn alle (in die selbe Richtung) mitziehen, kann das SWP mit einigermaßen vertretbarem Aufwand durchgeführt werden
12 ** Wichtig: Planung was getan wird und was nicht (100 % in allen Übungsblättern schafft man auch nicht mit der normalen Stundenzahl)
13 ** Programmierung verleitet häufig dazu mehr zu tun … ;-)
14 * Trotzdem natürlich: Leistung = Arbeit/Zeit :-)
15
16 Anmerkung: Die Zahlen sind natürlich nur als Richtschnur zu sehen. Wichtig ist, dass man kontinuierlich an der Aufgabe dran bleibt, damit nicht am Ende die gesamten Stunden auf einen "einschlagen".
17
18 == Noch ein Nachtrag zum Aufwand. ==
19
20 Es wird oft gesagt, dass 9 KP für das Software Projekt zu wenig sind. Hier liegt leider ein kleines Missverständnis vor. Das SWP sollte (so ist es zumindest geplant) so ausgelegt sein, dass ein durchschnittlicher Studierender mit den Kenntnissen die als Vorerfahrung verlangt werden mit dem Aufwand von 9 KP (also rund 250 Stunden) in der Lage sein sollte das Modul zu bestehen.
21
22 Das ganze ist immer relativ einfach zu definieren, wenn es keine Gruppenarbeit ist, dann kann man den Aufwand für das Modul auf eine einzelne Person ausrichten. Wir haben nun aber im SWP die Besonderheit, dass es Gruppenarbeit ist, und zwar keine einfache Gruppenarbeit mit 2 oder 3 Personen sondern mit bis zu 8.
23
24 Ich muss nun die Aufgabe so definieren, dass alle 8 Personen dieser Gruppe die Chance bekommen können, die 9 KP auch leisten zu können, d.h. es muss soviel "Arbeit" da sein, dass niemand aufgrund von fehlenden Aufgaben nichts für das Modul sinnvolles tun kann. Da es nun aber vorkommt, dass Personen nicht so gut mitziehen können oder wollen oder dass Personen das Modul abbrechen, könnte der Eindruck entstehen, dass die Gruppe mit weniger Personen das selbe leisten muss, wie eine Gruppe mit voller Besetzung. Das ist nicht der Fall! Bei der Bewertung der Gruppenleistung wird auch die Größe der Gruppe für die finale Bewertung herangezogen. Dabei ist ergänzend noch zu sagen, dass mit der Größe der Gruppe auch der Koordinierungsaufwand steigt. Es ist also nicht so, dass eine größere Gruppe automatisch linear mehr schafft.
25
26 Also, ich versuche immer eine Aufgabe zu finden, die sich so flexibel erweitern oder einschränken lässt, dass die ganze Gruppe etwas zu tun hat, aber Einzelne nicht mehr tun sollen. Das klappt zugegebenermaßen mal mehr und mal weniger, ist aber immer mein Bemühen. Die Stunden die aufgeschrieben werden sollen, sollen auch dazu dienen, zu sehen, wieviel Aufwand tatsächlich geleistet wird. Ich gehe davon aus, dass die Stunden korrekt sind, da sie auch essentiell für die Bewertung sind. In den letzten Jahren gab es tatsächlich immer einige Studierende, den Aufwand nach oben übertroffen haben (und zwar teilweise deutlich). Das war aber in der Summe der Teilnehmer immer nur ein kleinerer Teil. Die meisten Studierenden waren tatsächlich eher deutlich unterhalb des vorgegebenen Aufwands.
27
28 Ich habe schon mal darüber nachgedacht, die Stunden nach oben hin zu deckeln (d.h. sowas wie "Strafpunkte" zu vergeben, wenn man deutlich zu viele Stunden leistet), das widerstrebt mir aber, da es sich hier um eine Lehrveranstaltung handelt und ich niemanden für sein freiwilliges Engagement bestrafen möchte. I.d.R. sprechen die Tutoren die Personen an, die deutlich zu vielen Stunden leisten.
29
30 Ein anderes Problem ist sicherlich der gefühlte Aufwand, in dem man die z.B. 6 KP die man für eine Vorlesung bekommt mit den 9 KP vergleicht, die man für das SWP bekommt. Der große Unterschied hier: Man kann theoretische Konzepte sehr schnell verstehen oder braucht etwas Zeit. Die KP Berechnung für eine VL geht davon aus, dass man die Inhalte der Vorlesung vor- und nachbereitet und seien wir mal ehrlich ...[[image:https://confluence.swl.informatik.uni-oldenburg.de/s/j6mcdl/9203/cnf719/_/images/icons/emoticons/wink.svg||alt="(Zwinkern)"]]
31
32 In einem praktischen Modul kann man aber relativ wenig durch "schnelles Verstehen" herausholen. Man muss die Dinge aktiv tun und da gibt es auch keine Abkürzung indem man sich z.B. ein gutes YouTube Video anschaut und mit Hilfe von "Bulimie-Lernen" es irgendwie schafft, gut durch die Klausur zu kommen. Die Leistung bezieht sich in einem praktischen Modul immer kontinuierlich auf die ganze Zeit (hier zwei Semester).
33
34 Was final noch dazukommt: Typischerweise schaffen es nicht alle, gleichmäßig die ganze Zeit an dem Modul zu arbeiten (wenn man mal 28 VL-Wochen nimmt, kommt man übrigens auf eine wöchentliche Arbeitsbelastung von ca. 9-10 Stunden für das Modul und der Besuch einer VL oder des Gruppensitzung decken davon je gerade mal 1,5 h ab) kommt es gerade vor Präsentationen zu erhöhtem Aufwand und der bleibt deutlich nachhaltiger im Kopf hängen, als die 3 Wochen in denen man mal nur so 2-3 h gemacht hat.
35
36 Hier noch mal etwas zum Thema Credit-Points: [[https:~~/~~/www.zeit.de/studium/studienfuehrer-2010/studium-bachelor-leitfaden/seite-3>>url:https://www.zeit.de/studium/studienfuehrer-2010/studium-bachelor-leitfaden/seite-3]]
37
38 = Bewertung: Gruppennote =
39
40 Die folgenden Dinge gehen in die Gruppennote ein (gültig ab Start WS 2019, bei allen anderen gilt Inhalt der Präsentation):
41
42 * Produkt, d.h. Software und zugehörige Dokumentation wie JavaDoc, Installationsanleitung, Wartungsanleitung (ca. 50 %)
43 * Testen inkl. Dokumentation (ca. 10%)
44 * Software Entwurfsdokumente: Anforderungsanalyse und Entwurfsbeschreibung (ca. 20%)
45 * Vorgehen und Arbeiten im Team (Scrum Prozess), Kommunikation, Projektmanagement (ca. 10 %)
46 * Präsentationen/Abnahme (ca. 10 %)
47 * **Natürlich fließt dabei die Gruppengröße auch in die Bewertung ein.**
48
49 = Kriterien für Gruppennoten =
50
51 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.
52
53 == Dokumente: Anforderungsdefinition und Analyse bzw. Entwurf ==
54
55 **Grundsätzliche Kriterien**
56
57 * Aufbau
58 * Struktur
59 * Nachvollziehbarkeit
60 * Vollständigkeit
61 * Konsistenz
62 * Grammatik, Rechtschreibung und Sprache
63 * Präzision der Darstellung
64 * Begründungen von Entscheidungen
65
66 **Kriterien für einzelne Diagramme**
67
68 **Anwendungsfälle**
69
70 * Sind alle Akteure (Aufgaben/Rechte) identifiziert und benannt?
71 * Lässt sich jede Anforderung einer Gruppe von Akteuren zuordnen?
72 * Sind alle Anforderungen in Form von Anwendungsfällen dokumentiert?
73 * Ist das Anwendungsfalldiagramm übersichtlich und aussagekräftig? Stimmt es mit den Anwendungsfällen überein (Konsistenz)?
74 * Ist die Benennung der Anwendungsfälle intuitiv verständlich?
75 * Sind die Beschreibungen der Anwendungsfälle ausreichend/vollständig (Analysemodell/Prototyp)?
76 * Sind alle nichtfunktionalen Anforderungen dokumentiert?
77
78 **Klassendiagramme**
79
80 * Ist für jede Anforderung klar, welche (Eingabe-)Daten notwendig sind und welche (Ausgabe-)Daten entstehen?
81 * Sind alle in den Anwendungsfällen benötigten Objekte auch im Klassendiagramm enthalten?
82 * Werden alle Objekte auch tatsächlich von Anwendungsfällen benötigt?
83 * Gibt es Widersprüche zwischen Attributen im Klassendiagramm und in den Anwendungsfällen?
84 * Liegen für alle Klassen verständliche Beschreibungen vor?
85 * Gibt es eine sinnvolle Einteilung in Grenz-, Entitäts- und Steuerungsobjekte?
86 * Wird das MVC-Pattern korrekt umgesetzt?
87 * Sind die Namen für die Objekte sinnvoll gewählt?
88 * Fehlen Assoziationen? Gibt es zu viele? Stimmen die Multiplizitäten?
89 * Wie lesbar ist das Klassendiagramm?
90 * Wie gut sind die Namen im Klassendiagramm gewählt?
91 * Wie gut wird die Vererbung eingesetzt?
92
93 **Sequenzdiagramme**
94
95 * Werden die Sequenzdiagramme richtig eingesetzt? (Nutzer ~-~-> Grenzobjekte ~-~-> Steuerungsobjekt)
96 * Können die Sequenzdiagramme als Basis für die weiteren Schritte dienen?
97 * Führen die Interaktionen im Sequenzdiagramm auch zu einer Änderung im Modell?
98 * Sind die Interaktionen im Sequenzdiagramm möglich, d.h. gibt es ggf. passende Assoziationen und Methoden im Klassendiagramm?
99 * Gibt es Widersprüche zum Klassendiagramm?
100
101 **Speziell auf den Entwurf bezogen**   
102
103 * Werden die Entwurfsziele genannt und gut motiviert, d.h. vor allem gegenüber anderen Entwurfszielen gewichtet?   
104 * Wie gut ist die Systemzerlegung in Module bzgl.  
105 ** Kopplung: Wie häufig kreuzen Assoziationen die Modulgrenzen?   
106 ** Kohäsion: Wie gut passen die Klassen eines Moduls zusammen? Wie viele Klassen enthält ein Modul? Müssten weitere Untermodule gebildet werden?   
107 * Wie gut wird eingegangen auf:  
108 ** Abbildung auf Hardware-/Softwarekomponenten   
109 ** Management von persistenten Daten   
110 ** Zugriffskontrolle und Sicherheit   
111 ** Globaler Kontrollfluss   
112 ** Randbedingungen   
113 * Sind die Subsystemdienste ausreichend beschrieben?  
114
115 **Glossar**   
116
117 Wie gut ist das „dokumentenübergreifende" Glossar?   
118
119 == Produkt ==
120
121 **Quellcode allgemein**   
122
123 * Wie gut ist der Code nachvollziehbar?   
124 * Wie gut ist der Code erweiterbar?   
125 * „Riecht" der Code? (Fowler) u.a.:  
126 ** Redundanter Code/Magic Numbers   
127 ** Unklarer Zweck   
128 ** Zu viele Kommentare, Große Methoden/Klassen, Switch Statements, wenige Schnittstellen   
129 * Sinnvolle Verwendung der Vererbung (Siehe auch Analyse)   
130 * In wieweit stimmt der Quellcode mit dem Entwurf überein?   
131 * Wurde das MVC/P-Muster konsequent weiterverfolgt?   
132 * Wie sieht es mit anderen Mustern aus?   
133 * Welche werden eingesetzt?   
134 * Weitere Dokumente   
135 * Benutzerhandbuch   
136 * Wartungs-/Installationshandbuch   
137
138 **Prototyp**   
139
140 * Werden die Regeln und allgemeinen zu Semesterbeginn genannten notwendigen Anforderungen vollständig und korrekt umgesetzt?   
141 * Werden optionale Anforderungen umgesetzt? Wenn ja, wie gut?   
142 * Wie sieht es mit nichtfunktionalen Umsetzungen aus?  
143 ** Robustheit   
144 ** Bedienbarkeit   
145 ** Nachvollziehbarkeit   
146 ** Spielspaß   
147 ** Sicherheit   
148 * Wie originell ist die Adaption?   
149 * Wie gut sind das Design und die GUI?   
150
151 **Testen**   
152
153 * Welche Arten von Tests liegen vor?  
154 ** JUnit   
155 ** Manuelle Tests   
156 ** Integrations-/Endtests   
157 * Wie gut sind die Tests dokumentiert?   
158 * Wie gut decken die Tests den Code ab?   
159 * Wie gut sind die Tests gewählt?   
160 * Wurden Code-Reviews durchgeführt?   
161 * Wie gut sind die dokumentiert?   
162
163 **Projektmanagement/Vorgehen und Arbeiten im Team**   
164
165 * Wie gut wurde der Scrum Prozess umgesetzt?
166 ** Sprints
167 ** Backlog
168 ** Sprintlog
169 ** Planung
170 ** Review
171 ** Retrospektive
172 * Gibt es dokumentierte Meilensteine?   
173 * Gibt es eine dokumentierte Planung von Aufgaben mit Zuordnungen zu Personen?   
174 * Wurde ein Projekttagebuch geführt in das alle Änderungen der Planung eingetragen wurden?   
175 * Wie wird kommuniziert?   
176 * Protokolle der Treffen und Kontrolle der Einhaltung der Festlegungen?   
177 * Umgang mit Problemen/Konflikten?   
178 * Gibt es Maßnahmen, wenn die Arbeit im Team nicht funktioniert?   
179 * Wird die Arbeit klar und gerecht verteilt?   
180 * Welche Tools werden eingesetzt? Werden diese auch sinnvoll verwendet?
181
182 == Präsentationen ==
183
184 **Allgemeines zum Vortrag**   
185
186 **Aufbau/Gliederung:**   
187
188 (++) Logisch, klar erkennbar, systematisch, folgerichtig   
189
190 (~-~-) Sprunghaft, unsystematisch, zusammenhangslos   
191
192 **Qualität**   
193
194 (++) Wesentliche Informationen und Zusammenhänge   
195
196 (~-~-) wenige Substanz, zusammenhanglos   
197
198 **Rechtschreibung**   
199
200 (~-~-) Fehler bei Rechtschreibung und Grammatik   
201
202 **Korrektheit**   
203
204 (++) Gesamte Präsentation inhaltlich korrekt, keine faktischen Fehler   
205
206 (~-~-) Der Inhalt ist verwirrend und enthält mehrere faktische Fehler   
207
208 **Quantität**   
209
210 (++) angemessen   
211
212 (~-~-) zu kurz/zu lang, zu viele/zu wenige Informationen   
213
214 **Sachwissen**   
215
216 (++) souveräner Vortrag, bei Nachfragen flexible Reaktionen möglich, kompetente Antworten   
217
218 (~-~-) Vortrag meist abgelesen, bei Nachfragen schnell aus dem Konzept zu bringen, unsicher   
219
220 **Sprachliche Qualität**   
221
222 **Welche der folgenden Aspekte wurden betrachtet:**   
223
224 * Struktur der Gruppe   
225 * Konzepte/Ideen: Hier sind Begründungen und Motivation sowie die Betrachtung von Alternativen wichtig   
226 * Projektmanagement   
227 * Testen   
228 * Einblicke in die Software   
229 * Präsentation eines Prototyps. Hier sind Moderation spezielle Szenarien sehr hilfreich   
230 * Dokumentation von Problemen/Fehlern   
231 * Allgemeine Reflexion über sich selbst (die Gruppe) und das Projekt   
232
233 **Weitere Aspekte**
234
235 * Sind die Schwerpunkte gut gesetzt?   
236 * Verhältnismäßigkeit von verbrauchter Zeit und inhaltlicher Bedeutung?   
237 * Wurden wichtige Aspekte mit der entsprechenden Tiefe behandelt?   
238 * Wie interessant wurde die Vorstellung gestaltet? Wie war der allgemeine Ablauf, das ganze drum herum? 
239 * Wie verständlich wurden die Inhalte präsentiert? Zielgruppenkonformität?   
240 * Wie waren die Anlagen/Handouts etc. gestaltet?   
241 * Sind auf der DVD alle bewertungsrelevanten Unterlagen vorhanden und zum Zeitpunkt der Abnahme aktuell?   
242 * Diskussion/Reaktion auf Fragen
243
244 = Bewertung: Einzelnote =
245
246 * Gruppensitzungen (Anwesenheitspflicht!)
247 ** Das SWP ist massiv auf Zusammenarbeit ausgerichtet. Aus diesem Grund muss ich leider eine Anwesenheit verlangen
248 ** 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.
249 ** Regelmäßige und aktive Beteiligung
250 ** Jeder muss mindestens einen Kurzvortrag gehalten haben (z.B. Einzelaufgabe oder Präsentation eines Untergruppenkonzeptes)
251 * [[Einzelleistungen und Einzelaufgabe>>doc:Main.Anforderungen Gruppen.WebHome||anchor="HAnforderungen:EinzelleistungenundEinzelaufgaben"]]
252 ** Regelmäßige Erstellung von Software und Dokumenten (Test, Präsentation von Ergebnissen, Einhaltung von Standards/Richtlinien, …), Engagement, Moderation
253 ** im Rahmen des Projekts, u. a. Projektplanung
254 ** **WICHTIG**: Sorgen Sie dafür, dass Ihre **Leistung identifizierbar** ist,
255 *** 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!
256 *** Buchen Sie sinnvoll Ihre Stunden. Verwenden Sie möglichst wenige "unspezifische" Buchungen wie Gruppensitzung (wenn hier z.B. gemeinsam entwickelt worden ist) und Organisatorisches.
257 *** 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!
258 * Stundenbuchungen
259 ** 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.
260 ** 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.
261 ** 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).
262 ** Für Krankheitszeiten sollte es ein zusätzliches Ticket geben, in dem Stunden gebucht werden können, zu denen man krank (z.B. in einer Gruppensitzung) gewesen ist.
263 ** Stundenbuchungen sind Vertrauenssache, allerdings können (bewusst) falsche Buchungen als Täuschungsversuch gesehen werden!
264 * [[Kriterien Einzelnote>>doc:Main.Bewertung.WebHome||anchor="HKriterienfFCrEinzelnote"]]
265 * 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**.
266 * Die Einschätzung bezieht sich dabei auf die **Gruppengesamtleistung**:
267 ** **Ü**: Die Leistung liegt über der durchschnittlichen Leistung der Gruppe. Dies kann dabei sowohl knapp drüber, als auch deutlich drüber liegen. Gespräche mit dem Tutor können hier helfen.
268 ** **D**: Die Leistung liegt in etwa auf Gruppenniveau
269 ** **U**: Die Leistung ist schlechter als das Gruppenniveau. Dies kann dabei knapp, als auch deutlich drunter liegen. Gespräche mit dem Tutor können hier helfen.
270 ** **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.
271 **NEU: Bei einem N gibt es ein Gespräch mit mir.**
272 ** **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.
273 * Hinweise, um Missverständnisse vorzubeugen:
274 ** Die Einschätzungen werden **durch die Tutoren** auf der Basis von dokumentierten Leistungen und dem Verhalten in den Gruppensitzungen vorgenommen und mit mir abgesprochen.
275 ** 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.
276 ** **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.
277 ** 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
278 ** 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.
279 ** 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.
280 ** [[Aufwand SWP>>doc:Main.Anforderungen Software.WebHome||anchor="HAnforderungen:Aufwand"]], 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 Bewerungszeitraum. Darunter gibt es in der Regel ein N.
281 ** 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.
282
283 = Kriterien für Einzelnote =
284
285 |(% colspan="3" %)**Mitarbeit und Individualleistung**
286 |Hat die Person ausreichend selbstständig programmiert
287 (auch: sinnvolle Commit-Messages, Kommentare, …)?|+ OOOOO -|
288 |Hat die Person ausreichend Dokumentation
289 (u.a. Diagramme, JavaDoc) geleistet?|+ OOOOO -|
290 |Hat die Person ausreichend Qualitätssicherung (u.a. Tests) geleistet?|+ OOOOO -|
291 |Wie komplex ist die geleistete Arbeit?|1-10|
292 |Welche wesentlichen Aufgaben und Bestandteile
293 hat die Person für das Projekt beigesteuert?|Freitext|
294 |Welche Qualität haben die verfassten Protokolle (verständlich, Gliederung, …)?|Freitext|
295 | | |
296 |(% colspan="3" %)**Beteiligung in der Sitzung**
297 |Wie gut ist die Qualität der Beiträge?|+ OOOOO -|
298 |Wie häufig ist die Beteiligung (Quantität)?|+ OOOOO -|
299 |Werden eigene Ideen und Vorschläge eingebracht?|+ OOOOO -|
300 |Weitere Bemerkungen (nicht zuhören, andere nicht ausreden
301 lassen, Nebengespräche, …):|Freitext|
302 | | |
303 |(% colspan="3" %)**Moderation**
304 |Gibt es eine sinnvolle Tagesordnung?|Ja/Nein|
305 |Wird (mindestens am Ende) nach weiteren Tagespunkten gefragt?|Ja/Nein|
306 |Geht der Moderator auf Anregungen und Wünsche der Gruppe ein?|Ja/Nein|
307 |Kommt der Protokollant mit bzw. achtet der Moderator darauf?|Ja/Nein|
308 |Achtet der Moderator auf die Zeit?|+ OOOOO -|
309 |Unterstützt der Moderator die Gruppendiskussion
310 (immer nur ein Thema gleichzeitig, wird jede Diskussion mit einem
311 Ergebnis abgeschlossen, werden Störungen beseitigt,
312 werden komplexe Diskussionen strukturiert, ...)?|Freitext|
313 | | |
314 |(% colspan="3" %)**Verlässlichkeit**
315 |Werden die eigenen Aufgaben erledigt? Werden persönliche Deadlines eingehalten bzw. 
316 werden Probleme rechtzeitig kommuniziert?|+ OOOOO -|
317 |Ist die Person in der Sitzung anwesend
318 (bzw. entschuldigt abwesend) und pünktlich?|+ OOOOO -|
319 |Hält sich die Person an Gruppenstandards und Vereinbarungen?|+ OOOOO -|
320 | | |
321 |(% colspan="3" %)**Soziale Kompetenz**
322 |Zeigt die Person Kommunikationsbereitschaft?|+ OOOOO -|
323 |Legt die Person Sachlichkeit an den Tag?|+ OOOOO -|
324 |Ist die Person kritikfähig (konstruktiv Kritik geben und annehmen)?|+ OOOOO -|
325 |Wird versucht, andere Personen / die Gruppe mit einzubeziehen?
326 Oder versucht die Person, Probleme "auf eigene Faust" zu lösen?|+ OOOOO -|
327 | | |
328 |(% colspan="3" %)**Stundenbuchungen**
329 |Wie viele Stunden hat die Person für das Projekt gearbeitet?|Zahl|
330 |Stimmt das Verhältnis von gebuchten Stunden u. geleisteter Arbeit?|+ OOOOO -|
331 |Wie ist die Qualität der Stundenzettel an sich
332 (pünktlich, vollständig, nachvollziehbar, …)?|Freitext|
333 | | |
334 |(% colspan="3" %)**Entwicklung**
335 |Wie hat sich die Person über den Verlauf
336 des Bewertungszeitraums entwickelt?|Freitext|
337 | | |
338 |(% colspan="3" %)**Kurzvortrag**
339 |Thema des Kurzvortrags:| |
340 |Wird der Bezug des Themas zum Projekt hergestellt?|+ OOOOO -|
341 |Wurde die Zeit (~~ 10 Minuten) sinnvoll genutzt?|+ OOOOO -|
342 |Wurde der vermittelte Inhalt verständlich aufbereitet?|+ OOOOO -|
343 |Sind Folien (falls verwendet) gut lesbar (und durchnummeriert)?|+ OOOOO -|
344 |Werden die Inhalte erklärt und nicht nur von Folien abgelesen?|+ OOOOO -|
345 |Ist der Vortrag sinnvoll gegliedert?|+ OOOOO -|
346 |Wird das Thema kritisch betrachtet, Vor- u. Nachteile beleuchtet,...?|+ OOOOO -|
347 |Wird die vorgestellte Theorie auch praktisch angewendet
348 bzw. die Praxis gezeigt?|+ OOOOO -|
349
350 = Bewertungszeiträume =
351
352 **sind jeweils sieben Wochen: Die VL-freie Zeit kann genutzt werden, um "Bonus" zu sammeln.**
353
354 1. Start des Semesters bis Ende erste Dezemberwoche (oder so, dass es 7 Wochen sind)
355 1. bis Ende des Semesters
356 1. 01.04. - Ende der Woche in der der 21.05. ist (oder so, dass es 7 Wochen sind)
357 1. bis Ende des Semesters