Programmierprojekt HT12 (Modul 1136)

Leitung: Peter Lachenmaier, M.Sc.

Die Projektphasen

[Analyse] [Einarbeitung] [Design] [Implementierung] [Wartung]

Die Analysephase

Ziel:

Ziel dieser Phase ist es, das gestellte Thema vollständig zu durchdringen, seine Möglichkeiten auszuloten sowie die Anforderungen des Auftraggebers zu erkennen und letztendlich aus diesen Informationen ein stabiles Analysemodell zu erstellen. Wichtig ist auch zu beachten, dass die Arbeit und die Ergebnisse in dieser Phase domänenspezifisch und damit unabhängig von der Technik (Framework) sind.

Vorgehensweise:

Zum einen ist die Reihenfolge der Arbeitsschritte, mit denen Sie sich der Aufgabe nähern nicht ganz unerheblich, da jeder Schritt auf den Ergebnissen und dem Wissen des vorangegangenen Schritte aufbaut, und sollte deswegen versucht werden einzuhalten. Zum anderen ergeben sich aber sicherlich auch Rückgriffe und Iterationen in der Abarbeitung, da zu Beginn natürlicherweise nicht das notwendige Wissen in vollständiger Form zur Verfügung steht.

Die nun folgenden Ausführungen orientierten sich im Ergebnis grobgranular an (maßgeblichen) Anteilen eines Pflichtenhefts und sind auch als solches in kummulierender Form dann im Analyse-Abschnitt der jeweiligen Projektseite umzusetzen.

Den Anfangspunkt der Analyse bildet verständlicherweise die jeweilige Aufgabenstellung, welche zunächst im Gruppenrahmen diskutiert werden sollte. Hierbei werden sicherlich Lücken in der Themenstellung und Fragen zur gewünschten Funktionalität auftreten, welche zusammen mit dem Auftraggeber geklärt werden müssen. Im Ergebnis entsteht hierbei eine detaillierte bzw. erweiterte Aufgabenstellung (in textueller Form).
Aus dieser wird dann eine Use-Case Liste extrahiert. Diese Anwendungsfälle sollen durch kurze Teilsätze (z. B.: "Kunde anlegen", "Photoauftrag im Internet annehmen") beschrieben werden. Weitere Anwendungsfälle finden sich beim Spielen von Szenarien und deren Protokollierung (Szenarien sollen hierbei konkrete, vorstellbare Abläufe innerhalb des Programms widerspiegeln, also z.B. "Nicht registrierter Kunde sendet Photoauftrag per Post ein"). Die Liste dieser Anwendungsfälle soll alle möglichen, durch die Aufgabe implizierten, Funktionalitäten des Programms wiedergeben. Eine Priorisierung der Anwendungsfälle hilft, Schwerpunkte für die spätere Implementierung zu setzen. Diese ersten zwei Schritte sind entscheidend für den späteren Funktionsumfang des Programms, weshalb die Ergebnisse regelmäßig mit dem Auftraggeber abgestimmt werden sollten.
Aus der Use-Case Liste sollen nun Use-Case Diagramme erstellt werden. Dazu werden die einzelnen Anwendungsfälle zu Funktionsgruppen zusammengefasst. Die Diagramme sind zur leichteren Verständlichkeit wo immer nötig mit Kommentaren und Beschreibungen zu versehen. Desweiteren werden Beschreibungen zu den Anwendungsfällen und Ablaufbeschreibungen verfasst.
Die gefundenen Anwendungsfälle und durchgespielten Szenarien können zusätzlich als Leitfaden für zu erstellende Skizzen der späteren Benutzeroberflächen (sowie einer zugehörigen Gestaltungsrichtlinie) dienen, welche in ihrer Gesamtheit gleichzeitig auch die Rolle eines Storyboards für die zu erstellende Anwendung einnehmen können.
Iterieren Sie nun so lange über die vorangegangenen zwei (evtl. auch drei) Schritte, bis sich ein stabiles Analysemodell herauskristallisiert (sie also merken, dass zunächst erstmal keine neue Funktionalität mehr hinzu kommt). Insgesamt gesehen, sollte sich für den Auftraggeber ein attraktives Produkt mit abgerundeter Funktionalität abzeichnen. Das ein oder andere geplante "Highlight" zeigt dem Kunden zusätzlich, dass die Entwickler seine Interessen im Auge haben - bevor man jedoch beim Auftraggeber mit konkreten Vorschlägen Erwartungen weckt, sollte man zumindest prinzipiell deren Umsetzbarkeit durchdacht haben. Legen Sie diesen Produktvorschlag nun nochmals dem Kunden vor und klären Sie mit diesem erneut offene Fragestellungen ab.
Im Anschluss werden die bisherigen Ergebnisse aus im Hinblick auf die spätere Umsetzung weiter verfeinert. Zuerst wird hierzu ein Paketdiagramm erstellt. Strukturierungsmöglichkeiten finden sich zum Beispiel durch Zuordnung der Anwendungsfälle zu ihren realen Benutzern.
Für die Erstellung der Klassendiagramme kann wieder auf die erweiterte Aufgabenstellung zurückgegriffen werden. In dieser Phase sollen die Klassendiagramme nur grobgranular gestaltet werden, d.h. die Angabe von Typen und Sichtbarkeiten ist sehr implementierungsnah und kommt deshalb erst in der Designphase zum Einsatz.
Weiterhin erstellen Sie ein ein vorläufiges Benutzerhandbuch, welches den anskizzierten Funktionsumfang textuell aus Anwendersicht beschreibt. Im Normalfall spiegeln sich die Anwendungsfallgruppen in der Gliederung wider; die angefertigten GUI-Skizzen können der Verbildlichung dienen.
Schlussendlich ist noch der erste Abschnitt (die Systemtests) des Testhandbuchs zu erstellen, welcher die bis dato ersichtlichen Fehlerquellen (siehe Use-Cases und Szenarien) im Programmablauf sowie die erhobenen, funktionalen Anforderungen abdeckt.

