Konzept zur Implementierung eines Testwerkzeugs für die Automatisierung von Black-Box-Testverfahren

Inhaltsverzeichnis

1 Einleitung und Problemstellung

2 Softwarequalität
2.1 Qualitätsmerkmale
2.1.1 Statische Qualitätsmerkmale
2.1.2 Dynamische Qualitätsmerkmale
2.1.2.1 Funktionalität
2.1.2.2 Leistung
2.1.2.3 Kontinuität
2.1.2.4 Benutzungsfreundlichkeit
2.2 Kosten und Nutzen von Softwarequalität

3 Qualitätssicherung
3.1 Organisatorische Maßnahmen und Management der Qualitätssicherung
3.2 Konstruktive Maßnahmen der Qualitätssicherung
3.2.1 Das iterierte Phasenmodell
3.2.1.1 Die Phasen des Softwarelebenszyklus
3.2.1.2 Bewertung des iterierten Phasenmodells
3.2.2 Prototyping und Rapid Application Development
3.3 Analytische Maßnahmen der Qualitätssicherung
3.3.1 Klassifikation der Maßnahmen der analytischen Qualitätssicherung
3.3.2 Das V-Modell
3.3.2.1 Modultest
3.3.2.2 Integrationstest
3.3.2.3 Systemtest
3.3.2.4 Abnahmetest

4 Black-Box-Testverfahren
4.1 Testablaufplanung
4.2 Äquivalenzklassen
4.3 Grenzwertanalyse
4.4 Praxisbeispiel zur Ermittlung von Testfällen

5 Automatisiertes Testen
5.1 Capture/Replay-Tools
5.1.1 Skripterstellung
5.1.2 Skriptwiedergabe
5.2 Vorteile und Ziele der Testautomatisierung
5.3 Einsatzmöglichkeiten der Testautomatisierung
5.4 Skriptprogrammierung
5.4.1 Entwicklung automatisierter Tests
5.4.2 Functional Decomposition
5.4.3 Die Aktionswort-Methode
5.5 Erfolgsfaktoren für die Testautomatisierung
5.6 Schwierigkeiten der Testautomatisierung
5.7 Quantitativer Nutzen der Testautomatisierung

6 Praktische Erfahrungen mit Testautomatisierung in der AXA Krankenversicherung AG
6.1 Einsatzmöglichkeiten für die Makro-Funktionalität der Emulations-Software
6.2 Einsatzmöglichkeiten für das Capture/Replay-Tool QA-Hiperstation
6.3 Anreicherung von Testdaten für das Projekt Euro-Umstellung
6.4 Regressionstests im Rahmen des Projekts Beitragsanpassung 2002
6.5 Ausblick

7 Fazit

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Umsetzungstabelle Qualitätsmerkmale TMap und ISO 9126,

Abbildung 2: Aufteilung der Softwarekosten,

Abbildung 3: Qualitätskosten,

Abbildung 4: Vorbeugen ist billiger als heilen!,

Abbildung 5: Maßnahmen der Software-Qualitätssicherung,

Abbildung 6: Das iterierte Phasenmodell,

Abbildung 7: Das V-Modell,

Abbildung 8: Fachvorgabe für die Prämienberechnung,

Abbildung 9: Testfallkandidaten für die Prämienberechnung,

Abbildung 10: Verdichtung der Testfallkandidaten für die Prämienberechnung,

Abbildung 11: Testfälle für die Prämienberechnung,

Abbildung 12: Testdatenkombinationen für die Prämienberechnung,

Abbildung 13: GUI-Tabelle,

Abbildung 14: GUI-Tabelle für neue Softwareversion,

Abbildung 15: Testbericht,

Abbildung 16: Testtabelle mit Eingabedaten,

Abbildung 17: Testfalldokumentation für die Aktionswort-Methode,

Abbildung 18: Testframe-Automatisierungs-Architektur,

Abbildung 19: Break-Even-Point der Automatisierung von GUI-Tests,

Abbildung 20: Vergleich von manueller und Makro-unterstützter Testdaten-anreicherung,

Abbildung 21: Nutzen der Testautomatisierung im Rahmen des Projekts Beitragsanpassung 2002,

1 Einleitung und Problemstellung

Diese Diplomarbeit beschäftigt sich mit der Automatisierung von Black-Box-Testverfahren für Computersoftware. Basierend auf der Erkenntnis, dass ein qualitativ hochwertiger Testprozess für eine hohe Softwarequalität unabdingbar ist, gilt es, diesen so effizient wie möglich zu gestalten. Ein Großteil der Zeit in einem Testprozess wird mit der manuellen Durchführung von zuvor definierten Testfällen verbracht. Unter bestimmten Voraussetzungen besteht die Möglichkeit, Teile dieser Implementierungsphase der Testfälle zu automatisieren. Eine solche Automatisierung setzt einen strukturierten und methodischen Testprozess voraus. Besonders an die Analyse der Testanforderungen sowie an das Design der Testfälle werden hohe Ansprüche gestellt. In den seltensten Fällen kann die Automatisierung realisiert werden, indem einfaches ‚Capture‘ (Aufzeichnen) und ‚Replay‘ (Wiedergabe) von Benutzereingaben erfolgt. Mit Hilfe mächtiger Skriptsprachen, die den eingesetzten Testtools zugrunde liegen, gilt es, wieder verwendbare Testskripts zu entwickeln. Diese Arbeit ordnet die Testautomatisierung in den Softwareentwicklungs- und Testprozess ein und zeigt die Einsatzmöglichkeiten und Vorteile, aber auch die Schwierigkeiten und Grenzen der Testautomatisierung auf. Dies alles muss unter Kosten-Nutzen-Aspekten betrachtet werden. Das bedeutet auch, dass nicht in jedem Fall die ausgefeilteste Testautomatisierung angebracht ist, sondern dass unterschiedliche Anforderungen auch unterschiedliche Lösungen bedingen.

In Kapitel 2 wird zunächst ein allgemeiner Überblick zur Softwarequalität gegeben. Es wird beschrieben, wie die Qualität einer Systemanwendung anhand von Qualitätsmerkmalen gemessen wird, um eine objektive Beurteilung des entwickelten Produkts zu ermöglichen. Des Weiteren wird der wirtschaftliche Aspekt von Softwarequalität untersucht. Hierzu werden die unterschiedlichen Arten von Softwarekosten erläutert, und die Qualitätssicherung wird nach ökonomischen Gesichtspunkten betrachtet.

Mit den unterschiedlichen Ausprägungen der Qualitätssicherung beschäftigt sich Kapitel 3. Das Ziel dieses Abschnitts besteht vor allem darin, die Zusammenhänge zwischen Softwareentwicklung und Qualitätssicherung herauszuarbeiten. Dies ist notwendig, um herauszustellen, in welchem Gesamtkontext das Testen von Software und insbesondere die Testautomatisierung stattfindet. Dabei wird auch auf die Verzahnung von konstruktiven und analytischen Maßnahmen der Qualitätssicherung eingegangen.

In Kapitel 4 werden mit der Äquivalenzklassenmethode und der Grenzwertanalyse zwei Spezifikationstechniken vorgestellt, mit denen Black-Box-Testfälle definiert werden können. Anhand eines praktischen Beispiels wird die Vorgehensweise erläutert. Das Ziel dieses Abschnitts besteht in der Veranschaulichung der Ermittlung der Testfälle, die anschließend automatisiert werden sollen.

