Skip to main content

Lästige Forderung von Normen oder hilfreiche Maßnahme zur Qualitäts- und Effizienzsteigerung?

Normen, die Safety-Aspekte adressieren, fordern ausnahmslos eine Traceability. Früher wurde dieser Forderung durch die aufwändige Erstellung und Pflege von sog. Cross-Referenz-Listen Genüge getan. Hinsichtlich Engineering-Effizienz ist die händische Pflege von CrossReferenz-Listen in Bezug auf Nutzen zu Aufwand sicher fragwürdig.

Heute gibt es Anforderungs-Management-Lösungen, mit denen das Erstellen und Pflegen von Linkbeziehungen um ein vielfaches einfacher möglich ist. Aber noch wichtiger, es können aus diesen Links dann je nach Kontext und Fragestellung sehr ausdrucksstarke Traceability-Analysen durchgeführt und dargestellt werden, was Cross-Referenz-Listen nicht leisten können.

Das wiederum ist nur möglich, wenn die Metastruktur der Linkbeziehungen die Daten so bereitstellt, wie sie für die Analyse benötigt werden, was in der Praxis leider selten der Fall ist. Bereits bei DOORS® , dem ‚Platzhirsch‘ der Anforderungs-ManagementLösungen, ist die Default-Einstellung der Linkbeziehungen so gewählt, dass alles mit Allem auf Basis eines Default Linktypes verlinkt werden darf. Projekte, in denen diese Default-Einstellung genutzt wird ohne eine Metastruktur zu konfigurieren landen nach wenigen Wochen im LinkGewirr, in dem über mehrere Ebenen hinweg alles mit Allem verlinkt und eine aussagekräftige Analyse nicht mehr möglich ist.

Dieser Engineering Report stellt im ersten Teil den Wirkmechanismus von Linkbeziehungen und darauf aufbauenden Traceability-Analysen dar.

Im zweiten Teil geht es dann um die häufigsten Fehler bei der Anwendung, die dazu führen, dass qualitative Traceability-Aussagen nicht möglich sind und damit der Effizienzgewinn nicht erzielt wird.

Komplexität

Um zu verstehen, in welcher Form die Traceability Einfluss auf die Qualität und damit auch auf die Effizienz ausübt, möchte ich mit einem Blick auf die Komplexität in das Thema einsteigen. Glaubt man den aktuellen Theorien zum Thema Komplexität, dann liegt das Hauptproblem in der Wirkkette: Hidden Links -> Emergenz -> Dysfunktion.

Das bedeutet, verborgene Abhängigkeiten führen bei Änderungen eines Gesichtspunktes des Systems zu sogenannten emergenten Zuständen in Bezug zu anderen Gesichtspunkten des Systems. Ein Zusammenhang beider Gesichtspunkte ist nicht offensichtlich und bildet einen Hidden Link. Emergente Zustände sind Zustände, die nicht erwartet werden und damit auch das Verhalten innerhalb dieser Zustände nicht definiert ist. Dieses kann wiederum zu Fehlverhalten (Dysfunktion) führen, was im schlimmsten Fall Schaden verursachen kann.

∨ mehr Text anzeigen

Hier sehen wir den Zusammenhang zu Safety Gesichtspunkten. Am Ende soll sicher gestellt werden, dass ein System keinen Schaden anrichtet, also Dysfunktion vorgebeugt wird. Gehen wir noch einen Schritt zurück. Wie entstehen denn überhaupt die sogenannten Hidden Links? Ein Basis Mechanismus, der seit Jahrzehnten im Engineering eingesetzt wird, um steigender Kompliziertheit zu begegnen ist ‚Teile & Herrsche‘. Im Engineering unter anderem auch in Form von hierarchischer Dekomposition angewandt. Bei jeder Teilung einer Einheit in zwei Teileinheiten ergeben sich potentiell neue Schnittstellen. Wie in der Abbildung Nr. 1 zu sehen ist wächst bei zunehmender Teilung die Anzahl der neuen Schnittstellen polinom zur Anzahl der einzelnen Elemente.

Die Anwendung von ‚Teile & Herrsche‘ verringert also die Kompliziertheit eines einzelnen Teils, erhöht aber gleichzeitig die Kompliziertheit der Interfaces zwischen den Teilen. Bisher haben wir die Interfaces lediglich auf einer Ebene betrachtet und sprechen aus diesem Grund nur von Kompliziertheit. In der Realität haben wir dieses Beziehungsgeflecht jedoch nicht nur auf einer Ebene, sondern parallel auf mehreren Ebenen. Erschwerend kommt hinzu, dass die Grenzen zwischen zwei Komponenten, bezogen auf verschiedene Ebenen, nicht unbedingt gleich verlaufen. Zum Beispiel entsprechen logische Komponenten nicht exakt den physikalischen Komponenten. Sehr gut zu sehen bei der Darstellung von U-Bahnnetzen. Die grafische Darstellung des Fahrplans entspricht nur sehr bedingt dem realen Verlauf der U-Bahn.

