Systematisches Testen als analytische Qualitätssicherungsmaßnahme im Software-Entwicklungsprozess (Stand 1995)

Inhaltsverzeichnis

1. Einleitung

2. Qualitätssicherung im Software-Entwicklungsprozeß
2.1. Psychologisch-orientierte Qualitätssicherungsmaßnahmen
2.2. Konstruktive Qualitätssicherungsmaßnahmen
2.2.1. Software Engineering
2.2.2. Prinzipien
2.2.3. Methoden
2.2.4. Formalismen und Sprachen
2.2.5. Werkzeuge
2.2.6. Strukturierung durch ein standardisiertes Vorgehen
2.3. Analytische Qualitätssicherungsmaßnahmen
2.3.1. Testplanung und -ablauf
2.3.2. Zweck oder Ziel des Testens
2.3.3. Bestimmung der Testverantwortlichen
2.3.4. Statische Prüfungen
2.3.5. Dynamische Prüfungen
2.3.5.1. Methoden für die Testfallermittlung
2.3.5.1.1. Whitebox-Methoden (Strukturtest)
2.3.5.1.1.1. Überdeckungsorientierte Testfallbestimmung
2.3.5.1.1.2. Schleifentesten
2.3.5.1.2. Blackbox-Methoden (Funktionstest)
2.3.5.1.2.1. Äquivalenzklassenmethode
2.3.5.1.2.2. Grenzwertanalyse
2.3.5.1.2.3. Ursache-Wirkungsgraph-Methode
2.3.5.1.2.4. Intuitive Testfallermittlung
2.3.5.1.3. Beurteilung der Methoden und Teststrategie
2.3.5.2. Testausführungsphasen
2.3.5.2.1. Modultest (Unittest)
2.3.5.2.2. Integrationstest
2.3.5.2.2.1. Nichtinkrementelles/ inkrementelles Testen
2.3.5.2.2.2. Top-down-Testen
2.3.5.2.2.3. Bottom-up-Testen
2.3.5.2.3. Systemtest
2.3.5.2.4. Anwendertest und Regressionstest
2.3.6. Besonderheiten beim Testen objektorientierter Programme
2.3.7. Testauswertung und Fehlerbehebung
2.3.8. Testdokumentation
2.3.9. Kriterien für die Beendigung des Testens
2.3.10. Testwerkzeuge
2.3.11. Forschung und Praxis der analytischen Qualitätssicherung

3. Abschließende Bewertung

Literaturnachweis

1. Einleitung

Der Wettbewerb für europäische Unternehmen wird aufgrund des gemeinsamen Binnenmarktes schärfer. Daraus erwächst die Notwendigkeit, die Kosten zu senken. Demgegenüber ist mit einem steigenden Anspruch auf seiten der Konsumenten und Investoren zu rechnen.^[1] Qualität ist ein wichtiger Faktor für den Erfolg von Unternehmen.^[2] Der Qualitätssicherung muß sich ein Unternehmen in seiner Gesamtheit stellen.^[3] Ohne Qualitätssicherung entstehen erhebliche Fehlleistungskosten. Offene Fehlleistungskosten sind z.B. Gewährleistung, Ausschuß und Nacharbeit. Verdeckte Fehlleistungskosten sind geringe Kundenloyalität, aufwendige und unflexible Steuerung der Produktion, unnötige Verwaltungsvorgänge und Managementbedarf für Krisen. Sie sind weitaus höher als die offenen Kosten.^[4]

In dieser Arbeit werden die Merkmale benannt, die die Qualität von Software charakterisieren und die Maßnahmen beschrieben, die zur Qualitätssicherung von Software notwendig sind. Es kann hier nicht jede Qualitätssicherungsmaßnahme mit der gleichen Aufmerksamkeit und in der gleichen Tiefe behandelt werden. Die Arbeit enthält daher Kernteile und periphere Teile. Der Schwerpunkt liegt auf dem konventionellen systematischen Testen kommerzieller, modular und strukturiert entwickelter Software. Mit dieser Schwerpunktbildung soll aber keineswegs eine Geringschätzung gegenüber den anderen Qualitätssicherungsmaßnahmen ausgedrückt werden. Vielmehr verbergen sich hinter den knappen Titeln der anderen Qualitätssicherungsmaßnahmen so große Themen, daß der Rahmen dieser Arbeit für eine angemessene Behandlung auch dieser Bereiche zu eng ist.