Kapitel 5 beschäftigt sich mit der Automatisierung für die Durchführung der vorher generierten Testfälle. Dabei wird zunächst die grundsätzliche Funktionsweise eines sogenannten Capture/Replay-Tools erläutert. Neben den Vorteilen und Zielen werden auch die Einsatzmöglichkeiten sowie Erfolgsfaktoren und Schwierigkeiten der Testautomatisierung beschrieben. Der Abschnitt über die Skriptprogrammierung enthält zwei Implementierungsansätze für wieder verwendbare Testskripts. Den Abschluss dieses Kapitels bildet die Ermittlung des quantitativen Nutzens der Testautomatisierung inklusive Berechnung des Break-Even-Points im Vergleich zu manuellem Testen.

Über die Erkenntnisse der Literaturrecherche hinaus werden in Kapitel 6 vom Autor gesammelte Erfahrungen mit selbst entwickelten Testfällen und Testskripts eingebracht. Der gewonnene Nutzen der Automatisierung im Vergleich zu manueller Testausführung wird anhand einiger empirischer Vergleichszahlen verdeutlicht.

In Kapitel 7 werden die Ergebnisse der Arbeit zusammengefasst und ein Fazit gezogen.

2 Softwarequalität

In der heutigen Zeit agieren Unternehmen auf globalen und dynamischen Märkten, die in sehr kurzen Zeitabschnitten immer neue Entwicklungen hervorbringen. Eine schnelle Reaktion auf immer spezifischer werdende Kundenwünsche sowie individuelle und kostengünstige Lösungen für Produkte und Dienstleistungen in hoher Qualität sind der Schlüssel für die Zufriedenheit der Kunden.

In diesem Zusammenhang spielen Systeme der Informations- und Kommunikationstechnologie eine zunehmend größere Rolle. Diese Technologien dienen der Implementierung einer strategischen Marktposition sowie der Erschließung neuer Märkte, indem sie Möglichkeiten einer schnelleren Erweiterung und Verbesserung des Produkt- und Dienstleistungsangebotes offerieren. Die zunehmende Integration von Informationstechnologie und Betriebsführung sowie die immer wichtiger werdende Qualität der Informationsversorgung haben zur Folge, dass Störungen in den DV-Systemen und somit in den Betriebsprozessen der Unternehmungen unmittelbar negative Auswirkungen auf die Kostenstruktur hervorrufen.

Das Testen von Computerprogrammen im Rahmen der Softwareentwicklung stellt einen wesentlichen Prozess dar, um den hohen Anforderungen an die Funktionsfähigkeit der DV-Systeme gerecht zu werden. Die Folgen unzureichender Softwarequalität sind vielfältig. Überlastete Anwendungen, die keine Verarbeitung von Geschäftsvorfällen mehr zulassen, können rasch Verlustpositionen von mehreren Millionen Euro zur Folge haben. Systeme, die aufgrund zu schneller Einführung noch keine marktfähige Produktqualität aufweisen, können zu Imageschäden und zur Verunsicherung von Kunden führen. Im Extremfall wenden sich die Kunden der Konkurrenz zu (CMG, o.J. (a), S.7-13).

Gleichzeitig steigt durch die Integration von Systemen der Informationstechnologie deren Komplexität und somit auch das Fehlerrisiko. Die Herstellung von absolut fehlerfreien und fachlich in jedem Fall korrekten Anwendungssystemen ist in der Regel nicht möglich, da es sich bei der Softwareentwicklung um einen Prozess mit vielen Schnittstellen handelt. Das Ziel aller Maßnahmen zur Qualitätssicherung ist daher die größtmögliche Annäherung an das Ideal einer fachlich und funktional perfekten Software und die Reduzierung möglicher Fehlerquellen auf ein absolutes Minimum. Die letztendliche Qualitätskontrolle der entwickelten Systeme muss über die Durchführung von Softwaretests sichergestellt werden (CMG, o.J. (b), S.1).

Einen Leitfaden zur erfolgreichen Softwareherstellung und zur Erzielung der notwendigen Qualität beinhaltet die Normenreihe DIN ISO 9000. Diese beschreibt Anforderungen an die organisatorische Einordnung von Qualitätssicherungssystemen und legt von der Entwicklungsphase abhängige Qualitätsziele sowie Maßnahmen zu deren Erreichung fest. Zusätzlich werden qualitätsbezogene Aktivitäten phasenübergreifend in einem Qualitätssicherungsplan definiert. Unternehmen, deren Entwicklungsprozesse normenkonform gestaltet sind, können eine Zertifizierung anstreben, um ihren Kunden gegenüber nachzuweisen, dass die mit der Norm verbundenen Qualitätsrichtlinien erfüllt werden (Bodendorf/König/Mertens/Picot/Schumann, 1998, S.169).

Die Beurteilung des entwickelten IT-Systems kann anhand von sogenannten Qualitätsmerkmalen erfolgen.

2.1 Qualitätsmerkmale

Nach der DIN-Norm 55350, Teil 11 (Mai 1987), wird Qualität als die Beschaffenheit einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen, definiert. Der Begriff Beschaffenheit bezeichnet die Gesamtheit der Merkmale und Merkmalswerte einer Einheit (Trauboth, 1996, S.25-26). Die Qualitätsmerkmale, die im Rahmen von Softwareprüfungen relevant sind, können nach dynamischen und statischen Qualitätsmerkmalen differenziert werden.

2.1.1 Statische Qualitätsmerkmale

Als statische Qualitätsmerkmale werden die intrinsischen Eigenschaften einer Anwendung sowie der dazugehörigen Dokumentation bezeichnet. Die Betrachtung erfolgt aus der Sicht des Softwareentwicklers bzw. des zukünftigen Administrators. Beispiele für solche Merkmale sind die Verwaltungsfähigkeit oder die Aktualisierbarkeit eines Informationsverarbeitungssystems. Statische Qualitätsmerkmale werden mittels Inspektionen oder Reviews statisch analysiert.

2.1.2 Dynamische Qualitätsmerkmale

Dynamische Qualitätsmerkmale beziehen sich auf das Funktionieren des DV-Systems. Die Betrachtung jener Aspekte erfolgt aus der Sicht des zukünftigen Systemanwenders (Koomen/Pol/Spillner, 2000, S.279 und S.282-283).

Die internationale Norm ISO 9126 bestimmt einerseits zwar Softwarequalitätskriterien, beschreibt aber gleichzeitig, dass nur wenige allgemein anerkannte Methoden zur Bestimmung von Softwarequalität existieren. In der Norm wird daher empfohlen, eigene Modelle und Verfahren zur Messung der Softwarequalität zu entwickeln (Lindermeier/Siebert, 1995, S.11).

Einige der wichtigsten dynamischen Qualitätsmerkmale werden im Folgenden näher betrachtet, da diese im Rahmen von Softwaretests eine bedeutende Rolle spielen. Die Beschreibung der dynamischen Qualitätsmerkmale erfolgt im Wesentlichen auf Basis des Testkonzepts TMap. Es handelt sich hierbei um ein strukturiertes Testkonzept für Systeme der Informationstechnologie, wobei TMap für ‚Test Management approach‘ steht (Koomen/Pol/Spillner, 2000, S.183).

Zwecks Referenzierung zur Norm ISO 9126 wurde für die dynamischen Qualitätsmerkmale Funktionalität, Leistung, Kontinuität und Benutzungsfreundlichkeit die folgende Umsetzungstabelle entwickelt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Umsetzungstabelle Qualitätsmerkmale TMap und ISO 9126

