Kostentreiber Softwarequalität – Optimierung von Testmanagement und Testprozessen

Tesis , 2005 , 71 Páginas , Calificación: 1,3

Informática - Informatica de negocios

Die zentrale Fragestellung der vorliegenden Diplomarbeit lautet:
Wie kann eine hohe Softwarequalität sichergestellt und Fehlerkosten in der
Entwicklung und Wartung von Software reduziert werden, ohne dass die Kosten
für den Test das Softwareprojekt unwirtschaftlich werden lassen?
Die Diplomarbeit soll die folgenden Ergebnisse erbringen:

•Übersicht über die Möglichkeiten des organisierten Softwareentwicklungs- und
Testprozesses.
Das Kapitel 2 beschäftigt sich mit den verschiedenen Arten der
Softwareentwicklung. Angefangen vom statischen Wasserfallmodell, bei dem der
Testprozess erst in einer späten Phase beginnt, werden verschiedene Modelle
bis hin zur agilen Programmierung in kleinen Projektteams vorgestellt.

•Überblick über die Qualitätssicherung
Testen ist kein Selbstzweck oder abschließendes Ereignis in der Softwareentwicklung,
sondern dient der Qualitätssicherung. In Kapitel 3 werden Merkmale für
Softwarequalität und ihre Messbarkeit vorgestellt. Dazu werden die Qualitätsmerkmale
nach ISO 9126 beschrieben. Es wird auf Metriken im Allgemeinen eingegangen
und der Bezug von Qualitätssicherung und Softwaretest herausgestellt.

•Möglichkeiten Software zu testen und Tests zu managen
Kapitel 6 beschreibt den eigentlichen Testprozess. Es werden die verschiedenen
Arten des Testens in verschiedenen Phasen der Softwareentwicklung dargestellt.
Neben statischen und dynamischen Verfahren der Programmanalyse wird auf die
Automatisierung von Tests und auf das Testmanagement eingegangen.

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einleitung
1.1 Motivation
1.2 Gegenstand, Ziel und Aufbau der Arbeit

2 Der Softwareentwicklungsprozess
2.1 Grundlagen zu Prozessmodellen
2.2 Das Wasserfallmodell
2.3 Allgemeines V-Modell
2.4 Das W-Modell
2.5 Agile Programming mit XP

3 Software-Qualität
3.1 Software-Qualitätssicherung
3.2 Messbarkeit von Software-Qualität
3.2.1 Qualitätsmerkmale nach ISO 9126
3.2.2 Metriken
3.3 Qualität und Kosten
3.4 Qualitätssicherung und Softwaretest

4 Der Testprozess
4.1 Zielsetzung des Testens
4.2 Konventionelle Testphasen
4.2.1 Modultest oder Komponententest
4.2.2 Integrationstest oder Modulgruppentest
4.2.3 Systemtest
4.2.4 Abnahmetest
4.3 Dynamische Programmanalyse
4.3.1 White-Box-Test
4.3.2 Coverage und Metriken im White-Box-Test
4.3.2.1 Kontrollflussorientierte Verfahren
4.3.2.2 Datenflussorientierte Verfahren
4.3.3 Black-Box-Test
4.3.4 Verfahren und Metriken im Black-Box-Test
4.3.5 Gray-Box-Test
4.4 Statische Programmanalyse
4.4.1 Statische Codeanalyse
4.4.2 Inspektion
4.4.3 Review
4.4.4 Walkthrough
4.5 Testautomatisierung
4.5.1 Motivation
4.5.2 Anwendungsbereiche
4.5.3 Werkzeuge zur Testautomatisierung
4.5.3.1 Testroboter
4.5.3.2 Load and Stress
4.5.3.3 Testdatengeneratoren
4.5.3.4 Driver and Stubs
4.5.3.5 Statische Analyse-Tools
4.5.4 Probleme beim Werkzeugeinsatz
4.5.5 Automated Test Life-Cycle Methodology (ATLM)
4.5.6 Aufwand und Nutzen
4.6 Test Maturity Model (TMM)
4.7 Test und Management
4.7.1 Motivation und Ziele
4.7.2 Testendekriterien
4.7.3 Testteamstruktur
4.7.4 Risikomanagement
4.7.5 Kosten und Wirtschaftlichkeit

5 Schlussbetrachtung und Ausblick

6 Literaturverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Wasserfallmodell nach Balzert

Abbildung 2: Allgemeines V-Modell

Abbildung 3: W-Modell nach Spillner

Abbildung 4: Manifesto for Agile Software Development

Abbildung 5: FCM-Modell nach Balzert

