Mit Fehlerkennzahlen Software-Entwicklungsprozesse verbessern - Erfahrungen bei der IDG -

Transkript

1 Mit Fehlerkennzahlen Software-Entwicklungsprozesse verbessern - - Rainer Paasche (IDG) Oral Avcı (SQS) Universität zu Köln Lehrstuhl für Wirtschaftsinformatik, Prof. Dr. W. Mellis SQS Software Quality Systems AG Informationsverarbeitung und Dienstleistungen GmbH

2 Agenda Mit Fehlerkennzahlen Software-Entwicklungsprozesse verbessern Darstellung des Verfahrens zur Fehleranalyse Verfahren zur Fehleranalyse in der praktischen Anwendung: 2

3 Verfahren zur Fehleranalyse -Darstellung - 3

4 Wie können Fehler vermieden oder zumindest früher entdeckt werden? Ziel: Fehler vermeiden Ziel: Fehler früher entdecken Mängel im Prozess der Entwicklungsaufgaben beheben. Mängel im Prozess der Qualitätssicherung beheben. 4

5 Prozessmängel in Entwicklungsaufgaben verursachen systematisch Fehler mit gleichen Merkmalen. Prozessmangel A verursacht Fehler Prozessmangel B verursacht Prozessmangel C verursacht 5

6 Fehler auswerten, um Mängel im Prozess zu identifizieren. erlauben Rückschlüsse über Fehler Prozessmängel in Entwicklungsaufgaben verursachen Ursache Wirkung 6

7 Verfahren zur Identifikation von Mängeln im Prozess Schritt 1 Erfassung von Fehlern mit einer semantischen Fehlerklassifikation. (Entwicklungs- und Produktionsfehler) Schritt 2 Auswertung der Fehler mit dem Ziel, Fehlermuster zu erkennen. Schritt 3 Welche Mängel im Prozess führen zu den zwei oder drei wichtigsten Fehlermustern? 7

8 Welche Merkmale eines Fehlers unterstützen die Ursachenanalyse? Ein Fehler wurde entdeckt: Aktivität: In welcher Prüf- oder Testaktivität wurde der Fehler entdeckt? Prüf- oder Testkriterium: Welche Bedingungen beziehungsweise Kriterien haben dazugeführt, dass der Fehler entdeckt wurde? Auswirkung: Welches Fehlverhalten verursacht bzw. kann der Fehler verursachen? Ein Fehler wurde behoben: Gegenstand der Änderung: Was musste geändert werden, um den Fehler zu beheben? Art der Änderung: Wie wurde der Fehler behoben? Ursprung: Woher stammt der fehlerbehaftete Teil des Arbeitsergebnisses ursprüngich? Vorgeschichte: Welche Vorgeschichte weist der Fehler aus? 8

9 Ausprägungen für das Merkmal Prüf- oder Test-Aktivität sind projektspezifisch. Entwurfsdokumente prüfen: z. B. Review, Inspektion Code prüfen: z.b. Review, Inspektion Software testen: z. B. Modultest, Funktionstest, Systemtest 9

10 Ausprägungen für das Merkmal Gegenstand der Änderung sind vorgegeben (Auswahl). Zuweisung/Initialisierung Wenige Codezeilen wurden geändert: eine Zuweisung von Werten, die Initialisierung von Kontrollstrukturen oder Datenstrukturen war fehlerhaft. Bedingung Die Überprüfung von Parametern oder Daten in Bedingungen war fehlerhaft. Algorithmus Ein Algorithmus oder eine lokale Datenstrukturen wurde geändert, weil sie fehlerhaft waren. Funktion Ein Funktionsfehler beeinträchtigt eine vom Kunden erwartete Funktion, Benutzerschnittstellen, externe Programmierschnittstellen der Software (API), Schnittstellen mit der Hardwarearchitektur oder globale Datenstrukturen. 10

