Programmierprojekt HT14

Leitung: Dr. Sonja Maier, Alexander Uherek

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 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 der 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.: "neues Level laden", "Spiel-Einstellungen vornehmen") 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. "Spieler legt sich einen eigenen 'Character' an"). 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 verfasst.
Die gefundenen Anwendungsfälle und durchgespielten Szenarien können zusätzlich als Leitfaden für zu erstellenden 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 im Hinblick auf die spätere Umsetzung weiter verfeinert. 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 vorläufiges Benutzerhandbuch, welches den anskizzierten Funktionsumfang textuell aus Anwendersicht beschreibt. 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 zu den Use-Cases
Benutzeroberfläche:
- GUI-Skizzen (Vorabversion)

Endpräsentation

Produktübersicht
- Benutzerhandbuch
- Klassendiagramme
- Testhandbuch
Benutzeroberfläche:
- Allgemeine Gestaltungsrichtlinien
- 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:

Ziel der Einarbeitungsphase ist es, Ihnen die Gelegenheit zu geben, sich mit der technischen Plattform, den (eventuell) zu verwendenden Bibliotheken, und 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 ein 'Workshop' 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 den Ihnen zur Verfügung gestellten Tutorials usw. auseinander zusetzen.
Arbeiten Sie nun im nächsten Schritt das Tutorial durch, welches Ihnen erste praktische Einblicke in Beispiel-Anwendungen gibt und Sie Schritt für Schritt an die genutzte Technik heranführt. Hierbei kann auch die API-Spezifikation der Beispiel-Anwendungen in Form einer JavaDoc-Dokumentation hilfreich sein.
Danach sollen nun die Beispiel-Anwendungen auf Basis einer vorgegebenen Aufgabenstellung überarbeitet werden. Gehen Sie dabei analog zum 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.
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 anschließenden Phase der Implementierung fließend in die Codierung übergehen.

Vorgehensweise:

Es ist zunächst ein erster Abgleich zwischen dem Analyseergebnis und der zu verwendenden technischen Plattform bzw. den verwendeten Bibliotheken (das Wissen hierüber sollte man sich in der Einarbeitungsphase angeeignet haben!) erforderlich, um festzustellen

welche der geforderten Funktionen in Form von Standardfunktionalität (Fall 1) abgedeckt wird
welche weiteren Funktionen nach Anpassungen (Fall 2) abgedeckt werden, und wie diese Anpassungen genau aussehen
was darüber hinaus an Erweiterungen (Fall 3) notwendig sind, 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 der Bibliotheken (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 zusätzliche Anteile gesondert zu beschreiben. Im Folgenden typische Beispiele genutzter Modellanteile:
- die Festlegung des Aufbaus des Programms auf Basis von Paket- und Klassendiagrammen
- die Umsetzung von Anwendungsfällen in Prozessen, 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 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