Programmierpraktikum HT07

Leitung: Dipl. Inform. Daniel Volk

 

 

 

Der Projektrahmen

 

 

 

 

Der grobgranulare Ablauf

 

Das Praktikum wird in fünf aufeinanderfolgenden Phasen durchgeführt, wobei für jede Phase ein maximales Zeitfenster vorgesehen ist. Den Beginn stellt die Einführungsveranstaltung dar, das Ende des Praktikums wird durch die Abschlusspräsentation markiert. Zusätzlich finden wöchentliche Zwischenstands- bzw. Phasenendpräsentationen statt. Im Folgenden ist ein kurzer Überblick über den Ablauf gegeben:

In der dritten Phase wird nun das vorliegende, domänenspezifische Analysemodell in eine technische Sicht übertragen. Hierbei entsteht ein auf dem jeweiligen Framework basierendes Designmodell.

Die vierte Phase des Entwicklungsprozess dient der Umsetzung des zuvor erstellten Designmodells. Sie durchläuft mehrere Iterationen, in welchen die Funtionalität in der Reihenfolge der festgelegten Priorisierung implementiert wird.

 

Die fünfte und letzte Phase hat das Einpflegen von Fehlerkorrekturen und Änderungswünschen durch den Auftraggeber zum Zweck. Je nach Art der Änderungen kann die Wartungsphase ein erneutes Durchlaufen von Analyse und Design notwendig machen.

  • Die Analysephase (2 Wochen) [Details]

    Die erste Phase im Entwicklungsprozess dient dem Verstehen und Durchdringen der Problemstellung und erfolgt in enger Kooperation mit dem Auftraggeber (Tutor). Ihr Ziel ist die Erstellung eines stabilen Analysemodells.

  • Die Einarbeitungsphase (2 Wochen) [Details]

    Die zweite Phase erlaubt den Teilnehmern, die zur Verfügung stehenden Frameworks und Entwicklungswerkzeuge kennenzulernen. Hierzu wird der Entwicklungsprozess in vereinfachter Form am Beispiel eines Tutorials durchgespielt.

  • Die Designphase (1 Woche) [Details]
  • Die Implementierungsphase (3 Wochen) [Details]
  • Die Wartungsphase (2 Wochen) [Details]

 

 

 

Ergebnispräsentation und Dokumentation

 