Betrachten wir exemplarisch das Software Engineering, dann haben wir es in der Regel mit mindestens
folgenden Ebenen zu tun:

  • Zeit
  • Datenfluss
  • Logisches Verhalten
  • Prioritäten 
  • Varianten
  • Versionen
  • Betriebsmodi

Aus Applikationssicht kommen in der Regel noch weitere Ebenen hinzu, z.B. in Form von überlagerten Kontrollflüssen, wie beispielsweise Not-Aus, Software Update oder Service & Diagnose Modus. Auf jeder Ebene ergeben sich Interfaces einzelner Gesichtspunkte zueinander und die wenigsten davon sind in heutigen Systemen dokumentiert. Das Wissen über diese Interfaces befindet sich in der Regel in den Köpfen der Entwickler. Haben wir unser System häufig genug in Komponenten zerteilt, und ziehen sich nun Abhängigkeiten über mehrere der obigen Ebenen kreuz und quer über die Komponenten hinweg, dann sind wir bei komplexen Systemen angelangt.

Häufig wird vergessen, dass nach jeder hierarchischen Dekomposition der Schritt der Aggregation (Zusammensetzen einzelner Komponenten zu einem Gesamtsystem) folgen muss. Spätestens an dieser Stelle müssen alle Schnittstellen und vor Allem deren Auswirkungen im Gesamtsystem wieder homogen zueinander passen. Wird ein Zusammenhang übersehen ist das der Einstieg in die Wirkkette Hidden Links -> Emergenz -> Dysfunktion.

Um einem Gedankengang grundsätzlich vorzubeugen: ‚Teile & Herrsche‘ ist immer noch die Grundlage und unverzichtbar zum Managen von Kompliziertheit. Zum Managen von Komplexität benötigen wir darüber hinaus Mechanismen, um die steigende Komplexität der Interfaces in den Griff zu bekommen. 

Unser Gehirn als Engpass

Die Neurobiologie besagt, dass unser Gehirn auf der bewussten Ebene ca. 7 +/- 2 Artefakte und/oder Beziehungen in einem Augenblick überblicken (Begreifen) kann. Verglichen mit der Anzahl an potentiellen Artefakten und Schnittstellen komplexer Systeme ist das nicht sehr viel. Stellen Sie sich vor, Sie haben gerade 7 Artefakte parat und deren Zusammenhänge logisch durchdacht, dann fällt Ihnen ein 8. Artefakt ein. Im selben Moment fällt eines der vorherigen Artefakte, wie bei einem Schieberegister, aus Ihrem Fokus heraus und das geschieht, ohne dass unser Bewusstsein uns darauf aufmerksam macht. Wir merken für gewöhnlich nicht, dass wir in diesem Moment gerade etwas vergessen. Stattdessen befinden wir uns in dem Irrglauben alles zu berücksichtigen. Gibt es nun zufällig einen logischen Zusammenhang zwischen dem 8. neuen Artefakt und dem gerade herausgefallenen haben wir eine potentielle Situation für die Entstehung eines ‚Hidden Link‘.

Wenn wir nun bedenken, dass heutige komplexe Systeme tausende an Artefakten haben, die über deutlich mehr als 7 Ebenen potentiell in Beziehung stehen können, ist es naheliegend, dass es ein Trugschluss ist, dass unser Gehirn in der Lage ist, die möglichen Auswirkungen von Änderungen vollständig zu durchdringen.

Abgesehen davon versagt unser Gedächtnis bereits, wenn es die möglichen Zusammenhänge einer begrenzten Auswahl an Artefakten aus dem Stegreif aufführen sollte. Und jetzt stellen Sie sich noch die Entwicklung eines komplexen Systems auf Basis von vielen Gehirnen vor, in denen keines der Gehirne das Gesamtsystem mit all seinen potentiellen Zusammenhängen kennt, sondern immer nur Anteile des Systems.

Wenn also ein einzelnes Gehirn (selbst, wenn es ein optimales Gedächtnis hätte) nicht mehr alle Zusammenhänge kennt, bleibt die spannende Frage: Welche anderen Gehirne des Teams soll es zu Rate ziehen, um mit Sicherheit alle Abhängigkeiten herauszufinden? Noch eines zeigt die Neurobiologie. Wahrscheinlich wäre unser Unterbewusstsein in der Lage uns aus dem Dilemma zu helfen, denn unser Unterbewusstsein scheint einem optimalen Gedächtnis sehr nahe zu kommen. (Thema Alpha Mode, siehe auch ESER No. 26: Unser Gehirn als Werkzeug) Nur ist die Menschheit noch nicht in der Lage deterministisch mit dem Unterbewusstsein zu arbeiten, und so lange müssen wir andere Wege gehen, wenn wir komplexe Systeme entwickeln möchten, die sich am Ende deterministisch verhalten sollen.