Abbildung 6: Fehlerkosten nach Boehm

Abbildung 7: Qualitätskosten nach Juran

Abbildung 8: Testen und Prüfen

Abbildung 9: Stubs und Driver

Abbildung 10: Outside-In-Integrationstest

Abbildung 11: Kontrollflussgraph

Abbildung 12: Überblick über die datenflussorientierten Testverfahren

Abbildung 13: Test von Zustandsautomaten

Abbildung 14: Ablauf eines Walkthrough

Abbildung 15: Automated Test Life-Cycle Methodology

Abbildung 16: Reifemodell für den Testprozess angelehnt an CMM

Abbildung 17: Prozesse während des Testens

Abbildung 18: Optimierung von Test und Risiko

Tabellenverzeichnis

Tabelle 1: Kosten-/Nutzenanalyse von Entwurfsinspektionen 35

Tabelle 2: Simple ROI calculation for test automation 45

Tabelle 3: Verbesserte Testqualität 46

Tabelle 4: Manuelles und automatisiertes Testen im Vergleich 46

1 Einleitung

1.1 Motivation

Der Einsatz moderner DV ist für viele Unternehmen ein entscheidender Erfolgsfaktor. Der Einsatzbereich von Software ist groß und Fehler sind in der Regel mit hohen Kos- ten verbunden. Software dringt immer häufiger in neue Anwendungsgebiete vor. We- gen ihrer in vielen Lebensbereichen hohen Durchdringung ist die Forderung nach inno- vativer, qualitativ hochwertiger Software hoch und das Wachstum des Umfangs der Programme groß.

Der Stand der Dinge: Unternehmen der Automobilindustrie müssen Rückrufaktionen bei Fahrzeugen wegen mangelhafter Software auslösen. Der Absturz der Ariane 5 im Dezember 2002 basiert auf einem Softwarefehler. Das fehlerhafte 623 Millionen Pfund teure, von Lockheed Martin gelieferte System in Swanwick sollte schon 1996 fertig ge- stellt werden, ging aber erst 2002 in Betrieb. Seitdem war es durch Fehler geprägt¹ und legte im Juni 2004 die britischen Flughäfen lahm.² Fehlerhafte Abrechnungssoftware bei Toll Collect bescherte dem deutschen Staat monatlich einen millionenschweren Schaden und den beteiligten Unternehmen einen großen Imageverlust weltweit. So kommentierte der verkehrspolitische Sprecher der Grünen-Bundestagsfraktion, Albert Schmidt, die Einsetzbarkeit der Maut-Software von Toll Collect kurz vor dem geplanten Auslieferungstermin: „Die Software wurde kurz vor Weihnachten noch einmal überprüft, und die Ergebnisse waren desaströs“.³

Softwarefehler haben oft nicht einschätzbare Folgen und können selten kalkuliert wer- den. Softwarefehler sind immer noch ein Hauptproblem in der Softwareentwicklung. Nach Spillner⁴ gibt es keine fehlerfreie Software. Doch woher kommt nach Jahrzehnten der Softwareentwicklung die häufig mangelhafte Qualität von Software? Die Ursachen sind vielschichtig, in jedem Projekt verschieden und in unterschiedlicher Ausprägung erkennbar.

Ein Bestandteil der Qualitätssicherung bei IT-Systemen ist das Testen von Software. Doch Testen wird vielfach als notwendiges Übel betrachtet, das zu lange dauert und zu hohe Kosten verursacht. Nach Martin Pol, Tim Koomen und Andreas Spillner⁵ umfas- sen die Kosten für das Testen 25 bis 50% des gesamten Projektbudgets. Allerdings ist der Umstand ein fehlerhaftes System zu implementieren mit viel höheren Folgekosten verbunden. Fehler, die bei der Nutzung der Software auftreten, sind während der Soft- wareerstellung entstanden. Wenn es sich dann auch noch um ein schlecht dokumen- tiertes Produkt handelt, das womöglich auch ungenügend strukturiert ist, kann es bei der Fehlerbereinigung zu Folgefehlern kommen, die weitere Kosten verursachen.⁶

Trotz hoher Kosten, die entstehen können und auch entstehen, wird dem Testen häufig nicht die Bedeutung beigemessen, die es verdient. Die Tatsache, dass es trotz der Ausgaben für Test und Wartung immer wieder Probleme mit implementierter Software gibt, zeigt wie wichtig es ist hinreichend zu testen.

1.2 Gegenstand, Ziel und Aufbau der Arbeit

