Bewertung - XWiki des Softwarelabors der Informatik in der Universität Oldenburg

1

[[image:Main.Organisatorisches.WebHome@softwareprojekt_logo_transparent.png||alt="SoftwareprojektLogo.png" data-xwiki-image-style-alignment="end" height="136" width="309"]]

2

3

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.

= Aufwand =

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

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

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

{{expandable summary="== Dokumente: Anforderungsdefinition und Analyse bzw. Entwurf =="}}

51

**Grundsätzliche Kriterien**

* Aufbau

* Struktur

* Nachvollziehbarkeit

56

* Vollständigkeit

57

* Konsistenz

58

* Grammatik, Rechtschreibung und Sprache

59

* Präzision der Darstellung

60

* Begründungen von Entscheidungen

61

62

**Kriterien für einzelne Diagramme**

**Anwendungsfälle**

* Sind alle Akteure (Aufgaben/Rechte) identifiziert und benannt?

67

* Lässt sich jede Anforderung einer Gruppe von Akteuren zuordnen?

68

* Sind alle Anforderungen in Form von Anwendungsfällen dokumentiert?

69

* Ist das Anwendungsfalldiagramm übersichtlich und aussagekräftig? Stimmt es mit den Anwendungsfällen überein (Konsistenz)?

70

* Ist die Benennung der Anwendungsfälle intuitiv verständlich?

71

* Sind die Beschreibungen der Anwendungsfälle ausreichend/vollständig (Analysemodell/Prototyp)?

72

* Sind alle nichtfunktionalen Anforderungen dokumentiert?

**Klassendiagramme**

* Ist für jede Anforderung klar, welche (Eingabe-)Daten notwendig sind und welche (Ausgabe-)Daten entstehen?

77

* Sind alle in den Anwendungsfällen benötigten Objekte auch im Klassendiagramm enthalten?

78

* Werden alle Objekte auch tatsächlich von Anwendungsfällen benötigt?

79

* Gibt es Widersprüche zwischen Attributen im Klassendiagramm und in den Anwendungsfällen?

80

* Liegen für alle Klassen verständliche Beschreibungen vor?

81

* Gibt es eine sinnvolle Einteilung in Grenz-, Entitäts- und Steuerungsobjekte?

82

* Wird das MVC-Pattern korrekt umgesetzt?

83

* Sind die Namen für die Objekte sinnvoll gewählt?

84

* Fehlen Assoziationen? Gibt es zu viele? Stimmen die Multiplizitäten?

85

* Wie lesbar ist das Klassendiagramm?

86

* Wie gut sind die Namen im Klassendiagramm gewählt?

87

* Wie gut wird die Vererbung eingesetzt?

**Sequenzdiagramme**

* Werden die Sequenzdiagramme richtig eingesetzt? (Nutzer ~-~-> Grenzobjekte ~-~-> Steuerungsobjekt)

92

* Können die Sequenzdiagramme als Basis für die weiteren Schritte dienen?

93

* Führen die Interaktionen im Sequenzdiagramm auch zu einer Änderung im Modell?

94

* Sind die Interaktionen im Sequenzdiagramm möglich, d.h. gibt es ggf. passende Assoziationen und Methoden im Klassendiagramm?

95

* Gibt es Widersprüche zum Klassendiagramm?

96

97

**Speziell auf den Entwurf bezogen**

98

99

* Werden die Entwurfsziele genannt und gut motiviert, d.h. vor allem gegenüber anderen Entwurfszielen gewichtet?

100

* Wie gut ist die Systemzerlegung in Module bzgl.

101

** Kopplung: Wie häufig kreuzen Assoziationen die Modulgrenzen?

102

** Kohäsion: Wie gut passen die Klassen eines Moduls zusammen? Wie viele Klassen enthält ein Modul? Müssten weitere Untermodule gebildet werden?

103

* Wie gut wird eingegangen auf:

104

** Abbildung auf Hardware-/Softwarekomponenten

105

** Management von persistenten Daten

106

** Zugriffskontrolle und Sicherheit

107

** Globaler Kontrollfluss

108

** Randbedingungen

109

* Sind die Subsystemdienste ausreichend beschrieben?

**Glossar**

Wie gut ist das „dokumentenübergreifende" Glossar?

== ==

== Produkt ==

**Quellcode allgemein**

121

122

* Wie gut ist der Code nachvollziehbar?

123

