0

So bezwingt man das Traceability-Monster

„Wie sichern Sie, dass …?“ lautet die oft missbrauchte Floskel eines Auditors. Wie sichern Sie, dass keine Aufgaben verloren gehen? Wie sichern Sie, dass die Ablage immer konsistent bleibt? Wie sichern Sie, dass das Design den Anforderungen entspricht? Wie sichern Sie, dass Sie es sichern können? Die Rekursivität dieser Frage ist offensichtlich oft aber scheinbar nur für Außenstehende. Diese fragwürdige Fragetechnik trägt Mitschuld daran, dass Prozessqualität im Softwarebusiness vielerorts als irrelevant oder gar schädlich angesehen wird.

Doch nicht nur Prozessberater sind häufig Opfer des eigenen Mangels an Professionalität und Sensibilität; die generalisierende Ablehnung sinnvoller Praktiken bedeutet einen Rückschlag für die Softwareindustrie. Einige Schlüsselkonzepte sollten definitiv nicht geopfert werden, allen voran das Prinzip der „Traceability“: der Nachvollziehbarkeit von Arbeitsergebnissen.

Worauf zielt Traceability ab? Auf dem Weg von Anforderungen bis zum fertigen System werden verschiedene Aktivitäten und Arbeitsprodukte benötigt: Projektplan, Anforderungsunterlagen, Design, Testfälle, Change Requests etc. Die Entwicklung „aus dem Hirn auf den Schirm“, die sich häufig als besonders agil hoher Beliebtheit erfreut, birgt die Gefahr, dass sich ungünstige Informationsmonopole bilden, die den Hergang der hergestellten Softwaremodule verschleiern und dazu führen, dass irgendwann niemand mehr weiß, warum bestimmte Systemeigenschaften überhaupt implementiert wurden.

Interessant sind dabei folgende Traceability-Pfade:

1.       Anforderungen <-> Planung

2.       Anforderungen <-> Design <-> Code

3.       Anforderungen/Design <-> Test

1. Anforderungen <-> Planung

Der Projektverantwortliche möchte wissen, wann welche Anteile des Lastenhefts umgesetzt werden. Was wurde nun fertig und kann dem Kunden gezeigt werden? Welche Anforderungen oder Anforderungsblöcke gelten als besonders riskant und sollten früh umgesetzt werden?

Diesen Traceability-Pfad nenne ich „orthogonal“, weil er nicht entlang des V-Modells, sondern orthogonal zu ihm verläuft.

2. Anforderungen <-> Design <-> Code

Damit das System sinnvoll entworfen werden kann, müssen Entwickler ihre Anforderungen kennen und ins Design umsetzen. Dabei geht es vor allem um Schnittstellen und ihre Definition. Die Beschaffenheit der Schnittstellen bestimmt letztendlich das Gesamtdesign, denn das System hat schließlich die Aufgabe, an den Schnittstellen zur Außenwelt das Richtige zu liefern bzw. zu empfangen (Blackbox-Prinzip).

Gleiches gilt für die Umsetzung des Designs: Entwickler müssen interne Schnittstellen kennen, um den dahinter verborgenen Code entwickeln zu können.

Dieser Pfad gewinnt besondere Bedeutung, wenn sich Anforderungen ändern. Man muss schnell entscheiden können, wie teuer eine neue bzw. veränderte Anforderung wird – und das geht am einfachsten, wenn dieser Traceability-Pfad funktioniert.

Diesen Traceability-Pfad nenne ich „vertikal“, weil er entlang des linken Armes des V-Modells verläuft.

3. Anforderungen/Design <-> Test

Dieser Pfad ist besonders interessant, denn hier geht es um Qualitätssicherung, die sogar in den agilsten Methodikansätzen ihren festen Platz hat. Anforderungen ergeben nur dann einen Sinn, wenn sie testbar sind – aber testen wir sie auch tatsächlich? Das kann man nur dann zufriedenstellend beantworten, wenn zwischen den Testfällen auf allen Ebenen (Systemtest, Integrationstest, Unit Test) und ihren Anforderungen (Systemanforderungen, Design, Moduldesign) eine feste Verknüpfung besteht.

