Vollständigkeit von Spezifikationen – Ein neuer Ansatz

Das Spezifizieren von Systemen stellt immer noch eine der großen Herausforderungen und Fehlerquellen in der Entwicklung dar. Auch die modellbasierte Entwicklung kann die Spezifikationsproblematik nicht wirklich lösen. Ein Modell definiert detailliert, wie ein System funktioniert (Architektur), nicht aber was das System macht (Funktion).

Die Vollständigkeit von Spezifikationen zählt dabei zu einer der zentralen Problemstellungen. Der Beitrag widmet sich diesem Aspekt und diskutiert Ansätze, wie man vor allem in sicherheitsrelevanten Projekten deren Spezifikationen zukünftig systematisch vervollständigen kann.

Natürliche Sprache als Spezifikationselement

Für das Erstellen von Spezifikationen ist die natürliche Sprache ein wesentliches Element. Der große Vorteil der natürlichen Sprache liegt darin, dass Sie von jedem verstanden wird. Es ist das wesentliche Kommunikationsmittel zwischen uns Menschen. Die Sprache wird aber nicht dazu verwendet, um eindeutig, korrekt und vollständig zu kommunizieren. Es gibt viele gute Gründe, warum das für unseren Alltag gut und richtig ist.

Für die Spezifikation eines zu entwickelnden Systems wiederum sind Eindeutigkeit, Korrektheit und Vollständigkeit sehr wichtig. Das Anforderungsmanagement (Requirements Engineering) hat in den letzten Jahrzehnten einige Techniken entwickelt, um Systeme unter Verwendung der natürlichen Sprache einigermaßen eindeutig, korrekt und vollständig zu beschreiben. Insbesondere für sicherheitsrelevante Systeme ist die dadurch erreichte Qualität aber nicht ausreichend.

Modellierung als Spezifikationselement

In den letzten Jahren hat sich in der Softwareentwicklung die modellgetriebene Entwicklung deutlich weiterentwickelt. Auf den ersten Blick sind Modelle auch deutlich besser geeignet um eindeutige, korrekte und vollständige Systeme zu spezifizieren. Dies wiederum liegt daran, dass Modelle auf mathematischen Regeln beruhen.

Die vielen modellgetriebenen Entwicklungsprojekte zeigen aber auch, dass Modelle nicht die natürlichsprachlichen Anforderungsspezifikationen (Requirements) ersetzen können. Vielmehr ergänzen sich Modelle und natürlichsprachliche Anforderungsspezifikationen. Ein Modell legt im Wesentlichen fest, wie ein System funktioniert. Natürlichsprachliche Anforderungsspezifikationen haben Ihre Stärke in der Beschreibung der Funktionalität eines Systems (Was).

Liegt die Wahrheit im Source Code?

Viele Entwickler und Projektleiter, die schlechte Erfahrungen mit Anforderungsspezifikationen gemacht haben, tendieren zur Aussage: „Die Wahrheit liegt im Source Code!“ Dieser Satz impliziert, dass man auf die Mühen zur Erarbeitung von Anforderungsspezifikationen und deren Dokumentation letztlich verzichten kann. Auch die agilen Entwicklungsansätze zielen auf den ersten Blick in diese Richtung.

Wenn man aber die agilen Methoden genauer betrachtet, stellt man schnell fest, dass Anforderungsspezifikationen sogar ein zentrales Element sind. Jede Sprintplanung beruht darauf, dass die zu implementierenden Funktionen klar identifiziert sind. Auch die agile Welt erlaubt es nicht, einfach drauflos zu codieren.

Agile Projekte zeichnen sich viel mehr dadurch aus, dass es ganz kurze, iterative Entwicklungsschleifen gibt. Dadurch entsteht schnelles Feedback und ggf. falsch verstandene Anforderungsspezifikationen werden schnell korrigiert.

Bei der heutigen Komplexität der Systeme würde ein unkoordiniertes Drauflosprogrammieren absehbar ins Chaos führen. Das Scheitern des Projektes wäre nur eine Frage der Zeit.