Traceability: Ausweg aus dem Dilemma

Um dieses Ziel zu erreichen haben sich folgende Maßnahmen als grundlegend hilfreich herausgestellt.

  1. Strukturierung und Elimination von Ebenen und Beziehungen auf Basis von Architektur-Design
  2. Einschränkung der Ausprägung von Schnittstellen auf Basis von Contract-Based-Design (Auch DbC Design by Contract)
  3. Strukturierte Speicherung von Link-Beziehungen zwischen System-Artefakten und darauf basierenden Traceability-Analysen

Die 1. Maßnahme beruht darauf, über geeignete Ausprägung der Schnittstellen das Beziehungsgeflecht einfach und verstehbar zu halten. Z.B. durch ein geeignetes Kommunikationsverfahren den gegenseitigen Impact von Funktionen auf der Zeitebene zu verringern. Bezogen auf obiges Beispiel z.B: durch asynchrone Kommunikation, die auf blockierende Semaphoren verzichtet und damit keine Auswirkung auf der Zeitebene verursacht. Diesen Aspekt werden wir an dieser Stelle nicht weiter verfolgen, was nicht bedeuten soll, dass er nicht eine mindestens gleichwertige Maßnahme ist, um Komplexität zu beherrschen (Siehe auch ESER No. 31: Archtitektur & Design)

Die 2. Maßnahme Contract-Based-Design ist eine hervorragende Möglichkeit Ausprägungen von Schnittstellen einzuschränken oder auch die Basis, um diese automatisiert zu prüfen. Auch diesen Aspekt werden wir an dieser Stelle nicht weiter verfolgen, was nicht bedeutet dass er nicht hoch wirksam ist.

Wir verfolgen hier die 3. Maßnahme, Analysen auf Basis von Traceability. Der Sinn erschließt sich inzwischen von allein, wenn in komplexen Systemen die Zusammenhänge von Artefakten über mehrere Ebenen von unseren Gehirnen nicht mehr vollständig überblickt werden können, liegt es nahe, die Zusammenhänge strukturiert zu dokumentieren oder noch besser in Modellen zu hinterlegen. Das ist im übrigen, was alle Safety Normen mit der Traceability fordern.

∨ mehr Text anzeigen

Praktiziert wurde es in der Vergangenheit (und auch heute noch sehr häufig) in Form von Cross-ReferenzListen. In diesen tabellarischen zumeist Excel-Listen stehen z.B. die Zusammenhänge von Kundenanforderungen zu Systemeigenschaften und von dort wiederum zu den SystemImplementationen.

Abgesehen davon, dass die Pflege solcher Listen aufwändig ist und aus diesen Listen schnell einmal die Summe aller Abhängigkeiten zu analysieren nicht wirklich praktikabel ist, bleibt noch das Problem, dass diese Abhängigkeiten keine 1:1 Beziehungen, sondern n:n Beziehungen besitzen, was in zweidimensionalen Darstellungen (wie Excel-Tabellen) zu vielfacher Redundanz führt.

Besser geht es auf Basis von Datenbanken (Multidimensional) und geeigneten Werkzeugen, in denen Abhängigkeiten von Artefakten einfach mit der Maus durch Drag & Drop als so genannte LinkBeziehung gespeichert werden können und n:n Beziehungen ohne Bildung von Redundanz möglich sind.

Diese Werkzeuge können dann auf Basis dieser Links sehr elegant sogenannte Trace-Analysen
erstellen und übersichtlich darstellen.

Solch eine Traceability Analyse vor Änderungen zu berücksichtigen, ist was die Normen im eigentlichen Sinn fordern. Bevor eine Änderung am System durchgeführt wird sollte dessen Auswirkung auf das Gesamtsystem möglichst vollständig analysiert werden. Inzwischen verstehen Sie, Hidden Link > … > Dysfunktion … ja genau, der Ablauf dieser Kette soll verhindert werden.

Die praktische Umsetzung

Genau für diesen Zweck gibt es inzwischen verschiedenste Anforderungs-Management-Werkzeuge. Diese basieren auf Datenbanken, die nicht nur das strukturierte Speichern von Artefakten (das ist auch mit MS Word oder Excel möglich), sondern auch das Speichern von deren Abhängigkeiten in Form von Linkbeziehungen effizient ermöglichen.

