Software richtig verifizieren und validieren
Fortsetzung des Artikels von Teil 1
Szenarien durchspielen
Jeder Anwendungsfall oder jede Anwendergeschichte umfasst verschiedene Szenarien. Das erste Szenario ist immer der »Basispfad« oder das »sonnige« Szenario, bei dem der Akteur und das System auf normale Art und Weise fehlerfrei miteinander agieren. Wenn wir zu unserem Beispiel mit dem Motormanagementsystem zurückkehren, dann kann ein solches Szenario darin bestehen, dass sich das System im Leerlauf mit konstanter Benzinzuführung befindet und sich die Temperatur innerhalb des erlaubten Bereiches bewegt. Dann sind alternative und außergewöhnliche Szenarien zu betrachten, in denen das System Probleme und Ausfälle behebt, wie zum Beispiel Stoppen der Benzinzufuhr.
Jobangebote+ passend zum Thema
Der Endanwender muss voll in die Entwicklung solcher Szenarien einbezogen sein, und sobald jedes vollständig ist, muss jedem Szenario eine Priorität zugeordnet werden, sodass sich eine vollständige Rangfolge der Szenarien erzeugen lässt. Wie in Bild 3 gezeigt, benötigt das Projektteam eine nach Prioritäten geordnete Liste von Szenarien, damit es jede Iteration planen kann und den Teil des Systems auswählen kann, der implementiert werden soll.
Nachdem die Verifizierung einer Iteration vollständig ist, lassen sich Metriken für den Fortschritt berechnen. Das Team muss folgende Fragen beantworten: Wurden alle ausgewählten Szenarien implementiert und getestet? Wurde irgendein Rückschritt in früher ausgeführten Iterationen beobachtet? Durch die regelmäßige Analyse des Fortschritts des Projekts kann die berechnete »Geschwindigkeit« benutzt werden, um zukünftige Iterationen zu planen. In der Zwischenzeit, also während der Entwicklung, kann der Endanwender seine Anforderungen geändert oder angepasst haben, sodass sich möglicherweise die prioritätsgeordnete Liste der Szenarien geändert hat. Ein solcher iterativer Ansatz erlaubt es, flexibel auf derartige Änderungen sowie auf den Fortschritt bei der Entwicklung zu reagieren.
Anforderungsbasiertes Testen
In der Softwareentwicklung ist der Test oft eine armselige Angelegenheit, denn beim Wasserfall-Ansatz ist dieser die letzte Phase im Entwicklungszyklus. So wird die Zeit für das Testen unvermeidlich zwischen den anderen Phasen, die in der Regel länger gedauert haben als geplant, und dem unverrückbaren Auslieferungstermin eingezwängt. Im Ergebnis kommen Softwarekomponenten zur Auslieferung, die hinter einem vorgegebenen Standard zurückbleiben, einfach weil nicht genügend Zeit zum Testen geblieben ist. Bleiben jedoch Defekte in der ausgelieferten Software zurück, werden mit hoher Wahrscheinlichkeit Probleme auftreten. Diese können zu kostspieligen Untersuchungen ausarten oder gar zum Rückruf des Produktes. Der eigene Ruf wird beschädigt, und es kann zu großen wirtschaftlichen Schäden kommen.
Es ist ein weit verbreitetes Missverständnis, dass man Software mithilfe von Tests verifiziert. Tatsächlich sollten Tests die Anforderungen verifizieren und validieren, denn es sind die Anforderungen, die mit dem Endanwender diskutiert werden. Daher wird dieser die gelieferte Lösung weitgehend danach beurteilen, ob sie seine Anforderungen erfüllt. In Bild 1 verweisen sowohl die Verifizierung (VER) als auch die Validierung (VAL) auf die Anforderungsentwicklung (RD). Somit treiben die Anforderungen den Testaufwand voran.
- Software richtig verifizieren und validieren
- Szenarien durchspielen
- Anforderungen richtig verfolgen
- Software richtig verifizieren und validieren
