Softwaretechnik- Praktikum: 4. Vorlesung

Softwaretechnik- Praktikum: 4. Vorlesung Jun.-Prof Prof.. Dr. Holger Giese Raum E 3.165 Tel. 60-3321 Email: hg@upb.de

Übersicht I Einleitung II Ergänzungen zur Software-Entwicklung III Software-Management IV Software-Qualitätssicherung V Zusammenfassung V4-2

Softwaretechnikpraktikum: IV Software- Qualitätssicherung Jun.-Prof Prof.. Dr. Holger Giese Raum E 3.165 Tel. 60-3321 Email: hg@upb.de

IV Software-Qualitätssicherung IV.1 Grundlagen IV.2 Analytisches Qualitätsmanagement IV.2.1 Analysierende Verfahren IV.2.2 Testende Verfahren IV.3 Konstruktives Qualitätsmanagement IV.5 Prozessqualität IV.6 Diskussion & Zusammenfassung IV.7 Literaturhinweise V4-4

IV.1 Grundlagen 5 Ansätze des Qualitätsbegriffes ([Balzert1998]): Transzendenter Ansatz: universell, absolut, einzigartig und vollkommen Produktbezogener Ansatz (Entwicklung): messbare Eigenschaft des Produkts Benutzerbezogener Ansatz (Marketing/Vertrieb): Sicht des Produktbenutzer Prozessbezogener Ansatz (Fertigung): richtige Erstellung eines Produktes Kosten/Nutzen-bezogener Ansatz (Finanzen): Funktion von Kosten und Nutzen. Warum nicht: Qualität = Anforderungen erfüllen Benutzersicht (Effizienz, ) vs. Entwicklersicht (Wartbarkeit, ); häufig unvollständig und inkonsistent Anforderungen (Teil des Entwicklung!) Fragen Was ist Qualität und wie kann man sie messen? Wie kann man systematisch Qualität erzeugen? V4-5

Was ist Qualität und wie kann man sie messen? Qualität (nach DIN 55350, Teil 11) Gesamtheit von Eigenschaften und Merkmalen eines Produkts oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse bezieht Software-Qualität (nach ISO 9126) Gesamtheit der Merkmale und Merkmalswerte eines Software-Produkts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen V4-6

Qualitätsmodell Qualitätsmodell Der allgemeine Qualitätsbegriff wird durch Ableiten von Unterbegriffen operationalisiert Qualitätsmerkmale (factors) Satz von Eigenschaften, anhand dessen die Qualität eines Produkts beurteilt wird Verfeinerung durch Teilmerkmale bzw. Kriterien Teilkriterien werden durch Qualitätsindikatoren evaluiert Qualitätsindikatoren bzw. Metriken Mess- und bewertbar gemachte Teilmerkmale Beispiele: Pfadlänge, modularer Aufbau, Programmstruktur, Kommentar. [Balzert1998] V4-7

Beispiel: (ISO 9126) Qualitätsmerkmale: Funktionalität Zuverlässigkeit Benutzbarkeit Effizienz Änderbarkeit Übertragbarkeit [ISO 9126] V4-8

Qualitätsmerkmale [ISO 9126] (1/6) Funktionalität: Vorhandensein von Funktionen mit festgelegten Eigenschaften, die die definierten Anforderungen erfüllen Richtigkeit: Liefern der richtigen oder vereinbarten Ergebnisse oder Wirkungen, z.b. die benötigte Genauigkeit von berechneten Werten Angemessenheit: Eignung der Funktionen für spezifizierte Aufgaben, z.b. aufgabenorientierte Zusammensetzung von Funktionen aus Teilfunktionen. 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. V4-9

Qualitätsmerkmale [ISO 9126] (2/6) 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 Software-Fehlern oder Nicht- Einhaltung ihrer spezifizierten Schnittstelle zu bewahren Wiederherstellbarkeit: Fähigkeit, bei einem Versagen das Leistungsniveau wiederherzustellen und die direkt betroffenen Daten wiederzugewinnen. V4-10

