Ein Angebot von

Requirements Engineering –Qualitätssicherung durch Anforderungsmanagement und Rückverfolgbarkeit

| Autor / Redakteur: Shan Bhattacharya * / Sebastian Gerstl

Die Anforderungen stets im Blick: Rückverfolgbarkeit der Anforderungen stellt sicher, dass alle Requirements umgesetzt sind und sich sämtliche Entwicklungs-Artefakte auf eine oder mehrere Anforderungen zurückführen lassen.
Die Anforderungen stets im Blick: Rückverfolgbarkeit der Anforderungen stellt sicher, dass alle Requirements umgesetzt sind und sich sämtliche Entwicklungs-Artefakte auf eine oder mehrere Anforderungen zurückführen lassen. (Bild: © Sergey Nivens - Fotolia)

Qualitätssicherung kann nicht nur Code-Analyse und Test bedeuten. Denn sie allein stellen nicht sicher, dass Systemanforderungen korrekt umgesetzt wurden. Daher kommt es bei Sicherung der Code-Qualität auch auf konkretes Anforderungsmanagement an.

Normen wie ISO/DIS 26262 der Automobilindustrie oder die Norm IEC 62304 des Medizinsektors verlangen nach bidirektionaler Rückverfolgbarkeit. Sie betonen die Notwendigkeit, jede Entwicklungs-Ebene aus der jeweils darüber liegenden Ebene herzuleiten. Die meisten Anbieter statischer und dynamischer Analyse-Lösungen sind jedoch nicht in der Lage, das Benötigte zu liefern.

Die Lösung liegt in einer Requirements Traceability Matrix (RTM), die sich im Mittelpunkt jedes Projekts befindet. Eine RTM ist zunächst einmal ein Konzept, sie kann aber auch Teil eines Werkzeugs sein, das die Verknüpfungen zwischen Anforderungen und Entwicklungsartefakten wie zum Beispiel Code-Objekten, Modellen oder Dokumenten verwaltet. Die Verknüpfungen existieren unabhängig davon, ob sie real protokolliert und verwaltet werden oder nicht. Ein Entwickler erzeugt etwa bereits dann eine Verknüpfung, wenn er eine Design-Spezifikation liest und für die Implementierung heranzieht.

Rückverfolgbarkeit: Die RTM im Software-Lebenszyklus

Aufgrund dieser zentralen Rolle sollten Projektmanager den Investitionen in Tools für das Erstellen der RTM einen genügend hohen Stellenwert einräumen. Die RTM muss außerdem zum Unterstreichen ihrer Bedeutung in jedem Lebenszyklus-Modell explizit dargestellt werden. Bedingt durch diese verstärkte Fokussierung wird die RTM effizient und präzise erstellt und gepflegt. Wenn die RTM zum Zentrum des Entwicklungsprozesses wird, beeinflusst sie sämtliche Stadien des Designs von den übergeordneten Anforderungen bis zum zielbasierten Deployment.

Bei den übergeordneten Anforderungen auf Ebene 1 kann es sich um eine definitive Beschreibung des zu entwickelnden Systems handeln. Je nach Umfang und Komplexität des Systems kann diese Ebene auch weiter unterteilt werden.

Ebene 2 beschreibt das Design des in Ebene 1 definierten Systems. Vor allem muss diese Ebene für Verknüpfungen oder die Rückverfolgbarkeit zur ersten Ebene sorgen und mit dem Erstellen der RTM beginnen. Dazu gehört das Erfassen der untergeordneten Anforderungen, die design- und implementierungsspezifisch sind und die Funktionalität des Systems nicht beeinflussen.

Die Implementierung auf Ebene 3 bezieht sich auf den in Übereinstimmung mit Ebene 2 entwickelten Quell- bzw. Assemblercode. Zu den Verifikations-Aktivitäten gehören hier das Prüfen der Codierungsregeln und die Qualitätsanalyse. Das Pflegen der RTM birgt auf dieser Ebene viele Herausforderungen, da das Zurückverfolgen der Anforderungen zu den Quellcode-Dateien möglicherweise nicht spezifisch genug ist und die Entwickler unter Umständen auf einzelne Funktionen verweisen müssen.

In vielen Fällen dürfte das System mehrere Funktionen involvieren. Die Rückverfolgung dieser Funktionen zu den Anforderungen von Ebene 2 umfasst aufgefächerte Beziehungen, und es passiert nur allzu leicht, dass in einer manuell verwalteten Matrix eine oder mehrere dieser Beziehungen aus dem Blick geraten.

In Ebene 4 (Host-basierte Verifikation) beginnt die formelle Verifikation. Sobald per Automated Code Review der Nachweis erbracht ist, dass der Code die relevanten Standards erfüllt, können Modul-, Integrations- und Systemtests in eine Teststrategie eingebunden werden, die auf dem Top-Down- oder dem Bottom-Up-Prinzip oder einer Kombination aus beiden beruhen kann. Softwarestimulations-Techniken leisten Hilfe beim Erstellen automatisierter Testumgebungen und Testfall-Generatoren. Execution Histories können den Nachweis erbringen, dass der Code getestet wurde.