(in Anlehnung an Koomen/Pol/Spillner, 2000, S.535)

2.1.2.1 Funktionalität

Als Funktionalität bezeichnet man die Sicherheit, dass die durch die Software zu erfolgende Datenverarbeitung korrekt und vollständig sowie gemäß der Beschreibung in der Fachspezifikation erfolgt (Koomen/Pol/Spillner, 2000, S.281).

Solange es sich um arithmetische und logische Funktionen handelt, kann die Anforderungsdefinition eindeutig durch mathematische Formeln beschrieben werden. In der Praxis werden große Teile im Fachkonzept häufig in der Umgangssprache beschrieben. Dies kann zu Unvollständigkeit, Mehrdeutigkeit und Missverständlichkeit in der fachlichen Beschreibung führen. Bei der Prüfung eines Software-Produkts auf Funktionserfüllung ist zunächst sicherzustellen, dass die Fachspezifikation vollständig und korrekt ist. Der zu einem späteren Zeitpunkt stattfindende Softwaretest verifiziert schließlich, ob das entwickelte Programm der Anforderungsdefinition entspricht (Trauboth, 1996, S.32).

Das Qualitätsmerkmal Funktionalität ist somit nach den Merkmalen Vollständigkeit und Korrektheit zu unterscheiden:

- Vollständigkeit: Hierunter versteht man die Sicherheit, dass alle Eingaben und Änderungen vom DV-System verarbeitet werden.
- Korrektheit: Das Merkmal Korrektheit ist erfüllt, wenn die Software die angebotenen Eingaben und Änderungen korrekt gemäß den Vorgaben des Fachkonzepts zu konsistenten Datensammlungen verarbeitet (Koomen/Pol/Spillner, 2000, S.281).

Um festzustellen, ob eine Anwendung korrekt arbeitet, sind folgende fünf Aspekte zu beachten:

- Das Programm liefert auf eine gültige Eingabe die korrekte Ausgabe.
- Das Programm weist eine ungültige Eingabe korrekt und angemessen zurück.
- Das Programm stürzt sowohl bei ungültigen als auch bei gültigen Eingaben nicht ab.
- Das Programm wird so lange korrekt ausgeführt, wie es in der Fachspezifikation definiert ist.
- Das Programm verhält sich gemäß der fachlichen Beschreibung in der Anforderungsdefinition (Dustin/Paul/Rashka, 2000, S.135-136).

Das dynamische Qualitätsmerkmal Funktionalität stellt häufig das wichtigste Kriterium dar, um beim Anwender die Akzeptanz des IT-Systems zu erreichen. Es ist daher sicherzustellen, dass die entwickelte Software der spezifizierten Funktionalität entspricht (Koomen/Pol/Spillner, 2000, S.281).

2.1.2.2 Leistung

Die Leistung eines Software-Produkts drückt sich zum einen im Zeitverhalten bzw. in der Geschwindigkeit, mit der interaktive und Batch-Verarbeitungen ausgeführt werden, und zum anderen in der Inanspruchnahme von Betriebsmitteln aus. Leistungsmerkmale, die dem Zeitverhalten zugeordnet werden, sind beispielsweise der Zeitaufwand für die Ausführung einer Funktion, der Durchsatz von verarbeiteten Daten oder das Antwortzeitverhalten, also die verstrichene Zeit, bis auf ein auslösendes Ereignis reagiert wird. Leistungsmerkmale, die sich auf die Inanspruchnahme von Betriebsmitteln beziehen, sind zum einen die Menge, die Häufigkeit und die Zeitdauer des benutzten Speicherplatzes für Programme und Daten und zum anderen die Häufigkeit des Zugriffs und die Dauer der Belegung von externen Dienstleistungsfunktionen (Trauboth, 1996, S.33).

2.1.2.3 Kontinuität

Als Kontinuität bezeichnet man sowohl die Sicherheit, dass die Datenverarbeitung ungestört ablaufen kann, als auch die Eigenschaft eines Systems, dass diese auch nach ernsthaften Störungen innerhalb einer akzeptablen Zeitspanne wieder fortgeführt werden kann. Das Qualitätsmerkmal Kontinuität kann anhand mehrerer Kriterien differenziert werden, die bei einer sich ausbreitenden Störung des DV-Systems Anwendung finden:

- Als Betriebssicherheit bezeichnet man den Umfang, in dem die Informationsverarbeitung ungestört bleibt.
- Die Robustheit ist eine Angabe darüber, inwieweit mit den Daten auch nach einer Störung weiter gearbeitet werden kann.
- Die Wiederherstellbarkeit ist ein Indiz dafür, wie schnell und wie einfach die Informationen nach einer Störung reproduziert werden können.

Schließlich zeichnen sich Programme, die das Qualitätsmerkmal Kontinuität erfüllen, dadurch aus, dass nach dem Ausfall von Teilen des Systems oder der Feststellung der Fehlerhaftigkeit mit geringem Aufwand die Kernfunktionalität der Anwendung weiterhin erhalten werden kann (Koomen/Pol/Spillner, 2000, S.280).

2.1.2.4 Benutzungsfreundlichkeit

Die Benutzungsfreundlichkeit drückt sich in der Mühelosigkeit aus, mit der ein Anwender mit der Software interagieren kann. Da sich der Grad der Benutzungsfreundlichkeit nur schwer messen lässt, sind bei der Bewertung dieses Qualitätskriteriums durchaus subjektive Meinungen gefragt. Die Einschätzung der zukünftigen Nutzer des Systems spielt bei der Feststellung der Benutzungsfreundlichkeit eine wichtige Rolle (Koomen/Pol/Spillner, 2000, S.281).

Man kann ferner zwischen dem zeitlichen Aufwand für den Benutzer und der sogenannten Handhabbarkeit der Anwendung unterscheiden. Dem zeitlichen Aufwand können beispielsweise die Zeit zum Erlernen der Bedienung der Software, die Zeit und die Anzahl der Schritte, um Fehlersituationen zu erkennen und zu beheben oder die Zeit für das Warten auf eine Systemreaktion nach einer Kommando-Eingabe zugeordnet werden. Der Grad der Handhabbarkeit eines Programms wird unter anderem durch die Anzahl und die Komplexität der Bedienungsschritte im Verhältnis zur auszuführenden Funktion, die Übersichtlichkeit der Informationsdarstellung, die Unterstützung beim Fehlerhandling und durch die Benutzerführung in der Anwendung determiniert (Trauboth, 1996, S.34).

Benutzungsfreundlichkeit kann in einem IT-System erreicht werden, indem die Entwicklung der Benutzungsoberfläche nach softwareergonomischen Gesichtspunkten erfolgt (Pagel/Six, 1994, S.53). Die Software-Ergonomie befasst sich mit der menschengerechten Gestaltung von interaktiven Programmsystemen im Rahmen computergestützter Arbeit sowie mit der Benutzerfreundlichkeit von DV-Systemen (Carl von Ossietzky Universität Oldenburg, Abruf am 12.7.2001). Beispiele für die softwareergonomische Gestaltung von Benutzungsoberflächen sind die Implementierung von grafischen Oberflächen in Fenstertechnik sowie der adäquate und systematische Einsatz von Farben und Formen bei der Darstellung von einzelnen Elementen. Die Verfügbarkeit von Hilfefunktionalitäten in Abhängigkeit vom jeweiligen Systemzustand sowie die Möglichkeit, die Art der Interaktion mit dem System in einem gewissen Umfang an den Kenntnisstand des Anwenders anzugleichen (z.B. durch Automatisierung von Routinevorgängen mittels eines Makros oder durch verkürzte Menüsteuerungen), erhöhen ebenfalls den Benutzerkomfort (Pagel/Six, 1994, S.53).

