15.01.2006 - 01.02.2006 Anmeldezeitraum für Review
(Anmeldefrist abgelaufen, Termine werden per Email bekanntgegeben.)06.02.2006 Abgabetermin für Designdokument 08./09./22./23. Februar 2006 mögliche Reviewtermine
Ein integraler Aspekt der Softwareentwicklung ist die Arbeit in Teams. Daher wird das Programmierprojekt in Teams à drei bis fünf Studierenden durchgeführt. Die Anmeldung der Teams ist ab jetzt über das Webregsystem möglich. Bei Problemen mit der Anmeldung melden Sie sich bitte bei Martin Girschick. Achtung: Es wird außerdem eine weitere Anmeldung (per Email) zum Review benötigt!
Das Projekt beginnt Anfang Dezember 2005. Die Projektbeschreibung
beinhaltet technische Rahmenbedingungen, eine Use-Case-Übersicht sowie
eine Beschreibung der Release 1 und die weitere Releaseplanung.
Der Quellcode zur Release 1 sowie die dazugehörige Javadoc-Dokumentation steht ebenfalls zur Verfügung. Hinweise, um die Sourcen in Eclipse zu importieren finden Sie im Forum.
Da das enthaltene UML-Diagramm im EclipseUML-Format evt. nicht geöffnet werden kann, stellen wir dieses Diagramm separat im SVG-Format bereit.
Release 1 wird von uns zur Verfügung gestellt und bietet die Basisfunktionalität für einen einfachen Chatclient. Die Weiterentwicklung zur Spieleplattform erfolgt dann von ihnen in zwei Ausbaustufen. Release 2 dient als Zwischenstufe, deren Entwurf sie uns bei Bedarf vorstellen können, um zu sehen, ob sie auf dem richtigen Weg sind. Das dritte Release wird dann im Rahmen eines Reviews von ihnen vorgestellt.
Um am Review teilnehmen zu können, das über den Klausurbonus entscheidet, muss das Team Release 3 vollständig implementieren. Bei einem Reviewtermin, zu dem man sich vorher anmelden muss, stellt das Team die eigene Lösung vor und jedes anwesende Teammitglied beantwortet Fragen zur erarbeiteten Lösung. Teammitglieder, die das Review erfolgreich absolviert haben, erhalten einen Bonus von 0.3 auf die Klausurnote. Dieser Bonus kann jedoch erst bei einer bereits ohne Bonus bestandenen Klausur wirksam werden.
Senden Sie uns in einer Email ihren Terminwunsch. Folgende Termine stehen zur Auswahl:
Geben Sie außerdem an, ob sie den Termin vormittags oder nachmittags haben möchten. Ihre Anmeldung sollte spätestens am 1.2.2006 bei uns eintreffen, damit wir alle Anfragen passend berücksichtigen können.
Wir teilen ihnen dann den per Email den konkreten Termin mit und fordern das "Designdokument" an, welches spätestens zum 6.2.2006 bei uns eintreffen muss. Bitte keine Dokumente ohne Anforderung schicken! Mit der Email erhalten Sie einen Fragebogen, mit dem Sie sich auf das Review vorbereiten können (einige Fragestellungen finden sie bereits weiten unten). Sollten sie bis zum 5.2.2006 noch nichts von uns gehört haben, sprechen sie uns bitte nach der Vorlesung oder in den Sprechstunden am Montag an.
Falls für ihr Team die genannten Termine zu spät liegen, können wir in Ausnahmefällen einen früheren Termin vereinbaren. Spätere Termine sind nicht möglich.
Aus der Projektbeschreibung: "Diese sollte aus erklärenden UML-Diagrammen und Text bestehen. Nachdem man es gelesen hat, sollte man fähig sein, ihr System weiterentwickeln zu können. Man muss also wissen, wo welche Funktionalität wie implementiert ist. Gerade für das ,,wie“ bietet es sich an, die verwendeten Entwurfsmuster auch zur Dokumentation zu verwenden. Das Dokument sollte 2-4 Seiten lang sein und als PDF vorliegen."
Wie bereits an anderer Stelle erwähnt unterstützt EclipseUML nicht die präferierte "Entwurfsmusternotation". Falls sie diese nicht mit anderen Mitteln (Notizelemente, Stereotypen, etc.) nachbilden wollen können sie alternativ andere UML-Werkzeuge oder Zeichenprogramme verwenden. Beispielsweise wäre es auch möglich, die Diagramme mit EclipseUML im SVG-Format zu exportieren und mit Inkscape weiterzubearbeiten. Eine rein textuelle Beschreibung wäre darüber hinaus ebenfalls möglich.
Zu dem Dokument selbst noch ein paar Anmerkungen: Bei dem Leser kann die Kenntnis der Projektbeschreibung vorausgesetzt werden, d.h. ihr Dokument beschreibt, wie sie auf der Basis von Release 1 die Release 3 entworfen (und implementiert) haben. Die Beschränkung auf 2-4 Seiten (exklusive Deckblatt und Screenshots) legt bereits nahe, dass nur die grobe Struktur dargestellt werden soll. Primäres Ziel ist es, die Umsetzung der fehlenden Use-Cases zu dokumentieren und die dabei verwendeten Muster herauszustellen.
Hier noch ein paar typische Fragestellungen, die durch das Dokument beantwortet werden sollten:
Darüber hinaus wäre es schön, wenn das Dokument auch ein bis zwei Screenshots von einem laufenden Spiel zeigt. Diese können auf einer zusätzlichen Seite abgebildet sein und zählen somit nicht zu den vorgegebenen 2-4 Seiten.
Wir haben auf Basis der Projektbeschreibung ein Designdokument für Release 1 erstellt. Dieses stellt exemplarisch verschiedene Diagrammtypen dar und ist daher mit sechs Seiten etwas umfangreicher. Sie müssen in Ihrem Dokument nicht so viel Fließtext produzieren und können das Augenmerk auf Diagramme und deren Beschreibung legen. Auch der Aufbau des Dokuments (orientiert an dem Ablauf des Programms) ist nur als Beispiel zu sehen, sie können gerne eine eigene Struktur verwenden.
Bitte stellen Sie sicher, dass das Deckblatt des Dokuments die Namen aller Teammitglieder inklusive Matrikelnummern enthält, damit wir sie eindeutig zuordnen können. Sie werden mit der Terminbestätigung ein fortlaufende Nummer erhalten, die ebenfalls im Dateinamen und auf jeder Seite des Dokuments enthalten sein soll. Nur so können wir sicherstellen, dass es keine Verwechslungen gibt.
Rechtzeitig zum Projektbeginn werden wir eine Poolraumbetreuung anbieten. Dies ist sowohl für die zu verwendende Software und Werkzeuge sowie Fragen zum Entwurf und zur Entwicklung gedacht. Natürlich können auch außerhalb der Poolzeiten Fragen im Forum gestellt werden.
Eine umfangreiche Informationssammlung zum Thema Software Engineering, inklusiver projektrelevanter Informationen finden Sie in unserem Helpdesk.