Im Rahmen der analytischen Qualitätssicherung werden Testplanung und Testablauf beschrieben sowie Zweck und Ziel des Testens definiert. Die Bestimmung der testverantwortlichen Personen wird diskutiert. Statische Prüfungen werden nur überblicksartig dargestellt. Im Rahmen der dynamischen Prüfungen werden verschiedene Methoden für die Testfallermittlung in abstrakter Form beschrieben und gegenübergestellt. Die verschiedenen Testausführungsphasen werden aufgezeigt. Auf die Besonderheiten beim Testen objektorientierter Programme wird kurz eingegangen. Es wird kurz auf die Notwendigkeit der Testdokumentation und auf die Schwierigkeit der Fehlerlokalisierung und Fehlerbehebung hingewiesen. Die Problematik der mangelhaften Kriterien zur Bestimmung des Testendes wird beschrieben. Die Testwerkzeugsarten werden überblicksartig vorgestellt. Zum Schluß wird kurz Forschung und Praxis des Software-Testens gegenübergestellt.

Auf das Qualitätssicherungsmanagement wird hier nicht eingegangen. Meßzahlen und Verfahren zur Messung von Software-Qualität sowie Software-Normen und Zertifizierung von Software werden im Rahmen dieser Arbeit nicht behandelt. Auf Methoden des mathematischen Beweises der Programmkorrektheit und des symbolischen Tests wird hier nicht eingegangen. Da der umfangreiche Komplex des Software Engineering nur in groben Zügen beschrieben werden kann, werden für das Lesen des Hauptteils dieser Arbeit Kenntnisse des Software Engineering, insbesondere der modularen, strukturierten und objektorientierten Programmierung, vorausgesetzt.

2. Qualitätssicherung im Software-Entwicklungsprozeß

Als Qualität bezeichnet man die Gesamtheit der Eigenschaften und Merkmale eines Produktes, eines Verfahrens oder eines Systems, die erforderlich sind, um die Funktionen, die es für seinen sicheren und fehlerfreien Einsatz benötigt, zu erfüllen.^[5] In der Literatur herrscht Einigkeit darüber, daß unter Software-Qualität weitaus mehr zu verstehen ist als nur Korrektheit. Die Qualitätsanforderungen schlagen sich in der Definition von Qualitätsmerkmalen nieder. Es ist eine Fülle von Merkmalen bekannt, die zur Charakteristik der Software-Qualität verwendet werden. Über die Qualitätsmerkmale, die sich aufgrund der Qualitätsanforderungen ergeben und die Güte eines Softwaresystems bestimmen, ist sich die Fachwelt einigermaßen einig.

Die wichtigsten, auch in der Praxis anerkannten Qualitätsmerkmale sind:^[6]

Korrektheit,

Zuverlässigkeit,

Benutzerfreundlichkeit (Adäquatheit, Erlernbarkeit, Robustheit),

Wartungsfreundlichkeit (Lesbarkeit, Erweiterbarkeit, Testbarkeit),

Effizienz,

Portabilität.

Korrektheit wird als das wichtigste Qualitätsmerkmal betrachtet. Eine in hohem Maße fehleranfällige Software ist praktisch wertlos, auch wenn ihre anderen Qualitätsmerkmale ausreichend sind.^[7] Unter Korrektheit wird verstanden, daß das Programm übereinstimmt mit der Spezifikation.^[8]

Zuverlässigkeit: Ein Programm kann als zuverlässig angesehen werden, wenn die Fehlerrate, d.h. die Wahrscheinlichkeit, daß in einem bestimmten Zeitintervall ein Fehler auftritt, gering ist.^[9]

Benutzerfreundlich ist ein Programm, wenn die vom Anwender erforderlichen Eingaben sich auf das Notwendigste beschränken. Das Programm sollte dem Anwender eine flexible Dateneingabe ermöglichen und Plausibilitätskontrollen der eingegebenen Daten durchführen. Einheitlichkeit, Klarheit und Einfachheit der Benutzerführung ist in dialogorientierten Programmsystemen besonders bedeutend. Die Leistungsfähigkeit sollte unter Berücksichtigung der eventuellen Erweiterbarkeit den Wünschen des Kunden angepaßt sein. Die Ergebnisse sollten übersichtlich und gut strukturiert ausgegeben werden Das Programm soll flexibel bezüglich des Umfangs und der Art der Präsentation der Ergebnisse sein. Fehlermeldungen sollen für den Benutzer verständlich aufbereitet sein.^[10] Das Programm soll gut erlernbar sein. Die Erlernbarkeit hängt von der Benutzerführung und der Benutzerdokumentation ab. Das Programm soll robust sein, d.h. die Eigenschaft haben, die Auswirkungen von Bedienungsfehlern, falschen Eingabedaten und Hardwarefehlern abzuschwächen.