Die vorliegende Arbeit richtet sich an alle Organisationen, die mit der Softwareent- wicklung, Softwarequalität und dem zugehörigen Test von Software sowohl als Auftragnehmer als auch als Auftraggeber zu tun haben. Es werden verschiedene Möglichkeiten der professionellen Entwicklung von Software mit integriertem, organisiertem Testwesen bei hoher Softwarequalität vorgestellt. Die Diplomarbeit ist weder eine Universalanleitung für das Testen und die Entwicklung von Software, noch ein Plan für die Vorgehensweise bei der Qualitätssicherung. Die vorgestellten Bausteine müssen vielmehr den jeweiligen Bedürfnissen, Qualitätsansprüchen, Strukturen und finanziellen Möglichkeiten von Unternehmen entsprechend zusammengestellt werden.

Die zentrale Fragestellung der vorliegenden Diplomarbeit lautet:

Wie kann eine hohe Softwarequalität sichergestellt und Fehlerkosten in der Entwicklung und Wartung von Software reduziert werden, ohne dass die Kosten für den Test das Softwareprojekt unwirtschaftlich werden lassen?

Die Diplomarbeit soll die folgenden Ergebnisse erbringen:

- Übersicht über die Möglichkeiten des organisierten Softwareentwicklungs- und Testprozesses. Das Kapitel 2 beschäftigt sich mit den verschiedenen Arten der Softwareentwicklung. Angefangen vom statischen Wasserfallmodell, bei dem der Testprozess erst in einer späten Phase beginnt, werden verschiedene Modelle bis hin zur agilen Programmierung in kleinen Projektteams vorgestellt.

- Überblick über die Qualitätssicherung Testen ist kein Selbstzweck oder abschließendes Ereignis in der Softwareent- wicklung, sondern dient der Qualitätssicherung. In Kapitel 3 werden Merkmale für Softwarequalität und ihre Messbarkeit vorgestellt. Dazu werden die Qualitäts- merkmale nach ISO 9126 beschrieben. Es wird auf Metriken im Allgemeinen ein- gegangen und der Bezug von Qualitätssicherung und Softwaretest herausge- stellt.

- Möglichkeiten Software zu testen und Tests zu managen

Kapitel 6 beschreibt den eigentlichen Testprozess. Es werden die verschiedenen Arten des Testens in verschiedenen Phasen der Softwareentwicklung dargestellt. Neben statischen und dynamischen Verfahren der Programmanalyse wird auf die Automatisierung von Tests und auf das Testmanagement eingegangen.

2 Der Softwareentwicklungsprozess

2.1 Grundlagen zu Prozessmodellen

Um bei allen Beteiligten eine einheitliche Sicht der logischen und zeitlichen Struktur eines Softwareprojektes zu erzielen, ist es unerlässlich nach einem festgelegten Schema vorzugehen. Bei einer geordneten Projektabwicklung ist es wichtig die Phasen (einzelne Arbeitsschritte und Methoden) zu definieren und die Rollen mit den zu erzie- lenden Ergebnissen festzulegen. Rollen sind im Wesentlichen Aufgaben, die einem Stelleninhaber zugeordnet werden. Jede Phase ist zeitlich begrenzt. Das Ergebnis ei- ner Phase (Meilenstein) ist im Rahmen von Qualitätssicherungsmaßnahmen überprüf- bar.⁷

In der Softwareentwicklung bieten sich viele verschiedene Prozessmodelle an. Neben Rational Unified Process (RUP), SCRUM⁸, dem Spiralmodell, dem Vorgehensmodell des Bundes und der Länder, dem Fontänenmodell und einigen mehr, gibt es das W- Modell, dessen Entstehung im Folgenden beschrieben werden soll. Im weiteren Verlauf wird auch auf die Methode der agilen Programmierung am Beispiel von eXtreme programming (XP) eingegangen.

2.2 Das Wasserfallmodell

Das wohl älteste Prozessmodell, entstanden gegen Ende der 60er Jahre nach Royce⁹, ist das Wasserfallmodell. Trotz seines Alters sind seine Ziele immer noch aktuell:

1. Gliederung der gesamten Entwicklung in Phasen

2. Verifizierung von Software am Ende jeder Phase der Entwicklung

Die einzelnen Phasen werden schrittweise durchlaufen. Erst nach Abschluss einer Phase kann mit der nächsten begonnen werden.¹⁰

Abbildung 1: Wasserfallmodell nach Balzert¹¹

Abbildung in dieser Leseprobe nicht enthalten

Die Vorteile des Wasserfallmodells liegen hauptsächlich in seiner einfachen Struktur. Der sequenzielle Aufbau ist leicht verständlich, so dass kein großer Schulungsbedarf erforderlich ist. Eine Partizipation der Anwender findet sowohl in der Analysephase als auch beim Test statt. Es ist nur ein begrenzter Managementaufwand nötig.¹²