2.2 Kosten und Nutzen von Softwarequalität

Der Nutzen eines DV-Systems wird durch die Übereinstimmung zwischen dem Software-Produkt und den tatsächlichen Anforderungen bestimmt. Zusätzliche Leistungen und Eigenschaften der Anwendung, die in der Fachspezifikation nicht explizit gefordert waren, können darüber hinaus ebenfalls als nützlich und vorteilhaft empfunden werden. Mit Hilfe moderner Informationstechnologie sollen betriebliche Abläufe rationaler gestaltet und die Produktivität erhöht werden. Darüber hinaus verfolgen Unternehmen mit Hilfe der IT die Realisierung von Nutzenpotenzialen durch strategische Maßnahmen, um beispielsweise Innovationsvorsprünge gegenüber Marktkonkurrenten zu erzielen. Der Nutzen einer Softwareentwicklung, der in der Regel schwieriger zu quantifizieren ist als die Kosten, kann nur dann realisiert werden, wenn das Produkt den im Pflichtenheft spezifizierten Qualitätsmerkmalen entspricht (Frühauf/Ludewig/Sandmayr, 2000, S.17).

Die wirtschaftlichen Auswirkungen von Qualitätsmängeln verdeutlicht das Beispiel des Flugbuchungssystems SABRE von American Airlines. Das Unternehmen konnte 1987 einen Umsatz von ca. 50 Millionen US-Dollar nicht realisieren, weil nach der Änderung einer Softwareeinheit im Reservierungssystem über Monate hinweg Flüge bereits als ausgebucht angezeigt wurden, obwohl noch Plätze vorhanden waren (Bodendorf/König/Mertens/Picot/Schumann, 1998, S.169).

Die Kosten eines Software-Produkts können in Herstellungskosten und Qualitätskosten differenziert werden. Während den Herstellungskosten alle Aufwendungen zugerechnet werden, die sich auf das Erbringen der gemäß Fachkonzept geforderten Leistung beziehen, werden den Qualitätskosten die Aufwendungen für das Verhüten, Erkennen, Lokalisieren und Beheben von Fehlern sowie die Folgekosten der Fehler, die im Betrieb auftreten, zugeordnet. Je größer das Risiko von Folgekosten und Garantieleistungen ist, desto mehr Sinn macht die Investition in Prävention und Prüfung (Frühauf/Ludewig/Sandmayr, 2000, S.17).

Die folgende Abbildung veranschaulicht die unterschiedlichen Kostenarten eines Software-Produkts:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Aufteilung der Softwarekosten

(in Anlehnung an Frühauf/Ludewig/Sandmayr, 2000, S.18).

Im Folgenden soll kurz erläutert werden, durch welche Maßnahmen zur Sicherstellung der Softwarequalität die genannten Kostenarten beeinflusst werden:

- Fehlerverhütungskosten entstehen durch Vorbeugemaßnahmen, die Qualitätsmängel verhindern sollen. Zu nennen sind in diesem Zusammenhang z.B. Dokumentationsrichtlinien oder Methoden und Techniken zur Softwareentwicklung.
- Prüfkosten werden durch sogenannte Prüf- und Beurteilungsmaßnahmen generiert, die Qualitätsmängel entdecken sollen. Beispiele hierfür sind statische Analyseverfahren wie Inspektionen und Reviews sowie die Durchführung von Softwaretests.
- Zu den Fehlerkosten zählen Folgekosten, die beispielsweise für Kulanzzahlungen anfallen, Garantiekosten, die sich aus vertraglichen Verpflichtungen zur Garantieleistung ergeben und Fehlerbehebungskosten, die aus Korrekturmaßnahmen entstehen. Korrekturmaßnahmen haben die Aufgabe, den Mangel an Qualität zu beheben. Beispielhaft sei die Korrektur von Fehlern genannt, die durch Softwaretests entdeckt wurden (Koomen/Pol/Spillner, 2000, S.12).

Alle Maßnahmen zur Sicherstellung der Softwarequalität beinhalten das Ziel von möglichst wenigen Fehlern in dem erstellten Produkt. In der US-Industrie geht man von einer durchschnittlichen Rate von bis zu 10 Fehlern je 1.000 ausgelieferten Zeilen Quellcode aus (Trauboth, 1996, S.15). Die Folgen eines Fehlers, der erst während der Betriebsphase des IT-Sytems auftritt, können sehr unterschiedliche Ausmaße annehmen. Genannt seien in diesem Zusammenhang die Verschwendung von Material und Energie, Rückrufaktionen bereits ausgelieferter Produkte sowie extreme finanzielle Verluste aufgrund von Softwarefehlern in vernetzten Banksystemen oder in Telefonvermittlungssystemen. Im schlimmsten Fall können Menschen zu Schaden kommen.

Das Ideal einer fehlerfreien Software ist jedoch üblicherweise wirtschaftlich nicht realisierbar. Daher ist eine Minimierung der Qualitätskosten anzustreben, indem die Aufwendungen für Fehlerverhütungs- und Prüfkosten mit den Einsparungen bei den Fehlerkosten in Einklang gebracht werden (Frühauf/Ludewig/Sandmayr, 2000, S.18).

In Abbildung 3 wird der Zusammenhang zwischen den verschiedenen Kostenarten dargestellt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Qualitätskosten

(in Anlehnung an Koomen/Pol/Spillner, 2000, S.13)

Festzuhalten bleibt, dass das Streben nach perfekter Qualität aus wirtschaftlichen Gesichtspunkten nicht sinnvoll ist, da ab einem gewissen Zeitpunkt jeder kleine Gewinn an Qualität immer größere Investitionen bedingt. Das Testen von Software macht ökonomisch so lange Sinn, wie die Kosten für das Finden und die Beseitigung eines Fehlers niedriger sind als die Kosten, die ein Fehler während der Betriebsphase der Anwendung verursacht (Koomen/Pol/Spillner, 2000, S.14).

3 Qualitätssicherung

Die Qualitätssicherung ist die Summe aller geplanten und systematischen Aktionen, welche dazu dienen, die für das zugrundeliegende Software-Produkt festgelegten Qualitätsanforderungen zu erzeugen (Koomen/Pol/Spillner, 2000, S.12).

Die Qualität darf nicht als eine lästige Forderung angesehen werden, die nach der Erstellung eines DV-Systems durch Eliminierung von Fehlern nachträglich erzeugt wird. Vielmehr muss Qualität durch gezielte Maßnahmen in ein Software-Produkt eingebaut werden. Um dies zu erreichen, bedarf es einer strukturierten Planung der Qualitätssicherung, die mit den übrigen Aufgaben des Projektmanagements harmonisiert. Die Qualitätsanforderungen an die herzustellende Anwendung müssen zu Beginn der Entwicklung definiert werden, um die Qualität im Rahmen der vorgegebenen Kosten und Termine zu optimieren. Aus einer Vielzahl relevanter Qualitätsmerkmale müssen diejenigen ermittelt werden, die für das betreffende Produkt die höchste Bedeutung haben. Diese Kriterien müssen gewichtet und quantifiziert werden. Die Qualitätsanforderungen sind anschließend als verpflichtend in der Fachspezifikation bzw. im Pflichtenheft festzuhalten (Trauboth, 1996, S.87).