Diesen Traceability-Pfad nenne ich „horizontal“, weil er zwischen den Armen des V-Modells verläuft.

Im V-Modell sind die Pfade wie folgt abzubilden:

Abbildung 1 Traceability-Pfade im V-Modell

Dieses scheinbar simple Traceability-Prinzip ist schnell postuliert, oft jedoch schwer umzusetzen. Vor allem beim vertikalen Traceability-Pfad stellt sich die Frage nach der Granularität: Wie fein sollten die einzelnen Arbeitsergebnisse miteinander verbunden sein? Wie kann man das Design überhaupt mit den Anforderungen verbinden? Auf Zeilenebene? Auf Modulebene? Per Schnittstelle oder für jede Schnittstellenfunktion und Anforderung?

Ich habe Projekte gesehen, in denen Anforderungen in DOORS zeilenweise mit der textuellen Designbeschreibung verlinkt wurden. In dieser Flut von Links ging der eigentliche Inhalt häufig unter, und jede Änderung der Anforderungs- und Designdokumentation wuchs sich wegen der Pflicht zur Linkpflege zur Qual aus. Traceability ist vielfach von einer sinnvollen Anforderung zu einem verhassten, dem mystischen Prozesssumpf entstiegenen Monster mutiert, das dem Projektteam schnell lästig und schlussendlich zur Erleichterung aller Beteiligten abgeschafft wird.

Die Lösung dieses Dilemmas besteht in einer Lockerung der Traceability-Granularität. Anstatt Anforderungen und Design zeilenweise zu verlinken, können ganze Use Cases mit ihren Realisierungen im Designkontext verbunden werden:

Abbildung 2 Lösung für Vertikale Traceability zwischen Anforderungen und Design

Diese einfache Systematik erlaubt es, die Anforderungen in Use Cases auf Systemschnittstellen („Aktionen“ im obigen Diagramm) zu „mappen“ und somit eine Verbindung zwischen Anforderungen und Systemschnittstellen herzustellen.

Besonders zielführend ist die grobe Granularität dieses Ansatzes. Anstatt einzelne Funktionen an Passagen im Anforderungskatalog zu knüpfen, werden Teilmengen von Anforderungen mit Teilmengen von Schnittstellendefinitionen verbunden. Ein Nachteil dieser Vorgehensweise stellt die resultierende Unschärfe dar: In welcher Schnittstelle wurde nun welche Anforderung abgebildet? In der Praxis fällt das jedoch nicht ins Gewicht, denn für einen erfahrenen Entwickler ist diese Frage leicht zu beantworten. Mit diesem pragmatischen Ansatz entsteht eine „semantische“ Traceability, die in der Praxis deutlich einfacher zu verwalten ist als die starre „syntaktische“ Traceability, die satz- und zeilenweise erfolgt und in ihrer Anwendung erheblich mehr Aufwand verursacht.

Keine Angst vor Prozessmonstern

Dieses simple Traceability-Konzept – Teil unserer SlimTrace-Initiative – ist branchenneutral, einfach in der Anwendung und vielfach praxisbewährt. Der Traceability-Pfad wird als Struktur in einem CASE-Tool umgesetzt, das man für wenige Hundert Euro erwerben kann und ohnehin in jedem objektorientierten Projekt benötigt. Die Vorteile dieser Praxis liegen auf der Hand: Nicht nur ist eine CMMI- und SPICE-konforme, vertikale Traceability „billig“ zu haben; ein systematischer Übergang von Anforderungen ins Systemdesign gestaltet sich unkompliziert und redundanzfrei. Somit hat man ein weiteres Prozessmonster bezwungen.

Auch andere Prozessqualitätsvorgaben sind einfacher zu realisieren als angenommen. Dazu mehr demnächst auf diesen Seiten.

 