Kritiker des Modells bemängeln hauptsächlich die starre Abfolge der Phasen. Ein Rücksprung in frühere Phasen ist nicht gewünscht.¹³ Das würde allerdings bedeuten, dass alle Phasen, angefangen mit der Auftragsvergabe und dem Feinkonzept, zu Projektbeginn feststehen und perfekt ausgearbeitet sein müssen.

Ein weiterer Nachteil ist, dass der Endanwender frühestens beim Benutzertest das erste Mal das Produkt begutachten kann. Sollten sich daraus weitere Anforderungen ergeben, oder sich Fehler zeigen, erfolgt der Rücksprung unter Umständen bis zum Feinkonzept. Sollten hier die Ursachen des Fehlers liegen, müssten alle Phasen erneut durchlaufen werden. Dieses Procedere kann mehrmals durchlaufen werden, weil der Benutzer das Produkt wiederum erst am Ende der Kette sieht und testet.¹⁴

2.3 Allgemeines V-Modell

Einen großen Einfluss auf die Bedeutung des Testens innerhalb der Softwareentwick- lung hat das allgemeine V-Modell nach Boehm.¹⁵ Das V-Modell ist im eigentlichen Sinne eine Erweiterung des Wasserfallmodells um den Aspekt der Qualitätssicherung.

Im V-Modell (Abb. 2) sind Entwicklung und Test gleichberechtigte Tätigkeiten. Im Verlauf des linken Zweiges werden die Schritte der Entwicklung einer Software dargestellt, während im Rechten die Test- und Integrationsschritte aufgelistet sind. Einzelne Bauteile eines Programms werden sukzessive zu größeren Einheiten zusammengefasst, auf richtige Funktion überprüft und schließlich im Abnahmetest als Gesamtsystem geprüft und abgenommen.¹⁶ In jeder Teststufe ist zu validieren, ob die Ergebnisse die auf dieser Stufe geforderten Anforderungen erfüllen. Das heißt, dass als Bezugsgröße der Tests einer Stufe die dazugehörige Entwicklungsstufe zugrunde gelegt wird.¹⁷ Die einzelnen Testphasen werden im Kapitel 4.2 näher erläutert. Neben der Validierung sieht das Modell die Verifikation der Entwicklungsphasen vor. Es wird

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Allgemeines V-Modell¹⁸

Im Gegensatz zum Wasserfallmodell deckt das V-Modell alle Phasen des Entwicklungsprozesses ab. Das V-Modell bezieht sich nicht nur auf die Softwareerstellung, sondern auch auf Wartung, Qualitätssicherung und Projektmanagement.¹⁹

Allerdings ist das Modell im Bezug auf das Projektmanagement sehr aufwendig und bürokratisch. Durch die Vielzahl von Ergebnistypen und Prozessschritten ist das Modell ohne entsprechendes CASE²⁰ Tool nicht handhabbar. Daraus ergibt sich auch ein ho- her Schulungsbedarf beim Projektmitarbeiter.²¹ Ein weiterer Mangel ist, dass es keine eindeutige Trennung zwischen Test-, Debug-, und Änderungsaktivitäten gibt und Test- aktivitäten ähnlich wie beim Wasserfallmodell erst zu einem späten Zeitpunkt begin- nen.²²

2.4 Das W-Modell

Die Erweiterung des V-Modells, das W-Modell, sieht das Testen innerhalb des Entwicklungszyklus eines Softwareproduktes als parallelen Prozess. Der Name W- Modell ergibt sich aus der Darstellung des Testprozesses als zweites „V“.²³ Das W- Modell soll Nachteile des V-Modells beheben und Aspekte der agilen Programmierung, die im Kapitel 2.5 beschrieben wird, einbeziehen.

Durch den Beginn der Testaktivitäten beim Projektstart²⁴ kann der Testaufwand und die Teststrategie schon zu einem frühen Zeitpunkt festgelegt werden. Das heißt, dass in der Phase der Anforderungsdefinition die Testfälle für den Abnahmetest definiert wer- den. Die Vorgehensweise beginnt in der Regel mit der Frage ob die Anforderungen testbar sind. Danach wird die Teststrategie festgelegt. Dazu gehört sowohl die Risiko- analyse als auch eine möglichst realistische Einschätzung des Testaufwands. Danach kann der Testplan erstellt und, falls nötig, die Testmitarbeiter geschult werden. Der Testmanager prüft den Einsatz von Werkzeugen und sorgt für deren Bereitstellung. Die Testumgebung kann geplant und Hard-/Softwareressourcen können organisiert wer- den. Parallel zu jeder der folgenden Phasen werden dann die zugehörigen Tests ge- plant.