Wartungsfreundlich ist ein Programm, wenn es zur Lokalisierung von Fehlerursachen und Durchführung von Korrekturen geeignet ist und wenn es sich leicht verändern oder erweitern läßt. Die Wartungsfreundlichkeit hängt ab von der Lesbarkeit, Erweiterbarkeit und Testbarkeit eines Programmsystems.^[11]

Effizienz bedeutet, daß ein Programm in der Lage ist, seinen Zweck unter bestmöglicher Ausnutzung aller Ressourcen, d.h. Zeit, Speicherplatz, Übertragungskanäle und periphere Einheiten, zu erfüllen.^[12]

Unter Portabilität wird die Leichtigkeit verstanden, mit der ein Programmsystem auf andere Rechner übertragbar ist.^[13]

Bei gleichzeitiger Realisierung führen viele Anforderungen an Software-Produkte zu Interdependenzen unter den Qualitätsmerkmalen, z.B. verringert zusätzliche Effizienz oft die Portabilität, die Verständlichkeit und somit die Wartbarkeit. Manchmal wird anstelle einer höheren Programmiersprache Assembler verwendet, um auf Kosten der Lesbarkeit Effizienzverbesserungen zu erhalten.^[14]

Am Anfang einer Software-Entwicklung müssen eindeutige Qualitätsziele festgelegt und Prioritäten gesetzt werden. Welches Maß an Qualität verlangt werden muß, hängt von der Art der Aufgaben und Ziele ab, insofern gibt es keine absolute, sondern nur eine relative Qualität.^[15] Als Qualitätssicherungsmaßnahmen werden alle Maßnahmen zur Erzielung der geforderten Qualität bezeichnet.^[16] Durch eine entwicklungsbegleitende Qualitätssicherung muß dann die Einhaltung dieser Ziele gewährleistet werden. Die Qualitätsmerkmale sind jedoch schwer quantifizierbar. Es fehlen ausgewogene Methoden und Maße, um Qualitätsmerkmale von Software zu messen.^[17] In der Praxis stößt man oft auf ungelöste Probleme, die darauf zurückzuführen sind, daß eine eindeutige Definition und objektive Bewertung der Qualität eines Software-Produktes nicht möglich ist.^[18]

In traditionellen Ingenieurdisziplinen beinhaltet die Qualitätssicherung^[19] "...die Planung und Installation eines Produktionsprozesses, der die Erfüllung festgelegter Qualitätsanforderungen unter organisatorischen Rahmenbedingungen wie Kosten, verfügbares Personal usw. sowie die stichprobenartige Überprüfung der aus der wiederholten Ausführung dieses Prozesses resultierenden Produkte gewährleistet."^[20] In einer Serienproduktion wird nicht das einzelne Produkt, sondern die Einhaltung des Produktionsprozesses überprüft. Diese Form der Qualitätssicherung kann man nicht ohne weiteres auf individuelle Entwicklungsprozesse übertragen. In der Software-Entwicklung wird Individualentwicklung betrieben. Bei der Qualitätssicherung wird aber häufig so getan, als handele es sich von Projekt zu Projekt um die wiederholte Anwendung desselben Entwicklungsprozesses, d.h. bei der Qualitätssicherung von Software wird das auf Prozeßwiederholung basierende Produktionsparadigma zugrundegelegt.^[21]

2.1. Psychologisch-orientierte Qualitätssicherungsmaßnahmen

Mängel und Störungen arbeitspsychologischer und zwischenmenschlicher Art wirken sich stark negativ auf die Qualität der Arbeitsleistung und Produktivität der Entwickler aus. Die Unternehmenskultur und die Kommunikation enthalten solche Störquellen. Unternehmenskultur ist die Gesamtheit des durch eine spezifische Unternehmung geprägten und initiierten Denkens (Ideen, Normen, Weltanschauung), des Fühlens (Werthaltungen, Ethik) und des Handelns (Verhalten, Umsetzungsstrategien und Arbeitsweisen). Die Unternehmenskultur beeinflußt das betriebliche Geschehen und die Beziehungen der Mitarbeiter zueinander. Die Ergebnisqualität wird schlechter, wenn in der Unternehmenskultur Mängel bestehen, weil sich die Denk- und Verhaltensweisen der Mitarbeiter unmittelbar auf die Qualität der Leistungen und somit auch auf die Qualität der entwickelten Produkte auswirken. Die Beziehung Vorgesetzter / Mitarbeiter ist eine wesentliche Komponente der Unternehmenskultur. Diese Beziehung wird durch den Führungsstil beeinflußt. Motivierende Führung fördert bei Mitarbeitern die Bereitschaft, sich unternehmenskonform zu verhalten und vorgegebene oder vereinbarte Ziele zu erreichen.^[22]

