Was braucht man zum Gedankenlesen?

Wäre es nicht wunderbar, wenn wir wissen könnten, was unsere Entwickler sich dabei gedacht hatten, als sie sich für die eine oder die andere Lösung entschieden? Alles nichts Neues! Das Thema Traceability geht dieser Idee nach. In einem der vorangegangenen Artikel (Link), vom 3. April 2012, haben wir mögliche Ziele vorgestellt, die durch Traceability erreicht werden sollen. Heute möchten wir diese Ziele zur Diskussion stellen und das Thema Traceability einmal unter einem anderen Licht betrachten.

Oft wird unter Traceability das Verfolgen von Entwicklungsartefakten verstanden. Von welcher abstrakten Anforderung leiten sich welche detaillierten Anforderungen ab? Welche Testfälle prüfen Lösungen gegen welche Anforderungen? Welche Realisierungen/Implementierungen ergeben sich aus den Anforderungen? Diese und weitere Entwicklungsartefakte sind Ergebnisse, die aus einem kreativen Lösungsprozess entstehen. Die Protagonisten – Wissensarbeiter – die Entwicklungsartefakte herstellen sind u.a. Entwickler, Konstrukteure, Architekten, Analysten, Requirements- und Testengineers.

Traceability – als ein Verfolgen von Entwicklungsergebnissen

Was für Erkenntnisse gewinnen wir aus der Verfolgbarkeit? Wir können sehen, welche „groben Lösungen“ mit welchen „detaillierten Lösungen“ zusammenhängen. Ein einfaches Beispiel nur mit Anforderungen und ohne Anspruch auf Vollständigkeit :

• Anforderung 1: Eine Leiter muss eine Lebensdauer von 10 Jahren oder 17.500 TIS (Time in Service – bisher Betriebsstunden) gewährleisten.
• Anforderung 1.1: Die Leiter darf nicht durch Oxydation beschädigt werden.
• Anforderung 1.2: Die Leiter muss eine mechanische Belastung von 200 kg gewährleisten.
• Anforderung 1.2.1: Die Profilteile müssen nach Konstruktion ABC gewalzt werden.
• Anforderung 1.2.2: Jedes Trittteil muss mit 8 YXB-Nieten gemäß Konstruktion LTE verbunden werden.
• Anforderung 1.1/2.3: Alle Teile müssen aus Aluminium-Legierung 6063 T5 gefertigt werden.

Verfolgbarkeit von Anforderungen

Wir können also erkennen welche Lösungen zusammenhängen. Damit können wir auch annehmen, wenn sich eine Anforderung ändert, ändern sich möglicherweise auch abgeleitete oder übergeordnete Anforderungen. Zum Beispiel: wenn sich Anforderung 1.2 wie Folgt ändert:

• Anforderung 1.2′: Die Leiter muss eine mechanische Belastung von 500 kg gewährleisten.

Das könnte dazu führen, dass statt einer Aluminium- eine Stahl-Legierung 708A25 (BS) verwendet werden muss. Auch könnte es sein, dass in der übergeordneten Anforderung 1, die Anzahl der Betriebsstunden auf 10.000 TIS geändert werden muss. Sie merken schon, irgendwie können wir auf Grund der Verfolgbarkeit nur Indizien ermitteln. Um die Auswirkungen der Anforderungsänderung wirklich bewerten zu können, müssten wir verstehen, warum welche Lösungen gewählt worden sind. Mit der Verfolgbarkeit alleine können wir Änderung also nicht fundiert bewerten.

Traceability – mehr als Verfolgbarkeit

Damit die Änderung aus unserem Beispiel beurteilt werden könnte, müssen wir Lösungen nachvollziehen können. Wir brauchen eine Nachvollziehbarkeit für Entwicklungsartefakte. Das ist mehr als die Verfolgbarkeit, denn für unser Beispiel heißt das, dass wir zur Anforderung 1.2.1 die Konstruktionszeichnung ABC und die Testfälle kennen müssen. Nur in diesem Kontext wäre es möglich, Lösungsalternativen zu beurteilen und zu definieren.