Bereits in der Phase der Anforderungsdefinition ist es sinnvoll, die Anforderungen anhand einer Checkliste eines Reviews zu unterziehen. Daraus resultiert:

- 75% aller Testaktivitäten bereits abgeschlossen
- alle Testfälle spezifiziert
- alle benötigten Testrahmen vorhanden
- alle benötigten Testwerkzeuge zum Einsatz bereit²⁵

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: W-Modell nach Spillner²⁶

Das zweite „V“ definiert den eigentlichen Testprozess. Im Idealfall müssen hier nur noch die vorbereiteten Testfälle zur Ausführung gebracht werden. Der Test geschieht in einer Schleife aus Testausführung, Vergleich, Bewertung und Berichterstattung auf der einen Seite und debugging, ändern und erneut testen auf der anderen. Hierbei müssen Test und Debug strikt voneinander getrennt werden. In allen Phasen finden Tests statt, so dass der Abnahmetest kaum Fehler enthalten sollte.²⁷

2.5 Agile Programming mit XP

Die Agile Methode Software zu entwickeln gewinnt in der Praxis zunehmend an Bedeutung. Ein Problem in der Softwareentwicklung heute ist, dass Kundenwünsche bei der Anforderungserstellung nicht immer vollständig enthalten sind oder sich Änderungswünsche im Software Lifecycle erst spät ergeben. Das erfordert hohe Flexibilität bei der Entwicklung. Auch bedingt durch den Anspruch immer kürzere Releasezyklen zu realisieren, entsteht großer Zeitdruck in Softwareprojekten. Es werden frühe Zwischenergebnisse erwartet. Dabei bleibt die Forderung nach Qualität der Software hoch.²⁸

Im Jahr 2001 entstand die „Agile Alliance“.²⁹ Die Mitglieder der Alliance stellten ein Manifest zusammen um den Softwareentwicklungsprozess zu verbessern.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Manifesto for Agile Software Development.³⁰

Nach den Prinzipien der Agilen Programmierung³¹ liegt das Ziel darin, Software früh und häufig zu liefern, einen einfachen Prozess anzustreben, ohne den Aufwand einer regelmäßigen Überprüfung und zur Verbesserung der eigenen Effektivität. Face-to- Face-Kommunikation zum Kunden und spätere Änderungswünsche sind willkommen.

Eine Methode der Agilen Programmierung ist eXtreme programming (XP). Basierend auf seiner Idee bessere Software zu entwickeln beginnt Kent Beck 1996 ein Projekt bei der Daimler Chrysler AG. Das Ergebnis ist XP.³²

Beim XP ist ein wesentlicher Aspekt, dass der Kunde möglichst während der gesamten Entwicklung vor Ort ist. Der Kunde formuliert die Anforderungen anhand von Benutzerbeispielen.³³ Durch die intensive Kommunikation wird bei Entwicklern und dem Kunden ein genaues Verständnis der Anforderungen erreicht.³⁴

Ein weiterer Bestandteil des eXtreme programming ist, dass jeweils zwei Programmierer zusammen arbeiten (pair programming). Einer der beiden Entwickler programmiert und der andere beobachtet, unterstützt, hinterfragt und kritisiert konstruktiv. In der Wirkung wird durch das Vier-Augen-Prinzip und gegenseitige Überwachung die Qualität der Software verbessert. Gleichzeitig wird durch die Paarbildung, insbesondere wenn diese wechselt, die Erfahrung der Entwickler ausgebaut.³⁵

Bei der Agilen Softwareentwicklung kommen in der Hauptsache zwei Testphasen zur Anwendung, der Modul oder Komponententest (vgl. Kap. 4.2.1) und der Abnahmetest (vgl. Kap. 4.2.4). Da iterativ entwickelt wird (d.h. es werden immer kleinste Einheiten fertig gestellt) sind weitere Tests in der Regel nicht erforderlich. Auch beim Komponententest werden durch das pair programming nur wenige Fehler gefunden.

Auf den ersten Blick sind die Personalkosten beim pair programming um 100% erhöht. Allerdings stehen dem nach Zeller³⁶ eine um 40 - 50% reduzierte Codierungszeit und 16,3% weniger nicht bestandene Tests entgegen, die ebenfalls kostenintensiv bearbeitet werden müssen.

3 Software-Qualität

3.1 Software-Qualitätssicherung