* Wie gut ist der Code erweiterbar?

124

* „Riecht" der Code? (Fowler) u.a.:

125

** Redundanter Code/Magic Numbers

126

** Unklarer Zweck

127

** Zu viele Kommentare, Große Methoden/Klassen, Switch Statements, wenige Schnittstellen

128

* Sinnvolle Verwendung der Vererbung (Siehe auch Analyse)

129

* In wieweit stimmt der Quellcode mit dem Entwurf überein?

130

* Wurde das MVC/P-Muster konsequent weiterverfolgt?

131

* Wie sieht es mit anderen Mustern aus?

132

* Welche werden eingesetzt?

133

* Weitere Dokumente

134

* Benutzerhandbuch

135

* Wartungs-/Installationshandbuch

**Prototyp**

* Werden die Regeln und allgemeinen zu Semesterbeginn genannten notwendigen Anforderungen vollständig und korrekt umgesetzt?

140

* Werden optionale Anforderungen umgesetzt? Wenn ja, wie gut?

141

* Wie sieht es mit nichtfunktionalen Umsetzungen aus?

142

** Robustheit

143

** Bedienbarkeit

144

** Nachvollziehbarkeit

145

** Spielspaß

146

** Sicherheit

147

* Wie originell ist die Adaption?

148

* Wie gut sind das Design und die GUI?

**Testen**

* Welche Arten von Tests liegen vor?

153

** JUnit

154

** Manuelle Tests

155

** Integrations-/Endtests

156

* Wie gut sind die Tests dokumentiert?

157

* Wie gut decken die Tests den Code ab?

158

* Wie gut sind die Tests gewählt?

159

* Wurden Code-Reviews durchgeführt?

160

* Wie gut sind die dokumentiert?

161

162

**Projektmanagement/Vorgehen und Arbeiten im Team**

163

164

* Wie gut wurde der Scrum Prozess umgesetzt?

** Sprints

** Backlog

** Sprintlog

** Planung

** Review

** Retrospektive

* Gibt es dokumentierte Meilensteine?

172

* Gibt es eine dokumentierte Planung von Aufgaben mit Zuordnungen zu Personen?

173

* Wurde ein Projekttagebuch geführt in das alle Änderungen der Planung eingetragen wurden?

174

* Wie wird kommuniziert?

175

* Protokolle der Treffen und Kontrolle der Einhaltung der Festlegungen?

176

* Umgang mit Problemen/Konflikten?

177

* Gibt es Maßnahmen, wenn die Arbeit im Team nicht funktioniert?

178

* Wird die Arbeit klar und gerecht verteilt?

179

* Welche Tools werden eingesetzt? Werden diese auch sinnvoll verwendet?

== Präsentationen ==

**Allgemeines zum Vortrag**

184

185

**Aufbau/Gliederung:**

186

187

(++) Logisch, klar erkennbar, systematisch, folgerichtig

188

189

(~-~-) Sprunghaft, unsystematisch, zusammenhangslos

**Qualität**

(++) Wesentliche Informationen und Zusammenhänge

194

195

(~-~-) wenige Substanz, zusammenhanglos

**Rechtschreibung**

(~-~-) Fehler bei Rechtschreibung und Grammatik

**Korrektheit**

(++) Gesamte Präsentation inhaltlich korrekt, keine faktischen Fehler

204

205

(~-~-) Der Inhalt ist verwirrend und enthält mehrere faktische Fehler

**Quantität**

(++) angemessen

(~-~-) zu kurz/zu lang, zu viele/zu wenige Informationen

**Sachwissen**

(++) souveräner Vortrag, bei Nachfragen flexible Reaktionen möglich, kompetente Antworten

216

217

(~-~-) Vortrag meist abgelesen, bei Nachfragen schnell aus dem Konzept zu bringen, unsicher

218

219

**Sprachliche Qualität**

220

221

**Welche der folgenden Aspekte wurden betrachtet:**

222

223

* Struktur der Gruppe

224

* Konzepte/Ideen: Hier sind Begründungen und Motivation sowie die Betrachtung von Alternativen wichtig

225

* Projektmanagement

226

* Testen

227

* Einblicke in die Software

228

* Präsentation eines Prototyps. Hier sind Moderation spezielle Szenarien sehr hilfreich

229

* Dokumentation von Problemen/Fehlern

230

* Allgemeine Reflexion über sich selbst (die Gruppe) und das Projekt

