Mittwoch, 8. Oktober 2008
Thema: Methoden
Projektkontext
Für einen Kunden sollten wir eine Datenbank für medizinische Bilder erstellen, die Anwendern ermöglichen sollte, möglichst einfach das richtige Bild zu finden. Einfachheit und Geschwindigkeit der Intranet-Applikation standen für die Anwender im Vordergrund. Andere Mitarbeiter, die Editoren, bereiteten die Bilder auf und qualifizierten sie.
Unser Kunde liebte die UML. Bereits das Lastenheft enthielt Aktivitätsdiagramme. Diese Chance wollten wir nutzen und UML auch in der Zusammenarbeit mit dem Kunden einzusetzen.
Lösung
Zu Projektbeginn entschied ich mich dafür, Zustandsdiagramme zur Konzeption zu nutzen, da sie erlauben, das Verhalten aus Sicht des Systems zu spezifizieren. Wir nutzten die Diagramme zur funktionalen Spezifikation des Systems.
Ich erinnere mich gerne an die äußerst effektiven Workshops, in denen ich mit dem Kunden gemeinsam Zustandsmodelle entwickelte. Wir sprachen dieselbe Sprache – UML.
Es war einfach, Ausnahmen und Fehlerfälle zu erkennen und so die Vollständigkeit herzustellen. Das Ergebnis war eine sehr präzise Dokumentation des Systemverhaltens. Wichtig war dabei, dass die Diagramme immer durch Text ergänzt werden mussten. Ich nutzte die Möglichkeiten der UML, Informationen in den Diagrammen unterzubringen. Dennoch gab es Anforderungen, die nur textuell dokumentiert werden konnten, z. B. welche Informationen in einer Liste angezeigt werden sollten.
Wichtige Erfahrungen waren, dass das ganze Team geschult werden muss, um alle Feinheiten der Diagramme erkennen und nutzen zu können. Eine Voraussetzung für den konsequenten Einsatz von UML war, dass der Kunde diese Sprache sprach.
Beispiele
Zustände definierten einen logischen Schritt für den Anwender. Ein Zustand wurde dabei typischer Weise zu einem Screen der Applikation, in dem bestimmte Funktionen zur Verfügung standen, die als Transitionen am Zustand notiert waren.
Das Beispiel zeigt die Funktionalität beim Ansehen eines Bildes.
Wir setzten Zustandsdiagramme natürlich auch zur Beschreibung von Objektzuständen ein.
Für einen Kunden sollten wir eine Datenbank für medizinische Bilder erstellen, die Anwendern ermöglichen sollte, möglichst einfach das richtige Bild zu finden. Einfachheit und Geschwindigkeit der Intranet-Applikation standen für die Anwender im Vordergrund. Andere Mitarbeiter, die Editoren, bereiteten die Bilder auf und qualifizierten sie.
Unser Kunde liebte die UML. Bereits das Lastenheft enthielt Aktivitätsdiagramme. Diese Chance wollten wir nutzen und UML auch in der Zusammenarbeit mit dem Kunden einzusetzen.
Lösung
Zu Projektbeginn entschied ich mich dafür, Zustandsdiagramme zur Konzeption zu nutzen, da sie erlauben, das Verhalten aus Sicht des Systems zu spezifizieren. Wir nutzten die Diagramme zur funktionalen Spezifikation des Systems.
Ich erinnere mich gerne an die äußerst effektiven Workshops, in denen ich mit dem Kunden gemeinsam Zustandsmodelle entwickelte. Wir sprachen dieselbe Sprache – UML.
Es war einfach, Ausnahmen und Fehlerfälle zu erkennen und so die Vollständigkeit herzustellen. Das Ergebnis war eine sehr präzise Dokumentation des Systemverhaltens. Wichtig war dabei, dass die Diagramme immer durch Text ergänzt werden mussten. Ich nutzte die Möglichkeiten der UML, Informationen in den Diagrammen unterzubringen. Dennoch gab es Anforderungen, die nur textuell dokumentiert werden konnten, z. B. welche Informationen in einer Liste angezeigt werden sollten.
Wichtige Erfahrungen waren, dass das ganze Team geschult werden muss, um alle Feinheiten der Diagramme erkennen und nutzen zu können. Eine Voraussetzung für den konsequenten Einsatz von UML war, dass der Kunde diese Sprache sprach.
Beispiele
Zustände definierten einen logischen Schritt für den Anwender. Ein Zustand wurde dabei typischer Weise zu einem Screen der Applikation, in dem bestimmte Funktionen zur Verfügung standen, die als Transitionen am Zustand notiert waren.
Das Beispiel zeigt die Funktionalität beim Ansehen eines Bildes.
Wir setzten Zustandsdiagramme natürlich auch zur Beschreibung von Objektzuständen ein.
... kommentieren