Freitag, 21. März 2014

Drei Basismodelle guter Software im praktischen Beispiel.

Beispiel zum System der Anforderungsermittlung

Artikelübersicht
1. Teil Ideen, Themenobjekte und die Roadmap im praktischen Beispiel.
2. Teil Praktisches Beispiel zur Kontextuntersuchung.
3. Teil Praktisches Beispiel zu User Stories.
4. Teil Drei Basismodelle guter Software im praktischen Beispiel.
5. Teil Das Bauen von Use Cases mit Hilfe von User Stories im praktischen Beispiel.
6. Teil Die praktische Umsetzung verschiedener Perspektiven bei der Suche nach Anforderungen.


Im letzten praktischen Beispiel haben wir eine User Story entwickelt. Sie drückte den Wunsch eines Stakeholders aus. Diese User Story wurde geschätzt und priorisiert. Innerhalb eines Themas gibt es natürlich mehrere User Stories. Stehen alle User Stories eines Themas auf PRIORITIZED, kann der Product Owner sie mit einer Aufgabe beauftragen. Damit stehen die Stories im Backlog des Teams. Die Erstellung von User Stories hat unser Projekt planbar gemacht. Drei einfache Modelle werden begleitend zur Systemkontextuntersuchung und zur Erstellung der User Stories angefertigt. In jeder Iteration werden sie erweitert und auf ihre Konsistenz geprüft. Sie zeigen sehr frühzeitig grobe Konflikte an und verhindern so aufwändige Fehlentwicklungen. Bei den Modellen handelt es sich um die Darstellung des Problemraumes, die Aufzählung der Randbedingungen und die Erstellung eines Zielmodells. Alle drei Modelle sorgen dafür, dass die Gesamtentwicklung sich nicht verläuft und wir im Nirgendwo enden.

An erster Stelle steht das Durchdenken des Problemraumes. In unserem Beispiel haben wir uns um die Umsetzung eines Systems zur Stakeholderanalyse gekümmert. Im folgenden Prozess versuchen wir, eine möglichst vollständige Liste von Problemen zu finden, die eine Stakeholderanalyse erforderlich machen. Beim Betrachten einzelner Probleme kann uns auffallen, dass sie sich aus Teilproblemen zusammensetzen oder auch andere Probleme verursachen. Damit entwickelt sich ein System von Problemen, welches wir in eine Baumdarstellung gießen können. Bei unserer Suche sind wir z.B. auf die folgenden Probleme gestoßen:

  • Wir besitzen keinen Überblick über die Stakeholder des Projektes.
  • Wir besitzen keinen Überblick über die Beziehungen der Stakeholder zueinander.
  • Wir besitzen keinen Überblick über die Beziehungen der Stakeholder zum Projekt.
  • Wir besitzen keine Kontaktdaten für die Stakeholder.
  • Wir besitzen keinen Überblick über die Wichtigkeit der Stakeholder.


Für den Problembaum kann man z.B. eine MindMap benutzen.


In gemeinsamer Teamarbeit fallen uns viele problematische Situationen ein, die uns an einer systematischen Arbeit hindern oder deren Beseitigung wir uns für die Vereinfachung wünschen würden. Dieses Problemraummodell wird mit jedem Sprint genauer und zeigt uns genau an, warum wir was lösen müssen. Außerdem werden uns die Zusammenhänge zwischen den Problemen klarer und ein kurzer Blick reicht, um anderen zu erklären, warum wir ein System erstellen müssen, welches diese Probleme beseitigt. Kommentare an der Problemdarstellung können Argumente enthalten. Im Folgenden zeige ich ein Problem und einen Kommentar dazu:

Problem Wir besitzen keine Kontaktdaten für die Stakeholder.
Kommentar Wir müssen uns die Kontaktdaten aus verschiedenen Systemen zusammensuchen. Dort sind sie oft nicht vollständig, bedürfen also Ergänzungen. Diese Arbeiten werden immer wieder ausgeführt und erfordern mehrere Tage Projektarbeit, die eingespart werden könnten.


