Das Organisieren von Softwaretechnik-Projekten ist für neue Dozenten stets eine Herausforderung: Man muss Kunden finden, Projekte definieren, Tutoren schulen, Anforderungen definieren, Terminpläne machen, Regeln aufstellen. . . und zum Schluss das Projektergebnis bewerten. Eine ungenügende Planung und Umsetzung kann schnell das gesamte Projekt gefährden. Daher empfiehlt es sich, für die häufigsten Fragen und Probleme Lösungen explizit aufzuschreiben. Dies können zunächst immer wiederkehrende Dinge sein, wie die Frage, wann welche Vorlesungsinhalte benötigt werden, oder wie die Begutachtung von Praktikums-Dokumenten organisiert werden muss. Andere Fragen mögen zunächst banal erscheinen, machen aber schnell deutlich, warum es sich empfiehlt, Wissen explizit zu dokumentieren: Ich möchte eine Grillfeier für 160 Teilnehmer organisieren. Wieviele Getränke und Speisen muss ich pro Person ansetzen? Woher bekomme ich Grills, Würstchen, Besteck, Salate? Ich möchte eine „Messe“ organisieren, auf dem meine Praktikums-Teilnehmer ihre Projekte vorstellen können. Was brauche ich, und woher bekomme ich es? Wann muss ich wen verständigen? Zusammenspiel mit anderen Mustern. Voraussetzungen in Form von anderen Mustern sowie Konflikte mit anderen Mustern sollten ebenfalls dokumentiert werden.
Um das Wissen über Softwaretechnik-Lehre zu verwalten, haben wir ein Wiki eingerichtet, um das Wissen über Softwaretechnik-Lehre zu organisieren und zu dokumentieren – und zwar in einer Form, die sowohl lokales als auch standortübergreifendes Wissen dokumentieren kann. Die Artikel nutzen das Format der Muster – analog zu Entwurfsmustern als Lösungsschablonen für immer wiederkehrende Probleme: Name. Jedes Muster hat einen Namen, damit es unter diesem Namen einfach referenziert und nachgeschlagen werden kann.
Ziel. Jedes Muster löst ein bestimmtes Problem, das hier allgemein charakterisiert werden kann. Motivation. Das Problem sollte relevant sein – also häufig oder in verschiedenen Ausprägungen immer und immer wieder auftreten.
Anwendung. Dies ist eine Beschreibung, wie das Muster umgesetzt wird – sowohl in abstrakter (standortunabhängiger) Form als auch illustriert an konkreten Beispielen. Die Anwendung sollte zeigen, wie das Muster das Problem löst. 2
Auf www.sewiki.de haben wir unser internes (lokales) Wissen in Form von Mustern zu organisieren. Wir möchten damit unser Wissen der Gemeinschaft bereitstellen, es aber auch jedem Interessierten ermöglichen, sie mit eigenen Erfahrungen weiter zu verfeinern, oder eigene Muster hinzuzufügen. Noch spiegeln diese Seiten unsere eigenen „Kochrezepte“ wieder, die zudem stark lokal geprägt sind. Unsere Vision ist aber, dass wir weitere solche Muster sammeln und weiter ausbauen können – und so das Wissen über erfolgreiche Lösungen der Softwaretechnik-Lehre lebendig halten können. In diesem Sinne rufen wir alle auf, die sich mit der Lehre der Softwaretechnik beschäftigen, ihre eigenen Erfolgsrezepte beizusteuern unter
http://www.sewiki.de/ Danksagung. Die Idee, ein Wiki zu nutzen, um Konzepte der Softwaretechnik-Lehre auszutauschen, entstand 2008 in Diskussionen mit Kurt Schneider (Hannover), dem wir zu tiefem Dank verpflichtet sind. Die Muster der Saarbrücker Veranstaltungen gehen auf jahrelange Feinarbeit mit zahlreichen Tutoren zurück, für deren Anregungen wir ebenfalls sehr dankbar sind.
Ziel ist es zum einen, die Zeit zu minimieren, die benötigt wird um sich domänenspezifisches Wissen bezüglich der Aufgabe anzueignen. Zum anderen jedoch, und viel wichtiger, zeigen sich die Studierenden bei Verwendung eines Spiels als Implementierungsziel besonders motiviert. Der Sinn der Aufgabenstellung wird kaum kritisiert.
Insbesondere in einem !Vollzeit-Praktikum, das innerhalb recht kurzer Zeit stattfindet, ist es wichtig, dass nicht zu viel Zeit aufgewendet werden muss, um die Aufgabenstellung und die sich daraus ergebenden Konsequenzen zu verstehen. [. . . ] Mit der Verwendung von Spielen, insbesondere von Brettspielen, als Implementierungsziel wurde die Erfahrung gemacht, dass die Studierenden innerhalb von einem bis maximal zwei Tagen die Aufgabe klar verstanden haben. Ein weiterer Vorteil von Spielen ist die gesteigerte Motivation und Lernbereitschaft der Studierenden. Die initiale Hürde, die genommen werden muss, um sich qualifiziert mit der Aufgabenstellung auseinanderzusetzen und darüber diskutieren zu können, ist relativ niedrig. Unterschiede in der Vorbildung der Studierenden kommen wenig zum tragen. Selten werden einzelne Gruppen-Mitglieder abgehängt und außen vorgelassen.
Zu guter Letzt sind massenweise geeignete und interessante Spiele, samt deren Anleitungen, verfügbar. Auf diesen Fundus zurückzugreifen spart das komplette Konzipieren einer Aufgabenstellung und erlaubt es dem Veranstalter, sich auf die Umsetzung zu konzentrieren.
(a) (b) (c) (d) (e) (f) (g) (h) (i)
Die Regeln des Spiels müssen einfach zu verstehen, also nicht zu komplex sein.
Das Spiel sollte Multiplayer-fähig sein. Somit können die Teilnehmer in einem finalen !Turnier gegeneinander antreten.
Kann das Spiel als !Client/Server Architektur umgesetzt werden, kann der Veranstalter einen zentralen Spielserver stellen, der von allen Teilnehmern während der Veranstaltungsdauer genutzt werden kann, um gegeneinander anzutreten und zu testen.
Es sollte relativ einfach möglich sein, für das gewählte Spiel eine einfache künstliche Intelligenz zu schreiben. Es sollte möglich sein ein vernünftiges (graphisches) User-Interface zu implementieren, das die Teilnehmer nutzen können, um ihre Implementierung zu testen und zu debuggen.
Ist das Spiel geeignet um von Menschen gespielt zu werden, kann der Mensch gegen seine eigene KI antreten, was zusätzlich motiviert. [. . . ] Die Spielregeln sollten genug Raum für eine kreative Umsetzung geben. Auch die Implementierung einer Strategie in der KI sollte genug Möglichkeiten der Differenzierung zwischen den Teilnehmern bieten. Die Implementierung des Spiels sollte einige algorithmische Möglichkeiten bieten.
Soll die Aufgabenstellung modifiziert werden (!Modifikation der Aufgabenstellung), sollten die Regeln des Spiels dies erlauben.
2. Es sollten keine Implementierungen des Spiels frei verfügbar sein, die die Studierenden einfach kopieren können. 3. Ist die Spielidee rechtlich geschützt, sollten die Rechteinhaber kontaktiert werden, um die Bedingungen der Benutzung zu klären. [. . . ] 4. Erstellen der Aufgabenstellung Ist eine spätere !Modifikation der Aufgabenstellung vorgesehen, so kann diese Erweiterte
Aufgabenstellung bereits mit erdacht werden. 5. Implementieren der vom Veranstalter vorgegebenen Teile [. . . ] 7. Anfertigen einer Referenz-Implementierung der von den Studierenden zu implementierenden Teile
Ein Spiel als Aufgabenstellung eignet sich sehr gut für ein abschließendes !Turnier.
. . .