Programmierprojekt HT09 (Modul 1136)

Leitung: Sonja Maier, M.Sc., Dipl.-Wirt.-Inf. Michael Kretzschmar, Peter Lachenmaier, M.Sc.

 

 

Der Projektrahmen

 

 

 

Der grobgranulare Ablauf

 

Das Projekt 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 Projektes wird durch die Abschlusspräsentation markiert. Zusätzlich finden wöchentliche Phasenendpräsentationen statt. Im Folgenden ist ein kurzer Überblick über den Ablauf gegeben:

In der dritten Phase wird nun das vorliegende, domänenspezifische Analysemodell zunächst verfeinert und dann in eine technische Sicht übertragen. Hierbei entsteht ein auf dem SalesPoint-Framework basierendes Designmodell.

Die vierte Phase des Entwicklungsprozesses 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, Optimierungen sowie Änderungswünschen von Seiten des Auftraggebers 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 (1 Woche) [Details]

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

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

 

 

Die Projekt-Homepage

 

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). Zudem werden der jeweilige Praktikumsleiter und Betreuer 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 müssen der Projektfortschritt und alle geforderten Entwicklungsartefakte auf den gruppeneigenen Web-Seiten dokumentiert werden.

Dies geschieht im folgenden Modus:

 

  • Projektfortschritt (ständig aktuell)

    Der Projektfortschritt dient dazu, den Stand des jeweiligen Projektes in einer übersichtlichen und aktuellen Form darzustellen. Die Ausprägungsform desselben ist (bis auf den Implementierungsstatus) unabhängig von der jeweiligen Phase.

    • Vorgehen und Aufgabenverteilung

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

    • ChangeLog

      Um Praktikumsleiter und Betreuer zu ermöglichen, Änderungen an den Projektseiten schnell und effizient zu erkennen (ohne jedesmal die ganze Homepage durchsehen zu müssen), ist eine Änderungshistorie zu führen. Das ChangeLog (das Wann) stellt die bisherigen Arbeitsschritte in folgender Form dar: "Datum", "Uhrzeit", "Was hat sich geändert?". Hierbei soll das ChangeLog nur immer verlängert werden - es ist weder notwendig noch sinnvoll, Einträge zu löschen!

    • Präsentationsprotokolle

      Zu den Phasenpräsentationen (weitere Info hierzu folgt im folgenden Abschnitt) sind Besprechungsprotokolle anzufertigen, welche u.a. die noch eingeforderten Änderungswünsche von Seiten der Praktikumsleitung widerspiegeln. Selbige Protokolle sind direkt im Anschluss an die Präsentationen aufzubereiten und auf die Projekt-Homepage zu stellen!

    • Implementierungsstatus (nur Implementierung und Wartung)

      Im Gegensatz zur Analyse- und Designphase, deren Artefakte alle auf den Projektseiten dargestellt werden, spiegelt sich der Fortschritt der Implementierungs- und Wartungsphase primär in der Codierung von Funktionalität wider. Da selbige Änderungen auf dem direktem Wege nur auf sehr umständliche Weise (per Inspektion des Versionsstandes) nachvollziehbar sind, ist hier zusätzlich noch ein Implementierungsstatus zu führen.

      Der Implementierungsstatus ist letztlich nichts anderes als eine Listung der Produktfunktionen/ Produktdaten mit der zusätzlichen Bewertung "nicht bearbeitet"/ "in Arbeit"/ "fertig" bzw. "rot"/ "gelb"/ "grün".

  • Phasenartefakte (wesentliche Änderungen)

    Neben dem reinen Projektfortschritt sind natürlich auch die geforderten Entwicklungsartefakte 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!

    Die Zusammensetzung dieses Bereichs ergibt sich (wie der Name schon vermuten lässt) aus der jeweiligen Projektphase und ist im Anteil [Projektphasen] näher beschrieben.

 

 

Die Projektpräsentationen

 

Neben der schriftlichen Dokumentation der Entwicklungsprojekte auf den Projektseiten finden sowohl wöchentliche Phasenpräsentationen als auch eine Abschlusspräsentation am Ende des Projektes statt. Deren Form ist im Folgenden beschrieben:

  • Phasenpräsentationen

    Die Phasenpräsentationen dienen zum einen der mündlichen Darstellung der erbrachten Leistungen gegenüber der Praktikumsleitung und bieten zum anderen Gelegenheit zur direkten Klärung noch offener Fragestellungen bzw. zur Abstimmung im Hinblick auf den weiteren Projektverlauf. Bei diesen muss 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 Phasenprä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 vorangegangenen Woche im Zusammenhang 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 (siehe auch vorherigen Abschnitt).

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

    Ebenso sind alle Präsentationen von den Teams sorgfältig vorzubereiten. Insbesondere ist sicherzustellen, dass auf dem Vorführrechner alles vor Beginn der Präsentation ablaufbereit vorliegt (ausführbares Programm!).

    Während oder nach den Präsentationen können noch Verbesserung eingefordert werden, wenn die Ergebnisse nicht den quantitativen oder qualitativen Anforderungen genügen. Da es hierbei immer wieder zu Missverständnissen bezüglich der Anmerkungen kommt, 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 Fragment zu ändern, sondern als Anweisung gemäß den am Beispiel gestellten Anforderungen alle äquivalenten Artefakte zu überarbeiten!

    Beachten Sie bitte auch, dass der zu präsentierende Stand 24 Stunden vor jeder Präsentation eingestellt sein muss (um dem jeweiligen 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 die Praktikumsleitung 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.

  • Abschlusspräsentation

    Das Programmierprojekt endet mit einer ungefähr einstündigen (halten Sie sich bitte an die Zeitvorgabe!) Abschlusspräsentation. Hierfür ist folgender Ablauf 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 repräsentative 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 Artefakte einen Überblick über die Analyse und den jeweiligen Grobentwurf, 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 der Implementierung herausgreifen und erläutern sowie ggf. Fragen hierzu 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 verantwortliche 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 Projekt 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. Bei Teams, die vorzeitig alle Phasen zufriedenstellend durchlaufen haben, besteht durchaus auch die Möglichkeit, die Projektdauer entsprechend zu verkürzen!

 

 

Sonstige Hinweise

 

Die Folgenden Hinweise beschreiben Erfahrungswerte 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 jegliche Form von UML-Diagrammen 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 zu versehen!
  • Zwischen unterschiedlichen Entwicklungsartefakten bestehen Konsistenzen, die entsprechend zu beachten sind. Ein Beispiel aus dem Bereich der Analyse (Use-Case-Diagrammen, Szenarien und CRC-Karten): 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.
  • 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