Der enorme Funktionsumfang selbst einfacher Systeme durch die Software erzwingt ein systematisches Vorgehen.

Die wesentlichen Elemente einer systematischen Entwicklung in sicherheitsrelevanten Projekten

Vor fast 40 Jahren (1983) wurde der Standard zur Entwicklung sicherer Software in der Luftfahrt RTCA DO-178 verabschiedet. Dies war die erste Norm, die Entwicklungsprozess und -ergebnisse mit dem Ziel definierte, Fehler in einer Software systematisch auf eine akzeptable Anzahl zu reduzieren.

1998 wurde die erste Version der IEC 61508 veröffentlicht. Der Verdienst dieser Norm war, dass sie einen funktionalen Sicherheitsstandard für alle Industriesektoren definierte, die keine branchenspezifische Norm hatten. 2011 erschien die zweite Version der IEC 61508, und heute gibt es in vielen Branchen eigene funktionale Sicherheitsstandards.

Auch wenn jede Norm eigene Schwerpunkte hat, haben sich in den letzten zehn Jahren einige Prozessschritte, Daten und Dokumente herauskristallisiert, die für eine qualitativ hochwertige Entwicklung von eingebetteten Systemen inzwischen unumstritten sind. Dies sind:

• Eine angemessene Projektplanung, mit einer entsprechenden Organisationsstruktur,
• konstruktive Maßnahmen, zur Senkung des funktionalen Risikos,
• Verfahren und Maßnahmen, um zufällige Hardwarefehler zu minimieren, und
• Verfahren und Maßnahmen, um systematische Software- und Hardwarefehler zu minimieren.

Bezogen auf die Softwareentwicklung sind inzwischen folgende Verfahren und Maßnahmen unstrittig notwendig:

• Frühzeitige Festlegung einer Entwicklungs- und Verifikationsstrategie,
• Sicherstellung einer guten und regelmäßigen Kommunikation zwischen allen Projektmitgliedern,
• funktionale Spezifikation der Software,
• Architektur und Design,
• statischer und dynamischer Test auf verschiedenen Ebenen,
• nachvollziehbare Rückverfolgbarkeit (Traceability) zwischen allen wesentlichen Artefakten,
• Konfigurations- und Änderungsmanagement sowie
• proaktive Qualitätssicherung.

Das Dilemma von Spezifikationen

Einerseits setzt sich also die Erkenntnis durch, dass Anforderungsspezifikation, Architektur und Tests unabdingbare Bestandteile einer systematischen Softwareentwicklung sind. Nur durch Anwendung eines Entwicklungsprozesses, der diese Elemente beinhaltet, lassen sich die Fehler in einer Software auf ein Minimum reduzieren.

Andererseits wissen wir, dass weder das Requirements Engineering noch das Test Engineering perfekt sind. Natürlichsprachliche Anforderungsspezifikationen sind nie zu 100% eindeutig, korrekt und vollständig. Ebenso verhält es sich mit den Tests. Die Kombinationsmöglichkeiten an Eingangssignalen für industrierelevante Systeme tendiert in der Praxis gegen unendlich. Auch können aus natürlichsprachlichen Anforderungsspezifikationen nur für Trivialfälle zu 100% vollständige Tests abgeleitet werden. Nur die Architektur einer Software lässt sich heute durch entsprechende Modellierungswerkzeuge so erstellen, dass daraus automatisch Quellcode erzeugt werden kann. Eine solche Architektur besitzt damit ein nachvollziehbares Kriterium für die Vollständigkeit und die Eindeutigkeit. Ob sie aber korrekt im Sinne des Anwenders der Software ist, lässt sich nicht eindeutig feststellen. Um diese Aussage treffen zu können, bräuchte man eindeutige, korrekte und vollständige Anforderungsspezifikationen, die dann vollständig mit der Architektur verlinkt werden. Jeder, der schon einmal eine Traceability zwischen Anforderungen und Architektur hergestellt hat, weiß, wie schwierig das ist. Hier beginnen die Probleme schon mit dem Tooling. Anforderungsspezifikationen werden idealerweise in Datenbanken und Architekturen in entsprechenden grafischen Tools gespeichert. Mir ist kein Tooling bekannt bei dem der notwendige Datenaustausch für die Erstellung der Rückverfolgbarkeit zwischen Anforderungsspezifikationen und Architektur reibungslos funktioniert.