Phasenartefakte:

Zwischenpräsentation

Zielbestimmung:
- Aufgabenstellung
- Erweiterte Aufgabenstellung
- Use-Case Liste
Produktübersicht:
- Use-Case Diagramme
- Beschreibung von Anwendungsfällen
Benutzeroberfläche:
- Gestaltungsrichtlinie
- GUI-Skizzen (Vorabversion)

Endpräsentation

Produktübersicht
- Use-Case Diagramme
- Beschreibung zu Anwendungsfällen
- Paketdiagramme
- Klassendiagramme
- Benutzerhandbuch
- Testhandbuch
Benutzeroberfläche:
- GUI-Skizzen

Hinweise:

Binden Sie in den oben genannten Schritten auf jeden Fall ihren Auftraggeber ein! Vor allem die Verfeinerung der Aufgabenstellung und die Abstimmung der Anwendungsfälle können Sie letzlich gar nicht sinnvoll alleine erledigen!
Die Analysephase ist domänenspezifisch, d.h. der "Entwicklungsprozess spricht" zu diesem Zeitpunkt die Sprache des Auftraggebers. Technische Denkstrukturen und Termini sind demzufolge nicht zulässig - bedenken sie dies bitte (z.B. bei der Identifikation und Benennung von Klassen).
Verwenden Sie für die von Ihnen entwickelten Klassen, Methoden und alle anderen Programmbezeichner durchgängig entweder englische oder deutsche Bezeichnungen. Halten Sie Ihre Webseite und die darin befindliche Dokumentation allerdings ausschließlich auf deutsch!
Achten Sie darauf, eine realistische, d.h. erfüllbare Use-Case Liste zu erstellen. Lassen Sie sich dabei von groben Aufwandsabschätzungen leiten. Bieten Sie umgekehrt dem Auftraggeber auch Funktionen an, die Sie leicht implementieren können.

Die Einarbeitungsphase

Ziel:

Ihnen steht mit dem Framework SalesPoint bereits eine "Halbfertiglösung" zur Verfügung, die Sie "nur noch" zu einer vollständigen Lösung ausbauen müssen - sobald die eigentliche Aufgabenstellung erarbeitet ist. Leider haben auch hier die Götter den Schweiß vor den Erfolg gesetzt: Bevor man das Framework nutzen kann, muss man es verstehen. Dementsprechend ist es Ziel der Einarbeitungsphase, Ihnen die Gelegenheit zu geben, sich sowohl mit dem SalesPoint-Framework, als auch mit den Entwicklungswerkzeugen vertraut zu machen.

Vorgehensweise:

Um Ihnen den Einstieg in die Materie zu erleichtern bzw. um Ihnen einen Überblick über die genutzten Entwicklungswerkzeuge zu geben, findet am Anfang der Einarbeitungsphase eine Workshop für das SalesPoint-Framework statt. Die genauen Örtlichkeit und der Termin werden rechtzeitig bekanntgegeben - die Teilnahme an der Veranstaltung ist Pflicht!
Nach dem Workshop sollten Sie sich zunächst intensiv mit der zugehörigen Framework-Dokumentation auseinandersetzen. Die Webseite des SalesPoint- Frameworks enthält zu diesem Zweck einen eigenen Bereich [Dokumentation]. Es wird hierbei empfohlen, sich zunächst den "technischen Überblick" und dann den "Großen Beleg" im Dokumentations-Bereich anzusehen.
Arbeiten Sie nun im nächsten Schritt das zugehörige [Tutorial] der "Videoverleihautomat" Beispiel-Applikation durch, welches Ihnen erste praktische Einblicke in das Framework gibt und Sie Schritt für Schritt an die genutzte Technik heranführt. Hierbei kann auch die API-Spezifikation des SalesPoint-Frameworks in Form einer [JavaDoc]-Dokumentation hilfreich sein.
Danach soll nun ein vereinfachter "Videoverleihautomat" auf Basis einer vorgegebenen Aufgabenstellung überarbeitet werden. Gehen Sie dabei analog zum jeweiligen Tutorial vor, wo auch alle benötigten Techniken beschrieben sind. Dokumentieren Sie die entsprechenden Schritte auf ihren Web-Seiten (laufend!).

