Meta-Informationen mal anders: 5 Alternativen zu Attributen
Attribute sind überall: Wenn wir Anforderungen erfassen, erfassen wir neben der Beschreibung typischerweise eine Priorität, generieren eine ID, speichern den Autor, etc. All dies sind Attribute. Oft kommen dann noch spezifische Attribute hinzu, wie bspw. eine Sicherheitsanforderungsstufe. Auch in der weiteren Entwicklung werden Attribute eingesetzt: Bspw. haben viele SysML-Modellelemente Dutzende von vordefinierten Attributen. Und selbstverständlich können diese um vom Nutzer definierte Attribute erweitert werden.
Disrupting Requirements: Webinar mit Colin Hood, Christer Fröling und Michael Jastram am 26. April um 17:00 – Jetzt registrieren >>
Doch oft greifen wir zu Attributen, ohne darüber nachzudenken, ob es nicht vielleicht bessere Alternativen gibt. Fünf dieser Alternativen werden heute vorgestellt.
Welche Attribute?
Ursula Meseberg veröffentlichte kürzlich den lesenswerten Artikel Ansichtssache: Welche Attribute braucht eine Anforderung? Darin geht es zwar um Attribute von Anforderungen, aber die Konzepte lassen sich problemlos auch auf andere Artefakte der Systementwicklung übertragen.
Attribuierung birgt auch Gefahren. Insbesondere die zwei Folgenden können zu Problemen führen:
Wildwuchs: Wildwuchs entsteht, wenn Attribute ad hoc angelegt werden. Wie groß die Gefahr ist, hängt in der Regel vom verwendeten Werkzeug ab. Extrembeispiel Excel: Ein neues Attribut wird angelegt, indem eine neue Spalte eingeführt wird. Da Excel kein Rechtesystem hat, kann jeder Nutzer neue Attribute erzeugen. Außerdem ist es mit Excel nicht möglich sicherzustellen, dass verschiedene Tabellen die gleichen Spalten haben.
Auch ältere RE-Werkzeuge haben das Problem, wie das „klassische“ IBM Rational DOORS: Dort hat jedes „Modul“ einen eigenen Satz von Attributen. Das bedeutet, dass zwei Lastenheft-Module eine unterschiedliche Attributierung haben können. Bei modernen Lösungen wie bspw. Jama Software werden die Attribute zentral administriert.
Ungepflegte/Veraltete Attribute: Was nützen Attribute, wenn sie nicht befüllt werden? Es sollte gut überlegt werden, ob ein Attribut wirklich gebraucht wird. Noch schlimmer wird es, wenn übermäßig viel Attribute zu Pflichtfeldern gemacht werden. In dem Fall kann das Element nur angelegt werden, wenn alle Pflichtattribute befüllt sind. Das führt oft zu unsinnigen und nichtssagenden Platzhalter-Werten. Falsche oder veraltete Attribute können viel Schaden anrichten.
Alternativen zu Attributen
In vielen Fällen sind Attribute die richtige Wahl, um Meta-Informationen festzuhalten. Aber es lohnt sich darüber nachzudenken, ob in der einen oder anderen Situation nicht eine Alternative besser geeignet ist. Insbesondere sind sich viele Leser vielleicht gar nicht bewusst, dass es Alternativen gibt. Die folgende Liste zeigt fünf Alternativen, die ich persönlich für sehr effektiv halte.
Eine Referenzierung ist ein Verweis auf ein anderes Element. Eine Referenzierung ist dann sinnvoll, wenn die referenzierten Elemente sich ändern können.
Konkretes Beispiel: Bei einer Risikobewertung wird in der Regel eine Gefährdung (Hazard) betrachtet. Diese könnte man einfach als Aufzählungsliste anlegen, was sich als Drop-Down im Werkzeug manifestieren würde, also eine Liste von Hazard-Bezeichnern. Bei einer Referenzierung würde ein Element vom Typ „Hazard“ aus einer Bibliothek ausgewählt werden.
Der Unterschied: Der Typ Hazard könnte selbst noch mit weiteren Attributen versehen werden. Außerdem wären Hazards nun ein versioniertes Element: Kaum ein Werkzeug versioniert Aufzählungslisten – mir ist keines bekannt.
Bei einer Verlinkung gelten die selben Vorteile wie bei der Referenzierung, nur dass es hier um Aufzählungslisten geht, bei denen mehr als ein Wert ausgewählt werden können. Es gibt auch noch einen weiteren Vorteil: bei einer Verlinkung kann das Element für die Traceability herangezogen werden.
Auch hier ein Beispiel: Wenn wir das Risiko über Verlinkung einbinden, könnten wir eine Verlinkungskette betrachten: Zum Beispiel, welche Anforderungen für ein Bauteil sicherheitsrelevant sind, weil diese indirekt über ein Risiko miteinander verknüpft sind.
Alle Elemente, die einzeln versioniert werden, erlauben in der Regel auch sogenannte „Commit-Statements“. Das ist Freitext, der beim Speichern in der Datenbank dieser Version hinzugefügt wird.
Ein klassisches Attribut, welches besser in einem Commit-Statement unterkommen würde, ist „Rationale„, oder „Begründung“. Die Rationale kann sich über die Zeit ändern, und gerade für drastische Änderungen sollte der Grund festgehalten werden. Wenn zum Beispiel die Anzahl der Bildschirme von 1 auf 2 erhöht wird, dann sollte der Grund leicht zu finden sein, aber die Ursprüngliche Rationale nicht verloren gehen.
Brauchbar umgesetzt habe ich das in der Softwareentwicklung bei gitHub gesehen, wo über Dialoge sogar Aktionen ausgeführt werden. Wenn ein Entwickler einen Code committet, dann kann über den Commit-Text automatisch der entsprechende Bug aufgelöst werden.
Das Hauptproblem bei Commit-Statement ist, dass diese in vielen Werkzeugen stiefmütterlich behandelt werden. Dennoch sind diese bspw. bei einem Audit extrem nützlich.
Was in sozialen Medien funktioniert, kann auch in der Entwicklung funktionieren. Tags sind Bezeichner, die ad hoc an Elemente geheftet werden können. Das schöne an Tags ist, dass diese orthogonal zum Datenmodell sind. Ich schrieb ja oben, dass wir keinen Wildwachs beim Datenmodell haben wollen. Tags geben uns die Freiheit einer eigenen Strukturierung, ohne dabei das formale Vorgehen in Frage zu stellen. Jedes Projekt entwickelt in der Regel ein eigenes System, was die Kommunikation verbessert und die Produktivität des Teams damit erhöht.
Man kann sich zwar über eine Attributierung ein eigenes Tag-System basteln, das ist aber nicht empfehlenswert: Dadurch wird die Versionshistorie der Elemente „verschmutzt“, und gebastelte Tags haben in der Regel eine so schlechte Usability, dass sie gar nicht genutzt werden. Tags sollten nur dann verwendet werden, wenn das Werkzeug diese vernünftig unterstützt.
Wie viele wertvolle Informationen gehen in E-Mails verloren, oder verschwinden im Chat von Slack und ähnlichen Werkzeugen? Wenn wir diese Dialoge an unsere Elemente „tackern“ könnten, dann würde viel Meta-Information wie von selbst an der richtigen Stelle festgehalten werden.
Moderne Werkzeuge haben auch begonnen, dies zu ermöglichen. Ich erwähnte ja bereits gitHub, welches Kommunikation aktiv einbindet, um Informationen festzuhalten und Aktivitäten auszuführen.
In der Produktentwicklung ist Jama Software ein Beispiel, wo im Kontext eines Elements (z.B. einer Anforderung) Kommunikation initiiert werden kann. Die relevanten Teilnehmer werden per E-Mail informiert und können auch direkt per E-Mail antworten, aber der Dialog wird in Jama im Kontext der Anforderung festgehalten.
Dialoge können weiterhin als Frage, Entscheidung oder Problem (Issue) markiert werden, wodurch Entscheidungen nachvollziehbar werden. Über den Zustand der Dialoge (bspw. offene oder abgeschlossene Entscheidungen) werden dynamische Aufgabenlisten erzeugt und automatisch gepflegt. Im folgenden Screenshot ist rechts zu sehen, wie Jason und Peter einen Issue diskutieren, der von „Sample User“ entschieden wurde. Auf der linken Seite sind alle beteiligten Stakeholder und deren Rollen aufgeführt.
Fazit
Attribute sind wichtig und unentbehrlich – und wir werden sie auch weiterhin brauchen. Es gibt allerdings Meta-Informationen, die besser über andere Mechanismen festgehalten werden können. In diesem Artikel wurden ein paar Beispiele gebracht. Ich gehe davon aus, dass viele dieser Techniken über die nächsten Jahre mehr und mehr Verbreitung finden werden.