Ergänzungen und Reproduzierbarkeit

Solche Tests können bei Bedarf durch Robustheitsprüfungen ergänzt werden – möglicherweise durch automatische Definition der Modultest-Vektoren oder durch statische Vorhersage des dynamischen Verhaltens.

Die Testfälle von Ebene 4 sollten, falls erforderlich, auf Ebene 5 reproduzierbar sein. In diesem Stadium liefern wir die Bestätigung, dass die Software in ihrer Entwicklungsumgebung wie vorgesehen arbeitet. Keine Garantie besteht indes dafür, dass sie auch in ihrer Zielumgebung funktionieren wird. Allerdings gibt das Testen in der Host-Umgebung erstmals die Möglichkeit, mit dem zeitaufwendigen Target Test einfach die Bestätigung zu liefern, dass die Tests in der Zielumgebung solide bleiben.

Die zielbasierte Verifikation auf Ebene 5 stellt das auf dem Zielsystem stattfindende Test-Element der formellen Verifikation dar. Sie beschränkt sich häufig auf die schlichte Bestätigung, dass die zuvor ausgeführte hostbasierte Verifikation in der Zielumgebung wiederholbar ist, auch wenn einige Tests möglicherweise nur in dieser Umgebung selbst anwendbar sind.

Wenn Zuverlässigkeit oberstes Gebot ist und die Budgets es zulassen, wäre die statische Analyse des dynamischen Verhaltens unter Verwendung der kompletten Datensätze ein Hilfsmittel, das bei einem solchen Ansatz eine gute Ergänzung darstellen würde. Dennoch bliebe die dynamische Analyse auch hier zentrales Element des Prozesses.

Welche Herangehensweisen an das Anforderungsmanagement sollten gewählt werden?

Es gibt schlagkräftige Argumente für die traditionellen formellen Methoden. Wegen des Entwicklungsaufwands für solch ein Verfahren und der Schwierigkeit, es rückwirkend auf bereits existierenden Code anzuwenden, ist es jedoch nur für höchst sicherheitskritische Anwendungen sinnvoll.

Die automatische Codeprüfung stellt fest, ob die Codierungsstandards eingehalten wurden. Dieses Verfahren dürfte sich für nahezu alle Entwicklungsumgebungen eignen.

Von den verbleibenden Verfahren stellen dynamische Analysetechniken eine Prüfumgebung zur Verfügung, die die finale Anwendung wesentlich besser widerspiegelt als statische Vorhersagen des dynamischen Verhaltens oder Möglichkeiten für Funktionsprüfungen.

Wenn die Rückverfolgbarkeit der Anforderungen in einer gemanagten und kontrollierten Entwicklungsumgebung entscheidend ist, passt das progressive Konzept von automatischer Codeprüfung, gefolgt von Modul-, Integrations- und Systemtests bestens zu dem in mehrere Ebenen gegliederten Konzept der meisten modernen Standards. Ebenso kommt es der häufig aufgestellten Forderung oder Empfehlung nach, den Code in seiner Zielumgebung zu prüfen.

Ist eine Robustheitsprüfung gerechtfertigt, dann kann sie durch automatische Definition der Modultest-Vektoren umgesetzt werden oder durch statische Vorhersage des dynamischen Verhaltens.

Jede dieser Techniken hat ihre Meriten. Erstere führt den Code in seiner Zielumgebung aus. Letztere bietet eine Möglichkeit, nicht nur einzelne Testvektoren, sondern den gesamten Datensatz auszuführen. Wenn es vom Budget her möglich ist, könnten diese sich gegenseitig ausschließenden Vorteile die Anwendung beider Techniken rechtfertigen. Andernfalls könnte das Unit-Test-Tool wegen seiner Multifunktionalität ein kosteneffektiver Ansatz sein.

Besteht ein nachgeordnetes Bestreben, die unternehmenseigenen Abläufe in Richtung auf die aktuellen bewährten Methoden zu verändern, müssen die automatische Codeprüfung und dynamische Analysetechniken eine wichtige Rolle im Management und der Rückverfolgbarkeit der Anforderungen übernehmen. Letztere ist entscheidend für den Nachweis, dass der Code seine funktionalen Zielsetzungen erfüllt.

Wenn das Ziel im Finden einer pragmatischen Lösung liegt, die die Zahl der Probleme reduziert, die bei einer schwierigen Applikation im Feld auftreten, so hat jeder der beiden Robustheits-Tests – also die statische Analyse des dynamischen Verhaltens und die automatische Definition der Modultest-Vektoren – das Potenzial, diffizile Probleme auf effiziente Weise einzukreisen.

* Shan Bhattacharya fungiert als Business Development Manager und leitet das US Field Engineering Team für LDRA.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 43334958 / Requirements)