Phasenartefakte:

Lösungen zu den Aufgabenstellungen, welche mit den jeweils passenden Modellanteilen (v.a. Klassendiagrammen) dargestellt und zusätzlich detailliert beschrieben werden. Die entsprechenden Beschreibungen sind zudem um den zugehörigen Sourcecode zu bereichern (siehe hierzu auch die Hinweise zu Java2HTML im Anteil [Projektrahmen]!).
das übersetzte (und funktionstüchtige!) Programm als ausführbares JAR
eine vollständige JavaDoc-Dokumentation mit Erläuterungen zur Implementierung (mit Beschreibung von allen Klassen, Attributen, Parametern, Methoden, Rückgabewerten und Ausnahmen).

Hinweise:

Die Einarbeitungsaufgaben sind von jedem Teammitglied zu bearbeiten - entsprechende Fragen zu den Lösungswegen sind bei der zugehörigen Präsentation zu erwarten.

Die Designphase

Ziel:

Ziel dieser Phase ist die Übersetzung des nichttechnischen Analysemodell (das WAS) der ersten Phase in ein technisches Designmodell (das WIE). Dies geschieht typischerweise in mehreren Durchläufen, welche immer feinere "Baupläne" für die zu erstellende Software (vgl. Grobentwurf/ Feinentwurf) zum Ergebnis haben, die dann in der anschliessenden Phase der Implementierung fließend in die Codierung übergehen.

Vorgehensweise:

Es ist zunächst ein erster Abgleich zwischen dem Analyseergebnis und dem genutzten Framework (das Wissen hierüber sollte man sich in der Einarbeitungsphase angeeignet haben!) erforderlich, um festzustellen

welche der geforderten Funktionen das Framework in Form von Standardfunktionalität (Fall 1) abdeckt
welche weiteren Funktionen es nach Anpassungen (Fall 2) erfüllt, und wie diese Anpassungen genau aussehen
was darüber hinaus an Erweiterungen (Fall 3) notwendig ist, und wie diese einzubinden sind

Dies ist sowohl für das sich in Form von statischen und dynamischen UML-Diagrammen äußernde Fachkonzept (hier müssen die vorliegenden Diagramme in eine technische Sicht detailliert werden), für den GUI-Prototypen (hier müssen die vorliegenden GUI-Skizzen in eine technische Sicht übersetzt werden), als auch für sich erst in technischer Sicht ergebenden Anteile (diese müssen vollständig neu entworfen werden) zu erledigen. Diese erste Abschätzung manifestiert sich in einem Grobentwurf, welcher auf architektureller Ebene die identifizierten, funktionalen Blöcke beschreibt.

Im hierauf folgenden Feinentwurf erfolgt nun, abhängig vom jeweils notwendigen Grad der Anpassung, die detaillierte Modellierung der Umsetzung auf Basis der Standard-Schnittstellen des Frameworks (im Fall 1 genügt dies), eventuell eine Adaption bzw. Erweiterung selbiger Schnittstellen (ausreichend für Fall 2) oder sogar der Entwurf zusätzlicher Komponenten (siehe Fall 3). Vor allem in letzteren beiden Fällen ist es natürlich notwendig, dies ausführlich (auch textuell) zu dokumentieren.

Phasenartefakte:

letztlich ergeben sich zahlreiche Modellanteile unterschiedlicher Diagrammtypen, welche miteinander im Zusammenhang stehen. Falls sich Modellierungsänderungen gegenüber der Analysephase ergeben, so sind diese ausführlich zu dokumentieren. Vor allem aber sind jegliche Anpassungsmaßnahmen des genutzten Frameworks sowie zusätzliche Anteile gesondert zu beschreiben. Im Folgenden typische Beispiele genutzter Modellanteile:
- die Festlegung konkreter Katalogs- und Bestandsklassen auf Basis von Klassendiagrammen
- die Umsetzung von Anwendungsfällen in Prozessen (Unterklassen von SaleProcess), anschaulich unterstützt durch Zustandsübergangsdiagramme
- die anschauliche Modellierung komplexer, sequentieller Abläufe mit Hilfe von Sequenzdiagrammen
ein aktualisiertes Testhandbuch, welches nun neben allgemeinen Fehlerquellen der Programmnutzung (aus der Analysephase) mögliche Unzulänglichkeiten der technischen Umsetzung (primär auf Ebene von Funktionsblöcken) aufdeckt und beschreibt, wie die Software hierauf abzuprüfen ist. Hierbei ist zu bedenken, dass vor allem jede zusätzliche Funktionalität angemessen zu testen ist!