Des weiteren können diese Werkzeuge dann auf Knopfdruck die Abhängigkeiten verfolgen und visualisieren. Das können leider nicht alle Werkzeuge gleich gut. Hier trennt sich die Spreu vom Weizen, z.B. zwischen einem klassischen Requirements Engineering Werkzeug und Team Collaboration Lösungen, wie beispielsweise der MS TFS, die heute auch von sich in Anspruch nehmen AnforderungsManagement zu ermöglichen. Ich erlebe immer häufiger, dass Letzteres zum Requirements Management eingesetzt wird. Anforderungen im TFS abzulegen ist grundsätzlich möglich, aber kongruente und aussagekräftige Traceability-Analysen habe ich persönlich noch nicht gesehen.

Was auf den ersten Blick einfach aussieht zeigt auf den zweiten Blick verschiedenste Fallstricke, die eine saubere verständliche Darstellung der Abhängigkeiten vereitelt. Wie so häufig im Leben zeigen sich einige dieser Fallstricke erst, wenn ein System eingeführt und über einen gewissen Zeitraum mit Daten angereichert ist. Aber dann ist es oftmals zu spät die Strukturen mit vertretbarem Aufwand zu ändern, und das eigentliche Ziel wird nur noch mit Abstrichen erreicht.

Metastruktur als Basis für Effizienz

Aber selbst mit der besten Anforderungs-Management-Lösung wird sich kein Erfolg einstellen, wenn sie nicht fachgerecht angewandt und konfiguriert wird. In der Praxis kommen AnforderungsManagement-Werkzeuge wie ein leeres Excel-Dokument daher. Sie bieten erst einmal nur das Potential Artefakte strukturiert abzulegen, in Beziehung zu setzen und auf dieser Basis auf Knopfdruck Sichten zu erstellen, die einen bestimmten Aspekt des Systems vollständig und verstehbar darstellen.

Die Struktur an sich (das Metamodell bzgl. der Struktur und Ausprägung von Artefakten und deren Zusammenhänge) muss für das Projekt und den Anwendungsfall spezifisch analysiert, definiert und im Werkzeug konfiguriert werden. Diese Konfiguration ist eine häufig unterschätzte Grundlage für effizientes Anforderungs-Management.

Ein wichtiges Beispiel sind die Linkbeziehungen. Hier gibt es entsprechend den verschiedenen Gesichtspunkten unterschiedliche Beziehungstypen. Die beiden üblichen sind Satisfies (Erfüllt) und Verifies (Prüft / Testet) Beziehungen. Sie dienen unterschiedlichen Gesichtspunkten und sollten in Traceability-Analysen entsprechend differenziert herangezogen werden können. Z.B. für eine Coverage Analyse, ob jedes Artefakt der System-Spezifikation ein entsprechendes Artefakt im Prüfplan besitzt. Eine aussagekräftige Darstellung wird auf Basis der Verifies-Beziehungen unter Ausschluss aller anderen Beziehungen analysiert. Kann die Traceanalyse nicht zwischen Satisfies- und Verifies-Beziehung unterscheiden, ist auch die Aussage, ob ein Artefakt einen Test hat, nicht eindeutig möglich, oder das Werkzeug müsste die Intelligenz haben, den Sinn der Artefakte zu kennen. (Dieses Vorgehen wäre denkbar, ist aber unüblich)

In der Praxis gibt es noch diverse weitere Typen für Linkbeziehungen. Die Unterstützung verschiedener Linktypen und deren definierte, strukturierte Anwendung, bezogen auf das Verlinken von Artefakten ist eine wichtige Voraussetzung für aussagekräftige Traceability-Analysen.

Folgend möchte ich exemplarisch einige häufig anzutreffende Fehler bezüglich der strukturellen Anwendung von Linkbeziehungen aufzeigen.

Richtung der Linkbeziehungen

Klingt banal, aber wir werden sehen, dass es einen großen Impact auf einen reibungslosen Workflow haben kann. Sehr häufig sehe ich, dass die Richtung der Linkbeziehungen dem Workflow des V-Modells folgen. Auf den ersten Blick ist das logisch. Aber in der praktischen Umsetzung führt dieses bei den meisten Werkzeugen in Folge zu Rechte-Problemen.

Betrachten wir exemplarisch einmal die Linkbeziehungen zwischen Lastenheft und Pflichtenheft. Physikalisch muss ein Link in der Datenbank real abgespeichert werden. Im allgemeinen hat man sich bei den gängigen Werkzeugen aus Best-Practice-Gesichtspunkten darauf verständigt, dass der Link immer an der Wurzel gespeichert wird. (Sollte das bei einem Werkzeug anders sein spricht das nicht für das Werkzeug, da es sich nicht an Best Practice orientiert. Wahrscheinlich ist, dass es sich dann auch in anderen Punkten nicht an üblichen BestPractice-Vorgehen orientiert und Sie sollten dieses Werkzeug um so kritischer prüfen.)

