Eine Problematik liegt darin, dass die Systeme unserer Zeit immer mächtiger und komplexer werden. Softwareanwendungen sind nur selten noch Stand-alone-Programme, sondern vernetzen Informationen aus diversen Quellen (z. B. Apps nutzen zahllose Web-Services Dritter). Hardwareprodukte besitzen komplexe Softwaresteuerungen, welche nun unter dem Schlagwort „Internet der Dinge“ vernetzt werden (z. B. digitale Stellwerke der Bahn). Selbst vermeintlich einfache Alltagsprodukte werden für die bequeme Bedienung von überall vernetzt (z. B. Smart-Home-Produkte).
Mächtig komplex
Häufig handelt es sich auch nicht mehr um ein homogen entwickeltes System eines einzigen Entwicklungsteams, sondern es wird von verteilten Spezialistenteams entwickelt. Ferner beinhaltet das System oft ältere Vorgänger-Subsysteme und Subsysteme vonDrittherstellern, sei es Hardware (HW) oder Software (SW). Weiterhin wird in vielen Projekten eine Middleware eingesetzt, welche die einzelnen Komponenten zu einem kompletten System verbindet.
Diese gestiegene Komplexität erfordert bei der Systementwicklung äußerste Sorgfalt. Mängel hierbei können heutzutage nicht mehr durch einzelne sehr erfahrene Entwickler ausgeglichen werden, denn die Komplexität des Gesamtsystems kann in der Tiefe nicht mehr von einer Person erfasst werden.
„Mein“ Entwicklungsprozess
Erprobte Entwicklungsprozesse sind bereits ausgiebig beschrieben, sei es das klassische Vorgehensmodell (V-Modell) oder agile Entwicklungsprozesse wie Scrum. In der Praxis stößt man jedoch nicht selten auf lückenhafte Prozesse, bei denen häufig nur die Programmiertätigkeit im Vordergrund steht.
Begründet wird dies meist damit, dass die bewährten Entwicklungsprozesse „nicht passend“ für das jeweilige Projekt seien und deshalb ein eigener Prozess genutzt wird. Dieser ist dann meist nicht näher definiert, geschweige denn in einem Projekthandbuch dokumentiert.
Gerade in Projekten, die „agil“ sein wollen, wird das agile Manifest geradezu missbraucht, um ungeplantes Arbeiten auf Zuruf zu rechtfertigen und Dokumentation als generell überflüssig abzulehnen. Eine erfolgreiche Systementwicklung erfordert es aber, dass die Spezialisten eines Teams Hand-in-Hand zusammenarbeiten, damit der Entwicklungsprozess gelingen kann.
sepp.med empfiehlt:
- Definieren Sie Ihren Entwicklungsprozess (z. B. Projekthandbuch, „Sprint 0“ in Scrum).
- Nutzen Sie bewährte Entwicklungsmethoden.
- Dokumentieren und hinterfragen Sie eigene Adaptionen.
System mit Fundament
Konzentrieren wir uns im Folgenden zunächst auf das V-Modell (siehe Abbildung 1) und die klassische Entwicklung. Basis eines Systems ist das kundenseitig erstellte Lastenheft und darauf aufbauend die Systemspezifikation, das Pflichtenheft. Die Komplexität wird dann zerlegt über den Systementwurf (Architektur & Schnittstellenspezifikation). Für komplexe Datenschnittstellen ist zu empfehlen, diese in separaten Dokumenten zu beschreiben, da diese für jedes an der Kommunikation beteiligte Subsystem genutzt wird und Schnittstellen ebenfalls einer Versionierung unterliegen, wenn sie weiterentwickelt werden.
Abb. 1: Vorgehensmodell (V-Modell) mit den Abstraktionsebenen
Für jedes Subsystem ist dann eine Subsystemspezifikation zu erstellen, in der das jeweilige Subsystem als „Black Box“ beschrieben wird. Gegebenenfalls können noch weitere Verfeinerungsebenen für Komponenten und Module folgen. Für diese gelten die weiter unten beschriebenen Grundsätze selbstverständlich ebenso.
Es ergibt sich schnell eine große Menge an Dokumenten mit einer hohen Zahl von Anforderungen. Bei sauber definierten Prozessen und klaren Regeln für das Anforderungsmanagement kann nun ein belastbares Fundament für alle folgenden Entwicklungsschritte gelegt werden. Idealerweise verfeinern sich die Anforderungen von Ebene zu Ebene wie folgt:
- Jede Anforderung hat eine Motivation, das heißt, sie hat mindestens einen Vorgänger (kein „Gold-Plating“).
- Jede Anforderung wird weiter verfeinert, das heißt, sie hat mindestens einen Nachfolger (keine Umsetzungslücken).
- Stellen Sie klare prüfbare Regeln für die Verfolgbarkeit (Traceability) durch die Dokumente auf (z. B. Verlinkung nur zwischen benachbarten Ebenen).
Abstraktionsebenen prüfen
Bei der strikten Umsetzung dieser Regeln treten im Bereich des Anforderungsmanagements teilweise Probleme auf. Ursache sind hierfür nicht zu strikte Regeln, sondern lückenhafte Anforderungen oder die fehlerhafte Zuordnung der Anforderung zur Abstraktionsebene (= Spezifikationsdokument, siehe Abbildung 2). Fordert der Kunde in seinem Lastenheft zum Beispiel nur eine spezielle Benachrichtigungsinformation nach 1000 Betriebsstunden für die Wartung des Systems, so meint er vermutlich eine komplexe Diagnoseschnittstelle über die Statusinformationen, Wartungs- und Fehlermeldungen. Schnell lässt sich erahnen, dass hierfür plötzlich ein großes Bündel an Anforderungen auf System-, Subsystemund Schnittstellenebene benötigt wird.
Abb. 2: Schematische Darstellung der Anforderungstraceability über drei Abstraktionsebenen
Ob eine Anforderung korrekt dem Spezifikationsdokument zugeordnet ist, kann sehr gut geprüft werden, indem die korrespondierende Testphase betrachtet wird. Lässt sich die Anforderung wirklich in dieser Phase testen oder gehört Anforderung und Test in eine andere Abstraktionsebene? Wird zum Beispiel in einer Schnittstellenspezifikation gefordert, dass innerhalb von 100 ms eine Anfrage korrekt beantwortet werden muss, so ist diese falsch zugeordnet. Es ist eine Anforderung an das Subsystem! Für die Schnittstellenspezifikation ist zutreffend, dass es einen Timeout nach 100 ms gibt. Das befragte Subsystem soll beim Timeout eine qualifizierte Fehlernachricht generieren und versenden. Das anfragende Subsystem muss diese Fehlernachrichten behandeln sowie eigenständig Timeouts feststellen (falls die Kommunikation unterbrochen ist).
Abb. 3: Schematische Darstellung zum anforderungsbasierten Testen
sepp.med empfiehlt die Prüfung (s. Abb. 3):
- Sind die Anforderungen den richtigen Anforderungsdokumenten zugeordnet?
- Sind die Anforderungen in der jeweils korrespondierenden Testphase prüfbar?
Robuste Systeme
Bei der Definition von Schnittstellen empfiehlt es sich, bereits vorhandene, standardisierte Schnittstellen zu nutzen. Diese sind bewährt, gewähren Interoperabilität, ermöglichen den einfachen Austausch von Subsystemen (z. B. von einem anderen Hersteller) und vereinfachen die Einarbeitung von neuen Mitarbeitern. Bei der Spezifikation von Schnittstellen und Subsystemen sollten nicht nur die funktional erlaubten Datenwerte im Funktionsbereich betrachtet werden, sondern der gesamte Wertebereich, der technisch über diese Schnittstelle übermittelt werden kann.
Das Subsystem sollte robust ausgelegt sein, sodass im Falle von fehlerhaften Signalen oder inkonsistenten Daten qualifizierte Fehlermeldungen zurückgemeldet werden. Selbstverständlich muss das aufrufende Subsystem adäquat auf mögliche Fehler reagieren.
sepp.med empfiehlt:
- Betrachten Sie den kompletten Wertebereich der Schnittstellen.
- Legen Sie Subsysteme robust aus.
Integrationsstrategie
Bereits im Testkonzept sollte festgelegt werden, welche Integrationsstrategie angewendet werden soll. Beim „Big Bang“ werden alle Subsysteme gleichzeitig integriert. Nachteilig ist hier, dass die Fertigstellung aller Subsysteme abgewartet werden muss und alle Fehlerwirkungen gleichzeitig auftreten. Inkrementelle Strategien wie Topdown- oder Botton-up-Integration ermöglichen es, frühzeitig mit Integrationstests zu beginnen, allerdings benötigen diese Platzhalter (für die fehlenden Funktionen) oder Testtreiber (für den Aufruf). Die Wahl einer passenden Strategie hängt von den Projektgegebenheiten ab, jedoch sollte die „Big Bang“-Strategie vermieden werden.
sepp.med empfiehlt:
- Nutzen Sie – wenn möglich – inkrementelle Integrationsstrategien.
- Stimmen Sie die Integrationstests mit den Zeitplänen des Projektes ab und aktualisieren Sie diese im Bedarfsfall.
Fokussierung beim Integrationstest
Fokus des Integrationstests ist die Überprüfung, ob die zu integrierenden Subsysteme zusammen korrekt funktionieren. Vorausgesetzt wird, dass die einzelnen Subsysteme funktionstüchtig sind, also die Subsystemtests abgeschlossen sind.
Damit gibt es eine strikte Trennung zwischen diesen beiden Testphasen! Beim Integrationstest muss lediglich geprüft werden, ob die Systeme korrekt miteinander kommunizieren. Typische Fehler sind zum Beispiel das Vertauschen von Pins bei der Verkabelung der Subsysteme, das Nichtbeachten von eingeschränkten Wertebereichen, welches ein Subsystem voraussetzt oder neue beziehungsweise geänderte Nachrichten, da die Subsysteme unterschiedliche Versionen einer Schnittstellenspezifikation nutzen. Kurzum: Es ist beim Integrationstest zu prüfen, ob die Subsysteme sich „verstehen“ und zusammenspielen – nicht mehr und nicht weniger (siehe Abbildung 4).
Abb. 4: Beispiel für Integrationsstrategie mit den Subsystemtests und Integrationstests
sepp.med empfiehlt:
- Trennen Sie strikt die Testphasen zwischen Subsystem- und Integrationstest voneinander ab.
- Beachten Sie die Testreihenfolge – zuerst die Subsystemtests abschließen!
Frühzeitig testen – auch beim Integrationstest
Wie bei anderen Testphasen auch sollten die Aktivitäten für den Integrationstest frühzeitig beginnen (Projektplanung – Testkonzeption – Anforderungsermittlung & -abstimmung – Systemarchitektur). Die Spezifikation der Integrationstests kann sofort nach Abschluss der Anforderungsspezifikation begonnen werden. So können Fehler oder Lücken der Anforderungsspezifikation zeitnah aufgedeckt werden.
Auch wenn für die finale Durchführung des Integrationstests zuerst auf den Abschluss der Subsystemtests gewartet werden muss, können vorab durchgeführte Integrationstests von Vorversionen der Subsysteme (mit eingeschränkter Funktionalität) sinnvoll sein. Mit diesen Vorabtests kann sichergestellt werden, dass die Subsysteme mindestens bei den grundlegenden Funktionen korrekt zusammenspielen.
sepp.med empfiehlt:
- Beplanen Sie die Testaktivitäten ab Projektstart.
- Führen Sie die jeweiligen Testaktivitäten so früh wie möglich durch.
- Sichern Sie mit Vorabtests die generelle Funktion der Schnittstellen.
Agil? – Alles anders?
Nein! Prinzipiell gibt es die Testphasen auch bei der agilen Entwicklung. Insofern sind auch die Integrationstests mit zu betrachten. Oft werden diese aber implizit im Rahmen des Systemtests mit durchgeführt. Werden aber Integrationstests explizit gefordert (z. B. aufgrund der Kritikalität des Systems), so müssen diese auch bei der agilen Entwicklung explizit berücksichtigt und dokumentiert werden. Automatisierte Tests sind unverzichtbar, damit Tests zügig für jedesInkrement des Systems durchgeführt werden können.
In der Praxis anzutreffen sind Projekte, deren Subsysteme agil entwickelt werden, formale Abnahmen mit Integrations- und Systemtests sowie weitere Aufgaben für die Auslieferung (Dokumentationen, Inbetriebsetzung) jedoch „klassisch“ zu bestimmten Zeitpunkten stattfinden.
Fazit
Zusammenfassend lässt sich feststellen, dass die Entwicklungsprozesse vieler Projekte ausschließlich die Programmierung fokussieren. Anforderungen und Tests werden gerne vernachlässigt. Dies stellt jedoch ein unnützes Projektrisiko dar, welches insbesondere in Zeiten von Fachkräftemangel, Fluktuation von Mitarbeitern und dem Willen nach Wiederverwendung von (Sub-) Systemen unverständlich ist.