„Wie sichern Sie, dass…“ ist die oft missbrauchte Floskel eines Auditors. Wie sichern Sie, dass keine Aufgaben verlorengehen? Wie sichern Sie, dass die Ablage immer konsistent bleibt? Wie sichern Sie, dass das Design den Anforderungen entspricht? Wie sichern Sie, dass Sie es sichern können? Die Rekursivität dieser Frage ist offensichtlich – aber scheinbar oft nur für Außenstehende. Diese fragwürdige Fragetechnik trägt Mitschuld daran, dass Prozessqualität im Softwarebusiness vielerorts als irrelevant und gar schädlich angesehen wird. Dumm gelaufen und selber schuld.

Doch nicht nur Prozessberater sind Opfer des eigenen Mangels an Professionalität und Sensibilität; Die generalisierende Ablehnung sinnvoller Praktiken ist ein Rückschlag für die Softwareindustrie. Einige Schlüsselkonzepte sollten definitiv nicht geopfert werden, allen voran das Prinzip der „Traceability“ – der Nachvollziehbarkeit von Arbeitsergebnissen.

Was bedeutet „Traceability“? Auf dem Weg von Anforderungen bis zum fertigen System werden verschiedene Aktivitäten und Arbeitsprodukte benötigt: Projektplan, Anforderungsunterlagen, Design, Testfälle, Change Requests, etc. Die Entwicklung „aus dem Hirn auf den Schirm“, die sich häufig als besonders agil hoher Beliebtheit erfreut, birgt die Gefahr, dass sich ungünstige Informationsmonopole bilden, die den Hergang der hergestellten Softwaremodule verschleiern und dazu führen, dass niemand mehr weiß, warum bestimmte Systemeigenschaften überhaupt implementiert wurden.

Interessant sind dabei folgende Traceability-Pfade:

1.Anforderungen <-> Planung

2.Anforderungen <-> Design <-> Code

3.Anforderungen/Design <-> Test

1. Anforderungen <-> Planung

Der Projektverantwortliche möchte wissen, wann welche Anteile des Lastenhefts umgesetzt werden. Was wurde nun fertig und kann dem Kunden gezeigt werden? Welche Anforderungen oder Anforderungsblöcke sind besonders riskant und sollten früh umgesetzt werden?

Diesen Traceability-Pfad nenne ich „orthogonal“, weil er nicht entlang, sondern orthogonal zu dem V-Modell verläuft.

2. Anforderungen <-> Design <-> Code

Damit das System sinnvoll entworfen werden kann, sollten Entwickler ihre Anforderungen kennen und ins Design umsetzen. Dabei geht es vor allem um Schnittstellen und ihre Definition. Die Beschaffenheit der Schnittstellen bestimmt letztendlich das Gesamtdesign, denn das System hat ultimativ die Aufgabe, an den Schnittstellen zur Außenwelt das Richtige zu liefern bzw. zu empfangen (das Blackbox-Prinzip).

Gleiches gilt für die Umsetzung des Designs: Entwickler müssen interne Schnittstellen kennen, um den dahinter verborgenen Code entwickeln zu können.

Dieser Pfad ist besonders wichtig, wenn sich Anforderungen ändern. Man möchte schnell entscheiden, wie teuer eine neue bzw. veränderte Anforderung wird – und dass geht am einfachsten, wenn dieser Traceability-Pfad funktionert.

Diesen Traceability-Pfad nenne ich „vertikal“, weil er entlang des linken Armes des V-Modells verläuft.

3. Anforderungen/Design <-> Test

Dieser Pfad ist besonders interessant, denn hier geht es um Qualitätssicherung, die sogar in den agilsten Methodikansätzen ihren festen Platz hat. Anforderungen sind nur dann sinnvoll, wenn sie testbar sind – aber testen wir sie auch tatsächlich? Das kann man nur dann zufriedenstellend beantworten, wenn zwischen den Testfällen auf allen Ebenen (Systemtest, Integrationstest, Unittest) und ihren Anforderungen (Systemanforderungen, Design, Moduldesign) eine feste Verknüpfung vorhanden ist.