Qualitätsmerkmale [ISO 9126] (3/6) Benutzbarkeit: Aufwand, der zur Benutzung erforderlich ist, und individuelle Beurteilung der Benutzung durch eine festgelegte oder vorausgesetzte Benutzergruppe Verständlichkeit: Aufwand für den Benutzer, das Konzept und die Anwendung zu verstehen Erlernbarkeit: Aufwand für den Benutzer, die Anwendung zu erlernen (z.b. Bedienung, Ein-, Ausgabe) Bedienbarkeit: Aufwand für den Benutzer, die Anwendung zu bedienen. V4-11

Qualitätsmerkmale [ISO 9126] (4/6) 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ührung Verbrauchsverhalten: Anzahl und Dauer der benötigten Betriebsmittel für die Erfüllung der Funktionen. V4-12

Qualitätsmerkmale [ISO 9126] (5/6) Änderbarkeit: Aufwand, der zur Durchführung vorgegebener Änderungen notwendig ist Änderungen: Korrekturen, Verbesserungen oder Anpassungen an Änderungen der Umgebung, der Anforderungen & der funktionalen Spezifikationen 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: Wahrscheinlichkeit des Auftretens unerwarteter Wirkungen von Änderungen. Prüfbarkeit: Aufwand, der zur Prüfung der geänderten Software notwendig ist V4-13

Qualitätsmerkmale [ISO 9126] (6/6) Übertragbarkeit: Eignung der Software, von einer Umgebung in eine andere übertragen zu werden (Umgebung kann organisatorische Umgebung, Hardwareoder Software-Umgebung einschließen.) Anpassbarkeit: Software an verschiedene, festgelegte Umgebungen anpassen Installierbarkeit: Aufwand, der zum Installieren der Software in einer festgelegten Umgebung notwendig ist 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 Umgebung jener Software zu verwenden, sowie der dafür notwendige Aufwand. V4-14

Wie kann man Qualität erzeugen? - Kosten der Software-Qualität - [Galin2004] Kosten der Software- Qualität Kosten der Qualitätssicherung Kosten für Fehlerbehebung Kosten für präventive Maßnahmen Kosten für Qualitätssicherung Interne Kosten für Fehlerbehebung Externe Kosten für Fehlerbehebung V4-15

Balance zwischen Kosten und Qualität [Galin2004] Kosten Minimale Gesamtkosten bzgl. Qualität Gesamt- Kosten bzgl. Qualität Kosten für Fehlerbehebung niedrig Optimum Kosten der Qualitätssicherung hoch Software-Qualität V4-16

Prinzipien (1) Analytische & Konstruktive Maßnahmen (2) Qualität muss geplant werden (3) Produkt- & Prozessqualität (4) Frühzeitige Maßnahmen / kontinuierliche Qualitätssicherung (5) Unabhängige Qualitätssicherung (6) Quantitative Qualitätssicherung (Metriken) V4-17

(1) Analytische vs. Konstruktive Maßnahmen Analytische Qualitätsmanagement/Maßnahmen Untersuchen das fertige Produkt, ob es bezüglich bestimmter Qualitätsmerkmale die gewünschte Stufe erreicht Beispiel: Tests sind eine analytische Maßnahme zur Qualitätssicherung, die ggf. die Qualität sicherstellen aber keine Qualität erzeugen (sie können nur schlechte Qualität aussortieren) Konstruktive Qualitätsmanagement/Maßnahmen Sorgen während des Erstellungsprozesses dafür, dass direkt bei der Entwicklung die benötigten Qualitätsmerkmale möglichst erfüllt werden V4-18