Würde also ein Link von einem Artefakt aus dem Lastenheft zu einem Artefakt aus dem Pflichtenheft gezogen, dann würde dieser Link im Lastenheft gespeichert werden.

Aber wie ist das in der Realität? Wahrscheinlich wird der Auftraggeber das Lastenheft an den Auftragnehmer geben, um ein Angebot zur Umsetzung zu erhalten. Nun wird der Auftragnehmer sein Pflichtenheft gegen das Lastenheft stellen und die jeweiligen System-Spezifikations-Artefakte mit den entsprechenden User Requirements des Lastenheftes verlinken. Werden nun die Links im Lastenheft gespeichert (also nicht an der Wurzel der Beziehung) benötigt der Lieferant die Schreibrechte im Lastenheft des Auftraggebers. Aus vertraglicher Sicht eine bedenkliche Situation. Der Auftragnehmer hätte damit ja auch auch das Recht Artefakte des Lastenheftes verändern.

Diese Problematik zieht sich wie ein roter Faden durch alle Dokumente und Artefakte des Systems. Test zu Spezifikation, Normen zu Design usw. Der Designer wird sicher nichts in der Norm ändern wollen, aber zur Norm verlinken. Das sollte möglich sein, ohne dass er Schreibrechte in der Norm besitzt.

Grundsätzlich gilt: Die Linkrichtung geht immer vom vermeintlich jüngeren Dokument zum vermeintlich älteren Dokument.

∨ mehr Text anzeigen

Wer diese Regel berücksichtigt wird auch die Rechte der Dokumente entsprechend eines natürlichen Workflows vergeben können und hier keine strukturellen Probleme bekommen.

In diesem Zusammenhang noch ein Hinweis auf die Richtung der Linkbeziehungen und die Richtung der Traceability. Die Linkbeziehungen sind grundsätzlich gerichtet und nicht mit der Richtung der Traceability-Analysen zu verwechseln, die in den Normen in der Regel als bidirektional gefordert wird. (Siehe Pfeile der Beziehungen in den Abbildungen der IEC 62304 in Abbildung Nr. 2 und ASPICE in Abbildung Nr. 6) Auch auf Basis gerichteter Linkbeziehungen können die Traceability-Analysen in beide Richtungen (bidirektional) verfolgt werden. Darüber hinaus erhöht es die Aussagekraft der Analysen, indem Links mit bestimmten Richtungen in die Analysen ein- bzw. ausgeschlossen werden.

Einschnürungen in der Traceability