Die qualitative Wirksamkeit der Prinzipien, Methoden und Hilfsmittel des Software Engineering hängt in erster Linie von der Akzeptanz der Mitarbeiter ab. Akzeptanz läßt sich nicht durch eine den Menschen vernachlässigende, bloß zielgerichtete Manipulation erreichen, sondern nur durch ehrlich gemeinte Motivation. Motivationssteigerung kann dazu beitragen, die Ziele der Qualitätssicherung zu erreichen.^[23] "Der wichtigste Garant für preiswerte und qualitativ hochwertige Software ist die Motivation und Begeisterungsfähigkeit des Entwicklungsteams."^[24] Eine Aufgabe der Qualitätssicherung ist daher auch darin zu sehen, auf die Erfüllung der Bedürfnisse der Mitarbeiter nach Selbstbestätigung, Anerkennung für qualitativ gute Arbeit und Selbstverantwortung zu achten und fördernd für die Mitarbeiter einzugreifen.

Bei einer arbeitsteiligen Software-Entwicklung und -pflege ist Kommunikation eine der wichtigsten Tätigkeiten der Mitarbeiter.^[25] Diskussion und Abstimmung nehmen mehr als 35 % der Tätigkeiten von Software-Entwicklern ein.^[26] Kommunikation spielt eine bedeutende Rolle bei Qualitätssicherungsmaßnahmen wie Reviews, Inspektionen und Qualitätszirkeln. Darüber hinaus nimmt die Kommunikation mit Anwendern, innerhalb und zwischen Projektteams sowie mit Vertretern aus unterschiedlichen Hierarchiestufen der Unternehmung einen bedeutenden Raum ein.^[27] Mangelhafte Kommunikation ist eine Hauptfehlerquelle. Die Auswirkungen mangelhafter Kommunikation auf die Qualität von Software-Produkten wird meist unterschätzt.^[28] In der Informatikausbildung muß diesen Aspekten viel mehr Aufmerksamkeit gewidmet werden.^[29]

Psychologisch-orientierte Qualitätssicherungsmaßnahmen sind im Rahmen der Informatik wenig untersucht worden. Informatiker neigen aufgrund ihrer technisch ausgerichteten Denkhaltung dazu, Probleme aus diesen Bereichen zu vernachlässigen. Sie sind meistens so überzeugt von der Bedeutung ihrer technischen Arbeit, daß sie Experten anderer Fachgebiete, wie z.B. Arbeitspsychologen, als ungeeignete Partner einstufen und deren Disziplin als unwissenschaftlich abtun.^[30] "Gutes Management von Software-Projekten heißt aber, mehr Aspekte zu berücksichtigen als nur Werkzeuge und Technologie."^[31]

2.2. Konstruktive Qualitätssicherungsmaßnahmen

Ziel der konstruktiven Qualitätssicherung ist es, Fehler im Entwicklungsprozeß zu vermeiden, während es bei der analytischen Qualitätssicherung darum geht, die vorhandene bzw. nicht vorhandene Qualität zu bestimmen. Die Devise der konstruktiven Qualitätssicherung lautet, keine Fehler machen ist besser als Fehler zu beheben.^[32] Durch geeignete präventive Maßnahmen im Entwicklungsprozeß wird die Qualität des Produkts verbessert und erhöht. Durch vorbeugende Maßnahmen läßt sich der Aufwand der Qualitätsprüfungen, z.B. des Testens, erheblich reduzieren.

Ein weiterer positiver Aspekt dieses Prinzips ist es, daß durch konstruktive Qualitätssicherungsmaßnahmen analytische Qualitätsprüfungen erst möglich gemacht werden.^[33] So kann z.B. durch eine gute Schnittstellenspezifikation für ein Modul das funktionsorientierte Testen wesentlich vereinfacht werden. Die Anwendung maximaler konstruktiver Qualitätssicherung bringt zusammengefaßt folgende Vorteile:^[34]

Direkte Verbesserung der Qualität,

Fehlervermeidung,

Ermöglichung analytischer Maßnahmen,

Verringerung des Aufwandes analytischer Maßnahmen.