Es wird immer wieder deutlich, dass es wenig gesundes Misstrauen gegenüber der Entwicklung eines komplexen Softwaresystems gibt.³⁷ Häufig werden Anforderungen oder der Zeitplan des „Going live“ erst in späten Phasen eines Projektes nachgeliefert oder geändert. Diese Vorgehensweise birgt sowohl Vorteile für den Besteller als auch Risiken für Qualität des Endproduktes. Auch werden Anwender und Tester vielfach erst spät in das Projekt einbezogen und schlecht geschult, insbesondere wenn Tests erst am Ende der Projektphase ausgeführt werden.

In der Praxis findet sich häufig nicht nur einer dieser Gründe, sondern eine Verkettung von Ursachen, die durch mangelhafte Qualitätssicherung und falsche Vorgehensweise in Softwareprojekten viel zu spät erkannt werden.

Softwarequalität ist keine feststehende Größe, sondern ist relativ zu den Erwartungen zu sehen. Das bedeutet, es muss Qualitätsvorgaben geben, an denen die Qualität zu messen ist.³⁸ Um diese Anforderungen zu definieren und im Entwicklungsprozess zu überwachen, müssen Maßnahmen getroffen werden. Diese Maßnahmen werden Qualitätssicherung (engl. Quality assurance) genannt.

„Qualitätssicherung ist die Gesamtheit aller geplanten und systematischen Aktionen, die erforderlich sind, um in ausreichendem Maße das Vertrauen darin zu vermitteln, dass ein Produkt oder eine Dienstleistung den festgelegten Qualitätsanforderungen entspricht.“³⁹

Qualitätssicherung kann in drei wesentliche Bereiche eingeteilt werden:⁴⁰

- Vorbeugemaßnahmen sollen durch z.B. Dokumentationsrichtlinien, spezielle Methoden und Techniken einen Mangel an Qualität verhindern.
- Prüf- und Beurteilungsmaßnahmen sollen durch z.B. Tests, Inspektionen, Analysen den Mangel an Qualität entdecken.
-Korrekturmaßnahmen sollen z.B. Fehler die beim Testen entdeckt wurden beheben und somit die erforderliche Qualität herstellen.

Ziele der Maßnahmen:⁴¹

-Messpunkte und -größen über die Qualität der Prozesse werden erstellt (Normierung).
-Mitarbeitern ist klar welchen Ansprüchen und Normen seine Arbeit zu entsprechen hat.
- Einer unabhängigen Partei ist es möglich, die Produkte und Dienstleistungen mittels der erstellten Normen zu prüfen.
- Das Management kann bei festgestellten Mängeln an Produkten feststellen, welche Ursache der Mangel hat und wie er in Zukunft vermieden werden kann.

3.2 Messbarkeit von Software-Qualität

3.2.1 Qualitätsmerkmale nach ISO 9126

Woran erkennt man die Qualität einer Software und wodurch lässt sich Softwarequalität beschreiben? Die hier beschriebenen Qualitätsmerkmale sind um Erläuterungen nach Balzert⁴² erweitert und in Anlehnung an ISO 9126⁴³ dargestellt:

Funktionalität

- Funktionen mit festgelegten Eigenschaften erfüllen die definierten Anforderungen
-Richtigkeit
-Liefern der richtigen oder vereinbarten Ergebnisse oder Wirkungen
- Angemessenheit
-Interoperabilität
-Fähigkeit, mit vorgegebenen Systemen zusammenzuwirken
-Ordnungsmäßigkeit
-Erfüllung von anwendungsspezifischen Normen, Vereinbarungen, gesetzlichen Bestimmungen und ähnlichen Vorschriften
-Sicherheit
-Fähigkeit, unberechtigten Zugriff sowohl versehentlich als auch vorsätzlich, auf Programme und Daten zu verhindern

Zuverlässigkeit

- Fähigkeit der Software, ihr Leistungsniveau unter festgelegten Bedingungen über einen festgelegten Zeitraum zu bewahren
-Reife
- Geringe Versagenshäufigkeit durch Fehlzustände
- Fehlertoleranz
- Fähigkeit, ein spezifiziertes Leistungsniveau bei Softwarefehlern oder Nicht- Einhaltung ihrer spezifizierten Schnittstelle zu bewahren
-Wiederherstellbarkeit
- Fähigkeit, bei einem Versagen das Leistungsniveau wiederherzustellen und die direkt betroffenen Daten wiederzugewinnen

Benutzbarkeit

- Verständlichkeit
-Aufwand für den Benutzer, das Konzept und die Anwendung zu verstehen
- Bedienbarkeit
- Aufwand für den Benutzer, die Anwendung zu bedienen