Während in der Konstruktion physische Grenzen (Gewicht, Formen, Materialeigenschaften, Verarbeitungsverfahren usw.) den Lösungsspielraum oft stark einschränken und damit viel Kontext schaffen, sind in der Softwareentwicklung eher wenige Grenzen vorhanden. Prozessor-, Speicher- oder Netzwerkleistungen limitieren die Lösungsalternativen immer weniger. Moderne Programmiersprachen lassen dem Entwickler ebenfalls viel Freiraum. Gerade in diesem Umfeld ist eine Nachvollziehbarkeit von Lösungsvarianten ohne geeigneten Kontext sehr schwierig. Traceability – im Sinne von Nachvollziehbarkeit – kann solch einen Kontext durch (klassisches) Verlinken einzelner Entwicklungsartefakte (u.a. Anforderungen mit Source-Code Dateien) nicht herstellen. Einer der Gründe sind Softwarelösungen, also definierte Methoden, Datenstrukturen, Variablen und Objekte, die sich in Codeblöcken – auch unterschiedlicher Dateien – befinden.

Kontext mit Change Sets

Um also geeignete Kontexte herzustellen, brauchen wir andere Methoden als die Verlinkung von Entwicklungsartefakten. Eine solche Methode ist das Verwenden von Change Sets.

Nachvollziehbarkeit von Lösungen

Change Sets sind Kontexte, die beim Implementieren entstehen. Bei jedem Check-in entsteht ein Minimalinkrement, bestehend aus den veränderten Source-Code-Dateien, den damit umgesetzten Requirements und den durchgeführten Test Cases. Die Bezeichnung des Change Sets mittels semantischen Tag benennt den Kontext der Änderung, zum Beispiel „sleep function“.

Check-ins müssen definierten Qualitätskriterien entsprechen, also beispielweise muss der Code dem Styleguide entsprechen, Unit-Tests erfolgreich und die relevanten Entwicklungsergebnisse (Requirements und Test Cases) im Change Set enthalten sein. Change Sets entstehen nach jedem Entwicklungs- /Lösungsschritt in der Implementierung, also im besten Fall mehrmals am Tag. Der Kontext ist dadurch entsprechend überschaubar und kann relativ leicht nachvollzogen werden.

Eine klassische Verlinkung der Entwicklungsergebnisse im Change Set ist nicht notwendig. Die Semantik der Relationen zwischen Requirements, Implementierung und Tests sind disjunkt und damit eindeutig interpretierbar definiert. Der Aufwand die Traceability herzustellen reduziert sich auf die ggf. zusätzliche Zuordnung von realisierten Requirements und relevanten Test Cases – welche semantisch vor einer Implementierung bekannt sein sollten. Die Zuordnung der Entwicklungsergebnisse wird mit der Zugehörigkeit zu einem Change Set nachvollziehbar dokumentiert. Es entsteht beim Check-in eine Mini-Baseline. Change Sets können dann miteinander verglichen werden und stellen versionierte Stände für Branching- und Merging-Strategien bereit.

Diese Methode lässt sich selbstverständlich auf andere Realisierungsebenen – neben der Codierung von Software – übertragen. Es wird damit systematisch möglich, überschaubare Deltas zwischen Inkrementen nachzuvollziehen. Somit können bei jedem „debugging“ passende Kontexte zur Verfügung stehen, mit denen Erweiterungen bzw. Änderungen noch besser beurteilt werden können.

Mit dieser – nicht nur aufwandoptimierten – Methode der Change Sets kann Traceability im Sinne nachvollziehbarer Lösungen Wirklichkeit werden. Die eingangs gestellte Frage: Was braucht man zum Gedankenlesen? lässt sich beantworten: passender Kontext aus Requirement (Was wird gefordert?), Implementierung (Wie ist es realisiert?) und Test (Nachweis, dass die Realisierung der Forderungen entsprechen.).

Jens Donig

Kontaktieren Sie Jens Donig

Jens Donig ist systemischer Coach (dvct) und Principal Consultant für Software- und Systems- Engineering. Die Schwerpunkte seiner Coaching- und Beratungstätigkeit liegen in den Bereichen Organisationsentwicklung, Teamentwicklung und der persönlichen Entwicklung seiner Kunden. Seit mehreren Jahren beschäftigt er sich mich intensiv mit der nachhaltigen Verankerung von Veränderungsprozessen in Organisationen verschiedener Branchen. Auf Basis des systemischen Coachings, von Transformationsprozessen und agiler Werte und Prinzipien, begleitet er seine Kunden erfolgreich auf ihrem persönlichen Weg der Weiterentwicklung und Veränderung.