Diesen Traceability-Pfad nenne ich „horizontal“, weil er zwischen den Armen des V-Modells verläuft.

Im V-Modell sind die Pfade wie folgt abzubilden:

Abbildung 1 V-Modell und Traceability

Dieses scheinbar simple Traceability-Prinzip ist leicht zu postulieren jedoch oft schwer umzusetzen. Vor allem bei dem vertikalen Traceability-Pfad stellt die Frage nach der Granularität: wie fein sollten die einzelnen Arbeitsergebnisse miteinander verbunden sein? Wie kann man das Design überhaupt mit den Anforderungen verbinden? Auf Zeilenebene? Auf Modulebene? Per Schnittstelle oder für jede Schnittstellenfunktion und Anforderung?

Ich habe Projekte gesehen, in den Anforderungen in DOORS zeilenweise mit der textuellen Designbeschreibung verlinkt wurde. In dieser Flut von Links ging der eigentliche Inhalt häufig unter, und jede Änderung der Anforderungs- und Designdokumentation wurde wegen der Pflicht zur Link-Pflege zur Qual. Die Traceability hat sich aus einer sinnvollen Anforderung zu einem verhassten Monster das entwickelt, das aus dem mystischen Prozesssumpf kam, und das dem Projektteam schnell zur Last wurde und schlussendlich zur Erleichterung aller Beteiligten abgeschafft wurde.

Die Lösung dieses Dilemmas besteht in einer Lockerung der Traceability-Granularität. Anstatt Anforderungen und Design zeilenweise zu verlinken können ganze Use Cases mit ihren Realisierungen im Design-Kontext verbunden werden:

Abbildung 2Lösung für Vertikale Traceability zwischen Anforderungen und Design

Diese einfache Systematik erlaubt es, die Anforderungen in Use Cases auf Systemschnittstellen („Aktionen“ im obigen Diagramm) zu „mappen“, und somit eine Verbindung zwischen Anforderungen und Systemschnittstellen herzustellen.

Besonders hilfreich ist die grobe Granularität dieses Ansatzes. Anstatt einzelne Funktionen an Passagen im Anforderungskatalog zu knüpfen, werden so Teilmengen von Anforderungen mit Teilmengen von Schnittstellendefinition verbunden. Ein Nachteil dieser Vorgehensweise stellt eine damit einhergehende Unschärfe dar: in welcher Schnittstelle wurde nun welche Anforderung abgebildet? In der Praxis funktioniert dies aber gut, denn einen erfahrenen Entwickler ist dies eine leicht zu beantwortende Frage. Mit diesem pragmatischen ist eine „semantische“ Traceability geschaffen, die in der Praxis deutlich einfacher zu verwalten ist als die starre „syntaktische“ Traceability, die satz- und zeilenweise erfolgt und in ihrer Anwendung erheblich aufwendiger ist.

„Wie sichern Sie, dass…“ ist die oft missbrauchte Floskel eines Auditors. Wie sichern Sie, dass keine Aufgaben verlorengehen? Wie sichern Sie, dass die Ablage immer konsistent bleibt? Wie sichern Sie, dass das Design den Anforderungen entspricht? Wie sichern Sie, dass Sie es sichern können? Die Rekursivität dieser Frage ist offensichtlich – aber scheinbar oft nur für Außenstehende. Diese fragwürdige Fragetechnik trägt Mitschuld daran, dass Prozessqualität im Softwarebusiness vielerorts als irrelevant und gar schädlich angesehen wird. Dumm gelaufen und selber schuld.

Doch nicht nur Prozessberater sind Opfer des eigenen Mangels an Professionalität und Sensibilität; Die generalisierende Ablehnung sinnvoller Praktiken ist ein Rückschlag für die Softwareindustrie. Einige Schlüsselkonzepte sollten definitiv nicht geopfert werden, allen voran das Prinzip der „Traceability“ – der Nachvollziehbarkeit von Arbeitsergebnissen.