Wie bereits in Kapitel 2 kurz angesprochen, können sich Unternehmen aus der EDV-Branche beim Aufbau eines Qualitätssicherungssystems an den Forderungen der DIN ISO 9000 orientieren. Dabei ist zu beachten, dass die DIN ISO 9000 Teil 3 nicht die gültige Norm, sondern ein Leitfaden für die Herstellung von Software ist. Um die Zertifizierung zu erlangen, wird die DIN ISO 9001 für Qualitätsmanagementsysteme als verbindliche Norm benötigt. Es existieren eine Reihe von Gründen, eine Zertifizierung im Bereich der Qualitätssicherung anzustreben. Neben dem Druck des Wettbewerbs und des Marktes, sich mit der Zertifizierung auseinanderzusetzen, eröffnet die Beschäftigung mit der Norm auch die Möglichkeit, die Strukturen und Prozesse einer Organisationseinheit auf Richtigkeit und Effizienz hin zu untersuchen. Dabei ist allerdings zu beachten, dass erfolgreiche Qualitätssicherung nicht durch bloße Orientierung an Normen entsteht. Vielmehr müssen Unternehmen auf die Bedürfnisse und Forderungen ihrer Kunden eingehen, branchenspezifische Bedingungen berücksichtigen und dabei die eigenen Mitarbeiter nicht außen vor lassen. Es ist daher neben dem Studium der Forderungen der Normen essenziell, sich zu fragen, wie diese in der eigenen Unternehmung sinnvoll realisiert werden können (Thaller, 1996 (a), S.32-35).

Je früher ein Fehler im Entwicklungsprozess eines DV-Systems gemacht und je später er gefunden wird, desto höher ist der Aufwand für die Korrektur. Wenn ein Fehler entdeckt wird, muss die Software korrigiert und erneut getestet werden. Die Kosten der Korrektur korrelieren dabei stark positiv mit dem Zeitpunkt, zu dem der Fehler bemerkt wurde (Pagel/Six, 1994, S.46-47). Ein Fehler, der in einem frühen Stadium des Softwareentwicklungsprozesses entdeckt wurde, lässt sich mit relativ wenigen Ressourcen beheben und wirkt sich nicht auf die Betriebsphase der Anwendung aus. Ein Fehler, der erst nach der Inbetriebnahme des IT-Systems festgestellt wird, kann mehrere Organisationen betreffen, umfangreiche erneute Tests zur Folge haben und schließlich Ausfallzeiten für den Betrieb der Software verursachen (Dustin/Paul/Rashka, 2000, S.8).

Die folgende Tabelle veranschaulicht, dass sich die Kosten für die Fehlerbeseitigung im Verlauf der Systementwicklung multiplizieren:

Abbildung 4: Vorbeugen ist billiger als heilen!

(in Anlehnung an Dustin/Paul/Rashka, 2000, S.9)

Es ist deutlich geworden, dass wirksame Maßnahmen der Kostensenkung das Ziel haben müssen, einen Fehler so früh wie möglich festzustellen und zu beheben bzw. diesen erst gar nicht entstehen zu lassen. Die schwerwiegendsten Fehler werden häufig in den frühen Phasen der Softwareentwicklung gemacht, demnach in den Phasen der Analyse bzw. Beschreibung der fachlichen Anforderungen sowie der Entwurfsphase des DV-Konzepts. Entwicklungen von DV-Systemen bedingen aufgrund ihrer Größe und Komplexität umfangreiche und komplizierte Fachspezifikationen, die das menschliche Beurteilungsvermögen oft überfordern. Die Anforderungsdefinitionen von Software-Produkten sind daher häufig nicht detailliert genug und enthalten Fehler oder widersprüchliche Aussagen.

Die Konsequenzen einer unzulänglichen Systemspezifikation sind schwerwiegend, da diese die Basis für die weiteren Phasen der Softwareentwicklung darstellt. Um solche fundamentalen Fehler in den frühen Phasen des Softwareentwicklungsprozesses zu verhindern, haben sich unterschiedliche Methoden der analytischen Qualitätssicherung bewährt. Das Testen von Software hat als eine die Entwicklung begleitende Tätigkeit die Aufgabe, Fehler so früh wie möglich aufzudecken. In jeder Entwicklungsphase sollten Testfälle für nachfolgende Tests definiert werden. Im Gegensatz zu dieser dynamischen Methode der analytischen Qualitätssicherung dienen beispielsweise Inspektionen oder Reviews als statische Maßnahmen der Validierung von Produktdefinitionen. Während die analytische Qualitätssicherung der Fehlerfindung dient, hat die konstruktive Qualitätssicherung die Fehlervermeidung zum Ziel (Pagel/Six, 1994, S.47).

Die konstruktive Qualitätssicherung befasst sich mit der Durchsetzung von Prinzipien im Rahmen des Software Engineering. Hierunter versteht man moderne Verfahren der Softwareentwicklung, die dem Softwareentstehungsprozess zugrunde gelegt werden. Unter Heranziehung von Standards, Hilfsmitteln und Werkzeugen, die beispielsweise im Rahmen von Konsistenz- und Vollständigkeitsprüfungen wertvolle Dienste leisten, lässt sich die Softwarequalität erhöhen, indem der Entwicklungsprozess und die Dokumentation vereinheitlicht werden (Carl von Ossietzky Universität Oldenburg, Abruf am 12.7.2001). Die Wiederverwendung korrekter Softwarekomponenten liefert ebenfalls einen Beitrag zur Fehlervermeidung, da die Wahrscheinlichkeit von Fehlern in bereits sorgfältig getesteten und qualitätsgesicherten Modulen im Vergleich zu neu entwickelten Komponenten wesentlich geringer ist. Große Probleme bereitet die Tatsache, wenn ein in Bezug auf die Fachspezifikation durchaus korrektes DV-System dennoch nicht den Erwartungen des Auftraggebers entspricht. Die Ursache hierfür kann beispielsweise in einer viel zu ungenauen Produktdefinition liegen (Pagel/Six, 1994, S.47-48).

In diesem Zusammenhang sollen die beiden Begriffe Verifikation und Validation kurz erläutert werden, die innerhalb des Prüfprozesses zwei unterschiedliche Aspekte betrachten. Im Rahmen der Verifikation wird gegen Ende einer Phase überprüft, ob die spezifizierten Qualitätskriterien eines Produkts mit den tatsächlichen Merkmalen übereinstimmen. Als Prüfobjekte kommen alle Zwischenprodukte in Frage, die während des Entwicklungsprozesses erzeugt werden. Die Verifikation des Softwareentwurfs überprüft beispielsweise, ob die Entwickler die Systemarchitektur sowie die Definition und Struktur der einzelnen Systemkomponenten korrekt erstellt haben. Die Validation prüft die Tauglichkeit eines Produkts für seine vorgesehene Aufgabe. Sie beantwortet letztlich auch die Frage, ob die entwickelte Systemanwendung den Anforderungen des Auftraggebers entspricht (Trauboth, 1996, S.153).

Die Änderung von Software, die nicht der Vorstellung des Kunden entspricht, gehört zu den kostenintensivsten Aufwendungen im Rahmen der Softwareentwicklung. Abhilfe schafft hier die rasche Erstellung von Prototypen für relevante Teile des Systems, die dem Auftraggeber frühzeitig zur Überprüfung der Anforderungsdefinition vorgeführt werden. Der Prototyp als Diskussionsbasis offeriert die Möglichkeit, den Entwicklern die Vorstellungen der Anwender transparent zu machen und das Risiko von Missverständnissen zu vermindern (Pagel/Six, 1994, S.47-48).