Analytische Maßnahmen Analysierende Verfahren (Kapitel IV.2.1) Überprüfen die Qualität, ohne das Produkt auszuführen (insbes. Bei Dokumenten möglich) Beispiele: Statische Analyse, Programmverifikation, Reviews Testende Verfahren (Kapitel IV.2.2) Führen das Produkt (das Programm) zum Überprüfen der Qualität aus Beispiele: dynamischer Test, Bemerkung: Der Übergang zwischen testenden und analysierenden Verfahren ist fließend. Beispiele: Simulation, Modelchecking, Slicing, V4-19

(2) Qualität muss geplant werden Qualitätsmanagement (QM): Es umfasst alle Maßnahmen und Tätigkeiten, Qualität zu erzeugen Qualitätsplanung: Welches Teilprodukt (Dokument) muss wann, wie und von wem bezüglich welcher Qualitätsanforderungen überprüft werden! Qualitätslenkung: Arbeitstechniken und Tätigkeiten, die zur Erfüllung der Qualitätsanforderungen angewendet werden (dies sind in erster Linie konstruktive Maßnahmen) Qualitätssicherung (QS): Maßnahmen und Tätigkeiten, die Vertrauen schaffen, dass das Produkt die Qualitätsanforderungen erfüllt. V4-20

(3) Produkt und Prozess Produktorientiertes QM: Qualität unmittelbar am Produkt gewährleisten ( QS). Prozessorientiertes QM: Qualität des Prozesses gewährleistet, dass auch das durch den Prozess erzeugte Produkt die nötige Qualität besitzt (siehe Kapitel IV.5) Erfahrung zeigt: Rein produktorientiertes QM hat sich für Softwareprodukte als sehr unzweckmäßig erwiesen. V4-21

(4) Frühzeitige Maßnahmen Beobachtung: Je früher ein Fehler gefunden und beseitigt wird, desto weniger Folgekosten verursacht er. Schlussfolgerung: Man sollte versuchen Fehler möglichst früh zu entdecken! [Pressman2004] V4-22

Fehlerbeseitigung und Zeit Einige Autoren sehen sogar eine Korrelation zwischen Zeit und Defekt-Rate (s. [McConnell 1996]) V4-23

(5) Unabhängige Qualitätssicherung Niemand macht gern das eigene Produkt kaputt ( Psychologie des Testens )! Wer beim Entwickeln einen Fall vergißt, vergißt ihn auch beim Testen. Deshalb sollten QS-Maßnahmen wenn möglich nicht vom Entwickler selbst durchgeführt werden! V4-24

(6) Quantitative Qualitätssicherung Qualitätsindikator: (objektive) Eigenschaft eines Produktes zur Bewertung eines Qualitäts(teil)merkmals Kommentare, Struktur des Codes, Anzahl Methoden, Klassen etc. Qualitätsmaß: Skala und Verfahren zur Bestimmung des Wertes eines Qualitätsindikators (s. Software-Metriken) Qualitätsanforderung: Legt für jedes Qualitätsmerkmal das mind. erreichte Qualitätsmaß (Qualitätsstufe) fest V4-25

IV.2 Analytisches Qualitätsmanagement Analysierende Verfahren: Untersuchung auf konzeptioneller Ebene ohne Ausführung der konkreten Software Auch Modellierung (mathematische Darstellung) Testende Verfahren (Dynamische Analyse): Ausführung der konkreten Software oder von Teilen, um Abweichung von erwarteten Verhalten zu identifizieren V4-26

Verfahren und Phasen der Entwicklung Phase Testen Analyse Modellierung Anforderungsdefinition X X Analyse X X Entwurf X X Implementierung X X Testen (Verifikation) X X X Testen (Validation) X X [Storey1996] V4-27

IV.2.1 Analysierende Verfahren Reviews und Inspections persönliche Review, Walkthroughs, Inspections, Formale technische Reviews, Audit, Statische Codeanalyse Kontrolfluss- und Datenflussanalyse, Symbolische Ausführung, Timinganalysen, Modellierung mit üblichen Notationen Zustandsdiagramme, Datenflussdiagramme, Strukturdiagramme, Modellierung der Umgebung und Simulation der Modelle Modellierung mit formalen Methoden Diskrete Mathematik, Logik, temporal Logiken, Prozessalgebren, Modelchecking, Theorem Proving, Voll- oder semi-automatische Analyse formaler Modelle bzgl. einer formalen Spezifikation V4-28

