Programmierprojekt HT13 (Modul 1136)

Leitung: 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 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 Wiki-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 Wiki-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 45 minütigen (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!
  • Ein Entwicklungsartefakt einer Phase ist nicht eigenständig für sich zu sehen. Es bestehen sowohl Beziehungen zwischen den Artefakten einer Phase, als auch zwischen den Artefakten der verschiedenen Phasen. Es insbesondere darauf zu achten, dass die Übergänge von einer Phase zur nächsten und die damit verbundenen Änderungen/Weiterentwicklungen an den Phasenartefakten deutlich werden. Z. b. ist es entscheidend dass genau beschrieben wird, wie sich aus dem Klassendiagramm der Analysephase das Klassendiagramm in der Entwurfsphase entwickelt hat.
  • 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 Wiki-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!

 

zurück