Programmierprojekt HT09 (Modul 1136)

Leitung: Sonja Maier, M.Sc., Dipl.-Wirt.-Inf. Michael Kretzschmar, 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 (siehe hierzu auch die [Vorlage] im Dokumentenbereich des Projektes).

  1. 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 welcher dann eine Liste aus Muss- (Basisfunktionalität, welche die Einsetzbarkeit gewährleistet), Wunsch- (Zusatzfunktionalität, welche die Nutzung erweitert bzw. vereinfacht) und Abgrenzungskriterien (das, was die Software nicht können soll) extrahiert wird. Selbige Liste ist noch recht grobgranular und entspricht im Ungefähren späteren Funktionsblöcken der zu erstellenden Software (z.B. "Kunden können sich im Markt anmelden bzw. beim ersten Besuch registrieren").
  2. Im nächsten Schritt wird nun die MWA-Liste in Form von Anwendungsfällen aufgegriffen und verfeinert. Diese Anwendungsfälle sollen durch kurze Teilsätze (z. B.: "Kunde anlegen", "Photoauftrag im Internet annehmen") beschrieben werden. Die Liste dieser Anwendungsfälle soll alle möglichen durch die Aufgabe implizierten Funktionalitäten des Programms wiedergeben. Ordnen Sie die Anwendungsfälle auch ihren realen Benutzern zu und überlegen sie sich erste Strukturierungsmöglichkeiten für ihr Programm (in Form von Paketen).
  3. Spielen Sie nun (mindestens anfangs zusammen mit dem Auftraggeber) konkrete Szenarien zu diesen Anwendungsfällen, protokollieren Sie diese mit und erstellen sie parallel die zugehörigen CRC-Karten (Papier-Version!). Die Szenarien sollen hierbei konkrete, vorstellbare Abläufe innerhalb des Programms widerspiegeln, also z.B. "Nicht registrierter Kunde sendet Photoauftrag per Post ein". Jedes Szenario beschreibt also so detailliert wie möglich, welche Schritte zur Erfüllung einer spezifischen Aufgabe notwendig sind und welche Objekte an diesem Ablauf teilhaben.
  4. Neben der Identifikation und Befüllung von CRC-Karten dienen die ausgewählten Szenarien ebenso als Leitfaden für zu erstellende Skizzen der späteren Benutzeroberflächen (sowie einer zugehörigen Gestaltungsrichtlinie), welche in ihrer Gesamtheit gleichzeitig auch die Rolle eines Storyboards für die zu erstellende Anwendung einnehmen können.
  5. 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).
  6. Im Anschluss (bzw. schon sukkzessive vorher) extrahieren sie nun eine hierarchisierte und priorisierte Liste von zu implementierenden Produktfunktionen und einzubettenden Produkdaten aus ihren bisherigen Ergebnissen (wobei die Muss- und Wunschkriterien aus 1. die groben Kategorien für Hierarchie und Priorisierung bilden). Insgesamt gesehen, sollte sich für den Auftraggeber in der vorgelegten Liste 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.
  7. Detaillieren Sie nun ihre Zwischenergebnisse in Form zusätzlicher Modellierungsanteile, also z.B. in Form von Klassendiagrammen für die statischen Anteile des Fachkonzepts oder in Form von Aktivitäts-/ Zustandsdiagrammen (in manchen Fällen sind auch Sequenzdiagramme sinnvoll) für die dynamischen Anteile des Fachkonzepts. Bedenken Sie hierbei bitte auch die Zusammenhänge und Abhängigkeiten der einzelnen Artefakte untereinander (vgl. auch die Hinweise im Bereich [Projektrahmen])!
  8. Weiterhin erstellen Sie ein ein vorläufiges Benutzerhandbuch, welches den anskizzierten Funktionsumfang textuell aus Anwendersicht beschreibt. Im Normalfall spiegelt sich hier die Liste der Produktfunktionen in der Gliederung wider; die angefertigten GUI-Skizzen können der Verbildlichung dienen.
  9. 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

  1. Zielbestimmung:
    • Erweiterte Aufgabenstellung
    • MWA-Kriterien
  2. Produktübersicht:
    • Use-Case Diagramme / Paketdiagramme (Vorabversion)
  3. Fachkonzept:
    • PF/PD-Liste (Vorabversion)
    • Szenarien / CRC-Karten (Vorabversion)
  4. Benutzeroberfläche:
    • Gestaltungsrichtlinie
    • GUI-Skizzen (Vorabversion)

Endpräsentation

  1. Produktübersicht
    • Use-Case Diagramme / Paketdiagramme
    • Benutzerhandbuch
  2. Fachkonzept:
    • PF/PD-Liste
    • Szenarien / CRC-Karten
    • Aktivitäts-, Zustands- und evtl. Sequenzdiagramme / Klassendiagramme
  3. Benutzeroberfläche:
    • GUI-Skizzen
  4. Qualitätssicherung:
    • Testhandbuch (Ebene der Systemfunktionalität/ globalen Fehlerfälle)

Hinweise:

  • Binden Sie in den oben genannten Schritten auf jeden Fall ihren Auftraggeber ein! Vor allem die Verfeinerung der Aufgabenstellung, die CRC-Kartensitzungen und die letztliche Abstimmung der PF/PD-Liste 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 PF/PD-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:

  1. 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 [Einführungsvortrag] für das SalesPoint-Framework statt. Die genauen Örtlichkeit und der Termin werden rechtzeitig bekanntgegeben - die Teilnahme an der Veranstaltung ist Pflicht!
  2. Nach dem Einführungsvortrag 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.
  3. 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.
  4. 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!). Die Aufgabenstellung und die Ausgangsversion des Videoautomaten finden Sie im [Dokumentenbereich] des Projektes.

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) in Form eines ZIP-Archivs (die direkte Ablage im BSCW ist i.A. zu ineffizient!)

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 Modellierung der Funktionalität (der Aktionsfolgen) hinter der grafischen Oberfläche mit Hilfe von Aktivitätsdiagrammen
    • 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 Produktfunktionen/ Produktdaten (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) in Form eines ZIP-Archivs (die direkte Ablage im BSCW ist i.A. zu ineffizient!)
  • 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