Wie in den Erläuterungen zum personellen Rahmen bereits dargestellt, erfolgt die Vergabe der Scheine letztendlich auf Basis des Gesamteindrucks des kompletten Projektverlaufs (und nicht nur der Abschlusspräsentation). Demzufolge muss der Projektverlauf auch in mehreren Formen dokumentiert bzw. präsentiert werden:

  • Ständige Transparenz

    Der Praktikumsleiter und die Betreuer werden den Projektfortschritt kontinuierlich beobachten, um bei Fehlentwicklungen so früh wie möglich korrigierend eingreifen zu können. Bei den Ergebnispräsentationen am Ende einer Phase ist es dafür jedoch meist schon zu spät. Aus diesem Grund muß der Projektfortschritt laufend in Form der aktuellen Fassungen der geforderten Dokumente und Programme auf den gruppeneigenen Web-Seiten dokumentiert werden. Dies geschieht im folgenden Modus:

    Das Team beschreibt für jeweilige Phase die geplante Herangehensweise (das Wie) an die Problemstellung sowie die zugehörige Aufgabenteilung (das Wer). Sollte sich im Laufe der Abarbeitung der Phase hieran etwas ändern, ist dies natürlich in der Dokumentation nachzuziehen.

    Die MSK-Liste spiegelt die priorisierten Einzelaufgaben (das Was) wider. Hat die Implementierung begonnen, ist aus der Liste zusätzlich der aktuelle Fortschritt ersichtlich (in der Granularität "nicht bearbeitet"/ "in Arbeit"/ "fertig" bzw. "rot"/ "gelb"/ "grün"). Das ChangeLog wiederum stellt die Änderungshistorie (das Wann) dar, welche die bisherigen Arbeitsschritte listet (in der Form: "Wochentag", "Datum", "Uhrzeit", "Was hat sich geändert?"). Dabei soll das ChangeLog nur immer verlängert werden - es ist weder notwendig noch sinnvoll, Einträge zu löschen!

    Weiterhin sind grundsätzlich alle Artefakte der aktuellen Phase auf Stand zu halten. Dies bedeutet allerdings nicht, dass jede auch noch so unmerkliche Änderung nachzuziehen ist! Tun Sie dies mit einem vernünftigen Augenmaß aber mindestens einmal pro Woche - bedenken Sie hierbei auch, dass ihre Projektseite für den Praktikumsleiter die Hauptinformationsquelle darstellt!

    • Vorgehensweise und Aufgabenteilung (ständig aktuell)
    • Muss-Soll-Kann-Liste und ChangeLog (ständig aktuell)
    • Aktueller Stand der Phasenprodukte (wesentliche Änderungen)

     

  • Zwischenergebnisse

    Zusätzlich zur transparenten Darstellung des Projekts auf den gruppeneigenen Web-Seiten finden wöchentlich Zwischenstands- bzw. Phasenendpräsentationen statt. Bei diesen soll jedes Teammitglied eingebunden sein und den eigenen Beitrag kurz vorstellen und ggfs. Fragen dazu kompetent beantworten. Sourcecode soll, mit Ausnahme von Phase 2, nur auf Anfrage gezeigt werden. Die Dauer einer Präsentation (mit Ausnahme der Abschlusspräsentation) beträgt 15 Minuten, danach wird der Praktikumsleiter noch Fragen stellen und eigene Anmerkungen machen, sodass mit insgesamt etwa 30-45 Minuten pro Termin gerechnet werden kann.

    Bei den einzelnen Terminen geht es nicht darum, eine PowerPoint-Präsentation zu zeigen. Vielmehr soll anhand der Web-Seiten die Arbeit der letzten Woche dargestellt werden. Weitere Medien (wie Bilder o.Ä.) dürfen gerne benutzt werden, allerdings ist das erfahrungsgemäß nicht notwendig. Generiert die jeweilige Phase (2,4,5) ein ausführbares Programm, so muss dieses gezeigt werden. Dabei empfiehlt es sich, die identifizierten Szenarien direkt am Programm nachzustellen, damit ein anschaulicher Eindruck vermittelt wird. Weiterhin werden die in der Präsentation angesprochenen Punkte mitprotokolliert und auf den Web-Seiten veröffentlicht.

    Die Teilnahme an allen Präsentation (wöchentlich und am Ende) ist für jedes Teammitglied verbindlich. Außnahmen sind mit dem Praktikumsleiter vorher(!) abzusprechen - dies ist insbesondere auch bei der Urlaubsplanung zu bedenken! Bei Nichtbeachtung erfolgt u.U. ein Ausschluss aus dem Praktikum.

    Alle Präsentationen sind von den Teams sorgfältig vorzubereiten. Insbesondere ist sicherzustellen, dass auf dem Vorführrechner im Electronic Classroom alles vor Beginn der Präsentation ablaufbereit vorliegt (ausführbares Programm!). Kennung und Passwort für diesen Rechner werden vom Praktikumsleiter zum Beginn des Praktikums mitgeteilt.

    Während oder nach den Zwischenstands- bzw. Phasenendpräsentationen können noch Verbesserung eingefordert werden, wenn die Ergebnisse nicht in der gewünschten Ausführlichkeit vorhanden sind. Da es hierbei immer wieder zu Missverständnissen bezüglich der Anmerkungen gibt, sei hiermit noch einmal auf Folgendes hingewiesen: Kritik wird meist nur an einigen Beispielen (fehlende Dokumentation an einem UML-Diagramm, fehlende Javadoc-Beschreibung der Klasse XYZ etc.) geäußert. Verstehen Sie dieses jedoch nicht nur als Aufforderung, das angesprochene Objekt zu ändern, sondern als Anweisung gemäß den am Beispiel gestellten Anforderungen die gesamte Dokumentation der Phase zu überarbeiten!

    Beachten Sie bitte auch, dass 24 Stunden vor jeder Präsentation der zu präsentierende Stand eingestellt sein muss (um dem Praktikumsleiter die Durchsicht zu ermöglichen). Ist dies nicht der Fall (und weicht der präsentierte Stand zu sehr ab) dann behält es sich der Praktikumsleiter vor, die Präsentation zu verschieben.

    Wurde eine Phase erfolgreich abgeschlossen, so wird ihr aktueller Stand (mit Ausnahme noch ausstehender Änderungsforderungen) eingefroren. Beim Übergang in die nächste Phase müssen auch nicht sämtliche Artefakte kopiert werden - lediglich die, auf Basis derer Änderungen und Anpassungen vorgenommen werden.

  • Endergebnisse

    Das Programmierpraktikum endet mit einer ungefähr einstündigen (halten Sie sich bitte an die Zeitvorgabe!) Abschlusspräsentation. Folgender Ablauf ist dafür vorgesehen:

    Zuerst präsentiert das Team gemeinsam in einer 10-15 minütigen Demonstration das erstellte Programm. Hierbei soll nicht die gesamte Funktionalität gezeigt werden, sondern nur eine kleine Auswahl. Eine Art Rollenspiel, in der die Teammitglieder verschiedene Szenarien nachspielen, hat sich hierbei in den vergangenen Jahren als ideal erwiesen.

    Der Teamchef gibt dann anhand der erstellten Dokumente einen Überblick über Entwurf und Implementierung, insbesondere über später notwendige Änderungen (5-10 Minuten). Im Anschluss erläutern die einzelnen Teammitglieder (jeder etwa 5 Minuten lang) ihren Entwicklungsbeitrag, indem sie diesen in den Gesamtentwurf einordnen, interessante Stellen und Probleme herausgreifen und erläutern sowie ggf. Fragen zu Entwurf und Programmtext beantworten.

    In einer abschließenden Manöverkritik werden Erfahrungen ausgetauscht (vor allem konstruktive Verbesserungsvorschläge sind willkommen!).

 

 

 

