Die jeweils aktuellste Version dieser Seite findet sich unter http://www.techfak.uni-bielefeld.de/~iluetkeb/2006/tdpe/dra.html.

Informationen zur Konzeptbegutachtung

Ziel

Es soll gezeigt werden, dass das Team ein tragfähiges Konzept entwickelt hat und auf einem guten Wege ist, es zu realisieren.

Im Rahmen des TdPEs dient die Konzeptbegutachtung zusätzlich auch dazu, euch einen Eindruck vom Stand einiger "Mitbewerber" zu verschaffen.

Zeitlicher Rahmen

Die Gesamtdauer beträgt 90 Minuten. Es werden pro Termin 4 Teams teilnehmen, pro Team stehen also etwas mehr als 20 Minuten zur Verfügung. Für die Vorstellung selbst schlagen wir folgende zeitliche Aufteilung vor:

  1. 10-15 Minuten: Vorstellung aktueller Stand.
  2. 5-10 Minuten: Diskussion mit dem "Kunden".

Um das klarzustellen: Alle Teams dürfen die vollen 90 Minuten anwesend sein, so daß ihr auch den Stand der anderen Teams seht! Wie bei den früheren Terminen reicht die Anwesenheit von 3-4 Personen pro Team -- es dürfen aber natuerlich auch gerne alle kommen, der Raum sollte groß genug sein.

Inhalt

Wie eingangs erwähnt, liegt der Fokus auf der Einführung, Erläuterung und Begutachtung des Konzepts. Da wir aber auch wissen, dass das Konzept bei Beginn der Implementierung noch einmal ganz besonders beansprucht, und nicht selten auch deutlich modifiziert wird, soll mit der Implementierung schon begonnen worden sein. Aus diesem Grund möchten wir auch erste Eindrücke vom Programm sehen.

Zunächst aber zur Vorstellung des Konzepts bzw. Programmdesigns. Ein gutes Design muss natürlich die Anforderungen erfüllen, d.h. bei der Präsentation soll der Bezug zu den Anwendungsfällen und den technischen Anforderungen gezeigt werden. Ein gutes Design fällt nicht einfach vom Himmel, d.h. uns interessiert auch, welche Überlegungen zu eurem Design geführt haben und warum ihr glaubt, dass das Konzept den Maßstäben guten Software Engineerings genügt. Falls ihr z.B. die GRASP-Prinzipien verwendet habt oder Design Pattern zum Einsatz kommen, sagt es an den entsprechenden Stellen!

Insbesondere aufgrund der knappen Zeit ist auch die Präsentationsform und der Detailgrad wichtig. Klar ist, dass wir keine Diskussion auf Klassendiagrammebene durchführen können. Es geht um Konzepte und dynamisches Verhalten, d.h. Aktivitätsdiagramme, ggfls. ein Domänenmodell, etc. pp. Bemüht euch um eine klare, eingängige Präsentation, dann bleibt auch mehr Zeit für Fragen und Feedback!

Um einen Eindruck vom aktuellen Stand des Programms zu bekommen, bitten wir auch um entsprechende Demonstration. Diese kann auf der Ebene von Screenshots, kleinen Screencasts oder Live-Demos geschehen. Live-Demos sind erfahrungsgemäß sehr zeitaufwendig und sollten daher nur in begründeten Fällen verwendet werden. Mit einem Screencast der erkennen lässt, dass ein reales Programm gestartet wird, ist oftmals der gleiche Effekt erreichbar.

Vorbereitung

Um mehr Zeit für Vorführung und Diskussion zu haben und technische Probleme zu vermeiden, bitten wir euch, alle zur Präsentation verwendeten Dateien bis zum vorangehenden Tag um 17 Uhr per E-Mail an die Tutoren zu schicken. Wir installieren diese dann bereits auf dem Präsentationsrechner.

Anmerkungen

Es gab einige Rückfragen zur "Demo", offensichtlich war der Eindruck entstanden, es müsste bereits ein lauffähiges Programm gezeigt werden. Das kann man machen, es ist aber absolut nicht zwingend! Der Fokus der Veranstaltung liegt auf der Begutachtung des Konzepts, nicht auf der Implementierung. Das wir einen Eindruck vom aktuellen Stand des Programms selbst bekommen möchten dient vor allem dazu, praktisch zu belegen, dass das Konzept auch realisierbar ist. Mit anderen Worten: Es sollen schöne Worthülsen ohne was dahinter vermieden werden ;-) Daraus ergibt sich natürlich, dass auch schöne GUIs ohne was dahinter zwar einen Eindruck der Oberfläche vermitteln können, aber eben auch nicht viel mehr. Vertut keine Zeit mit unnötigem Blendwerk, das ist kein Prüfungstermin sondern eine Zeit für konstruktives Feedback!