Dieser Punkt liegt mir besonders am Herzen, da ich in der Praxis extrem häufig auf Copy & Paste von Artefakten stoße, um Einschnürungen zu vermeiden. In Wirklichkeit deutet es aber auf ein strukturelles Problem hin. Der dahinter liegende Sachverhalt scheint nicht trivial, zumindest habe ich in Seminaren regelmäßig das Problem, diesen verständlich zu machen (was auch an meiner Didaktik liegen kann ;-)  Trotzdem an dieser Stelle mein Versuch dieses Problem verständlich darzustellen. Betrachten wir einmal die Traceability in der Medical Norm IEC 62304, wie in Abbildung Nr. 2 dargestellt. Verfolgt man die Linkbeziehungen ausgehend von den Stakeholder-Anforderungen, dann geht der Pfad über die Systemarchitektur.

    Was ist denn eigentlich die Systemarchitektur oder präziser gefragt, wie sieht ein typisches Dokument aus, das die Systemarchitektur beschreibt und welche Artefakte beinhaltet dieses Dokument, zu denen Linkbeziehungen erstellt werden können?

    In Abbildung Nr. 3 ist eine SystemArchitektur dargestellt und, rot umrandet, exemplarisch zwei mögliche Komponenten dieser Architektur. Sehr richtig fordert die 62304 auch eine Komponenten-Spezifikation und die Traceability in diese Spezifikation. Betrachten wir nun einmal die Traceability exemplarisch von den SystemAnforderungen über die SystemArchitektur zu der KomponentenSpezifikation, wie in der Norm dargestellt.

    Dazu bringen wir drei Anforderungen (A B C) ins Spiel und deren abgeleitete Komponenten Spezifikationen (a’ b’ c’). Nehmen wir an, dass keine eineindeutige Zuordnung der Erfüllung von Anforderungen auf eine Komponente möglich ist, sondern für die vollständige Erfüllung der Anforderung B sowohl Komponente 1, als auch Komponente 2 anteilig verantwortlich ist, dann ergeben sich Linkbeziehungen, wie in Abbildung Nr. 4a dargestellt.

    So weit sieht das erste einmal recht gut aus. Doch was wäre das Ergebnis einer Traceability-Analyse?

    Anforderung B soll erweitert werden und wir möchten wissen, welchen Impact das auf das System hat. Dazu verfolgen wir alle Linkbeziehungen und siehe da: nach der System-Architektur bekommen wir alle Links als Suspect angezeigt, auch die Links zu a’ und c’, obwohl diese in diesem System keine Abhängigkeiten zu B haben, außer, dass sie innerhalb der selben Komponenten implementiert werden. Dieser Effekt der Verwässerung der TraceabilityAnalyse wird als ‚Einschnürung‘ bezeichnet. In der Sichtweise der System-Architektur kann die Filigranität der Anforderungs-Ebene nicht aufgelöst werden.

    Abhilfe schafft dann regelmäßig Copy & Paste der Elemente in die ArchitekturDokumente, wie in Abbildung Nr. 5a zu sehen. Nun kann die Einschnürung wieder aufgelöst werden, aber die Redundanz wurde unnötig erhöht.

    Der korrekte Ansatz wäre, die Architektur in Bezug auf die Satisfies Linkbeziehungen zu überspringen und die Artefakte der System Spezifikation direkt mit den Artefakten der Komponenten-Spezifikation zu verlinken. Natürlich kann es auch sinnvoll sein Architektur-Artefakte zu verlinken,
    aber das geschieht mit einer separaten  Linkbeziehung, nicht mit der so genannten Satisfies-Beziehung.

    In Abbildung Nr. 6 ist die Definition der Linkbeziehungen aus der IEC 15504 (Automotive SPICE) dargestellt. Gegenüber vielen anderen Normen sind hier parallele Pfade von System Requirements zu Software Requirements bzw. Software Requirements und Software Unit Specification gegenüber den Architektur- und Design Dokumenten definiert. So sollte es sein. (Achtung: auch wenn die Pfeile in beide Richtungen gehen, hier ist die Traceability gemeint, nicht die Richtung der Linkbeziehungen, siehe vorheriges Kapitel).

    Die Beschreibung der Architektur und die Spezifikation der Komponenten liegen zwar im Workflow hintereinander, auf Dokumentenebene in Bezug auf die Traceability der Satisfies-Beziehungen liegen sie jedoch parallel zueinander. Darstellungen des V-Modells orientieren sich üblicherweise am Workflow, was auch in verschiedenen anderen Situationen zu beachten ist und diesen nicht zwingend entspricht.

      Die Satisfies-Links gehen also an Architektur und Design Dokumenten vorbei, wie in Abbildung Nr. 5 b zu sehen. Das ist die Voraussetzung für redundanzfreie Dokumente ohne Einschnürungen in der Traceability.

      In der Praxis werden die Einschnürungen zumeist unbewusst umgangen. Jedem ist klar, dass etwas nicht stimmt, wenn auf einmal alle Linkbeziehungen auf ein Element zeigen. Die vermeintliche Lösung ist dann auf dieser Ebene die Filigranität zu erhöhen. Da aber keine neuen sinnvollen Aussagen bezogen auf dieses Element zu finden sind, die nicht schon in der Spezifikation des Elementes stehen (weil es auch keine weiteren sinnvollen Aussagen gibt), besteht die Neigung zu Copy & Paste. Als Hinweis für die Praxis sollten folgende Richtlinien herangezogen werden.

      •  Wenn die Neigung zu Copy & Paste zwischen Ebenen existiert, ist die Wahrscheinlichkeit groß, dass eine Ebene zuviel im Traceability-Pfad (bezogen auf einen Linktype) existiert.
      • Es gibt auch den umgekehrten Fall: Satisfies-Beziehungen sollten grundsätzlich nur zu übergeordneten Ebenen möglich sein. Gibt es die Neigung Satisfies-Beziehungen auch innerhalb einer Ebene zu ziehen, dann ist es wahrscheinlich, dass eine Ebene zu wenig im Traceability-Pfad existiert.

      Weitere Best Practice Ansätze

      Natürlich gibt es noch viele weitere Praktiken, die zu berücksichtigen sind, um am Ende effizientes Anforderungs-Management und damit Traceability Analysen zu gewährleisten. In der nächsten Ausgabe des ESER werde ich das Thema noch einmal aufgreifen und aus anderen Gesichtspunkten vertiefen. Hier sind abschließend noch einige aufgeführt ohne näher darauf einzugehen und ohne Anspruch auf Vollständigkeit.

      •  Rechte-unabhängige Dokumentation von Diskussionen unabhängig von der Definition von Artefakten
      • Link Controle
      • Definiertes einbeziehen bzw. ausblenden von Linkbeziehungen in die Traceability Analysen
      • Dokumentenzentrische Darstellung der Anforderungen (Orientiert an Kapitelstruktur)
      • Dokumentenzentrischer Aufbau der Traceability
      • Unterstützung von Review Prozessen

      Aber nicht nur das Vorgehen, auch die Werkzeuge haben Einfluss auf die Produktivität.

      Bei der Auswahl von Anforderungs-Management Lösungen zu beachten

      Anforderungs-Management erlebt aktuell einen Boom. Es ist daher kaum verwunderlich, dass die Anzahl der Werkzeuge, die von sich behaupten Anforderungs-Management zu unterstützen, in den letzten Jahren regelrecht explodiert sind.

      Neben wirklich guten Werkzeugen erweisen sich bei näherer Betrachtung einige der Lösungen als erschreckend untauglich. Eine kompetente Beurteilung ist jedoch erst möglich, wenn gewisse Erfahrungen und Kenntnisse im Umgang mit Anforderungs-Management-Lösungen vorhanden sind.

      Immer wieder kommen Kunden zu uns, die mit einer schnell eingeführten, halbherzigen Lösung nun an die Grenzen geraten. Gerade diese Lösungen unterstützen in der Regel keine Standards wie ReqIF, so dass der Aufwand, die Daten nun verlustfrei in eine alternative Lösung zu migrieren, ein Vielfaches an Kosten mehr verursacht, als vermeintlich gespart wurde. Hinzu kommt, dass die Kosten für eine fachgerechte Lösung nun doch investiert werden müssen.

      Folgend werden auszugsweise einige der wesentlichen Kriterien aufgezeigt, die ein Werkzeug an Funktionalität unterstützen sollte. Hier am falschen Ende zu sparen zahlt sich nicht aus. Bedenken Sie, dass nicht die Kosten des Werkzeuges am Ende des Tages den großen Brocken ausmachen, sondern die Kosten der Arbeitszeit, die benötigt wird, um die Werkzeuge mit Daten zu füllen und diese in eine neue Lösung zu migrieren.

      Bereitstellung von eineindeutigen ID’s für Artefakte (Anforderungen)

      Was wie eine Selbstverständlichkeit klingt ist in der Praxis häufig nur scheinbar gewährleistet. Ich treffe immer wieder auf Werkzeuge, die nicht wirklich in der Lage sind eineindeutige ID’s sicher zu stellen. Beispielsweise hervorgerufen durch die Freigabe von ID’s nach dem löschen eines Artefaktes. Wird z.B. ein Artefakt beim Löschen in den Papierkorb verschoben (und die ID dadurch freigegeben), anschließend ein neues Artefakt angelegt und dann das gelöschte Artefakt aus dem Papierkorb wiederhergestellt, kann es dazu führen, dass die selbe ID doppelt verwendet wird. Fatal für Safety Projekte, trotzdem in einigen Werkzeugen immer wieder zu finden. Fachgerecht wird eine einmalig verwendete ID nie  wieder freigegeben.

      Definition von verschiedenen Linktypen und Link-Controle

      Ohne die Möglichkeit verschiedene Linktypen zu verwenden und den Linktypen exakte Regeln bezüglich dessen Anwendung mitzugeben, ist es nur eine Frage der Zeit, wann aussagekräftige Traceability-Analysen nicht mehr möglich sind. Selbstverständlich müssen diese Linktypen dann auch in den Traceability-Analysen als Filter-Optionen verwendbar sein. Dieser Punkt klingt selbstverständlich, ist er aber leider nicht.

      Unterstützung von ReqIF als Austauschformat

      Auch die Unterstützung von ReqIF als Standardformat zum Austausch von Anforderungen ist noch lange keine Selbstverständlichkeit bei verschiedenen Anforderungs-Management-Lösungen.

      Häufig wird bei der Auswahl einer Lösung dieser Punkt unterschätzt, da erst im Verlauf eines Projektes eine Situation auftritt, in der Anforderungen ausgetauscht oder in anderen Domänen und Werkzeugen genutzt werden sollen.

      Anbindung und Integration in die existierende oder zukünftig genutzte SW Engineering Landschaft ist ein wichtiger Gesichtspunkt. Durchgängige Traceability oder Abbildung von Varianten sind nur zwei von vielen Anwendungsfällen, in denen die Integration verschiedener Werkzeuge die Voraussetzung für einen effizienten Workflow darstellen. Die Integration der Anforderungs-Management-Lösung in die Umgebung des SW Engineering-Umfelds ist häufig wichtiger, als die Unterstützung einzelner Features an sich.

      In diesem Zusammenhang ist auch die Unterstützung des OSLC Standards ein interessanter Gesichtspunkt.

      Dokumentenzentrische Darstellung der Artefakte

      Anforderungen state of the art zu definieren (Eineindeutig, vollständig, verstehbar …) ist in der Praxis nicht immer einfach und erzeugt Redundanz in der Spezifikation. Herkömmlich dienen Kapitel in Dokumenten dazu einen gewissen Kontext zu definieren, der für das Kapitel gilt. Das erhöht in nicht unerheblichem Maße die Verstehbarkeit ohne Erhöhung der Redundanz.

      Auch im Anforderungs-Management sind Kapitelstrukturen in dieser Hinsicht hilfreich, um einzelne Anforderungen in einen bestimmten Kontext zu stellen und übertriebene Redundanz zu verhindern. Das führt jedoch dazu, dass die Anforderungen außerhalb eines Kapitels nicht mehr eineindeutig, vollständig etc. sind und an Aussagekraft verlieren.

      Trotzdem hat sich in der Praxis gezeigt, dass eine KapitelStruktur im Anforderungs-Management hilfreich ist. Diese muss dann aber auch unter verschiedenen Gesichtspunkten zur Verfügung stehen z.B. bei der Darstellung von Traceability-Analysen oder bei der Anwendung von gefilterten Sichten, was bei vielen Werkzeugen nicht gegeben ist. In Folge leidet die Verstehbarkeit in Darstellungen, in denen Anforderungen aus ihrem ursprünglichen Kontext gerissen werden.

      Natürlich gibt es noch viele weitere Gesichtspunkte,dessen vollständige Erläuterung den Rahmen an dieser Stelle sprengen würde. Ziel ist es, eine Vorstellung zu geben welcher Natur Gesichtspunkte sein können.

      Der Einstieg

      In unseren Schulungen zur Einführung von AnforderungsManagement ist eine Analyse der Artefakte und involvierten Stakeholder (Dokumente, Ebenen, Linktypen, Attribute der Artefakte …) ein fester und wichtigster Bestandteil. Dieser Teil der Schulung ist weitestgehend Werkzeug-unabhängig und bietet eine hervorragende Basis zur Auswahl eines geeigneten Werkzeuges. Er dauert 1-2 Tage und die dabei erarbeitete Metastruktur kann zu einer späteren Konfiguration eines Werkzeuges direkt wieder verwendet werden. Ich persönlich empfehle solch eine fachkundig moderierte Analyse immer als ersten Schritt zur Einführung von Anforderungs-Management und elementare Voraussetzung zur Auswahl eines Werkzeuges.

      Nützlich zu kennen:

      ReqIF(Requirement Interchange Format):
      Offener Standard zum Austausch von Anforderungen.

      OSLC:
      Offener Standart zum Datenaustausch zwischen Werkzeugen

      Emergenz: 
      (lat. emergere „Auftauchen“, „Herauskommen“, „Emporsteigen“)
      Herausbildung von neuen (zuvor nicht definierten) Eigenschaften oder Strukturen eines Systems.

      Dysfunktion:
      Griechisch-lateinische Bezeichnung für Funktionsstörung.

      Polinom-Funktion:
      Ganzrationale Funktion in der Mathematik, eine Summe von Potenzfunktionen mit natürlichen Exponenten. Aggregation: Zusammenfassung mehrerer Einzelgrößen zu einer Gesamtgröße.

      Change Request:
      Änderungsanforderung.

      Interrupt Disabling:
      Deaktivierung einer Interrupt Quelle.

      ISR (Interrupt Service Routine):
      Funktion, die bei Aktivierung eines Interrupts ausgeführt wird.

      DbC (Design by Contract):
      Entwurf gemäß Vertrag ist ein Konzept mit dem Ziel des reibungslosen Zusammenspiels einzelner Programmmodule durch die Definition formaler Verträge zur Verwendung von Schnittstellen, die über deren statische Definition hinausgehen.

      Artefakt:
      Als Artefakt wird alles angesehen, das einen Beitrag zum System liefert. Angefangen bei Aussagen über das System über Bedingungen zum System bis hin zu realen Komponenten des Systems. Auch Anforderungen fallen unter diesen Begriff der Artefakte. Da die Traceability ja über die reinen Anforderungen hinaus geht, erscheint mir die Verwendungen des Begriffs Artefakt an einigen Stellen besser geeignet, als der Begriff Anforderung.

      Autor:

      Andreas Willert
      Haben Sie noch Fragen oder Anregungen zum Thema? Dann freue ich mich über eine E-Mail: awillert@willert.de

      Herausgeber:

      WILLERT SOFTWARE TOOLS GMBH
      Hannoversche Straße 21
      31675 Bückeburg
      E-Mail: info@willert.de
      Tel.: +49 5722 9678 - 60

      Alle ESE-Reports im Überblick

      Aktuelles Know-how und neueste Entwicklungen und Trends rund um das Thema Emedded Software Engineering

      > zu den ESE-Reports

      Hinweis: Unsere Webseite nutzt Cookies. Wenn Sie fortfahren, nehmen wir an, dass wir Ihre Erlaubnis haben Cookies zu setzen. Informationen zum Einsatz von Cookies sowie unsere Datenschutzbestimmungen finden Sie in unserer Datenschutzerklärung und über unser Impressum.