11 Ausprägungen für das Merkmal Art der Änderung sind vorgegeben. eingefügt: Etwas wurde eingefügt, weil es zuvor fehlte. modifiziert: Etwas Bestehendes wurde modifiziert, weil es falsch war. entfernt: Etwas wurde entfernt, weil es irrelevant war. 11

12 Anzahl Fehler Mit Fehlerkennzahlen Software-Entwicklungsprozesse verbessern Kann man aus der Entwicklung der Fehlerkurve Handlungsbedarf ableiten? 100,00% 90,00% 80,00% 70,00% 60,00% 50,00% 40,00% 30,00% 20,00% 10,00% 0,00% kumulative Entwicklung der Fehleranzahl Periode 1 Periode 2 Periode

13 Die prozentuale Zunahme der Funktionsfehler (Gegenstand der Änderung) in der Periode 2 zeigt Handlungsbedarf. Prozentualer Anteil Funktionsfehler 70% 60% 50% 40% 30% 20% 10% 0% 60% 45% 20% Periode 1 Periode 2 Periode 3 13

14 Aus der Fehleranalyse Handlungsmaßnahmen ableiten Aktivität Prüf- oder Testkriterium Auswirkung Gegenstand der Änderung Art der Änderung Ursprung Vorgeschichte 14

15 Zu welchem Zweck kann das Verfahren zur Fehleranalyse eingesetzt werden? Bewertung der Prüf- und Testaktivitäten hinsichtlich ihrer Effektivität (im laufenden Projekt oder nach Abschluss). Bestimmung der Qualität der Software (Risikobewertung). Steuerung der Prüf- und Testaktivitäten im laufenden Projekt. Unterstützung der Ursachenanalyse. Bewertung der Effektivität von Verbesserungsmaßnahmen. Aufzeigen von Verbesserungspotenzialen in Entwicklungsaufgaben (im laufenden Projekt oder nach Abschluss). Steuerung der Beziehung zwischen Auftraggeber und nehmer. Definition von quantitativen Freigabekriterien für einzelne Teststufen und für die Auslieferung der Software. 15

16 Verfahren zur Fehleranalyse: Voraussetzungen und Aufwand Voraussetzungen für die Einführung des Verfahrens: Fehlerverfolgung ist Bestandteil des Entwicklungsprozesses. Fehlerverfolgung wird durch ein Software-Werkzeug unterstützt. einmaliger Aufwand: Anpassung des Software-Werkzeugs zur Fehlerverfolgung. Schulung von Projektmitarbeitern. regelmäßiger Aufwand: Fehlererfassung nach dem Klassifikationsschema dauert ca. 3 Minuten pro Fehler. Fehlerauswertung kann automatisiert werden ( nahezu kein Aufwand). 2 Sitzungen an wichtigen Meilensteinen: Analyse von Fehlermustern und Ursachenanalyse. (2 * 2 Stunden) 16

17 Verfahren zur Fehleranalyse in der praktischen Anwendung

18 Ausgangssituation Herausforderungen Der Release-Zyklus von entwickelten Softwareprodukten soll erhöht werden (bei gleich bleibendem Umfang der Releases). Deutliche Reduktion der Anzahl ausgelieferter Implementierungsfehler. Verbesserung der Anforderungsanalyse und des Testmanagements. 18

19 Pilotprojekt: Nachträgliche Fehlerklassifikation für zwei abgeschlossene Release-Entwicklungen einer Software. Release A Umfang in Codeanweisungen absolut: 1,4 Mil. Anweisungen relativ: Anweisungen Release B Umfang in Codeanweisungen absolut: 1,5 Mil. Anweisungen relativ: Anweisungen Zeiträume Entwicklung: ca. 2,5 Monate Betrieb: ca. 5 Monate Zeiträume Entwicklung: ca. 5 Monate Betrieb: ca. 4,5 Monate 19

