Späte Änderungen an den Produktanforderungen in komplexen Softwaresystemen
22. September 2021
In der Theorie geht man davon aus, dass im Rahmen der „traditionellen“ Entwicklung eines neuen komplexen Systems, frühzeitig stabile und vollständige Systemanforderungen aus den Produktanforderungen abgeleitet wurden. Dadurch sollte bereits vor der ersten Zeile Softwarecode oder dem ersten MVP klar sein, was und vor allem wie entwickelt werden soll.
Dieses Vorgehen ist dahingehend nachvollziehbar, weil es die Entwicklung planbar macht und dies von den zulassenden Stakeholdern akzeptiert und sogar gefordert wird.
Die frühzeitig feststehenden Anforderungen legen nahe, dass man die Testfallentwicklung (Testdesign) mit der Entwicklung/Entstehung des komplexen Systems parallelisieren kann. Dadurch wird in der Theorie das Produktrisiko und im Idealfall sogar die Entwicklungszeit reduziert.
Theorie vs. Praxis
Warum zeigt sich nun in der Praxis also häufig ein gegenteiliges Bild? Häufig sieht man eine Verzögerung bei der Entwicklung und Fertigstellung von komplexen Systemen. Woran liegt das?
Neben den allgemein bekannten Problemen (technische Herausforderungen, personelle Kapazitätsengpässe, etc.) spielt auch die Änderungsrate bei den Anforderungen eine wesentliche Rolle, wodurch die Entwicklung und Fertigstellung des komplexen Systems verzögert werden. Deshalb sollte die Änderungsrate der Anforderung als Metrik während des Projektverlaufs getrackt und ausgewertet werden.
Betrachtet man den zeitlichen Verlauf der Änderungsrate der Anforderungen und die Testdesignaufwände, erwartet man zurecht, dass zu Beginn der Entwicklung eine hohe Änderungsrate bei den Anforderungen zu beobachten ist, es werden in der Konzeptphase technische Lösungen erarbeitet und entsprechend auch in den Systemanforderungen spezifiziert.
Sobald sich diese Änderungsrate der Anforderungen aber auf einem niedrigen Niveau stabilisiert hat, sollte die Verifizierung mit der Spezifizierung der Testfälle (formale Systemtests) basierend auf stabilen Anforderungen beginnen. In der Regel werden jetzt nur noch wenige Änderungen an den Systemanforderungen erwartet und somit eine geringe Änderungsrate der Anforderungen.
In der Praxis zeigt sich ein anderer zeitlicher Verlauf: Sobald von stabilen Systemanforderungen ausgegangen wird, beginnt die Verifizierung mit der Entwicklung der Testfälle (formale Systemtests). Und genau hier zeigt sich der Fehler in der Theorie.
Entgegen der Erwartung, dass die Änderungsrate der Anforderungen stabil ist oder nur minimal steigt mit dem Beginn der Testdesignaktivitäten, zeigt sich häufig in der Praxis eine explosionsartige Steigerung der Änderungsrate der Anforderungen.
Dies ist häufig auf folgende Punkte zurückzuführen: Die Anforderungen sind unvollständig, widersprüchlich oder einfach nicht testbar.
Diese Gründe sind fast vollständig auf die späte Einbindung der Verifizierung in die Entwicklung von komplexem System zurückzuführen.
Letztlich mildert eine frühe Einbindung jedoch häufig nur diesen Effekt, verhindert wird er dadurch nicht.
Kommunikation verbessern, Verständnis für Anforderungsänderungen schärfen
Eine Steigerung der Kommunikation im Projekt und ein Verständnis für die Folgen von späten Änderungen von Anforderungen ist notwendig. Es ist immer eine Kosten-Nutzen-Abwägung bei Anforderungsänderungen erforderlich, bevor diese durchgeführt werden und gegebenenfalls zu Blindleistungen in der Verifizierung führen.
Die späten Änderungen von Anforderungen sollten niemals die Entscheidung eines Einzelnen innerhalb des Projekts sein, sondern immer durch ein Team oder ein Gremium aus den verschieden Fachvertretern entschieden werden. Auch der Blick von außen durch einen externen Testing-Partner ist eine sinnvolle Unterstützung, wenn es um eine rationale Einschätzung der Notwendigkeit von Änderungen geht.
Wir von HiQ Projects unterstützen Sie gerne als externen Testing-Partner in Ihren komplexen Softwarelösungen.
Kontaktieren Sie uns einfach und sprechen Sie uns ganz unverbindlich an.
Wir freuen uns auf Sie und den Austausch mit Ihnen!