Effizienz

- Verhältnis zwischen dem Leistungsniveau der Software und dem Umfang der eingesetzten Betriebsmittel unter festgelegten Bedingungen
-Zeitverhalten
-Antwort- und Verarbeitungszeiten sowie Durchsatz bei der Funktionsausfüh- rung
-Verbrauchsverhalten
-Anzahl und Dauer der benötigten Betriebsmittel für die Erfüllung der Funktionen

Änderbarkeit

-Aufwand, der zur Durchführung vorgegebener Änderungen notwendig ist
- Analysierbarkeit
-Aufwand, um Mängel oder Ursachen von Versagen zu diagnostizieren oder um änderungsbedürftige Teile zu bestimmen
-Modifizierbarkeit
-Aufwand zur Ausführung von Verbesserungen, zur Fehlerbeseitigung oder Anpassung an Umgebungsänderungen
- Stabilität
-Testbarkeit

Übertragbarkeit

- Eignung der Software, von einer Umgebung in eine (Hard- oder Software) andere übertragen zu werden
-Installierbarkeit
- Konformität
-Grad, in dem die Software Normen oder Vereinbarungen zur Übertragbarkeit erfüllt
-Austauschbarkeit
- Möglichkeit, diese Software anstelle einer spezifizierten anderen in der Umge- bung jener Software zu verwenden sowie der dafür notwendige Aufwand

3.2.2 Metriken

Ursprünglich stammt das Wort Metrik aus dem griechischen und bedeutet „Kunst des Messens“. In der Mathematik sind Metriken Funktionen zur Abstandsmessung zweier Punkte im Vektorraum. Obgleich der Begriff im Zusammenhang mit der Messung von Softwarequalität nicht korrekt ist, wird er zur Maßbestimmung in der Praxis verwen- det.⁴⁴

Metriken im Softwareengineering sind hilfreich zum Messen von Qualitätsindikatoren. Dadurch wiederum können Merkmale oder Teilmerkmale mess- und bewertbar ge- macht werden.⁴⁵ Das heißt, dass durch Metriken bestimmte Eigenschaften oder Quali- tätsmerkmale nachweisbar gemacht werden können.⁴⁶ Diese Merkmale und Teilmerk- male werden in so genannten Factor-Criteria-Metrics (FCM)-Modellen zusammenge- fasst (vgl. Abb. 5).

Q-Merkmale beschreiben benutzerorientierte Qualitätsmerkmale, während Q-Teil- merkmale feinere Abstufungen derselben darstellen. Mehrere Qualitätsmerkmale können dabei gemeinsame Teilmerkmale besitzen. Durch Q-Indikatoren können Teilmerkmale messbar gemacht werden.⁴⁷

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: FCM-Modell nach Balzert⁴⁸

Metriken kommen unter anderem auch im Softwaretest zur Anwendung. Sie dienen dem Tester oder Testmanager als Hilfe zu entscheiden, ob die Software ausreichend zuverlässig ist, als Testendekriterium, oder zur Messung des Testfortschritts. Beispiele für Testmetriken sind: Testaufwand, Testzeit in Stunden, Testüberdeckung, Fehler- dichte, Zahl der gefundenen Fehler und Zahl der geschätzten bzw. eingepflanzten Fehler.⁴⁹

Auch die Qualität des Softwaretests und der ausgewählten Testfälle lässt sich durch Metriken nachweisen, was wiederum Auswirkungen auf die Produktqualität hat und den Umfang der Tests auf ein wirtschaftlich verträgliches Maß reduziert.⁵⁰ Durch die Anwendung von Metriken werden dem Tester Maße zur besseren Planung und Steue- rung der jeweiligen Testphase gegeben. Wird z.B. durch eine Metrik errechnet, dass ein Programm überwiegend aus Anweisungen besteht, kann infolgedessen das Test- verfahren schwerpunktmäßig auf die Überprüfung von Anweisungen ausgerichtet wer- den.

3.3 Qualität und Kosten

Es wird häufig der Fehler gemacht, dass am Ende der Entwicklung angefangen wird sich über Tests Gedanken zu machen und Prüfungen weitgehend aus Kostengründen vernachlässigt werden. Qualität entsteht während der Entwicklung und lässt sich nach Einführung nur kostenintensiv einbauen.⁵¹ Wie im Kapitel 2.2.3 zum W-Modell beschrieben, sollten die Testaktivitäten beginnen, indem die Testfälle bereits während oder nach der Erstellung des Fachkonzeptes ermittelt werden. Softwarefehler kosten Geld und je später sie erkannt werden, umso mehr Geld kosten sie.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Fehlerkosten nach Boehm⁵²