Reviews und Inspections Mehr oder weniger formales Vorgehen, in dem es darum geht, Fehler, Unklarheiten, Inkonsistenzen (allg. Schwächen) eines Dokumentes aufzudecken oder ein Entscheidung über Annahme oder Ablehnung zu fällen. Dazu wird das Dokument systematisch in einem Team (teilw. unter Beteiligung der Autoren des Dokuments) angesehen und besprochen Menschen und deren Sachverstand und nicht Werkzeuge sind hier das Mittel zur Untersuchung des Dokumentes Das Ergebnis sind identifizierte Probleme oder die Freigabe des Dokumentes (ggf. nach Iteration). V4-29

Aufgabe und Ziele [SWENE] Sicherstellen, dass die Software Die Anforderungen erfüllt, Gegebenen Vorgaben/Standards entspricht und auf gleichartige Art und Weise entwickelt wird Auffinden von Fehlern Früher Mehrere und andere Andere Perspektive hinzufügen Projekte besser handhabbar machen Um neue Risiken zu identifizieren, die das Projekt beeinträchtigen könnten Verbesserung der Kommunikation Ständige Fortbildung aller Beteiligten Software sichtbar machen! V4-30

Die beteiligten Rollen [SWENE] Manager Review Team Entwickler V4-31

Rolle des Entwicklers Problem: Entwickler können in die Schusslinie geraten bzw. werden in die Mangel genommen Entwickler neigen deswegen dazu ihre Ergebnisse zu rechtfertigen statt sie nur zu erklären Psychologie des Reviews Grundregeln: Keine Vorgesetzen anwesend Keine Beurteilung anhand der Reviews Sachliche Gesprächsform Je nach Form des Reviews: Entwickler dabei oder auch nicht Entwickler V4-32

Beteiligung der Manager [SWENE] Bewertung ist eigentlich Aufgabe der Manager Probleme: Technische Kompetenz Bewertung eines Produkts vs. Bewertung einer Person Aktive Beteiligung Nur als Aussenstehender! Als Projekt- oder Teamleiter Allgemeine Kompetenz Post facto Beteiligung Review Material Ggf. Bericht des Review V4-33

Was und Wann? [SWENE] Was/Inhalt: Jedes im Rahmen der Entwicklung enstehende Dokument: Anforderungsdefinition, Analyse, Entwurf, Code, Dokumentation, Prozeduren, Schnittstellen,... Kontrolle der Produktkomplexität (implizit) Wann/Organisation: 2 Stunden Kontrolle der Länge der Reviews Termine für Reviews festlegen 10 Uhr V4-34

Arten der Reviews (1) Persönliche Reviews (2) Walkthroughs (3) Inspections (4) Formale technische Reviews [SWENE] V4-35

(1) Personal Review [SWENE] Eigenschaften Informal Durch den Entwickler selber Implikationen Nicht wirklich objektiv (nur eine Person) Nicht unabhängig (Entwickler hat als Ziel die Entwicklung abzuschließen und nicht Fehler zu finden begrenzter Überprüfungseffekt) Für jeden Entwickler verfügbar V4-36

(2) Walkthroughs [SWENE] Eigenschaften Gewisse Struktur Entwickler präsentiert oder steht zur Information zur Verfügung Implikationen Größeres Publikum kann teilnehmen (Fortbildung) Material muss für eine Sitzung passen Kaum Vorbereitungszeit Nachteil: Es ist schwer zu trennen zwischen Entwickler und Vorführendem Erklärung und Rechtfertigung V4-37

Prozess und Rollen [Galin2004] V4-38

