Traceability im Usability Engineering

Während eines Softwareentwicklungsprozesses entstehen verschiedenste Teilergebnisse – da ist es nicht immer einfach, den Überblick zu bewahren. Dieser ist jedoch essentiell für die Fortschrittsüberwachung, die Analyse von Änderungsauswirkungen und die Begründung von (Design-)Entscheidungen. Was uns dabei helfen kann, genau diesen Überblick zu bewahren, kläre ich in diesem Blogartikel und stelle euch am Ende außerdem eine Übersicht zum Download bereit.

Teilergebnisse in der Softwareentwicklung oder kurz: Informationsflut

Stellt euch Folgendes vor: Ihr arbeitet als Usability Engineer in einem Softwareentwicklungsprojekt und dort mit verschiedenen anderen Rollen zusammen – Kunden und Stakeholdern, dem Marketing-Team, Entwicklern, Architekten, Testern und dem Projektleiter. Wie viele Teilergebnisse fallen schon in einem so durchschnittlichen Projekt an?

Alleine in der Anforderungsanalyse und -spezifikation führen wir z. B. Kontextinterviews durch, die verschiedene Teilergebnisse zur Folge haben: Interviewleitfaden, Kontextszenarien, Erfordernisse und daraus abgeleitete Nutzungsanforderungen. Auch aus anderen Anforderungsquellen haben wir Dokumente, die z. B. Stakeholder- und Marktanforderungen zusammenfassen. Zusätzlich gibt es vielleicht eine aggregierte Anforderungsliste, in der wir die Informationen aus den verschiedenen Dokumenten sammeln, sowie Personas, die diese Anforderungen übersichtlicher darstellen. Das sind alleine für diese Phase acht verschiedene Teilergebnis-Typen.

Auch die Gestaltungs-, Entwicklungs- und Testphase bringen Teilergebnisse wie Prototypen und Wireframes, Styleguides, Architekturen, Quellcode, Tickets, Usability Testaufgaben, Testprotokolle, Ergebnislisten, usw. hervor. Und als wäre das nicht genug, kommen aus dem normalen Projektalltag E-Mails, Meeting-Protokolle, Change Requests und vieles, vieles mehr dazu.

Mir stellt sich da eine wesentliche Frage:

Wie behalte ich den Überblick über alle Teilergebnisse?

Dass diese Frage beantwortet werden muss, ist klar – schon allein, weil wir in unserem Projektalltag mit verschiedenen Herausforderungen konfrontiert werden, die genau damit zusammenhängen.

Herausforderung 1: Überzeuge den Kunden von deiner Design-Entscheidung

Wie oft stecken wir in folgender Situation: Wir stellen dem Kunden ein Konzept oder Design vor und dieser stellt die getroffene Design-Entscheidung von Grund auf in Frage. Nun liegt es an uns, ihm deutlich zu machen, WARUM wir unsere Entscheidungen getroffen haben. Glücklicherweise wird im Usability Engineering nichts ohne Grund getan, das Problem ist nur, die zugehörigen Dokumente schnell genug finden zu können, um dem Kunden die Zusammenhänge direkt aufzeigen zu können.

Herausforderung 2: Weise nach, dass alle Anforderungen umgesetzt wurden 

Im Kundengespräch kommt immer wieder die Frage auf, wie eigentlich der aktuelle Projektstatus ist und ob alle Anforderungen umgesetzt werden. Doch wann gilt eine Anforderung als umgesetzt? Dies kann zum Beispiel der Fall sein, wenn ein Prototyp vorliegt, dieser implementiert wurde, die Implementierung in einem Usability Test und in einem Softwaretest geprüft wurde und die Ergebnisse positiv sind. Um diesen Zusammenhang visualisieren zu können, müssen wir jedoch zunächst den Status aller Anforderung und Teilergebnisse identifizieren – was einen enormen Aufwand mit sich bringt.

Herausforderung 3: Finde heraus, welche Anforderungen von einem Change Request betroffen sind

Nicht selten haben wir bereits wesentliche Arbeiten erledigt und bekommen dann doch noch einen Change Request vom Kunden herein, zum Beispiel eine Anforderungsänderung. Ist die Anforderung aber schon umgesetzt, sind mit ihr bereits toolübergreifende Teilergebnisse verknüpft z. B. Konzepte, Personas, Teile des Quellcodes oder Tests. Nun gilt es herauszufinden, auf welche Teilergebnisse sich die Anforderungsänderung noch bezieht – was allerdings bei der Vielzahl von Teilergebnissen gar nicht so einfach ist.

Herausforderung 4: Bekomme mit, wenn sich etwas geändert hat

Es klingt so einfach, doch es ist elementar, dass jede Rolle darüber informiert ist, wenn sich etwas geändert hat – und was! – und sich daraus Aufgaben ergeben. Der Entwickler muss beispielsweise mitbekommen, dass der Usability Engineer das Konzept abgeändert hat und er nun die Implementierung anpassen kann. 

Licht am Ende des Tunnels

Das Gute ist: Alle Teilergebnisse, die in einem Entwicklungsprozess entstehen, hängen irgendwie zusammen. Exemplarisch skizziert, sieht dieser Zusammenhang so aus:

Gerade im Usability Engineering gibt es ein vordefiniertes Schema wie Nutzungsanforderungen erhoben werden, das den Zusammenhang zwischen Teilergebnissen deutlich macht: So haben wir Leitfragen für Kontextinterviews, die wiederum in Protokollen resultieren. Aus diesen leiten wir nacheinander Kontextszenarien, Erfordernisse und Nutzungsanforderungen ab. Haben wir eine konsolidierte Anforderungsliste, greift diese wiederum auf die Nutzungsanforderungen sowie auf andere Anforderungsdokumente zu, eventuell auch auf Anforderungen aus E-Mails. Auch Change Requests fließen dort ein. Die konsolidierte Anforderungliste wiederum ist die Basis für Personas, diese wiederum für Nutzungsszenarien, welche eine Brücke zum Prototyping darstellen. Die Prototypen sind Grundlage für den Quellcode und so weiter... In der Regel ist kein Teilergebnis und keine Anforderung losgelöst von allen anderen.

Traceability als Lösungsansatz

Ist man sich dieser Verbindung bewusst, ist der erste Schritt getan, der die Basis für einen konkreten Lösungsansatz bietet: Traceability Management.

Konkret bedeutet Traceability, ein Verständnis davon zu haben, woher Teilergebnisse kommen und wie sie miteinander in Verbindung stehen. Dazu müssen Verlinkungen zwischen einzelnen Teilergebnissen, wie in der obigen Grafik, hergestellt werden: Wir verlinken ein konkretes Kontextszenario mit einem konkreten Erfordernis, dieses mit einer konkreten Nutzungsanforderung, usw. Die Links helfen dabei, schnell zwischen Artefakten hin- und herzunavigieren und ersparen uns lange Suchzeiten.  Die Zusammenhänge können außerdem schnell grafisch visualisiert werden. Doch ein lückenloses Traceability Management ermöglicht uns noch mehr.

Traceability als Argumentationsstütze

Schauen wir zurück auf unsere Herausforderungen. Wollen wir den Kunden davon überzeugen, dass unsere Design-Entscheidungen nicht aus der Luft gegriffen sind, müssen wir ihm nur die Visualisierung der Verlinkungen zeigen. So sieht er genau, welche Aspekte die Design-Entscheidungen beeinflusst haben. Gleichzeitig können wir über die Visualisierung schnell zu den verlinkten Artefakten navigieren und sparen uns dadurch das umständliche Suchen und Öffnen von Dokumenten.

Traceability als Hilfe zum Fortschrittstracking

Haben wir alle Elemente verlinkt, können wir diese Verlinkungen nutzen, um den Status der Anforderungen zu identifizieren. Wir müssen nur noch eine Auswertung über den aktuellen Verlinkungsstatus machen und können sehen, für welche Anforderungen bereits Links gesetzt sind – diese gelten dann als umgesetzt. Für alle anderen Anforderungen können wir uns anzeigen lassen, bis zu welchem Teilergebnis diese bereits verlinkt sind und daraus offene Aufgaben ableiten.

Traceability als Werkzeug für eine Impact Analyse

Durch die Visualisierung der Verlinkungen können wir bei Change Requests schneller eine Impact Analyse – also eine Aufwandsschätzung – durchführen: Wir sehen direkt, welche Teilergebnisse mit einer Anforderung verbunden sind, können zu den Teilergebnissen navigieren und prüfen, wie umfangreich diese sind. Auf diese Art wird eine realistische Aufwandsschätzung ermöglicht.

Traceability zur Änderungsverfolgung

Das Vorhanden- oder Nicht-Vorhandensein von Links kann uns auch zeigen, ob wir in unserer Rolle offene Aufgaben haben oder nicht. Liegt beispielsweise für einen Prototypen noch kein Link zu einer Implementierung vor, heißt das, dass hier noch Entwicklung betrieben werden muss. Ob sich bereits bestehende Links geändert haben, kann außerdem durch automatische Validierungen geprüft werden.

Die Notwendigkeit werkzeugübergreifender Traceability

Der Einsatz von Traceability kann also prinzipiell in verschiedenen Situationen helfen. Es gibt jedoch ein wesentliches Problem: Die verschiedenen Rollen im Entwicklungsprozess arbeiten meist in verschiedenen Tools. Das bedeutet, dass wir eine werkzeugübergreifende Nutzung ermöglichen müssen, um wirklich alle Vorteile der Traceability nutzen zu können. Anwendungen, die nur Verlinkungen zwischen Teilergebnissen innerhalb des Tools oder zu ein oder zwei anderen Tools ermöglichen, bringen uns dauerhaft nicht weiter.

YAKINDU Traceability – Unterstützung für den gesamten Projektprozess

Das Tool YAKINDU Traceability ermöglicht uns genau das: die Herstellung einer zuverlässigen und lückenlosen Traceability über verschiedene Tools hinweg. Es bietet die Möglichkeit, den oben genannten Herausforderungen erfolgreich zu begegnen und unterstützt auf diese Weise den gesamten Projektprozess.