**Weitere Aspekte**

* Sind die Schwerpunkte gut gesetzt?

235

* Verhältnismäßigkeit von verbrauchter Zeit und inhaltlicher Bedeutung?

236

* Wurden wichtige Aspekte mit der entsprechenden Tiefe behandelt?

237

* Wie interessant wurde die Vorstellung gestaltet? Wie war der allgemeine Ablauf, das ganze drum herum?

238

* Wie verständlich wurden die Inhalte präsentiert? Zielgruppenkonformität?

239

* Wie waren die Anlagen/Handouts etc. gestaltet?

240

* Sind auf der DVD alle bewertungsrelevanten Unterlagen vorhanden und zum Zeitpunkt der Abnahme aktuell?

241

* Diskussion/Reaktion auf Fragen

242

243

= Bewertung: Einzelnote =

244

245

246

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

247

248

249

* Gruppensitzungen (Anwesenheitspflicht!)

250

** Das SWP ist massiv auf Zusammenarbeit ausgerichtet. Aus diesem Grund muss ich leider eine Anwesenheit verlangen

251

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

252

** Regelmäßige und aktive Beteiligung

253

** Jeder muss mindestens einen Kurzvortrag gehalten haben (z.B. Einzelaufgabe oder Präsentation eines Untergruppenkonzeptes)

254

* [[Einzelleistungen und Einzelaufgabe>>doc:Main.Projektarbeit.WebHome||anchor="HIndividuelleVerantwortungsbereicheundEinzelaufgaben"]]

255

** Regelmäßige Erstellung von Software und Dokumenten (Test, Präsentation von Ergebnissen, Einhaltung von Standards/Richtlinien, …), Engagement, Moderation

256

** im Rahmen des Projekts, u. a. Projektplanung

257

** **WICHTIG**: Sorgen Sie dafür, dass Ihre **Leistung identifizierbar** ist,

258

*** 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!

259

*** Buchen Sie sinnvoll Ihre Stunden. Verwenden Sie möglichst wenige "unspezifische" Buchungen wie Gruppensitzung (wenn hier z.B. gemeinsam entwickelt worden ist) und Organisatorisches.

260

*** 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!

261

* Stundenbuchungen

262

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

263

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

264

** 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).

265

** Krankheitsbedingte Fehlzeiten sollten in einem gesonderten Ticket dokumentiert werden,.

266

** Stundenbuchungen sind Vertrauenssache, allerdings können (bewusst) falsche Buchungen als Täuschungsversuch gesehen werden!

267

* [[Kriterien Einzelnote>>doc:Main.Bewertung.WebHome||anchor="HKriterienfFCrEinzelnote"]]

268

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

269

* Die Einschätzung bezieht sich dabei auf die **Gruppengesamtleistung**:

270

** **Ü**: 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.

271

** **D**: Die Leistung liegt in etwa auf Gruppenniveau

272

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

273

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

274

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

275

* Hinweise, um Missverständnisse vorzubeugen:

276

** Die Einschätzungen werden **durch die Tutoren** auf der Basis von dokumentierten Leistungen und dem Verhalten in den Gruppensitzungen vorgenommen und mit mir abgesprochen.

277

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

278

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

279

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

280

** 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

281

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

282

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

283