Was bedeutet „Traceability“? Auf dem Weg von Anforderungen bis zum fertigen System werden verschiedene Aktivitäten und Arbeitsprodukte benötigt: Projektplan, Anforderungsunterlagen, Design, Testfälle, Change Requests, etc. Die Entwicklung „aus dem Hirn auf den Schirm“, die sich häufig als besonders agil hoher Beliebtheit erfreut, birgt die Gefahr, dass sich ungünstige Informationsmonopole bilden, die den Hergang der hergestellten Softwaremodule verschleiern und dazu führen, dass niemand mehr weiß, warum bestimmte Systemeigenschaften überhaupt implementiert wurden.

Interessant sind dabei folgende Traceability-Pfade:

1.       Anforderungen <-> Planung

2.       Anforderungen <-> Design <-> Code

3.       Anforderungen/Design <-> Test

1. Anforderungen <-> Planung

Der Projektverantwortliche möchte wissen, wann welche Anteile des Lastenhefts umgesetzt werden. Was wurde nun fertig und kann dem Kunden gezeigt werden? Welche Anforderungen oder Anforderungsblöcke sind besonders riskant und sollten früh umgesetzt werden?

Diesen Traceability-Pfad nenne ich „orthogonal“, weil er nicht entlang, sondern orthogonal zu dem V-Modell verläuft.

2. Anforderungen <-> Design <-> Code

Damit das System sinnvoll entworfen werden kann, sollten Entwickler ihre Anforderungen kennen und ins Design umsetzen. Dabei geht es vor allem um Schnittstellen und ihre Definition. Die Beschaffenheit der Schnittstellen bestimmt letztendlich das Gesamtdesign, denn das System hat ultimativ die Aufgabe, an den Schnittstellen zur Außenwelt das Richtige zu liefern bzw. zu empfangen (das Blackbox-Prinzip).

Gleiches gilt für die Umsetzung des Designs: Entwickler müssen interne Schnittstellen kennen, um den dahinter verborgenen Code entwickeln zu können.

Dieser Pfad ist besonders wichtig, wenn sich Anforderungen ändern. Man möchte schnell entscheiden, wie teuer eine neue bzw. veränderte Anforderung wird – und dass geht am einfachsten, wenn dieser Traceability-Pfad funktionert.

Diesen Traceability-Pfad nenne ich „vertikal“, weil er entlang des linken Armes des V-Modells verläuft.

3. Anforderungen/Design <-> Test

Dieser Pfad ist besonders interessant, denn hier geht es um Qualitätssicherung, die sogar in den agilsten Methodikansätzen ihren festen Platz hat. Anforderungen sind nur dann sinnvoll, wenn sie testbar sind – aber testen wir sie auch tatsächlich? Das kann man nur dann zufriedenstellend beantworten, wenn zwischen den Testfällen auf allen Ebenen (Systemtest, Integrationstest, Unittest) und ihren Anforderungen (Systemanforderungen, Design, Moduldesign) eine feste Verknüpfung vorhanden ist.

Diesen Traceability-Pfad nenne ich „horizontal“, weil er zwischen den Armen des V-Modells verläuft.

Im V-Modell sind die Pfade wie folgt abzubilden:

 

Abbildung 1 V-Modell und Traceability

Dieses scheinbar simple Traceability-Prinzip ist leicht zu postulieren jedoch oft schwer umzusetzen. Vor allem bei dem vertikalen Traceability-Pfad stellt die Frage nach der Granularität: wie fein sollten die einzelnen Arbeitsergebnisse miteinander verbunden sein? Wie kann man das Design überhaupt mit den Anforderungen verbinden? Auf Zeilenebene? Auf Modulebene? Per Schnittstelle oder für jede Schnittstellenfunktion und Anforderung?

Ich habe Projekte gesehen, in den Anforderungen in DOORS zeilenweise mit der textuellen Designbeschreibung verlinkt wurde. In dieser Flut von Links ging der eigentliche Inhalt häufig unter, und jede Änderung der Anforderungs- und Designdokumentation wurde wegen der Pflicht zur Link-Pflege zur Qual. Die Traceability hat sich aus einer sinnvollen Anforderung zu einem verhassten Monster das entwickelt, das aus dem mystischen Prozesssumpf kam, und das dem Projektteam schnell zur Last wurde und schlussendlich zur Erleichterung aller Beteiligten abgeschafft wurde.

