Traceability in Softwareprojekten: Rückverfolgbarkeit von Anforderungen als Schlüssel zum Erfolg

Haben Sie in Ihren Projekten Ihre Anforderungen und deren Status stets im Blick oder fühlen Sie sich dahingehend manchmal wie ein „Projektarchäologe“? Ein optimaler Grad an sogenannter „Traceability“ [1] (englisch für „Rückverfolgbarkeit“) zeigt Ihnen, welche Anforderungen umgesetzt sind und welche relevanten Artefakte (wie etwa Modelle, Source-Code, Testfälle, etc.) sich darauf zurückführen lassen.

Ursprünglich aus sicherheitskritischen Normen wie etwa der ISO 26262 der Automobilindustrie oder der IEC 62304 des Medizinsektors kommend, stellt diese Rückverfolgbarkeit von Anforderungen gemäß Business Analysis Book of Knowledge (BABOK) ein wesentliches Kernelement des „Requirement Lifecycle Managements“[2] dar. In einer Studie konnte nachgewiesen werden, dass Softwareentwickler Sourcecode-Änderungen, basierend auf Analysen mit einer guten Traceability-Unterstützung nicht nur schneller, sondern vor allem auch korrekter durchführen.[3] Und das Beste: Traceability ist sowohl in klassischen- als auch in agilen Projekten lebbar. Lesen Sie in meinem Blogbeitrag welche Arten von Traceability es gibt und wie Sie diese für Ihre Projekte planen und herstellen können.

In der Phase der Anforderungserhebung wird definiert, wie das zu bauende System funktionieren soll und welchen Anforderungen dieses genügen muss. Nachbesserungen von Fehlern oder Analyseänderungen durch Changes führen speziell bei der Recherche nach unzureichend verlinkten Quell- und Zielartefakten dieser Phase zu höheren Kosten und längeren Laufzeiten betroffener Projekte.

Eine gut aufgesetzte Traceability bereits zu Projektstart sichert ihnen hierbei die lückenlose Rückverfolgbarkeit ebendieser Projekt-Artefakte entlang des Softwareentwicklungsprozesses.

Vier Arten von Traceability gestalten Ihr Projekt jederzeit zurückverfolgbar!

Sämtliche in Projekten betroffene Artefakte haben unterschiedliche (bidirektionale) Traceability-Beziehungen, die ich Ihnen nun im Folgenden vorstellen möchte[4]

1. Pre-Requirement Traceability: Darunter versteht man die Beziehung der „Solution Requirements“ (=funktionale Anforderungen) mit den Geschäfts- und Stakeholderbedürfnissen.
2. Post-Requirement Traceability: Hierbei handelt es sich um die Beziehung zwischen den „Solution Requirements“ und deren Entwürfen, Codes und Tests.
3. Inner Requirement Traceability: Darunter versteht man die Beziehung sich voneinander abgeleiteten Business-, Stakeholder- und Solution-Requirements als auch die Rückverfolgbarkeit der Beziehungen von Anforderungen untereinander sowie zu Dokumenten eben dieser.
4. Requirements-to-Task Traceability: Hierdurch wird die Beziehung der geplanten technischen Umsetzung von Anforderungen bezeichnet, welche im Verlauf der Entwicklung realisiert wird.

Planung von Traceability in Softwareprojekten: Erst denken, dann Handeln

Projektverantwortliche sollten die Rückverfolgbarkeit der Anforderungen in einem Softwareprojekt schlank planen, dass diese durch Projektbeteiligte effizient, präzise und ohne „ausschweifender Überorganisation“ angewendet werden können. Auf die Festlegung der notwendigen Tiefe und Breite der Rückverfolgbarkeit haben viele Punkte Einfluss, wie etwa[5]

• die Komplexität des Projektes,
• die Zuordenbarkeit von Anforderungen zu (beliebigen) Artefakten,
• erhobene Risiken,
• organisatorische und behördliche Vorschriften und auch
• die Kosten und vor allem
• der eigentliche angestrebte Nutzen der Rückverfolgbarkeit sowie die
• Nutzung heterogener Werkzeuge entlang des Softwareentwicklungsprozesses die eine werkzeugübergreifende Traceability möglicherweise nicht erlauben – und daher aufwendig zusammengeführt werden müssen

Speziell in agilen Projekten ist der Fokus auf schlanke Traceability zu legen, um nicht unnötigerweise Waste-Artefakte (zB zur Erlangung einer Übersicht von Traceability-Artefakten) herzustellen, welche für das Zusammensuchen von Informationen die Produktivität des Teams ausbremst.

Nutzen optimaler Rückverfolgbarkeit

Durch optimale Rückverfolgbarkeit können eine Reihe erfolgskritischer Fragen im Projekt lückenlos beantwortet werden, wie etwa:

• Welchem Stakeholder ist welche Anforderung wie wichtig?
• Welche Businessziele sollten ursprünglich mit der Anforderung erreicht werden? Trägt die geänderte Anforderung nach wie vor dazu bei?
• Welche anderen – in Beziehung stehenden Anforderungen – sind von Änderungen ggf. betroffen?
• Welche Anforderungen werden durch welche technischen Komponenten realisiert?
• Welche technischen Komponenten realisieren welche Anforderungen?
• Welche Arbeitspakete realisieren eine Anforderung?
• Welche Testfälle müssen ausgeführt werden, falls eine technische Komponente geändert wurde?
• Welche Fehler treten (bzw. traten) für eine Anforderung auf?
• Welche Arbeitspakete dienen der Behebung eines Fehlers?
• Etc.