Konstruktive Qualitätssicherungsmaßnahmen und analytische Qualitätsprüfungen ergänzen sich gegenseitig.^[35]

2.2.1. Software Engineering

Die Entwicklung des Qualitätsbewußtseins ist in der US-amerikanischen Literatur eng mit der Entwicklung des Software Engineering verbunden. Man kann sogar sagen, daß die konstruktiven und analytischen Qualitätssicherungsmaßnahmen vom Software Engineering entwickelt wurden und werden.^[36] In der deutschsprachigen Literatur ist der enge Zusammenhang nicht zu finden. Der Aspekt der Software-Qualität wird losgelöst vom Software Engineering erst viel später (ca. 1982) aufgegriffen.^[37]

Software Engineering ist eine Disziplin, die mit ökonomischem Vorgehen und ingenieurmäßigen Mitteln den Entwickler dabei unterstützt, zielgerichtet qualitativ hochwertige Software herzustellen und zu pflegen.^[38] Software Engineering ist eine relativ junge Disziplin. Gegenüber klassischen Produktionsentwicklungsbereichen, z.B. in der Industrie, die über eine lange technologische Tradition mit bewährten Techniken verfügt, befindet sich das Software Engineering erst am Anfang.^[39]

Der Begriff Software Engineering soll eine Abgrenzung gegenüber der Praxis der "Software-Bastelei" darstellen und kennzeichnet die Entwicklung von Software-Produkten, die auf durchdachten Methodologien basiert und von moderner Technik unterstützt wird.^[40]

Zu den konstruktiven Elementen des Software Engineering zur Qualitätssicherung gehören im einzelnen: Prinzipien, Methoden, Formalismen, Werkzeuge und die Strukturierung des Entwicklungsprozesses.

2.2.2. Prinzipien

Prinzipien sind Grundsätze, die dem Handeln zugrundeliegen. Sie enthalten allgemeine Verhaltensregeln. Allgemein anerkannte Prinzipien für die verschiedenen Aufgaben in der Entwicklung und Wartung von Software sind zum Beispiel:^[41]

Konstruktive Voraussicht,

Abstraktionsstufen, die schrittweise verfeinern oder schrittweise vergröbern,

Strukturierung,

Modularisierung,

Lokalität,

Information-Hiding,

Integrierte Dokumentation,

Objektorientierung,

gut definierte Schnittstellen,

Standardisierung,

Mehrfachverwendung.

An diesen Prinzipien sollte sich die Auswahl der Methoden, Formalismen und Werkzeuge grundsätzlich orientieren. Die Unterstützung dieser Prinzipien durch Werkzeuge und Methoden ist ein wesentlicher Erfolgsfaktor für ein praktikables Software Engineering. Prinzipien unterstützen und fördern das Entstehen von Qualität. So wird z.B. durch ein gut strukturiertes Dokumentenmuster (Anwendung des Prinzips der Strukturierung) für eine Anforderungsdefinition einem Analytiker bei der Spezifikation zu klaren, vollständigen und widerspruchsfreien Aussagen verholfen. Darüber hinaus verbessern diese Prinzipien aus der Sicht der analytischen Qualitätssicherung die Prüfbarkeit der Ergebnisse.

2.2.3. Methoden

Methoden sind planmäßig angewandte Vorgehensweisen zur Erreichung von festgelegten Zielen (z.B. bessere Qualität). Sie zeigen auf, wie ein Ziel erreicht werden kann, ohne Zeit und Energie für nutzloses Herumprobieren zu verschwenden. Eine Methode sollte eine systematische und zielstrebige Vorgehensweise bieten, die nach einer Anzahl planbarer Schritte zum Ziel führt. Darüber hinaus sollte sie die Dokumentation der Arbeitsergebnisse vereinheitlichen. Die Jackson Strukturierte Programmentwicklung (JSP) und die Systementwicklungsmethoden (JSD) sind Beispiele für Methoden.^[42] Aus der Sicht der Qualitätssicherung besteht der Zweck des Einsatzes von Methoden in der systematischen und daher nachvollziehbaren Ergebnisermittlung und in der Erstellung einer projektbegleitenden Dokumentation.^[43]

2.2.4. Formalismen und Sprachen

Der Aufwand für die Implementierung beträgt bei einem gut organisierten Software-Entwicklungsprozeß nur 20-30 % des Projektaufwands. Deshalb wird die Bedeutung der Programmiersprache für die Entwicklung eines Software-Produkts nicht so hoch eingeschätzt. Die Sprache ist jedoch für die Wartbarkeit von Applikationen bedeutend. Programme sollten in einer höheren Sprache geschrieben sein, die gut strukturiertes Programmieren ermöglicht. Durch folgende Konzepte und Merkmale von Sprachen wird die Erstellung von qualitätiv guter Software ermöglicht:^[44]