Die Lösung dieses Dilemmas besteht in einer Lockerung der Traceability-Granularität. Anstatt Anforderungen und Design zeilenweise zu verlinken können ganze Use Cases mit ihren Realisierungen im Design-Kontext verbunden werden:

 

Abbildung 2 Lösung für Vertikale Traceability zwischen Anforderungen und Design

Diese einfache Systematik erlaubt es, die Anforderungen in Use Cases auf Systemschnittstellen („Aktionen“ im obigen Diagramm) zu „mappen“, und somit eine Verbindung zwischen Anforderungen und Systemschnittstellen herzustellen.

Besonders hilfreich ist die grobe Granularität dieses Ansatzes.  Anstatt einzelne Funktionen an Passagen im Anforderungskatalog zu knüpfen, werden so Teilmengen von Anforderungen mit Teilmengen von Schnittstellendefinition verbunden. Ein Nachteil dieser Vorgehensweise stellt eine damit einhergehende Unschärfe dar: in welcher Schnittstelle wurde nun welche Anforderung abgebildet? In der Praxis funktioniert dies aber gut, denn einen erfahrenen Entwickler ist dies eine leicht zu beantwortende Frage. Mit diesem pragmatischen ist eine „semantische“ Traceability geschaffen, die in der Praxis deutlich einfacher zu verwalten ist als die starre „syntaktische“ Traceability, die satz- und zeilenweise erfolgt und in ihrer Anwendung erheblich aufwendiger ist.

Keine Angst vor Prozessmonstern

Dieses simple Traceability-Konzept – Teil unserer SlimTrace-Initiative – ist branchenneutral, einfach in Anwendung und praxisbewährt. Der Traceability-Pfad wird als Struktur einem CASE-Tool  umgesetzt, das man für wenige hundert Euro erwerben kann und ohnehin in jedem objektorientierten Projekt benötigt. Vorteile dieser Praxis liegen auf der Hand: nicht nur ist eine CMMI- und SPICE-konforme, vertikale Traceability „billig“ zu haben; ein systematischer Übergang von Anforderungen ins Systemdesign ist unkompliziert und redundanzfrei. Somit hat man ein weiteres Prozessmonster bezwungen.

Auch andere Prozessqualitätsvorgaben sind einfacher zu realisieren als angenommen. Dazu mehr demnächst auf diesen Seiten.

Keine Angst vor Prozessmonstern

Dieses simple Traceability-Konzept – Teil unserer SlimTrace-Initiative – ist branchenneutral, einfach in Anwendung und praxisbewährt. Der Traceability-Pfad wird als Struktur einem CASE-Tool umgesetzt, das man für wenige hundert Euro erwerben kann und ohnehin in jedem objektorientierten Projekt benötigt. Vorteile dieser Praxis liegen auf der Hand: nicht nur ist eine CMMI- und SPICE-konforme, vertikale Traceability „billig“ zu haben; ein systematischer Übergang von Anforderungen ins Systemdesign ist unkompliziert und redundanzfrei. Somit hat man ein weiteres Prozessmonster bezwungen.

Auch andere Prozessqualitätsvorgaben sind einfacher zu realisieren als angenommen. Dazu mehr demnächst auf diesen Seiten.

_____________________________________________________________

Über den Autor

Roman MildnerRoman Mildner, zertifizierter Projektmanager (PMP) und Mitglied im United Mentors Network (UMN), ist seit 1992 in der IT und seit 1998 als unabhängiger Berater und Projektmanager tätig. Zu seinen Beratungsschwerpunkten gehören IT-Strategieberatung, Projektmanagment und Prozessberatung. Weitere Details finden sich auf seiner UMN-Seite. (S. auch Google)

Kommentar hinterlassen

Loggen Sie sich ein, wenn Sie ein registrierter Benutzer sind.




*