20 Durchgeführte Testaktivitäten (Auswahl) Systemtest ca Testfälle, von denen 50% neu sind. alte und neue Funktionen werden getestet. ausschließlich automatischer Funktionstest. Systemtest II automatischer Funktionstest mit ca Testfällen. (Schwerpunkt: Funktionen, die häufig genutzt werden.) Parallel führen Fachbereiche mit erfahrenen Anwendern manuelle Tests durch, die einzelne Funktionen gemäß ihrem Aufgabenschwerpunkt testen. 20

21 Durchgeführte Testaktivitäten (Auswahl) - Fortsetzung Abnahmetest automatischer Funktionstest: alle Testfälle aus beiden Systemtests (ca Stück) werden nochmals durchgeführt. Fachbereichstest: manuelle Tests zuvor fehlerhafter und korrigierter Funktionen durch erfahrene Anwender. 21

22 Vereinfachte Anwendungsarchitektur der Software zentrales Verwaltungssystem (zvws) VWS-Anwendungskern (kurz VWS) Zentralsysteme In-/Exkasso Subsystem Technik Produktdaten Partner Briefschreibung Bestandsdaten Batch-Läufe 22

23 Aufteilung der Fehler nach Komponenten Schnittstelle zu Nachbarsystemen 7% unbekannt 1% Release A Subsystem Technik (SST) 14% Verwaltungssystem 38% Schnittstelle zu Nachbarsystemen 6% unbekannt 3% Release B Produktdaten und Plausibilitätsbedingungen 40% Subsystem Technik (SST) 27% Verwaltungssystem 41% Produktdaten und Plausibilitätsbedingungen 23% 23

24 Release A und B weisen viele Zuweisungs- und Bedingungsfehler aus. Release A 24

25 Bedingungsfehler in Release A und B: Aufteilung nach Komponenten Schnittstellen 10% Release A Produktdaten 36% VWS 54% Schnittstellen 8% Release B Produktdaten 40% VWS 52% 25

26 Entwicklung der Bedingungsfehler in der Komponente VWS für Release A Abnahmetest Systemtest II SOLL IST 26

27 Bedingungsfehler in der Komponente VWS für Release A und B: Art der Änderung Release A Release B 27

28 Fehlerauswertung ergibt u.a. folgendes Fehlermuster 1. Die Komponente Verwaltungssystem-Anwendungskern enthält viele Fehler. 2. Die Komponente Verwaltungssystem-Anwendungskern enthält viele Bedingungsfehler. 3. Die Bedingungsfehler in der Komponente Verwaltungssystem- Anwendungskern werden erst in späten Testaktivitäten oder sogar erst im Betrieb entdeckt. 4. Die Bedingungsfehler in der Komponente Verwaltungssystem- Anwendungskern werden überwiegend korrigiert, in dem etwas eingefügt wird. Folglich fehlte zuvor etwas. 28

29 Ergebnis der Ursachenanalyse für Bedingungsfehler in der Komponente VWS (Auszug) 29

30 Maßnahmen und Ausblick Im Projekt Ableitung von Verbesserungsmaßnahmen für identifizierte Fehlermuster. Die Fehlerverfolgung wurde um das Verfahren zur Fehleranalyse erweitert bzw. angepasst. Analyse der Testfälle, Zuordnung zu Testkriterien und damit Zuordnung von Fehlern zu Testkriterien. Fehlerauswertung wurde vervollständigt. Der Release-Prozess wurde modifiziert (Entwicklung, insbes. Test). Projektübergreifend Fehleranalyse wird als Verfahren in der Projektdurchführung ab 2007 unternehmensweit eingesetzt. 30

31 Haben Sie Fragen? Kontakt: Oral Avcι SQS Software Quality Systems AG Stollwerckstraße Köln Fon: +49 (0) / Fax: +49 (0) / oral.avci@sqs.de Internet: Internet: Rainer Paasche Informationsverarbeitung und Dienstleistungen GmbH Pohligstraße Köln Fon: +49 (0) 221 / Fax: +49 (0) 221 / rainer_paasche@idg.de Internet: 31