Strukturelle Coverage Messung beinhaltet ein eindeutiges Kriterium der Vollständigkeit

In der Luftfahrt ist man sich schon seit Jahrzehnten bewusst, dass die größte Schwäche von natürlichsprachlichen Anforderungen und Testfällen, wie oben erläutert, das Kriterium der Vollständigkeit ist. Aus dieser Erkenntnis heraus wurde die strukturelle Überdeckungsmessung (Coverage) eingeführt. Die Idee dabei ist, anforderungsbasierte Tests zu erstellen und im Hintergrund dazu die Testüberdeckung zu messen. Wenn alle Anforderungen vollständig getestet sind und die Testüberdeckungsmessung keine zu 100% vollständige Testüberdeckung ergibt (das ist fast immer der Fall), dann muss der nicht getestete Code analysiert werden.

Prinzipiell kann es vier Gründe für eine fehlende strukturelle Coverage geben:

1. Anforderungsspezifikationen fehlen oder sind unvollständig.
2. Es fehlen Testfälle.
3. Der Programmcode kann durch einen Test nicht erreicht werden, wird aber benötigt (z.B. defensiver Programmierstil).
4. Der Programmcode wird nicht benötigt.

Genau mit dieser Motivation wird in der Luftfahrt seit Jahrzehnten die Testüberdeckung gemessen. Allerdings ist dieses Verfahren bisher nur auf Modultestebene anwendbar, da mit der bisherigen Technologie zur Messung der Testüberdeckung immer eine Veränderung des Laufzeitverhaltens der Applikation einhergeht (Software-Instrumentierung). Für Testebenen, bei denen das Laufzeitverhalten relevant ist (Integrations- und Systemtests), kann die bisherige Methode zur Testüberdeckungsmessung daher nicht angewandt werden.

Da während des notwendigen Prozesses der Detaillierung der Anforderungsspezifikation für die Designebene funktionale Zusammenhänge notwendigerweise aufgetrennt werden, kann die auf Modultestebene gemessene Testüberdeckung keine verlässliche Aussage zur Vollständigkeit der funktionalen Anforderungsspezifikation machen. Daher besteht in der Luftfahrt schon lange der Wunsch, die Testüberdeckungsmessung bei den Integrationstests oder sogar Systemtests einsetzen zu können. Hier könnte die ursprüngliche Motivation der strukturellen Testüberdeckungsmessung ihre volle positive Wirkung entfalten.

Non-intrusive Messung der strukturellen Coverage

Fast alle modernen Prozessoren besitzen eine „Embedded Trace“- Schnittstelle. Mittels dieser Schnittstelle kann die Programmabarbeitung in einem Prozessor beobachtet werden, ohne dass das Verhalten des Prozessors beeinflusst wird. Dabei fallen riesige Datenmengen (viele Gbits/Sekunde) an.

Integrations- und Systemtests erstrecken sich oftmals über einen langen Zeitraum, so dass es sehr vorteilhaft ist, den Trace-Datenstrom in Echtzeit verarbeiten zu können.

Die Firma Accemic Technologies bietet mit den CEDARtools® eine Lösung für genau diese Echtzeitverarbeitung der Trace-Daten an. Damit kann die Trace-Schnittstelle zur Messung der strukturellen Testüberdeckung zeitlich unbegrenzt verwendet werden.

Da das Laufzeitverhalten der Applikation auf dem Prozessor in keiner Weise beeinflusst wird, ermöglicht diese neue Technologie nun auch die Messung der Testüberdeckung für Integrationstests und Systemtests.