Eine weitere sehr wichtige Überlegung ist das Bedenken und Aufzeichnen der Randbedingungen. Wenn wir die oben genannten Probleme lösen wollen, schränken die Randbedingungen unseren Lösungsraum ein. In unserem Fall erstellen wir eine einfache Liste. Für längere Listen von Randbedingungen wäre eine Unterteilung in Kategorien sinnvoll, wie z.B. Entwicklung, Administration, Vertrieb usw. Im Folgenden zeige ich eine kurze Liste von Randbedingungen zu unserem Beispiel:

  • Die Anwendung soll eine Webanwendung sein.
  • Die Anwendung soll mit Java programmiert werden.
  • Die Anwendung soll nur als kostenloser Download zur Verfügung gestellt werden.
  • Die Anwendung soll den Richtlinien und Gesetzen des Datenschutzes in Deutschland genügen.


Diese kurze Liste zeigt bereits, dass bestimmte Randbedingungen bestimmte Lösungsansätze nicht mehr zulassen. In diesem Fall sind wir gezwungen, eine Webanwendung zu programmieren. Aus der Restriktion, dass der Datenschutz eingehalten werden muss, wird im letzten Modell, dem Zielmodell, ein Ziel. Dieses Ziel schränkt Möglichkeiten ein und führt im weiteren Text zu einem Konflikt, der gelöst werden muss.

Das dritte Modell, welches den Startpunkt zur Entwicklung von Anforderungen setzt, ist das Zielmodell. Alle Probleme sollen mit einer Lösung aus dem Weg geräumt werden. Das Ziel löst also das Problem. Es ist noch nicht die genaue Anforderung, sondern die Intention der Lösung. Unser Problem, uns fehlt Mondstein, lösen wir, indem wir uns das Ziel setzen ein Fahrzeug zu bauen, dass den Mond erreichen kann. Im Zielmodell formulieren wir also unsere Absichten. Alles, was wir in unserem Projekt umsetzen, jedoch mit keinem unserer gesetzten Ziele verbunden ist, können wir als sinnlose Arbeit bezeichnen. Es gibt keine Anforderungen ohne Ziele. Ziele können wir mit Hilfe von Dekompositionen verfeinern. Unser oberstes Ziel ist:

  • Schaffung eines Stakeholderanalysesystems


Dieses große Ziel können wir auch die Systemvision nennen. Das Verfeinern in Unterziele schafft mehr und mehr Klarheit über unsere Absichten, die wir mit der Systemerstellung verfolgen. Direkte Unterziele können sein:

  • Alle Kontaktdaten der Stakeholder erfassen
  • Bestimmen der Projektakzeptanz der Stakeholder
  • Bestimmen der Stakeholderbetroffenheit
  • Darstellung von Stakeholderbeziehungen
  • Gruppenbildung von Stakeholdern
  • Bildung von Personas
  • Bildung von extremen Charakteren
  • Einhaltung des Datenschutzes


Eine weitere Verfeinerung für die Kontaktdaten kann z.B. sein:

  • Erfassen der persönlichen Daten
  • Erfassen des Gesundheitszustandes
  • Erfassen des Gehaltes


Einige dieser Ziele können im Konflikt zueinander stehen. Zwischen den Daten über den Gesundheitszustand und dem Ziel der Einhaltung des Datenschutzes besteht so ein Konflikt. Dieser wird anhand des Modells analysiert und muss mit entsprechenden Methoden gelöst werden, bevor wir an die Umsetzung des Projektes gehen.

Eine weitere Möglichkeit ist die Darstellung von Abhängigkeiten. Um Personas bilden zu können, ist die Bildung von Stakeholdergruppen eine notwendige Voraussetzung. Schnell ist ersichtlich, dass eine solche Abhängigkeit erfordert, dass für die Umsetzung des einen Ziels erst das andere Ziel umgesetzt werden muss. Im letzten Artikel führte das zur Zusammenfassung dieser beiden Ziele in einer User Story.

Diese einfachen Modelle erlauben es uns, mit relativ simplen Mittel, schon zu einem sehr frühen Zeitpunkt Konflikte, Restriktionen und Abhängigkeiten zu erkennen. Später bemerkt, verursachen diese Dinge einen weit größeren Zeitaufwand. Was hier noch ein einfacher Satz ist, ist in der Implementierung schon Code, der gefunden und geändert werden muss, im schlimmsten Fall sogar mit Auswirkungen auf die Architektur der Anwendung. Wie für alles gilt aber auch hier die 80%-Regel. Wenn es am schönsten ist, sollte man aufhören. Es kommt nicht darauf an, etwas zu sinnloser Perfektion zu treiben, es kommt darauf an, Prozesse effektiver, effizienter, stressfreier und zielgerichteter zu gestalten.

vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Keine Kommentare:

Kommentar veröffentlichen