Zur Termintreue

 

Auf Termintreue wird besonderer Wert gelegt. Bei Nichteinhaltung eines Termins setzt der Praktikumsleiter dem Team eine Nachfrist von 2 - 3 Tagen. Teams, die auch am Ende der Nachfrist kein zufriedenstellendes Phasenergebnis vorgelegt haben oder die mehr als zwei Nachfristen benötigen, scheiden aus dem Praktikum ohne Schein aus! Vor dem Ausscheiden oder bei Terminüberschreitungen aus nicht von den Teilnehmern zu verantwortenden Gründen findet eine Konsultation zwischen Team, Betreuer und Praktikumsleiter statt.

Ein Unterschreiten des Zeitplans ist dagegen erlaubt, ja sogar erwünscht! Teams, die vorzeitig fertig werden, können sich früher auf die DVP-Vorbereitung konzentrieren.

 

 

 

Allgemeine Hinweise

 

Die Folgenden Hinweise sind Unwegsamkeiten aus den letzten Durchläufen des Programmierpraktikums, welche unnötigerweise den reibungslosen Ablauf des Praktikums störten, aber andererseits relativ einfach abzustellen sind. Entsprechend sei hier um Kenntnisnahme und Beachtung gebeten.

  • Häufig sind Use-Case-Diagramme nicht durch einen zusätzlichen Text beschrieben. Dies erschwert unnötig das Verständnis - jedes Diagramm, egal in welcher Phase, ist mit einer aussagekräftigen Beschreibung versehen werden.
  • Zwischen Use-Case-Diagrammen, Szenarien und CRC-Karten bestehen enge Konsistenzen: Jedes Szenario muss auch als Anwendungsfall in einem Use-Case- Diagramm vorkommen, und die Aktoren sind selbstverständlich die gleichen. Genauso muss jeder einzelne Schritt in einem Szenario in der entsprechenden CRC-Karte reflektiert sein. Als Hilfestellung kann Ihnen auch die erste Übung (v.a. auch das Beiblatt!) der Vorlesung zur Objektorientierten Programmierung dienen.
  • Bei den meisten Gruppen ist die Gesamtfunktionalität nicht in einem Use-Case-Diagramm dargestellt, sondern in mehreren, meist drei oder vier Diagrammen. Eine Gruppierung kann hier anhand zugehöriger Anwendungsfälle, z.B. der Benutzerverwaltung, o.Ä. erfolgen. Ein Übersichts-Use-Case-Diagramm zeigt dabei genau diese Gruppierungen auf und ist zur Orientierung sehr hilfreich. Dieses Vorgehen ist sehr zu empfehlen und sollte daher von allen Gruppen umgesetzt werden.
  • Immer wieder kommt es zu sprachlichen Unsauberkeiten auf den Web-Seiten und in den Handbüchern. Bis zu einem gewissen Grad ist das verständlich und unvermeidlich. Beginnt allerdings die Lesbarkeit darunter zu leiden, ist dies nicht mehr akzeptabel - selbige Artefakte werden dann entsprechend in den Abnahmen zurückgewiesen!
  • Für die Darstellung von Quelltext gilt folgende Regelung: ab fünf Zeilen wird das Ganze mit Java2HTML dargestellt, damit die Übersichtlichkeit gewahrt bleibt. Die Verwendung von Screenshots zur Darstellung von Quelltext ist inakzeptabel!

 

 

zurück