Eine weitere Kategorisierung der Qualitätssicherung erstreckt sich auf die organisatorischen Maßnahmen bzw. das Management der Qualitätssicherung. Hierunter versteht man organisatorische und ablauftechnische Regelungen, die Überwachung qualitätsrelevanter Maßnahmen, die Schulung von Mitarbeitern sowie Beratungsleistungen für die Planung von Prüfungen oder die Auswahl von Werkzeugen (Trauboth, 1996, S.91-95).

Den Zusammenhang der einzelnen Maßnahmen der Qualitätssicherung veranschaulicht die folgende Grafik:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Maßnahmen der Software-Qualitätssicherung

(aus einer Vortragsunterlage anlässlich eines Workshops der AXA Krankenversicherung AG, Feldmann, 2001)

In den folgenden Abschnitten werden die organisatorischen, konstruktiven und analytischen Maßnahmen der Software-Qualitätssicherung näher erläutert.

3.1 Organisatorische Maßnahmen und Management der Qualitätssicherung

Qualitätsmanagement wird in der internationalen Norm ISO 8402 folgendermaßen definiert: Das Qualitätsmanagement umfasst alle Aktivitäten des Gesamtmanagements, die im Rahmen des Qualitätsmanagement-Systems die Qualitätspolitik, die Ziele und Verantwortungen benennen sowie diese mittels Qualitätsplanung, Qualitätslenkung, Qualitätsmanagement und Qualiätsverbesserung realisieren.

Das ‚Institute of Electrical and Electronic Engineers‘ (IEEE) beschreibt in seinem ‚Standard for Software Quality Metric Methodology‘ (IEEE88) die folgenden wesentlichen Aufgaben des Qualitätsmanagements:

- Festlegung von Qualitätsanforderungen in Form von Qualitätsmerkmalen bereits in frühen Phasen der Softwareentwicklung durch das Qualitätsmanagement.
- Information der Softwareentwickler über die vereinbarten Qualitätsanforderungen.
- Vereinbarung von Messkriterien für die festgelegten Qualitätsmerkmale.
- Bereitstellung von Messwerkzeugen, um das Qualitätsmaß zu bestimmen.
- Bewertung von Software-Produkten und Software-Prozessen bezüglich der elementaren Qualitätsmaße.
- Analyse der Messergebnisse zwecks Einschätzung und Verbesserung von Produkt- und Prozessqualität.

Diese Aussagen verdeutlichen, dass sich das Management der Software-Qualitätssicherung sowohl mit dem herzustellenden Produkt, als auch mit dem Erstellungsprozess selbst beschäftigt. Die eigentliche Entwicklung der Software und das Management der Qualitätssicherungsmaßnahmen sind innerhalb des Erzeugungsprozesses kaum zu trennen. Das Qualitätsmanagement ist somit integraler Bestandteil des Managements der Softwareentwicklung und bezieht sich auf alle Phasen, alle (Zwischen-)Produkte, alle Mitarbeiter sowie auf alle Ebenen und Aktivitäten (Planung, Durchführung, Überprüfung und Lenkung) und somit auf das Qualitätsmanagement selbst (DGQ/ITG, 1995, S.11-12).

Als eine wesentliche Aufgabe der organisatorischen Qualitätssicherung erachtet das ‚Institute of Electrical and Electronic Engineers‘ (IEEE) die Erstellung eines Handbuchs zur Software-Qualitätssicherung. Dieses Handbuch enthält für ein Unternehmen oder einen Bereich verbindliche Angaben bezüglich des geltenden Qualitätssicherungs-Systems. Es ist festzuhalten, wer welche Aufgaben durchführt. Hierzu zählen beispielsweise die Pflege und Überwachung des Qualitätssicherungs-Systems oder die Auswahl von Hilfsmitteln und Testwerkzeugen. Im Rahmen der Dokumentationsplanung ist festzulegen, welche Dokumentation bei welcher Art von Projekten zu erstellen ist und welche Informationen z.B. ein Pflichtenheft zwingend enthalten muss.

Ferner sind allgemein gültige Regeln für die Erfassung, Dokumentation und Auswertung von Software-Fehlern zu bestimmen. Nicht unerheblich ist hierbei die Erfassung der Fehlerkosten. Die Qualitätsprüfung hat festzuhalten, für welche Arten von Phasenergebnissen zwingend Prüfungen vorzunehmen sind. Die Verfahren, nach denen Reviews und Inspektionen an Dokumenten sowie Tests von Programmen vorzunehmen sind, müssen ebenso wie die Art der Dokumentation der Prüfergebnisse im Qualitätssicherungs-Handbuch niedergeschrieben werden. Bezüglich der Qualitätsberichterstattung ist zu bestimmen, welche Informationen in der Berichterstattung aufzuführen sind und in welchen Abständen über Fehlerschwerpunkte und Qualitätskosten berichtet wird (Trauboth, 1996, S.92-94).

Der Mensch spielt sowohl bei der Entwicklung der Software als auch beim Qualitätsmanagement eine entscheidende Rolle. Die schnelle Weiterentwicklung in der Datenverarbeitung sowie bei den Techniken zur Softwareerstellung bedingen daher eine kontinuierliche Aus- und Weiterbildung der Mitarbeiter. Der Wissensstand muss somit durch regelmäßige Schulungen ständig aktualisiert werden. Die Einführung neuer Methoden und (Test-)Werkzeuge verlangt eine zusätzliche Fortbildung, um Fehler bei der Anwendung zu verhindern und um die Akzeptanz und damit die Motivation der Mitarbeiter zu erhöhen. Diese fortlaufenden Schulungen müssen im Rahmen der organisatorischen Maßnahmen der Qualitätssicherung berücksichtigt werden (DGQ/ITG, 1995, S.23).

3.2 Konstruktive Maßnahmen der Qualitätssicherung

Die konstruktiven Maßnahmen der Qualitätssicherung werden durch eine Reihe von Verfahren, Methoden und Werkzeugen im Rahmen der Softwareerstellung verwirklicht. Sie tragen zur Erreichung der Qualitätsanforderungen, die im Pflichtenheft als Qualitätsmerkmale definiert werden, in erheblichem Maße bei. Die konstruktiven Maßnahmen haben neben dem Ziel der Fehlervermeidung die Aufgabe, nicht verhinderte Fehler schnell festzustellen und diese ebenso rasch und effektiv zu beseitigen. Während sich das Ziel der Fehlervermeidung auf den Aufbau der zu erstellenden Software und das Herangehen im Entwicklungsprozess bezieht, erstreckt sich die schnelle Entdeckung und Eliminierung von Fehlern auf den Entwurf der Software. Die Methoden und Verfahren der Fehlervermeidung begleiten alle Phasen der Entwicklung, wobei für die einzelnen Abschnitte unterschiedliche Maßnahmen greifen. Die konstruktiven Maßnahmen der Qualitätssicherung gehören zu einem guten Software-Engineering und gehen oftmals Hand in Hand mit den analytischen Maßnahmen. Auf jeden Entwicklungsschritt, der bestimmte konstruktive Methoden einsetzt, folgen Analysen oder Prüfungen. Dieses Zusammenspiel wurde bereits durch die Abbildung 5 verdeutlicht. Außerdem haben die konstruktiven Maßnahmen die Aufgabe, den Softwaretest zu unterstützen und zu vereinfachen (Trauboth, 1996, S.103-105). Für die Testautomatisierung ist es beispielsweise wichtig, dass die grafische Benutzeroberfläche standardisierte Steuerelemente enthält. Diese Notwendigkeit wird im Verlauf dieser Arbeit noch näher erläutert (Dustin/Paul/Rashka, 2000, S.41).

