Dienstag, 10. September 2013

Ein Objekt-Aufgaben-Modell für das Requirements Engineering

These: Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


Im Requirements Engineering gibt es Ideen, Ziele, User Stories, Use Cases, Szenarien, Anforderungen, und wenn es der Dokumentationshunger verlangt, einiges mehr. All diese Dinge können wir als Objekte auffassen. Sie existieren in realen Spezifikationen, in geordneten Wikis oder auch im großen Durcheinander des Projektalltags. Ein Ding ist also ein reales Objekt, welches wir auch als Artefakt bezeichnen können. Diese Artefakte werden erstellt, geändert oder gelöscht. Diese Handlungen weisen darauf hin, dass sich das einzelne Objekt in verschiedenen Status befindet.

Mit diesen Objekten verbinden sich Aufgaben. Solange niemand dafür verantwortlich ist, passiert auch nichts mit dem Objekt. Ist diese Verantwortlichkeit geklärt, wird eine Aufgabe erteilt. An das Objekt heftet sich die Aufgabe. Sie ist, im Gegensatz zum Objekt, kein sichtbares Artefakt. Sie ist eine Tätigkeit, die Artefakte erzeugt und Zeit für die Umsetzung benötigt. Aufgaben wiederum werden umgesetzt, abgebrochen und bewertet. Somit unterliegen auch Aufgaben Statusänderungen.

Es gibt also zwei verschiedene Grundeinheiten - Objekte und Aufgaben. Beide besitzen ein Statusmodell. Die Statusübergänge für Objekte und Aufgaben sind unterschiedlich. Um eine weitere Vereinfachung des Modells zu erreichen, und damit eine bessere Handhabbarkeit, wäre es gut, wenn alle Objekttypen das gleiche Statusmodell besitzen würden, ebenso die Aufgabentypen. Unter einem Objekttyp verstehen wir zum Beispiel die Typen Idee, Ziel und User Story und unter einem Aufgabentyp Codieren und Testen. Die Gesamtheit aller Objekt- und Aufgabentypen werden in den folgenden Posts im Einzelnen erläutert und diskutiert. Zu allen theoretischen Beiträgen wird außerdem ein praktischer Beitrag erscheinen.

Im Folgenden werde ich die Statusmodelle mit Hilfe einer Visualisierung und einer erläuternden Tabelle erklären. Diese Form hat sich bei uns als die am wenigsten ermüdende Dokumentationsform erwiesen.

Der Objekttyp

Tabelle der Status
ZustandBeschreibung
NEWDas Objekt wurde neu angelegt.
PRIORITIZEDDas Objekt wurde von einem geeigneten Gremium priorisiert.
DEFERREDDas Objekt wurde von einem geeigneten Gremium zurückgestellt. Die Priorität bildete dabei eine wichtige Entscheidungsgrundlage.
ORDERED Das Objekt wurde von einem geeigneten Gremium zur Bearbeitung beauftragt. Die Priorität bildete dabei eine wichtige Entscheidungsgrundlage. Wenn ein Objekt in diesem Zustand ist, kann für die Bearbeitung eine Aufgabe erzeugt werden.
IMPLEMENTEDDas Objekt wurde bearbeitet. Wenn die Aufgabe vollständig abgearbeitet wurde, ist das Objekt in diesen Zustand zu versetzen.


Tabelle der Statusübergänge
ZustandsübergangBeschreibung
createDas Objekt wird erzeugt.
prioritizeDas Objekt wird durch ein geeignetes Gremium priorisiert.
deferDas Objekt wird durch ein geeignetes Gremium zurückgestellt.
deleteDas Objekt wird gelöscht.
representDas Objekt wird durch ein geeignetes Gremium wieder vorgelegt.
orderDas Objekt wird durch ein geeignetes Gremium beauftragt.
implementDas Objekt wird durch den Bearbeiter der Aufgabe bearbeitet.


Der Aufgabentyp

Tabelle der Status
ZustandBeeschreibung
OPENDie Aufgabe wurde für die Bearbeitung eines Objektes erzeugt.
IMPLEMENTEDDie Aufgabe wurde durch den Bearbeiter bearbeitet.
REVIEWEDDie Aufgabe wurde durch eine Review-Gruppe begutachtet.


Tabelle der Statusübergänge
ZustandsübergangBeeschreibung
createDie Aufgabe wird für den Bearbeiter erzeugt.
implementedDie Aufgabe wird durch den Bearbeiter umgesetzt.
positiveReviewDie Aufgabe wird von der Review-Gruppe positiv bewertet.
negativeReviewDie Aufgabe wird von der Review-Gruppe negativ bewertet.
acceptanceDie Aufgabe wird von der QS abgenommen.
noAcceptanceDie Aufgabe wird von der QS nicht abgenommen.
abortDas Aufgabe wird durch ein geeignetes Gremium abbgebrochen.


In den obigen Tabellen ist des Öfteren von einem geeigneten Gremium die Rede. Damit meine ich die entsprechenden Entscheidungsträger, die Artefakte priorisieren und beauftragen können. Es wäre noch genau zu überlegen, wer alles in diesen Kreis gehört. Auf alle Fälle sollte ein Weg gefunden werden, den Kunden, für den die Software erstellt wird, in die Entscheidungen mit einzubeziehen. Der Begriff der Review-Gruppe bezieht sich auf eine geeignete Gruppe, die die Software innerhalb der Entwicklung begutachtet und zur QS-Abnahme freigibt. Die Organisation von Gremium, Review-Gruppe und QS ist stark abhängig von dem gewählten Vorgehensmodell in der Entwicklung.

Dieser Post sollte nur die beiden Grundeinheiten Objekt und Aufgabe einführen. In den kommenden Posts wird das gesamte System sowohl theoretisch ausgebaut als auch durch praktische Beispiele erläutert. Dabei sind theoretische und praktische Posts voneinander getrennt. Natürlich ist es immer möglich, durch Kommentare auf die Entwicklung dieser Gedanken Einfluss zu nehmen.

folgender Post dieses Themas


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

Keine Kommentare:

Kommentar veröffentlichen