(3) Inspections [SWENE] Eigenschaften Teammitglieder prüfen das Material unabhängig voneinander Das Team und die Entwickler treffen sich um die Ergebnisse zu diskutieren Nur selektierte Aspekte eines Produktes können so betrachtet werden Implikationen Fokus auf wichtige Dinge Wenn man weiß welche das sind Begrenzung des Materials pro Sitzung Signifikanter Aufwand für das Durcharbeiten des Materials V4-39

Prozess und Rollen [Galin2004] V4-40

(4) Formale Technische Reviews Eigenschaften Formalität Fest geplante Termine Fest definierte Abläufe Abschlussbericht notwendig Unabhängiges Team Entwickler ist nicht anwesend Implikationen Höherer Zeitbedarf für die Vorbereitung Es kann weiniger Material in einer Sitzung besprochen werden Produkt muss für sich alleine angenommen oder abgelehnt werden [SWENE] See also: IEEE Standard for Software Reviews and Audits [IEEE 1028, 1988] V4-41

Prozess [Galin2004] Agenda einer Review Sitzung: Eine kurze Präsentation des Dokuments Kommentare Verifikation und Validation der Kommentare, um benötigte Aktivitäten zu bestimmen (Korrekturen, Änderungen oder Ergänzungen). Entscheidung über das Dokument, die den Projektfortschritt bestimmt Post Review Aktivitäten: Bericht erstellen Überwachung der identifizierten Korrekturen, Änderungen oder Ergänzungen V4-42

Vergleich [Galin2004] Eigenschaft Vortreffen Formaler technischer Review Nein Inspection Ja Walkthrough Nein Vorbereitung der Teammitglieder Sitzung Ja - gründlich Ja Ja - gründlich Ja Ja - oberflächlich Ja Nachfolgende Aktivitäten Formales Training de Teilnehmer Checklisten Ja No No Ja Ja Ja Nein Nein Nein Systematische Erfassung von Fehlern Review dokument Nicht formal benötigt Formal design review report Formal benötigt 1) Bericht zu den Ergebnissen der Inspection-Sitzung 2) Zusammenfassung der Inspection-Sitzung Nicht formal benötigt V4-43

Formality of Technical Reviews Formaler technischer Review Inspections Korrektheit Personal Review Walkthroughs Fehler erkennen Team-orientiert verbessern individuelle Initiative V4-44

Effektivität Year Defect detection method Defects per 1000 lines of Test Design Code review inspection maintained % % % code 1977 85 --- 15 0.19 1978 80 5 15 0.13 1979 70 10 20 0.06 1980 60 15 25 0.05 1981 40 30 30 0.04 1982 30 40 30 0.02 [Galin2004] from [Cusomano1991] V4-45

Effizienz Case Study: 700 KLOC Projekt, Echtzeitsystem, über 400 Entwickler, moderne Hochsprache, 3 Jahre Entwicklungsdauer Effizienz = Design Reviews 8.44 Kosten gespart Kosten benötigt Code Reviews 1.38 Zeit für Korrekturen (Stunden): 7.5 Entwurf 6.3 Code 11.6 Testen Testen 0.17 [Collofello&Woodfield1989] V4-46

Fazit [SWENE] sehr effektive und effiziente Technik Low Tech (keine Tools etc.) Leider in der Praxis (und der Universität) viel zu wenig genutzt! V4-47