3.2.1 Das iterierte Phasenmodell

Man spricht im Allgemeinen von einem Vorgehensmodell, wenn zur Lösung einer komplexen Aufgabenstellung der Lösungsprozess systematisch aufgegliedert wird. Das Vorgehensmodell beschreibt den zeitlichen Ablauf und unterteilt den Lösungsprozess in überschaubare Abschnitte. Hierdurch wird ein schrittweiser Planungs-, Entscheidungs- und Konkretisierungsprozess erreicht. Auch bei der Entwicklung von Software werden einzelne Projektphasen gebildet. Diese Phasen stellen zeitlich und funktionell abgrenzbare Teile des gesamten Projektverlaufs dar. Alle Phasen zusammen genommen benennt man inklusive ihrer zeitlichen Abfolge als Software life cycle (Pomberger, 1990, S.218). Die Norm DIN ISO 9000 fordert in Teil 3 im Abschnitt 5.1 für die Entwicklung von Software ein Lebenszyklusmodell. Dabei betont die Norm, dass keinem bestimmten Lebenszyklusmodell der Vorzug gegeben wird (Thaller, 1996 (a), S.83).

Abbildung in dieser Leseprobe nicht enthalten

Der Software life cycle wird in der Literatur in vielen Varianten und mit unterschiedlichen Ausprägungen beschrieben. Das in Abbildung 6 dargestellte iterierte Phasenmodell ist das am weitesten verbreitete Vorgehensmodell und baut auf dem klassischen Wasserfallmodell auf (Pagel/Six, 1994, S.37 und S.65):

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Das iterierte Phasenmodell

(in Anlehnung an Pagel/Six, 1994, S.65)

Das iterierte Phasenmodell unterscheidet sich vom klassischen Wasserfallmodell durch die Rückkopplungspfeile. Diese ermöglichen eine Rückkehr in frühere Phasen, die notwendig wird, wenn in einer späteren Phase Fehler früherer Phasen aufgedeckt werden und eine Korrektur erfordern (Pagel/Six, 1994, S.65).

Im folgenden Abschnitt werden die Inhalte der einzelnen Phasen inklusive einiger konstruktiver Maßnahmen der Qualitätssicherung, sowie die Vor- und Nachteile des Modells, kurz erläutert.

3.2.1.1 Die Phasen des Softwarelebenszyklus

In der Analyse- und Definitionsphase wird zunächst einmal der Ist-Zustand erhoben, indem die Tätigkeiten des zu untersuchenden Problembereichs festgestellt und dokumentiert sowie deren Wechselwirkungen ermittelt werden. Des Weiteren werden die Automatisierungspotenziale für die zu entwickelnde Anwendung analysiert, eine Machbarkeitsstudie erstellt und eine Kosten-/Nutzen-Analyse aufbereitet. Die Systemdefinition, die auch Pflichtenheft oder Fachspezifikation genannt wird, bildet den Kontrakt zwischen dem Auftraggeber und dem Softwarehersteller. In der Systemdefinition wird das Leistungsspektrum des Software-Produkts beschrieben. Hierzu zählen unter anderem Vorgaben zum Funktionsumfang, zur Benutzungsoberfläche, zum Leistungsverhalten der Anwendung sowie zur Terminplanung. Die Abnahme des zu entwickelnden IT-Systems basiert auf den Angaben im Pflichtenheft (Pagel/Six, 1994, S.37).

Die Problemstellung sowie die Anforderungen an das zu entwickelnde DV-System müssen so vollständig und genau wie möglich beschrieben werden. Dies ist unter anderem auch deshalb wichtig, damit diese Anforderungen beim Softwaretest möglichst vollständig und detailliert geprüft werden können. Im Allgemeinen spezifiziert der Auftraggeber bzw. der Anwender seine Vorstellungen jedoch nur sehr vage. Es liegt daher am DV-Systemanalytiker, die Initiative zu ergreifen und eine Reihe von Fragen zu stellen, die vom Auftraggeber beantwortet werden. Oftmals sind hierzu mehrere Gespräche notwendig, bis alle Anforderungen erfasst und alle Fragen beantwortet sind (Trauboth, 1996, S.105).

Ein Beispiel für ein Werkzeug, das die Erstellung einer Anforderungsanalyse oder die Dokumentation von Systemanforderungen sowie die formale Überprüfung auf Eindeutigkeit und Vollständigkeit unterstützt, ist die Sprache ‚Problem Statement Language‘ (PSL). Das Ziel von PSL ist ein lückenloses, eindeutiges und widerspruchsfreies Konzept. Die Sprache PSL besteht aus formalen, teilweise formalen und aus freitextlichen Elementen, wobei die formalen und teilweise formalen Konstrukte mit entsprechenden Prozessoren, die ‚Problem Statement Analyzer‘ (PSA) genannt werden, automatisch bearbeitet und geprüft werden können (DGQ/ITG, 1995, S.69-70).

Im Entwurf werden auf Basis der Systemdefinition die Objekte festgelegt, welche die fachlichen Anforderungen abdecken sollen. Durch eine schrittweise Zerlegung des Gesamtproblems in Komponenten wird die innere Struktur des DV-Systems festgelegt. Der Systemarchitektur-Entwurf entsteht schließlich durch die Spezifikation der Aufgaben der einzelnen Systemkomponenten, die Festlegung der Schnittstellen und die Beschreibung der Wechselwirkungen der Komponenten untereinander. Zu beachten ist, dass programmtechnische Details der Realisierung nicht in der Entwurfsphase, sondern im Rahmen der nachfolgenden Implementation behandelt werden. Ein guter Entwurf zahlt sich vor allem langfristig aus, da er die Wartbarkeit einer Anwendung entscheidend beeinflusst (Pagel/Six, 1994, S.38).

Konstruktive Maßnahmen, die in der Entwurfsphase zur Vermeidung von Fehlern einen Beitrag leisten, sind beispielsweise standardisierte Schnittstellen zwischen Subsystemen und Modulen, die klare Trennung von Verarbeitungsprozessen und Daten sowie eine modulare Strukturierung nach dem Prinzip der Datenkapselung, auch ‚Information Hiding‘ genannt (Trauboth, 1996, S.112). Beim ‚Information Hiding‘ dürfen Module und Teilsysteme nur entsprechend ihrer Schnittstellenbeschreibung verwendet werden. Nicht erlaubt ist die Nutzung von Wissen über die innere Struktur, interne Abläufe oder lokale Variablen der Komponenten (DGQ/ITG, 1995, S.73).