** [[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.

284

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

285

286

= Kriterien für Einzelnote =

287

288

|(% colspan="3" %)**Mitarbeit und Individualleistung**

289

|Hat die Person ausreichend selbstständig programmiert

290

(auch: sinnvolle Commit-Messages, Kommentare, …)?|+ OOOOO -|

291

|Hat die Person ausreichend Dokumentation

292

(u.a. Diagramme, JavaDoc) geleistet?|+ OOOOO -|

293

|Hat die Person ausreichend Qualitätssicherung (u.a. Tests) geleistet?|+ OOOOO -|

294

|Wie komplex ist die geleistete Arbeit?|1-10|

295

|Welche wesentlichen Aufgaben und Bestandteile

296

hat die Person für das Projekt beigesteuert?|Freitext|

297

|Welche Qualität haben die verfassten Protokolle (verständlich, Gliederung, …)?|Freitext|

298

| | |

299

|(% colspan="3" %)**Beteiligung in der Sitzung**

300

|Wie gut ist die Qualität der Beiträge?|+ OOOOO -|

301

|Wie häufig ist die Beteiligung (Quantität)?|+ OOOOO -|

302

|Werden eigene Ideen und Vorschläge eingebracht?|+ OOOOO -|

303

|Weitere Bemerkungen (nicht zuhören, andere nicht ausreden

304

lassen, Nebengespräche, …):|Freitext|

305

| | |

306

|(% colspan="3" %)**Moderation**

307

|Gibt es eine sinnvolle Tagesordnung?|Ja/Nein|

308

|Wird (mindestens am Ende) nach weiteren Tagespunkten gefragt?|Ja/Nein|

309

|Geht der Moderator auf Anregungen und Wünsche der Gruppe ein?|Ja/Nein|

310

|Kommt der Protokollant mit bzw. achtet der Moderator darauf?|Ja/Nein|

311

|Achtet der Moderator auf die Zeit?|+ OOOOO -|

312

|Unterstützt der Moderator die Gruppendiskussion

313

(immer nur ein Thema gleichzeitig, wird jede Diskussion mit einem

314

Ergebnis abgeschlossen, werden Störungen beseitigt,

315

werden komplexe Diskussionen strukturiert, ...)?|Freitext|

316

| | |

317

|(% colspan="3" %)**Verlässlichkeit**

318

|Werden die eigenen Aufgaben erledigt? Werden persönliche Deadlines eingehalten bzw.

319

werden Probleme rechtzeitig kommuniziert?|+ OOOOO -|

320

|Ist die Person in der Sitzung anwesend

321

(bzw. entschuldigt abwesend) und pünktlich?|+ OOOOO -|

322

|Hält sich die Person an Gruppenstandards und Vereinbarungen?|+ OOOOO -|

323

| | |

324

|(% colspan="3" %)**Soziale Kompetenz**

325

|Zeigt die Person Kommunikationsbereitschaft?|+ OOOOO -|

326

|Legt die Person Sachlichkeit an den Tag?|+ OOOOO -|

327

|Ist die Person kritikfähig (konstruktiv Kritik geben und annehmen)?|+ OOOOO -|

328

|Wird versucht, andere Personen / die Gruppe mit einzubeziehen?

329

Oder versucht die Person, Probleme "auf eigene Faust" zu lösen?|+ OOOOO -|

330

| | |

331

|(% colspan="3" %)**Stundenbuchungen**

332

|Wie viele Stunden hat die Person für das Projekt gearbeitet?|Zahl|

333

|Stimmt das Verhältnis von gebuchten Stunden u. geleisteter Arbeit?|+ OOOOO -|

334

|Wie ist die Qualität der Stundenzettel an sich

335

(pünktlich, vollständig, nachvollziehbar, …)?|Freitext|

336

| | |

337

|(% colspan="3" %)**Entwicklung**

338

|Wie hat sich die Person über den Verlauf

339

des Bewertungszeitraums entwickelt?|Freitext|

340

| | |

341

|(% colspan="3" %)**Kurzvortrag**

342

|Thema des Kurzvortrags:| |

343

|Wird der Bezug des Themas zum Projekt hergestellt?|+ OOOOO -|

344

|Wurde die Zeit (~~ 10 Minuten) sinnvoll genutzt?|+ OOOOO -|

345

|Wurde der vermittelte Inhalt verständlich aufbereitet?|+ OOOOO -|

346

|Sind Folien (falls verwendet) gut lesbar (und durchnummeriert)?|+ OOOOO -|

347

|Werden die Inhalte erklärt und nicht nur von Folien abgelesen?|+ OOOOO -|

348

|Ist der Vortrag sinnvoll gegliedert?|+ OOOOO -|

349

|Wird das Thema kritisch betrachtet, Vor- u. Nachteile beleuchtet,...?|+ OOOOO -|

350

|Wird die vorgestellte Theorie auch praktisch angewendet

351

bzw. die Praxis gezeigt?|+ OOOOO -|

352

353

= Bewertungszeiträume =

354

355

**sind jeweils sieben Wochen: Die VL-freie Zeit kann genutzt werden, um "Bonus" zu sammeln.**

356

357

1. Start des Semesters bis Ende erste Dezemberwoche (oder so, dass es 7 Wochen sind)

358

1. bis Ende des Semesters

359

1. 01.04. - Ende der Woche in der der 21.05. ist (oder so, dass es 7 Wochen sind)

360

1. bis Ende des Semesters

Wiki source code of Bewertung