Weitere Quellen [Ackerman+1989] A.F. Ackerman, L.S. Buchwald, F.H. Lewski, Software inspections: an effective verification process, IEEE Software 6 (May 1989), pp. 31-36 [Bush 1990] M. Bush, Improving software quality: the use of formal inspections at Jet Propulsion laboratory Proceedings of the 12th International Conference on Software Engineering, Nice, France, March 1990, pp. 196-199 [Collofello&Woodfield1989] J.S. Collofello and S. N. Woodfield. Evaluating the Effectiveness of Reliability-Assurance Techniques. Journal of Systems and Software, March 1989. [Cusumano1991] M. A. Cusumano. Japan s Software Factories A Challange to u.s. Management. Oxford University Press, New York, 1991. [Dobbins1998] J. H. Dobbins. Inspections as an up-front quality technique. In G. G. Schulmeyer and J. i. McManus (eds), handbook of Software Quality Assurance, Prentice Hall, Harlow, Essex, UK, 1998. [Doolan1992] Doolan, E. P. Experience with Fagan s Inspection Method, Software-Practice and Experience, 22, 2, February 1992: 173-182. [Fagan 1976] M.E. Fagan, Design and code inspections to reduce errors in program development, IBM Systems Journal 15 (No. 3, 1976), pp. 182-211 [Fagan 1986] M.E. Fagan, Advances in software inspections, IEEE Transactions on Software Engineering, SE-12 (July 1986), pp. 744-751 [Fowler 1986] P.J. Fowler, In-process inspections of workproducts at AT&T, AT&T Technical Journal 65 (March/April 1986), pp. 102-112 [Kelly+1992] J. C. Kelly, J. S. Sherif, and J. Hops. An Analysis of Defect Densities Found During Software Inspections. Journal of Systems and Software, 1992. [Parnas&Weiss1985] Parnas, D. L. & Weiss, D. M. Active Design reviews: Principles and Practices, Proceedings of the 8th Conference on Software Engineering, pp. 215-222, August, 1985. [Parter+1994] Porter, A. A.; Votta, Jr., L. G.; & Basili, V. R. Comparing Inspection Methods for Software Requirements Inspections: A Replicated Experiment, University of Maryland Technical Report (CS-TR-3327), 1994. [E&S Tech Rept MDU 3327] [Weller1993] E. F. Weller. Lessons From Three Years of Inspection Data. IEEE Software, Sept. 1993. V4-48

Softwaretechnikpraktikum: Informationen, Aufgaben für die nächste Woche und Fragerunde

Abgabe: Lastenheft Deckblatt: Projekt, Auftraggeber, Auftragnehmer Produkteinsatz Einsatzbereich des zu entwickelnden Systems klarzustellen Beschreibung des Problembereichs Glossar Modell des Problembereichs Beschreibung der Geschäftsprozesse nur durch Text Produktfunktionen Dieser Abschnitt hat die Aufgabe, die Funktionalität des zu entwickelnden Systems überblicksartig zu beschreiben. Use Cases Beschreibung der Use Cases durch kurzen Text Benutzungsschnittstelle wichtige Aspekte der Benutzungsschnittstelle Produktcharakteristiken wichtige nicht-funktionalen Anforderungen bzw. Qualitätsmerkmale. V4-50

Aufgaben: Reviews im SOPRA Review des Pflichtenheftes: Inspection: Teamleiter = Pflichtenheftbeauftragter Vorbereitung vor dem Gruppentreffen Sitzung während des Gruppentreffens (spätestens Woche 20, max. 60 min) Ergebnis: Liste der Probleme, die man bis zur Abgabe lösen muss Design Review: Formaler technischer Review (Annahme/Ablehnung) Teamleiter = Entwurfsbeauftragter Auswahl der Entwurfsteile durch den Teamleiter (spätestens Woche 22) Vorbereitung vor dem Gruppentreffen Sitzung während des Gruppentreffens (spätestens Woche 23, max. 60 min) Bei Ablehnung ggf. kurze 2. Sitzung ein Woche später Implementierung: Code Walkthrough Teamleiter = Qualitätsbeauftragter Auswahl der Codefragmente durch den Teamleiter (spätestens Woche 23) Kurze Vorbereitung vor dem Gruppentreffen Sitzung während des Gruppentreffens (spätestens Woche 24, max. 60 min) Ergebnis: Liste von Problemen im Code Teammitglieder für einzelne Teile: Bis auf Entwickler immer aus den anderen nicht Teilgruppen rekrutieren Bei formalem technischen Review die Entwickler erst am Ende hören V4-51

Fragen? V4-52