Die Implementierungsphase

Ziel:

Das Ziel der Implementierungsphase ist die iterative Umsetzung des Designmodells in ein funktionierendes Programm.

Vorgehensweise:

Entsprechend der zuvor festgelegten und priorisierten Liste von Use-Cases (vgl. Implementierungsstatus) wird nun schrittweise das anskizzierte Programm implementiert. Hierbei werden in dieser Phase drei gleich geartete Iterationen durchlaufen, wobei der Priorisierung folgend implementiert wird. Die Iterationen ihrerseits folgen dabei dem Zyklus Implementierung, Evaluation und Re-Design, wobei die Evaluation sowohl das Testen auf technischer Ebene (funktioniert das Programm?), als auch die Nutzertests (entspricht das Programm den Erwartungen?) umfasst. Das Re-Design bezieht sich auf Modellanteile, deren Design sich im Laufe der Implementierung noch anpasst - dies lässt sich auch mit einem intensiven Vorabdesign nicht vollständig vermeiden und muss an dieser Stelle nun verbessert bzw. vervollständigt werden.

Phasenartefakte:

Zwischenpräsentationen:

das übersetzte (und funktionstüchtige!) Programm als ausführbares JAR
eine vollständige JavaDoc-Dokumentation mit Erläuterungen zur Implementierung (mit Beschreibung von allen Klassen, Attributen, Parametern, Methoden, Rückgabewerten und Ausnahmen).
ein aktualisiertes Testhandbuch (welches nun auch die Funktionstests der einzelnen Klassen umfasst) sowie Testprotokolle und ggfs. Testklassen der bereits durchgeführten Tests
die aktualisierten Modellanteile der vorherigen Phase - die Darstellung und Erläuterung der Änderungen genügt hier

Zusätzlich Endpräsentation: Das fertige Benutzerhandbuch zum Programm

Hinweise:

Unabhängig von der verwendeten Sprache (deutsch oder englisch) für den Programmcode sind die gängigen Konventionen einzuhalten:

Klassennamen beginnen mit einem Großbuchstaben, Paketnamen mit einem Kleinbuchstaben
"Getter" und "Setter" werden nicht übersetzt, also z.B. nicht "holeName" statt "getName"

Ferner ist darauf zu achten, dass das eigene Programm in sinnvolle Pakete eingeteilt wird (das default-Package darf nicht verwendet werden). Insbesondere die Testklassen sollten sich in einem eigenen Paket befinden.

Die Wartungsphase

Ziel:

Ziel dieser Phase ist die Korrektur noch verbliebener Programmfehler (so gut wie immer), das Einarbeiten von Ergänzungs- oder Änderungswünschen des Auftraggebers (häufig) und die Umsetzung evtl. notwendiger Optimierungsmaßnahmen (selten).

Vorgehensweise:

Die Wartungsphase ist jedoch im eigentlichen Sinne nicht als Phase des Entwicklungsprozesses zu verstehen, sondern entspricht eher einer weiteren Implementierungsiteration bzw. einem erneuten Durchlaufen weiterer Phasen (mit Ausnahme der Einarbeitung). Die genaue Ausgestaltung der Wartung ist hier schlicht abhängig von der Art der Änderung. Im Falle kleinerer Implementierungsfehler wird eine kurze, zusätzliche Phase der Implementierung meist ausreichend sein, ist der Fehler tiefgreifender wird ein Re-Design notwendig, handelt es sich dagegen um größere Änderungswünsche von Seiten des Kunden (bzw. um Analysefehler), ist ein vollständiges Durchlaufen aller Phasen angezeigt. Kurzum ist ein Fehler umso dramatischer, je früher er passiert ist - arbeiten Sie deswegen insbesondere in der Analyse- und Designphase besonders umsichtig, um sich in der Wartungsphase Arbeit zu ersparen!

Phasenartefakte:

Die Artefakte dieser Phase sind abhängig von ihrer Ausgestaltung und entsprechen mind. der Implementierungs-, evtl. auch der Design- und Analysephase.

Hinweise:

Auch eine auf Erweiterbarkeit ausgelegte Architektur des erstellten Programms (zumindest in vertretbarem Umfang) hilft bei einer effizienten Integration (absehbarer) Änderungswünsche des Auftraggebers und minimiert den in der Wartungsphase zu investierenden Aufwand - bedenken Sie dies bitte in der Designphase.

zurück