Modularität von Programmen: Die Modularität wirkt sich günstig aus auf die Lokalität und gestattet letztlich erst eine arbeitsteilige Realisierung von Programmen.

Strukturierter Kontrollfluß: Strukturiert entwickelte Programme sind leichter überschaubar und können leichter geändert oder erweitert werden.^[45]

Möglichkeit der Verwendung von beschreibenden Namen zur Bezeichnung von Programmen und Datenelementen.

Das Datentypenkonzept, sollte eine problemnahe Darstellung von Daten erlauben.

Objektorientierung^[46] steigert die Änderbarkeit, Erweiterbarkeit und Wiederverwendbarkeit erheblich.

Hinsichtlich vorgenannter Punkte bieten Sprachen wie Ada^[47] und Modula-2^[48] bereits gute Unterstützung. Objektorientierte Sprachen wie z.B. C++^[49] erhöhen die Produktivität und Qualität wesentlich. Es gibt aber keine allgemein "beste" Sprache, die sich für alle Aufgaben gleich gut eignet.^[50] Die Lesbarkeit eines Programms hängt nicht nur von der Programmiersprache, sondern noch stärker vom Programmierstil ab. Z.B. kann ein stilistisch gut entwickeltes COBOL-Programm besser strukturiert und besser lesbar sein als ein unübersichtlich entwickeltes Modula-2-Programm.^[51] Besonders bei Sprachen, die unzuverlässige Konstrukte zulassen (z.B. FORTRAN, COBOL; BASIC), ist ein diszipliniertes Programmieren durch Einhalten von strukturierten Richtlinien wichtig. Auf GOTO-Anweisungen sollte verzichtet werden. Dadurch werden Algorithmen leichter überschaubar und können leichter geändert oder erweitert werden.

In der Praxis wird die Frage nach dem Einsatz einer neuen Sprache meist gar nicht gestellt, da durch die bereits vorhandene Software die Sprache festgelegt ist.^[52] Eine DV-Organisation wechselt selten die Programmiersprache, weil die Sorge zu groß ist, daß der Aufwand zu hoch sein könnte. Informatiker müssen deshalb lernen, stilistisch gute Programme in den vorhandenen Sprachen zu entwickeln.^[53] Es wäre zu untersuchen, wie weit Programme, die in qualitätsfördernden Sprachen entwickelt werden, mit bereits vorhandener konventionell erstellter Software verknüpfbar sind und wie gut die Erlernbarkeit ist. Hiervon hängt u.a. ab, inwieweit diese Sprachen Eingang in die Informatik-Praxis finden.

2.2.5. Werkzeuge

Es gibt Werkzeuge zum Erstellen, Prüfen, Generieren, Testen und Verwalten von Software sowie zum Planen und Kontrollieren. Durch Werkzeuge wird die Qualität insofern verbessert, indem sie das Entstehen von Fehlern verhindern und andererseits die Anwendung der Prinzipien, Methoden und Formalismen vereinfachen und unterstützen können. Werkzeuge sind eine wertvolle Unterstützung bei der organisatorischen und physischen Bewältigung von großen Informationsmengen.

Problem ist, daß diese vielen Werkzeuge sich oft schwer miteinander kombinieren lassen. Es fehlen Konzepte für den Werkzeugeinsatz.^[54] Trotz vielfältiger Möglichkeiten können Werkzeuge das kreative Handeln und Denken der Entwickler nicht ersetzen, aber anregen und unterstützen.^[55]

2.2.6. Strukturierung durch ein standardisiertes Vorgehen

Das verbindende Element des Software Engineering ist ein standardisiertes Vorgehen, das alle vorher beschriebenen Elemente verbindet. Das standardisierte Vorgehen wird festgelegt in Phasenmodellen. I. d. R. wird der Software-Entwicklungsprozeß in einzelne Phasen eingeteilt. Die Qualität muß in jeder dieser Phasen entstehen. An jede Phase werden Anforderungen gestellt. Am Ende einer Phase wird diese auf Erfüllung der Anforderungen überprüft.^[56] Jedes Phasenende dient darüber hinaus als Kontrollpunkt für die Entscheidung, ob das Projekt weitergeführt, neu geplant oder aufgegeben werden soll.^[57] Die Gesamtqualität eines Programmes setzt sich stufenweise aus der Qualität der Phasenergebnisse und der Erfüllung der Prozeßanforderungen zusammen.^[58] Ziel des phasenorientierten Vorgehens ist es, Fehler möglichst gering zu halten bzw. sie möglichst früh aufzudecken, weil der Aufwand für das Vermeiden von Fehlern wesentlich geringer ist als der für die nachträgliche Beseitigung.^[59]

