Bewertung: 5 / 5

Stern aktivStern aktivStern aktivStern aktivStern aktiv
 

iele Softwareprojekte erweitern eine bestehende Applikation. Insbesondere, wenn es sich um „legacy“ Anwendung handelt kommt es hier zu Problemen, wenn das Anforderungsmanagement das bestehende System als einzelne Basisanforderung nimmt, anstatt die einzelnen Funktionen zu analysieren. Ein Beispiel für ein solches Vorgehen ist, dass das Unternehmen ein anderes aufgekauft hat und nun die Funktionalität der eigenen legacy Anwendung erweitert. Anstatt den kompletten Funktionsbedarf zu bestimmen, wird nur das „Delta“ betrachtet, die Menge an neuer Funktionalität, welche man zum aktuellen Zeitpunkt abschätzt. (Damit meine ich implizit: Auch die Testfallbasis für das bestehende System ist nicht vorhanden oder veraltet.)
Die Zeit für eine komplette Analyse wird „eingespart“.

Ist die bestehende Anwendung schlecht dokumentiert (und davon gehe ich jetzt einfach mal aus), dann führt eine Softwareerweiterung schon auf der Entwicklungsseite zu „unvorhergesehenen“ Problemen. Auf der Testseite wird es richtig spannend: Auf welcher Basis findet nun die Testfallermittlung statt?
Sie wollen ja nicht nur die neue Funktionalität testen, sondern auch sicherstellen, dass die bestehende Funktionalität das tut, was sie tun soll. Daher wird die Anforderungsanalyse eigentlich nur in die Testvorbereitung geschoben, anstatt schon vorher von den Business Analysten gemacht worden zu sein. Weshalb die Testvorbereitung dann plötzlich länger dauert, ist dann überraschenderweise vielen Projektmanagern ein Rätsel!

Eine weitere Komplexitätserhöhung resultiert aus der Projektlaufzeit: Zusätzlich zur Weiterentwicklung auf das eigentliche Projektziel hin, gibt es eine Wartung des Produktivsystems (Funktionserweiterungen zusätzlich zum laufenden Projekt), welche notwendige Erweiterungen der bestehenden Funktionalität macht. Gibt es jetzt kein übergreifendes Anforderungsmanagement (gibt es nicht, weil die Basisfunktionalitäten sind ja nicht einzeln benannt), dann werden die Testfälle auf ein „moving target“ hin entwickelt.

Auch die Testfallentwicklung auf Basis des Altsystems ist fragwürdig: Ein Testfall besteht ja bekanntlich aus einer Arbeitsanweisung, Testdaten und einem erwartetem Ergebnis. Das erwartete Ergebnis leitet der Tester nun aus einem Alt-System ab, von dem er nur annimmt, dass es das bisher richtig tut.

Wie geht man jetzt richtigerweise an das Problem heran:

  • Man bezieht die Neuentwicklung und das Applikationsverhalten auf eine definierte Version der Alt-Applikation. Parallelentwicklungen laufen in einem separaten Code-Strang, der erst in einer eigenen Teststufe am Projektende mit dem Projekt verheiratet wird.
  • Die bestehende Applikation wird analysiert und dokumentiert. Aus Zeitgründen kann dies als Liste, gliedert nach den Modulen, etc. passieren. Daraus leiten sich dann Testszenarien ab. Es reicht dabei nicht, die Benutzerschnittstelle zu dokumentieren. Dahinter liegende Prozesse und Rechenkerne müssen ebenfalls dokumentiert werden, um sinnvolle Testszenarien abzuleiten.
  • Einbindung von Aktualisierungen (Updates, Produktionswartung) der bestehenden Applikation in das übergreifende Anforderungsmanagement.
  • Für die Zukunft sollte ein Projekt-übergreifender (also zeitlich gemeint – von Projekt zu Nachfolgeprojekt) Entwicklungs-, Dokumentations- und Testprozess implementiert werden.