Von den Anforderungen bis zum Source Code Wie man für konsistente Dokumente im V-Modell sorgt

Ingenieurwesen ist die Wissenschaft des systematischen Erfindens. Doch wieviel Systematik bleibt noch, wenn die Anforderungen eines Projekts in einem Wust unstrukturierter Text-Dokumente definiert sind? Mit einem Repository lassen sich Ordnung und Übersicht in die Dokumentation bringen, so dass der Entwicklungsprozess nicht aus dem Ruder läuft.

Wer bleibt schon von wachsender Komplexität verschont? Sie als Leser dieser ARM-Sonderausgabe sicher nicht, denn es scheint, Sie informieren sich gerade über neue leistungsfähigere Mikrocontroller. Wahrscheinlich, weil der derzeitige den Anforderungen nicht mehr gerecht wird. Aber wie sieht es aus mit den Anforderungen im Software- und Systems-Engineering? Wie steht es um die Konsistenz der Projektdokumentation, den Lasten- oder Pflichtenheften zum Beispiel gegenüber dem Code? Wurden sie auf Basis von Word-Dokumenten erstellt? Bei steigender Komplexität geraten auch Vorgehen im Software-Engineering an die Grenzen der Effizienz.

Im Software-Engineering werden immer noch viele Informationen in Form von Office-Dokumenten verwaltet. Dabei entstehen je nach Phase und Technik im Engineering-Prozess separate Dokumente mit redundanten Informationen. Unter dem wachsendem Zeitdruck ist es fast unmöglich, diese redundanten Informationen in den verschiedenen Dokumenten konsistent zu halten.

So zeigt eine Umfrage unter unseren Kunden, dass in 95 % der Projekte die Dokumentation der Software (egal, ob sie mit MS Word, MS Visio oder anderen dokumentenzentrischen Werkzeugen erstellt wird) nahezu nutzlos ist, da sie nicht konsistent mit dem Source-Code gehalten werden kann und damit nicht verlässlich ist. In Projekten, in denen auf Grund von Sicherheitsanforderungen hohe Qualität gefordert wird, gehört es schon seit langem zum Stand der Technik, dass alle Dokumente, Modelle, Code und Testfälle untereinander konsistent gehalten werden. Grundsätzlich ist es also möglich und nur eine Frage des Vorgehens. Was mit einer dokumentenzentrischen Arbeitsweise ein fast unmögliches Unterfangen ist, wird auf Basis eines Repository auf einmal sehr einfach.

Lassen sich redundante Informationen vermeiden?

Stellen wir uns einmal die Rollen und Personen in folgendem Projekt vor. Eine Firma möchte die Entwicklung eines Audio-D/A-Konverters in Auftrag geben. Betrachten wir die so genannten Stakeholder in diesem Projekt hinsichtlich einer Produkteigenschaft, dann könnten in etwa folgende Informationen entstehen:

  • Der angestrebte Zielmarkt sind Menschen mit gehobenem Musikanspruch, hinsichtlich des Sounds steht im Lastenheft "HiFi High End Qualität".
  • Der Projektleiter hat bei dieser Definition berechtigte Bedenken bezüglich der Testbarkeit und definiert etwas exakter eine Auflösung von 16 bit und eine Sample-Frequenz von 44,1 kHz entsprechend dem RedBook-Standard für Audio-CDs.
  • Der Entwickler programmiert einen Timer, um den Takt für die erforderliche Sample-Frequenz zu erzeugen; die Syntax könnte in etwa so aussehen: GPT1Reload = 0xFF32;

Eigentlich steckt hinter der Syntax aller Stakeholder die gleiche Information -allerdings in verschiedenen sprachlichen Ausprägungen. Könnte man diese vereinheitlichen? Ich befürchte nicht. Die Aussagen sind domänenübergreifend nicht mehr verständlich oder nicht präzise genug. Wir müssen also mit redundanten Informationen leben, aber wie geht das mit vertretbarem Aufwand?

Im dokumentenzentrischen Vorgehen ergibt sich eine große Anzahl an Dokumenten mit redundanten Informationen und gegenseitigen Abhängigkeiten (Bild 1). Bei einem genaueren Blick in die Dokumente stellt sich heraus, dass es sich in der Regel um 1:n-Beziehungen handelt. In realen Projekten ist die Größe eines Lasten- oder Pflichtenheftes im Bereich von 100 Seiten nicht selten. Ändert sich eine Anforderung im Lastenheft, dann wird niemand das komplette Pflichtenheft durcharbeiten, um alle Abhängigkeiten herauszufinden. Dies ist der erste Schritt zu inkonsistenten Dokumenten.

Einfacher geht es auf Basis eines Repository z.B. mit Hilfe eines Anforderungsmanagement-Werkzeugs. (Bild 2) zeigt die Gegenüberstellung der Dokumente auf Basis ihrer Beziehungen. Hier können Auswirkungen auf einen Blick vollständig erfasst werden. Auf Basis eines Repository lassen sich Abhängigkeiten von Anforderungen eines Projektes in Beziehung setzen.

Sehr häufig werden als Quellen für Anforderungen lediglich Kunden oder Anwender gesehen. In der Praxis können Anforderungen aber von überall her kommen. Stellen Sie sich vor, die Leistung des eingesetzten Mikrocontrollers ist nicht mehr ausreichend. Ein Hardware-Re-Design ist geplant und in diesem Zusammenhang muss ein neuer Mikrocontroller ausgewählt werden. Was sind die Anforderungen für den Mikrocontroller?

In diesem Fall, in dem die Software wiederverwendet werden soll, kommen die Anforderungen im Wesentlichen aus der Implementierung. Wurden im Repository die Abhängigkeiten zwischen Software und Mikrocontroller-Peripherie definiert, lässt sich sehr schnell ein Dokument erstellen, in dem alle Peripherie-Elemente mit den Anforderungen aus der Software aufgelistet sind.