Phasenmodelle gibt es in zahlreichen Variationen. Sie beschreiben das systematische Entstehen von Software. Die einfachsten haben fünf, die komplizierteren über zehn Phasen. In allen Modellen müssen prinzipielle Grundsätze eingehalten werden: Hierzu gehört die Beschreibung, was und wie etwas zu tun ist. Die Phasenmodelle sind sich sehr ähnlich und alle haben eines gemeinsam: Der Beginn einer neuen Phase setzt den Abschluß der vorherigen voraus.

Im wesentlichen beinhalten die Modelle folgende Phasen des Software-Engineering-Prozesses:^[60]

Problemanalyse und Planung,

Systemspezifikation,

Entwurf,

Implementierung,

Test,

Installation und Abnahme,

Betrieb und Wartung.

Die Praxis hat gezeigt, daß eine rein sequentielle Vorgehensweise selten konsequent durchführbar ist.^[61] Aus diesem Grunde wurden Modellvariationen entwickelt, in denen diese streng sequentielle Vorgehensweise aufgeweicht wurde: Die Bezeichnungen hierfür lauten z.B.: objektorientiertes Life Cycle Modell,^[62] prototypingorientiertes Life Cycle Modell,^[63] Spiralmodell,^[64] Wasserfallmodell,^[65] V-Modell (Verifikations-Modell),^[66] Sichtenmodell.^[67] Das Wasserfallmodell wird in der Literatur am meisten zitiert^[68] und in der Praxis am meisten angewendet.^[69] Es würde hier zu weit führen, die Modelle zu beschreiben.

2.3. Analytische Qualitätssicherungsmaßnahmen

Es ist einleuchtend, daß Qualität von Software-Produkten zunächst dadurch erreicht werden kann, daß man sich leistungsfähiger Entwurfs- und Implementierungstechniken in Verbindung mit geeigneter Organisation und fähigem Management bedient. Jedoch treten erfahrungsgemäß trotzdem Fehler in beträchtlichem Ausmaß auf. Dieses umso mehr, je komplexer das jeweilige Software-System und je länger die Entwicklungszeit ist.^[70] Deshalb war und ist es auch weiterhin notwendig, Software zu prüfen, d.h. durch eine Soll/Ist-Analyse Fehler festzustellen. Es wird überprüft, ob geforderte Funktionen und Eigenschaften, das Soll, mit den realisierten Funktionen und Eigenschaften, dem Ist, übereinstimmen. Festgestellte Abweichungen werden lokalisiert und in ihrer Ursache ermittelt. Das Testen ist eine projektbegleitende Maßnahme zur Qualitätssicherung und bezieht sich auf die Phasen Systemspezifikation, Entwurf, Implementierung und Wartung. Der Test des Endprodukts kann erst nach Abschluß aller vorherigen Phasen durchgeführt werden.^[71]

2.3.1. Testplanung und -ablauf

Das Testen großer Systeme beinhaltet die Definition, Ausführung und Überprüfung tausender Testfälle, die Handhabung etlicher Module, die Korrektur zahlreicher Fehler und die Beschäftigung von vielleicht hundert Mitarbeitern zur gleichen Zeit über einen Zeitraum von eventuell einem Jahr oder mehr. Hier steht man einem großen Projektmanagementproblem, was das Planen, Überwachen und Steuern des Testprozesses anbelangt, gegenüber.^[72] Das Problem ist so umfangreich, daß allein dem Management des Software-Testens ein ganzes Buch gewidmet werden müßte. Hier werden nur einige der Überlegungen zusammengefaßt:

Ein Test besteht aus drei Schritten: Vorbereitung, Ausführung und Auswertung.

[...]

---

^[1] vgl. Berger, S. 22

^[2] vgl. Imai, S. 247

^[3] vgl. Schaerer, S. 27, vgl. Wildemann.S. 53

^[4] vgl. Bösenberg, S. 159

^[5] vgl. Schulze, S. 2237

^[6] vgl. Balzert (1992), S. 11, vgl. Franz, S. 9ff, vgl. Trauboth, S. 25, vgl. Dunn, S. 17 ff, vgl. Pomberger (1993), S. 9, vgl. Asam, S. 25