Zusammenfassen lassen sich obige Fragestellungen auf folgende vier Analysetypen, die Ihnen im Projektcontrolling hilfreich sein werden:

Drei Schritte zur Herstellung einer optimalen Traceability in Ihren Softwareprojekten

Aus meiner Erfahrung in der Business Analyse gibt es keinen vorgeschriebenen Weg, der in jedem Projekt auf gleiche Art und Weise die Traceability bestmöglich standardisiert. Letztendlich ist dies auch eine Kosten-Nutzen Frage, da das Verlinken von Dokumenten, vor allem mit Tools die bspw. eine ständige Wartung nicht mehr aktueller Verlinkungen mit sich bringt die Projektdurchführung wesentlich verlangsamt. Mein Tipp wäre hierzu situativ pro Projekt das tracen festzulegen.

Ich möchte Ihnen nun im Folgenden Überlegungen zur Festlegung einer schlanken Projekt-Traceability vorstellen. Grundsätzlich sollte man „so viel Traceability wie nötig mit so wenig Aufwand wie möglich“ als oberste Prämisse führen.

Schritt 1: Legen Sie fest, welche Fragestellungen (siehe vorheriges Kapitel) Sie mit der Traceability lösen wollen. Ist Ihnen bspw. wichtig festzustellen welche Herkunft Ihre Artefakte haben?

Schritt 2: Festlegen, zu welchem Detaillierungsniveau Artefakte getraced werden. So kann es bspw. bei modellgetriebener Entwicklung sinnvoll hinsichtlich Post-Requirement Traceability sein eine Beziehung zwischen der Solutionanforderung und deren Modellierung zu legen, jedoch auf eine Beziehung bis in den Code hinein zu verzichten, vor allem wenn aus dem Modell umfangreicher Code generiert wird. Oder entscheiden Sie bspw. ebenfalls ob es bei der Inner Requirement Traceability notwendig ist sämtliche Dokumente mitzutracen.

Schritt 3: Definieren Sie WELCHE Requirement Traces sie aufgrund Schritt 1 und Schritt 2 brauchen und mit welchen Mitteln (grafisch oder z.B. via Excel) Sie diese festhalten wollen: Es gibt eine Fülle unterschiedlicher Beziehungs-Arten beim Tracen. Oftmals reichen einige wenige davon aus die, in Ihrem Projekt effektiv eingesetzt, zu einer schlanken und effizienten Tracability verhelfen. Beispiele hierfür sind etwa[6]:

• Derive-Beziehung zwischen übergeordneten- und ggf. verfeinerten untergeordneten Anforderungen (z.B. zwischen Stakeholderanforderung und Solutionanforderung)
• Satisfy-Beziehungen zwischen Elementen und Anforderungen
• Validate-Beziehungen zwischen Testfällen und Anforderungen
• Depends-Beziehungen zwischen zwei abhängigen Anforderungen
• etc.

Zusammenfassung

Es lassen sich viele Spuren zwischen Projekt-Artefakten legen, entscheidend ist jedoch für eine optimale Tracability-Lösung welche davon modelliert werden müssen um Ihr Projekt effektiv und effizient abwickeln zu können um die Vorteile der Rückverfolgbarkeit nutzen zu können.

Traceability ist nicht nur in sicherheitskritischen Projekten von Nutzen, sondern hilft Projektbeteiligten genaue Aussagen über das Projekt zu machen. Projektverantwortliche sind gut beraten der Traceability von Projektartefakten einen hohen Stellenwert in der Planung einzuräumen. Diesen Herausforderungen kann man beispielsweise mit aufeinander abgestimmten Tools und etablierten Prozessen bestmöglich begegnen.

Die Traceability kann vor allem durch die Auswahl eines passenden ADLM-Werkzeuges, dass diese bereits berücksichtigt, vereinfacht werden[7]. Traceability soll die Softwareentwicklung unterstützen und einfacher machen, nicht durch einer „Über-Traceability“ behindern. Ein Situatives tracen je Projekt, dessen Feststellung ich Ihnen im vorherigen Abschnitt vorgestellt habe, ist hierbei ein gutes Instrument, dass ihr Projekt optimal unterstützen kann.

Haben Sie Erfahrungen mit Traceability in Projekten gemacht die Sie mit mir teilen wollen? Ich würde mich freuen wenn Sie Ihre Erfahrungen hier mit mir teilen!

[1] Abzugrenzen von der Revisionssicherheit (Zurückverfolgung der Historie von Artefakten) und der Compliance (Einhaltung von Prozessen und Standards)

[2] BABOK v3, S. 75ff

[3]  https://link.springer.com/article/10.1007%2Fs10664-014-9314-z

[4] Vgl. BABOK v3, S. 90

[5] BABOK v3, S. 44

[6] Siehe BABOK, S. 81ff

[7] Siehe hierzu etwa http://www.anecon.com/blog/projektmanagement-mit-der-ibm-rational-suite/

The post Traceability in Softwareprojekten: Rückverfolgbarkeit von Anforderungen als Schlüssel zum Erfolg appeared first on ANECON Blog.