In der Phase der Implementation, die auch Codierung genannt wird, erfolgt die Transformation des Realisierungskonzepts durch Implementierung der Komponenten des Entwurfs in eine Programmiersprache. In der Codierphase erfolgt eine schrittweise Verfeinerung der einzelnen Systemkomponenten, die Kompilierung des Quellcodes in Maschinencode sowie die Prüfung des Quelltextes auf syntaktische Richtigkeit. (Pomberger, 1990, S.220-221). Als konstruktive Maßnahmen der Qualitätssicherung seien an dieser Stelle die Festlegung von Programmierstandards oder die Nutzung von Programm-Bibliotheken genannt. Programmierstandards enthalten Regeln, die bei der Codierung eines Programms einzuhalten sind. Sie haben unter anderem eine bessere Wartbarkeit und Testbarkeit der Software zum Ziel. Der Einsatz von Programm-Bibliotheken soll eine Erhöhung der Wirtschaftlichkeit sowie eine Verringerung des Entwicklungsrisikos zur Folge haben. Dies setzt voraus, dass die mehrfach zu verwendenden Module, Prozeduren oder Funktionen gepflegt und katalogisiert werden (DGQ/ITG, 1995, S.83-84.

Die nächste Phase des iterierten Phasenmodells bildet der Test. Dem Modultest folgt der sogenannte Integrationstest. Dieser hat sicherzustellen, dass jede Softwareeinheit korrekt mit den anderen Einheiten zusammenarbeitet. Im Rahmen des Integrationstests werden die einzelnen Module basierend auf dem Programmablauf sukzessive integriert und gemeinsam getestet (Dustin/Paul/Rashka, 2000, S.277). Der anschließende Systemtest findet auf einer höheren Ebene als der Integrationstest statt. Er hat festzustellen, ob die entwickelte Software die Produktdefinition erfüllt. Den Abschluss dieser Kette von Tests bildet der sogenannte Abnahmetest, der vom Auftraggeber vorgenommen wird.

Die Phase Betrieb und Wartung beginnt nach der Abnahme des IT-Systems. Diese Phase gehört nicht mehr zum eigentlichen Entwicklungsprozess. Sie umfasst die Zeit von der ersten Installation der Anwendung bis zum Einsatzende des Systems. Während der Wartungszeit erfolgt die Behebung festgestellter Fehler, die Anpassung an eine veränderte Systemlandschaft oder die Erweiterung der Anwendung um neue Funktionalitäten (Pagel/Six, 1994, S.38).

3.2.1.2 Bewertung des iterierten Phasenmodells

Die Zerlegung des Entwicklungsprozesses in zeitlich aufeinanderfolgende Phasen und die damit verbundene Orientierung am Lebenszyklus eines IT-Systems ist in der Praxis weit verbreitet. Dieses Vorgehen ermöglicht die Bewältigung der Komplexität durch einen klaren Rahmen, der die relevanten Aufgaben des Softwareentwicklungsprozesses beschreibt und gegeneinander abgrenzt. Die durch das iterierte Phasenmodell vorgeschriebene Strukturierung des Entwicklungsprozesses führt zu einem strukturierten Software-Produkt und ermöglicht einen arbeitsteiligen Herstellungsprozess, wie er für große Software-Projekte unabdingbar ist (Pomberger, 1990, S.223-224). Die Phasen Test und Wartung betonen die Bedeutung einer guten Softwarequalität. Es wird deutlich, dass die Arbeit an einem Software-Produkt nicht mit der Implementation abgeschlossen ist, sondern dass Software Qualitätssicherung erfahren und während der Betriebsphase betreut und gewartet werden muss (Pagel/Six, 1994, S.39).

Gerade die praktische Anwendung hat aber auch die Unzulänglichkeiten des Phasenmodells hervorgebracht. Die Entwicklung von Software verläuft in der Regel nicht streng sequentiell und die einzelnen Phasen haben nicht einen definierten Anfang sowie ein definiertes Ende, sondern überlappen zeitlich. Der Grund hierfür liegt darin, dass sowohl Produktbeschreibungen als auch Softwareentwürfe und Implementationen Fehler enthalten, die erst in späteren Phasen entdeckt werden und rückwirkende Änderungen zur Folge haben. Wie die Rückkopplungspfeile in Abbildung 6 zeigen, berücksichtigt das iterierte Phasenmodell im Gegensatz zum klassischen Wasserfallmodell zwar Iterationen, jedoch bleibt unklar, wann und nach welchen Kriterien iteriert werden soll. Ein weiteres großes Problem bezieht sich auf die Vorstellungen des Auftraggebers in Bezug auf die zu entwickelnde Anwendung. Detaillierte Vorstellungen von dem Produkt reifen oftmals erst mit dem Fortschreiten der Entwicklung heran. Dies hat zur Folge, dass der Softwarentwurf und möglicherweise auch die Implementierung auf Basis unvollständiger oder fehlerhafter fachlicher Beschreibungen erfolgt. Dies betrifft nicht nur Oberflächenkosmetik der Benutzungsschnittstelle, sondern auch Funktionalitäten des Systems.

Dadurch, dass im Rahmen der Entwicklung erst relativ spät ein greifbares Produkt bzw. eine lauffähige Version der Software vorliegt, können viele Fehler und Missverständnisse erst spät entdeckt sowie Änderungswünsche der Benutzer nur mit hohem Aufwand berücksichtigt werden. Wie bereits veranschaulicht, wird die Behebung eines Fehlers um so teurer, je früher er gemacht und je später er entdeckt wird. Einen weiteren Anlass zur Kritik bietet die Tatsache, dass der Test der Anwendung erst am Ende des Entwicklungszyklus erfolgt. Der Testprozess muss mit Beginn der Softwareentwicklung alle Phasen begleiten, damit die Entstehung von Fehlern soweit wie möglich vermieden wird bzw. Fehler so früh wie möglich entdeckt werden (Pagel/Six, 1994, S.63-64).

Nach der Erfahrung des Autors werden durch die rechtzeitige Erstellung von detailliert beschriebenen Testfällen bereits in der Phase der Anforderungsdefinition viele Fragen und offene Punkte aufgedeckt, deren Beantwortung aus der Fachspezifikation oftmals nicht hervorgeht. Die Lösungen der zu klärenden Sachverhalte können bei rechtzeitiger Entdeckung in die fachliche Beschreibung einfließen. Somit werden Entwürfe und spätere Implementationen verhindert, die auf falschen Voraussetzungen aufbauen. Die Erstellung von Testfällen und die Relevanz einer detaillierten Beschreibung für eine spätere Automatisierung von Tests wird im Rahmen dieser Arbeit noch behandelt.

Im folgenden Abschnitt werden mit dem Prototyping und dem ‚Rapid Application Development‘ (RAD) zwei Lösungsansatze für den Software-Konstruktionsprozess vorgestellt, die das iterierte Phasenmodell nicht grundsätzlich ablehnen, sondern darauf aufbauen und bezüglich der bereits angesprochenen Schwierigkeiten eine bessere Praktikabilität versprechen.

3.2.2 Prototyping und Rapid Application Development

Prototypen werden zur Klärung von Benutzeranforderungen und von Entwicklungsproblemen verwendet. In Bezug auf die verschiedenen Arten des Prototyping kann zwischen explorativem, experimentellem und evolutionärem Prototyping differenziert werden. Das explorative Prototyping, manchmal auch Rapid Prototyping genannt, dient der Klärung von Benutzeranforderungen mit dem Ziel einer möglichst vollständigen Fachspezifikation. Die Realisierung des Prototypen übernehmen Entwickler und Anwender gemeinsam. Sie diskutieren verschiedene Lösungsansätze und klären die Realisierbarkeit der geplanten Anwendung in dem gegebenen organisatorischen Umfeld (Pomberger, 1990, S.226). Die Erstellung des Prototypen erfolgt mit Hilfe leistungsstarker Workstations durch Datenbanken, Maskengeneratoren und Hochsprachen. Benutzungsoberflächen und Funktionalitäten sind Aspekte, die mit Hilfe des Rapid Prototyping untersucht werden (DGQ/ITG, 1995, S.72-73).

[...]