^[7] vgl. Schumann, S. 47

^[8] vgl. Kopetz zit. in Pomberger (1993), S. 10

^[9] vgl. Kopetz zit. in Pomberger (1993), S. 11, vgl. Balzert (1992), S. 12

^[10] vgl. Pomberger(1993), S. 11

^[11] vgl. Pomberger(1993), S. 12

^[12] vgl. Balzert (1992), S. 12, vgl. Pomberger(1993), S. 13

^[13] vgl. Balzert (1992), S. 12

^[14] vgl. Peter, S. 48

^[15] vgl. Schulze, S. 2238

^[16] vgl. Hesse, S. 119

^[17] vgl. Schröter, S. 97, vgl. Dunn, S. 27ff, vgl. Sommerville, S. 331

^[18] vgl. Pomberger (1993), S. 9

^[19] vgl. Rombach, S. 267

^[20] Rombach, S. 267

^[21] vgl. Hering, S. 4 u.5., vgl. Rombach, S. 267

^[22] vgl. Wallmüller, S. 136

^[23] vgl. Wallmüller, S 137

^[24] Pressman, S. XVIII (Vorwort des Herausgebers)

^[25] vgl. Elzer, S. 186-187

^[26] vgl. Jones (1986) zit. in Wallmüller, S. 138

^[27] vgl. Wallmüller, S. 138

^[28] vgl. Wallmüller, S., 139

^[29] vgl. Denert, S. 299

^[30] vgl. Wallmüller. S. 26

^[31] Elzer, S. 196

^[32] vgl. Trauboth, S. 10, vgl. Balzert (1992), S. 444

^[33] vgl. Balzert (1992) , S. 444

^[34] vgl. Balzert (1992), S. 445

^[35] vgl. Wallmüller, S. 16

^[36] vgl. Griese, S. 577

^[37] vgl. Griese, S. 578

^[38] vgl. Wallmüller, S. 3

^[39] vgl. Wallmüller, S. 75

^[40] vgl. Dunn, S. 8

^[41] vgl. Balzert (1992). S. 27ff

^[42] vgl. Jackson, S. 1ff

^[43] vgl. Wallmüller, S. 78

^[44] vgl. Wallmüller, S. 106, 107

^[45] vgl. Pomberger(1993), S. 138

^[46] vgl. Trauboth, S. 133

^[47] vgl. Bornes zit. in Wallmüller, S. 107

^[48] vgl. Pomberger (1987) zit. in Wallmüller, S. 107

^[49] vgl. Stoustrup zit. in Wallmüller, S. 107

^[50] vgl. Pomberger (1993), S. 133

^[51] vgl. Pomberger(1993), S. 137, 138, vgl. Trauboth, S. 133, vgl. Ludewig, S. 287

^[52] vgl. Pomberger(1993), S. 9

^[53] vgl. Denert, S. 296

^[54] vgl. Wallmüller, S. 109

^[55] vgl. Wallmüller, S. 79

^[56] vgl. Wallmüller, S. 11,vgl. Frühauf, S. 14

^[57] vgl. Dunn, S. 114

^[58] vgl. Wallmüller, S. 11

^[59] vgl. Wischnewski, S. 31

^[60] vgl. Franz, S. 44, vgl. Pomberger(1993), S. 18ff, vgl. Balzert (1993), S. 469

^[61] vgl. Pressman, S. 52, vgl. Schäfer, S. 82, vgl. Elzer, S. 183

^[62] vgl. Pomberger (1993), S. 28

^[63] vgl. Pomberger (1993), S. 24

^[64] vgl. Wallmüller, S. 86, vgl. Pomberger (1993), S. 24

^[65] vgl. Pressman, S. 13, vgl. Pomberger (1993), S. 23, vgl. Frühauf, S. 14, vgl. Wallmüller, S. 84, vgl. Dunn, S. 114, vgl. Elzer, S. 183

^[66] vgl. Wallmüller, S. 84

^[67] vgl. Wallmüller, S. 86

^[68] vgl. Frühauf, S. 11, vgl. Pressman, S. 13

^[69] vgl. Pomberger (1993), S. 17, vgl. Schäfer, S. 82, vgl. Wallmüller, S. 88, vgl. Frühauf, S. 11, vgl. Pressman, S. 13

^[70] vgl. Gewald, S. 139

^[71] vgl. Pomberger (1993), S. 146

^[72] vgl. Myers, S. 118-119