Durch Qualitätssicherungsmaßnahmen entstehen, ebenso wie durch das Fehlen von Qualität, nicht unerhebliche Kosten. Softwarequalität ist demnach eine Relation aus Kosten und Qualität.

Nach Juran⁵³ ist der Versuch, höchstmögliche Softwarequalität zu erreichen, wirtschaftlich nicht sinnvoll. Der Schnittpunkt von Vorbeuge-, Prüf- und Bewertungskosten mit Fehlerfolgekosten in Abbildung 7 bildet den Grenznutzen von Softwaretests. In diesem Punkt sind Fehlervermeidungs- und Fehlerfolgekosten neutral und es ist ein Minimum der Qualitätskosten erreicht.

[...]

---

¹ Vgl. WEEKLY 2004.

² Vgl. HEISE 2004.

³ Vgl. OMP 2004.

⁴ Vgl. SPILLNER 2004 S. 9.

⁵ Vgl. POL et al 2002 S. 1 ff.

⁶ Vgl. LIGGES 1993 S. 23.

⁷ SPILLNER 2003 (2) S. 6.

⁸ Vgl. SUTHERLAND o.J.

⁹ Vgl. ROYCE 1970.

¹⁰ Vgl. SPILLNER o.J. S. 1.

¹¹ Vgl. BALZERT 1998 (1) S.99.

¹² Vgl. REICHWALD 2003 S. 15.

¹³ Vgl. THALLER 2002.

¹⁴ Vgl. ZÖLLER-GREER S. 14.

¹⁵ Vgl. BOEHM 1979 S. 711 ff.

¹⁶ Vgl. ZÖLLER-GREER S. 39.

¹⁷ Vgl. ZÖLLER-GREER S. 41.

¹⁸ Vgl. O.V. 2002.

¹⁹ Vgl. REICHWALD 2003 S. 25.

²⁰ CASE (Computer-Aided-Software-Engineering) Tools sind Computerprogramme, welche bei der Entwicklung von Software Aufgaben übernehmen können.

²¹ Vgl. REICHWALD 2003 S .26.

²² Vgl. SPILLNER 2001 S. 9.

²³ Vgl. SPILLNER o.J. S. 1.

²⁴ Vgl. SPILLNER 2003 (2) S. 12 ff.

²⁵ Vgl. SPILLNER 2003 (2) S. 19.

²⁶ Vgl. SPILLNER 2001 S. 15.

²⁷ Vgl. SPILLNER o.J. S. 2.

²⁸ Vgl. GUNDEL o.J. S. 3.

²⁹ Vgl. http://www.agilealliance.com.

³⁰ Vgl. BECK et al 2004 (2).

³¹ Vgl. BECK et al 2004 (1).

³² Vgl. WELLS 1999.

³³ Vgl. LUX 2004 S. 10.

³⁴ Vgl. MELLIS o.J. S. 12.

³⁵ Vgl. SCHARBERT 2004 S. 17.

³⁶ Vgl. ZELLER o.J. (2).

³⁷ Vgl. WALL 2001.

³⁸ Vgl. WALL 2001 S. 13.

³⁹ POL et al 2002 S. 12.

⁴⁰ Vgl. POL et al 2002 S. 12.

⁴¹ Vgl. POL et al 2002 S. 13.

⁴² Vgl. BALZERT 1998 (1) S. 259 ff.

⁴³ Vgl. DIN 9126.

⁴⁴ Vgl. LIGGES 2002 S. 212.

⁴⁵ Vgl. BALZERT 1998 (2) S. 4.

⁴⁶ Vgl. FURT 2002 S. 3.

⁴⁷ Vgl. MÖLLER 2004 S. 9.

⁴⁸ Vgl. BALZERT 1998 (2) S. 5.

⁴⁹ Vgl. SNEED 2002 S. 264.

⁵⁰ Vgl. FURT 2002 S. 3.

⁵¹ Vgl. GRUHN 2004.

⁵² Vgl. BOEHM 1981 S..40.

⁵³ Vgl. JURAN 1999 S. 8.22.

• Universidad: University of Applied Sciences Essen
• Calificación: 1,3
• Autor: Dipl. Wirtsch. Inform. Markus Rasing (Autor)
• Año de publicación: 2005
• Páginas: 71
• No. de catálogo: V79527
• ISBN (Ebook): 9783640185504
• Idioma: Alemán
• Etiqueta: Kostentreiber, Softwarequalität, Optimierung, Testmanagement, Testprozessen