Software richtig verifizieren und validieren

21. April 2009, 12:14 Uhr | Brian Hooper
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Anforderungen richtig verfolgen

Durch die Einführung von CMMI lassen sich spezifische Praktiken, die mit jedem Prozessbereich verknüpft sind, zu einem Rahmen für das ganze Projekt zusammenfügen. Beispielsweise sind Anforderungen während des Lebenszyklus’ eines Projektes sowie von ihnen abhängige, nachrangige Objekte durch die bidirektionale Verfolgbarkeit adäquat zu verwalten. Andererseits verlangt die Verifikation, die überwachenden Überprüfungen für alle Komponenten durchzuführen. Darüber hinaus beeinflussen die verschiedenen Prozessbereiche einander, daher muss der Entwickler diese während das Projekt voranschreitet, miteinander synchronisieren. Beispielsweise sind die Komponentenanforderungen, die während der Anforderungsentwicklung erzeugt wurden, mit derselben Disziplin zu verwalten wie der Anforderungssatz des Endanwenders. Verifizierung und Validierung tragen Tests und Testergebnisse zur Datenbank der Anforderungsverfolgung bei.

passend zum Thema

Die Entwicklung eines Prozessrahmens, der von CMMI beeinflusst wird, ist sicherlich ein guter Start. Die Notwendigkeiten und die Ziele für ein Projekt sind dann ziemlich klar. Wie lassen sich diese aber erreichen? Welche Arbeitsflussprozesse treiben die Anforderungen durch den Entwurf, die Implementierung und den Test voran? Welche Werkzeuge können Aufgaben wie Anforderungsverwaltung und Komponentenverifizierung automatisieren, unterstützen und optimieren?

Die technische Lösung schreibt vor, dass Lösungen gemäß den Anforderungen zu konstruieren sind. Das Entwicklungsteam muss entscheiden, ob alle Anforderungen auf einmal zu implementieren sind, oder ob es besser ist, sich auf einige wenige Anforderungen zu beschränken und eine Lösung für alle Anforderungen nach und nach zu entwickeln. CMMI schreibt dies nicht vor. Es liegt am Team, Entwicklungspraktiken und -prozesse zu adaptieren, die zum Projektfortschritt beitragen und gleichzeitig mit den Zielen von CMMI vereinbar sind.

Wenn die Entwicklung einem »Wasserfall-Modell« folgt, resultieren daraus viele Nachteile, sodass alternative Modelle wie »Unified Process«- oder »agile« Methoden an Popularität gewonnen haben. Solche neueren Methoden legen typischerweise großen Wert auf die Verwaltung von Anforderungen sowie auf deren Organisation, eidie ein wesentlicher Antrieb für die daraus nachfolgenden Entwicklungsebenen ist. Zusammengefasst sind anschließend die wesentlichen Schlüsselprinzipien der meisten Methoden:

  • Prägnante, auf den Endanwender bezogene Formulierung der Anforderungen wird langen Listen mit individuellen Merkmalen und Beschränkungen vorgezogen. Verschiedentlich als »Anwendungsfall « oder »Anwendergeschichte « bezeichnet, erlauben diese eine bessere Zusammenarbeit mit dem Endanwender und stellen den Wert oder das Ergebnis, das die Lösung erzeugen soll, in den Mittelpunkt.
  • Anforderungen ändern sich während der Lebenszeit eines Projektes. Dies ist ein natürlicher und nicht zu vermeidender Vorgang, der sich entweder daraus ergibt, dass der Endanwender seine Sichtweise auf die Lösung ändert oder dass sich der Rahmen des ganzen Projekts ändert. Projekte sind deshalb so zu organisieren und zu verwalten, dass Änderungen vorgenommen werden können.

Anwendungsfälle sind formal in der »Unified Modelling Language« (UML) definiert, während Anwendergeschichten ein Element der extremen Programmierung sind. Die Konzepte dahinter sind jedoch in beiden Fällen dieselben: Sie unterteilen das System grober als mit einer Liste von Anforderungen. Gleichzeitig wird betrachtet, wie das System dem Endanwender nutzt, und nicht, was es an und für sich kann. Beispielsweise denkt man bei einem Motormanagementsystem in einem Auto, das als Liste von Anforderungen spezifiziert ist, unweigerlich sofort an deren Implementierung. Allerdings ist zu diesem Zeitpunkt eigentlich nur wichtig, wie es sich zu den anderen Subsystemen im Auto verhält, mit denen es verbunden sein wird.

Anwendergeschichten werden typischerweise auf kleine Papierkarten oder sogar Haftnotizen geschrieben, sodass die Zusammenarbeit und Diskussion zwischen den Mitgliedern des Entwicklungsteams leicht vonstatten gehen kann. Anwendungsfälle lassen sich auf dieselbe Art und Weise formulieren, oder sie werden mit einem UML-Werkzeug erzeugt (Bild 2). Auf einige Schlüsselmerkmale soll in diesem Diagramm noch hingewiesen werden: So ist der Rand des Systems klar markiert, ferner sind die Anwendungsfälle innerhalb des Systems und alle Akteure außerhalb; das Strichmännchen für die Akteure impliziert nicht, dass diese unbedingt Menschen sind.

LDRA_02_af_03.jpg
Bild 2: Diagramm des Anwendungsfalls

  1. Software richtig verifizieren und validieren
  2. Szenarien durchspielen
  3. Anforderungen richtig verfolgen
  4. Software richtig verifizieren und validieren

Jetzt kostenfreie Newsletter bestellen!