Erste Ergebnisse der Anwendung dieser Technologie bestätigen auch die theoretischen Annahmen, dass bei Integrationstests eine strukturelle Coverage von 80% und mehr erreicht wird, wenn alle Anforderungen vollständig getestet werden.

Damit bestätigt sich, dass die Messung der strukturellen Testüberdeckung während der Durchführung der anforderungsbasierten, funktionalen Black-Box Tests ein effektives Mittel ist, um Lücken in der Anforderungsspezifikation und den zugehörigen Tests zu entdecken.

Non-intrusive Technologie zum Nachweis des Daten- und Kontrollfluss

Die non-intrusive Beobachtbarkeit eines Prozessors eröffnet weitere Testmöglichkeiten. Dadurch wird es auch möglich, die Inhalte von Software-Parametern interner Schnittstellen zu überprüfen und damit erstmalig die in allen einschlägigen funktionalen Sicherheitsstandards geforderte Daten- und Kontrollflussanalyse mittels dynamischer Tests zu verifizieren.

Da solche Tests im Vergleich zum Test mit einem Debugger vollständig automatisiert werden können, wird es möglich, Daten- und Kontrollflüsse in den Integrations- und Systemtests systematisch nachzuweisen. Genau bei diesen Tests wird auch die Erfüllung der funktionalen Anforderungen nachgewiesen. Damit bietet diese Technologie die Möglichkeit, auch die Vollständigkeit der Anforderungsspezifikation zu überprüfen. Wichtige Daten- und Kontrollflüsse spiegeln sich nämlich immer auch in Funktionalitäten des Systems wider.

Spezifiziert werden Daten- und Kontrollflüsse im Wesentlichen in der System- und Softwarearchitektur. Aber auch in funktionalen, textuellen Anforderungsspezifikation werden Daten- und Kontrollflüsse abgebildet. Damit wird zukünftig auch die Rückverfolgbarkeit zwischen funktionalen Anforderungsspezifikation und der Architektur deutlich einfacher werden.

Fazit

Textuelle Anforderungsspezifikationen und die grafische Architektur sind die beiden Methoden, um komplexe Systeme erfolgreich zu spezifizieren. Eine große Herausforderung textueller Anforderungsspezifikationen ist die Überprüfung ihrer Vollständigkeit. Die Messung der strukturellen Testüberdeckung stellt dagegen ein eindeutig messbares Vollständigkeitskriterium dar.

Durch die neue Technologie der non-intrusiven Messung der strukturellen Testüberdeckung kann die Vollständigkeit von Anforderungsspezifikationen durch dynamische System- und Integrationstests überprüft werden. Die klassischen Messmittel zur Überprüfung der strukturellen Testüberdeckung können nur bei Modultests eingesetzt werden. Mit Modultests wiederum kann nicht die Erfüllung funktionaler Anforderungen nachgewiesen werden.

Da die non-intrusive Technologie auch den dynamischen Nachweis von Daten- und Kontrollflüssen ermöglicht, kann man jetzt auch die Vollständigkeit von Anforderungen bezogen auf die Daten- und Kontrollflüsse überprüfen.

Die non-intrusive Technologie ermöglicht nun die praktische Umsetzung von Methoden, die schon vor vielen Jahren als notwendig erkannt wurden. Dies gilt insbesondere für die Entwicklung sicherheitskritischer Systeme.

Aber auch für alle anderen Bereiche können Daten, die durch das kontinuierliche, non-intrusive Beobachtungsverfahren jetzt zur Verfügung stehen, genutzt werden. Die Qualität von Tests wird davon enorm profitieren.

Hinweise:

Interessieren Sie sich für weitere Erfahrungen aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

HEICON und Accemic Technologies stehen Ihnen gerne für weitere Fragen zum Thema zur Verfügung. Senden Sie einfach eine Mail an info@heicon-ulm.de.

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.