![[Qualitätssicherung: (konstruktive Qualitätssicherung: technische + organisatorische Maßnahmen) + (analytische Qualitätssicherung: analysierende + testende Verfahren)]](40-1.jpg)
Abbildung 1: Qualitätssicherungsbaum
Besonders durch die zeitkritische Entwicklung von E-Commerce-Applikationen und der weltweiten Verfügbarkeit dieser Anwendungen haben die mit der Entwicklung und der Einführung von Software verbundenen Risiken eine neue Dimension gewonnen. Die Folgen von unzureichend kontrollierten Prozessen bei der Entwicklung und Einführung von geschäftskritischen Programmen wirken sich sowohl auf die Effizienz der Entwicklungsprozesse selbst als auch auf die klassischen Unternehmensrisiken aus. Typische Indikatoren für unzureichend kontrollierte Prozesse bei der Softwareentwicklung oder -einführung sind:
Unkontrollierte Prozesse bei der Softwareentwicklung können zu einem regelrechten Chaos bei der Entwicklung von Software oder der Anpassung von Standardsoftware führen. Dies kann sowohl erhebliche Finanzrisiken durch Überschreitung des geplanten Projektbudgets als auch Marketingrisiken durch den Verlust von "Time to Market" zur Folge haben.
Weiterhin liefert eine chaotische Softwareentwicklung auch zahlreiche Möglichkeiten für Flüchtigkeitsfehler oder Manipulationen, die bei geschäftskritischen Programmen zu erheblichen Unternehmensrisiken führen können. Dies betrifft unter anderem Betriebsrisiken (z. B. bei mangelnder Verfügbarkeit aufgrund einer fehlerhaften Software), Finanzrisiken (z. B. durch betrügerische Programmmanipulationen), Rechtsrisiken (z. B. bei falschen Preisangaben) oder Imagerisiken (z. B. durch Zunahme der Kundenbeschwerden bei Softwaremängeln).
Ein umfassendes Risikomanagementsystem muss die Risiken aus der Softwareentwicklung und -einführung daher zwingend miteinbeziehen. Dabei sollte sich das Risikomanagement sowohl auf Frühwarnindikatoren als auch auf ein funktionierendes, risikoorientiertes Softwarequalitäts- und -konfigurationsmanagement als Bestandteil des internen Überwachungssystems stützen.
Unter Qualitätssicherung werden per Definition des IEEE alle Maßnahmen verstanden, die ein angemessenes Vertrauen schaffen, dass eine "Einheit" eine Qualitätsforderung erfüllen wird. Qualitätssicherung in der Softwareentwicklung umfasst sowohl konstruktive als auch analytische Qualitätssicherungsmaßnahmen, die phasenspezifisch eingesetzt werden (vgl. Abb. 1). Im Rahmen der hier betrachteten Risiken sind besonders die Testverfahren als analytische Qualitätssicherungsmaßnahmen von Bedeutung.
Abbildung 1: Qualitätssicherungsbaum
Um kritische Softwarefehler vor einem Produktiveinsatz zu entdecken und gleichzeitig den Aufwand beim Testen auf ein wirtschaftlich vertretbares Maß zu reduzieren, müssen die Tests risikoorientiert geplant und durchgeführt werden. Eine risikoorientierte Testkonzeption sollte dabei in Form eines Managementkreislaufes erfolgen (vgl. Abb. 2), der folgende Phasen umfasst:
![[Risiken erkennen -> analysieren -> vermindern -> Testkonzept -> Risiken während des Tests überwachen -> Risiken erkennen ...]](40-2.jpg)
Abbildung 2: Risikoorientierte Testkonzeption
In dieser Phase werden Informationen über das IT-Projekt im Allgemeinen und über die Risiken in den einzelnen Funktionen und Modulen erhoben. Anhaltspunkte für Risiken sind beispielsweise der Einsatz neuer Technologien und Methoden, eine unzureichende Qualität des Fach- und DV-Konzeptes oder geringe Kenntnisse über den fachlichen Hintergrund bei den Programmierern [1, 2].
Die erkannten Risiken sind in Sinne der klassischen Risikoanalyse mit den Faktoren Eintrittswahrscheinlichkeit und Schadenshöhe zu bewerten. Dazu können bei der Softwareentwicklung und beim Customizing die Risikofaktoren Komplexität und "Kritikalität" (als Kunstwort für das Maß der kritischen Folgen) dienen. Mögliche Indikatoren für die Bewertung des Risikofaktors Komplexität als Maß für die Eintrittswahrscheinlichkeit sind
Mögliche Indikatoren für die Bewertung des Risikofaktors Kritikalität als Maß für die Schadenshöhe sind die Auswirkungen der Risiken in Bezug auf
Auf Basis der Risikoanalyse sollte man bereits vor Testbeginn Maßnahmen zur Risikoverminderung und damit zur Reduzierung des Testaufwands einleiten. Zum Beispiel können konstruktive Qualitätssicherungsmaßnahmen oder analysierende Qualitätssicherungsverfahren in risikokritischen Bereichen verstärkt werden, um spätere Aufwendungen für dynamische Testverfahren zu minimieren.
Auf Basis der Informationen aus den vorhergehenden Phasen wird im Testkonzept der Testumfang für jede Funktion und jedes Modul definiert. Ein Testkonzept kann für Bereiche mit hoher Komplexität und Kritikalität eine systematische Testfallermittlung festlegen, während für unkritische Funktionsbereiche ein intuitives Testvorgehen ausreichend sein kann (vgl. Abbildung 3).
![[für niedrige Komplexität und Kritikalität genügen intuitive Tests, hohe Anforderungen erfordern eine systematische Testfallermittlung]](40-3.jpg)
Abbildung 3: Risikoorientierte Priorisierung von
Testszenarien
Zur laufenden Einschätzung der identifizierten Risiken und zur Identifikation weiterer Risiken ist die Testdurchführung laufend zu überwachen. Dabei sollten Metriken zum Einsatz kommen, bei deren Abweichung von erwarteten Entwicklungen der Risikomanagement-Kreislauf wieder von vorne durchlaufen werden muss. Typische Testmetriken sind:
Eine Konfiguration eines modernen IT-Systems besteht in der Regel aus Programmen (Kern und Oberfläche), fachlichen Parametern und Systemeinstellungen, sowie aus Daten und Dokumenten. Unter Konfigurationsmanagement versteht man im Wesentlichen die Verwaltung aller greifbaren Ergebnisse (z. B. Programme, Datei- und Programmbeschreibungen, Testfälle und Anwenderdokumentation), die im Laufe des Projektes erzeugt werden. Darüber hinaus kann ein Konfigurationsmanagementsystem folgende Funktionen umfassen [3]:
Aus Sicht eines umfassenden Risikomanagements muss zur Verhinderung der genannten Risiken ein angemessenes Software-Konfigurationsmanagement sowohl eine geordnete Softwareentwicklung als auch einen kontrollierten Softwareeinsatz sicherstellen. Ohne ein risikogerechtes Konfigurationsmanagementsystem kann man die Konsistenz der unterschiedlichen Dokumente in einem IT-Projekt (z. B. Anforderungsdokumentation in MS Word, Relationenmodell in ERWin, Testdaten in MS Excel, Hilfe in HTML, Installationsskripte in PERL) oder die Kontrolle von Dateiänderungen über unterschiedliche Entwicklungsplattformen sowie über räumlich verteilte Standorte hinweg bei einer zunehmenden Heterogenität der Entwicklergruppe nicht mehr gewährleisten [4].
Ob ein organisatorisches Verfahren, eine einfache Versionsverwaltung oder ein komplexes Konfigurationsmanagementsystem notwendig sind, hängt von der Art und dem Umfang des IT-Projektes ab. Da die Einführung von Systemen für das Konfigurationsmanagement in einem IT-Projekt einen erheblichen personellen und finanziellen Aufwand darstellt, sollte man die Auswahl des Konfigurationsmanagementsystems risikoorientiert vornehmen [5]. Als Anhaltspunkte können dabei die Risikofaktoren Prozess- und Produktkomplexität dienen. Als Indikatoren für den Risikofaktor Prozesskomplexität sind beispielsweise folgende Kriterien denkbar:
Für den Risikofaktor Produktkomplexität können unter anderem folgende Indikatoren Verwendung finden:
![[niedrige Produktkomplexität erlaubt Speziallösungen, hohe Komplexität erfordert Universallösungen - niedrige Prozesskomplexität erfordert globale Lösungen, niederige Prozesskomplexität erlaubt lokale Lösungen]](40-4.jpg)
Abbildung 4: Risikoorientierte Auswahl von
Konfigurationsmanagementsystemen
Bei Anwendung dieser Risikofaktoren lässt sich das IT-Projekt in einen der vier Quadranten der in Abbildung 4 gezeigten Matrix mit den Achsen Prozess- und Produktkomplexität einordnen. Die Zuordnung in die Quadranten gibt einen risikoorientierten Anhaltspunkt für die Auswahl eines geeigneten Konfigurationsmanagementsystems.
Bei dessen Auswahl sollte man aber auch mögliche Revisionsanforderungen wie Protokollierung von Erstellungs- und Änderungsdatum, Zuweisung und Nachweis von Versionsständen während der gesetzlichen Aufbewahrungsfristen, Lieferung aktueller Statusinformationen und historischer Daten sowie Anforderungen an die Sicherheit beachten. Für buchführungsrelevante IT-Systeme ist die Sicherstellung der Programmidentität im Sinne einer inhaltlichen Übereinstimmung zwischen eingesetzter Software und der Dokumentation zu dieser Software zudem zwingend vorgeschrieben [6]. Grundsätzlich muss daher das zu prüfende System, sei es eine Eigenentwicklung oder eine Standardsoftware, beim Abnahmetest unter Konfigurationskontrolle stehen.
Markus Gaulke ist Senior Manager im Bereich Information Risk Management der KPMG in Frankfurt. Vom Autor wird in Kürze auch ein Buch über Risikomanagement in IT-Projekten erscheinen.
© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 4/2001, Seite 40
