Methoden und Werkzeuge zur Softwareproduktion - Qualitätssicherung -

Transkript

1 Methoden und Werkzeuge zur Softwareproduktion - Qualitätssicherung - Dirk Seifert Fachgebiet Softwaretechnik Technische Universität Berlin Wintersemester 2006/2007

2 Themen aus dem Bereich der Qualitätssicherung von Software und Softwareentwicklung Stichworte Prozess- und Produktqualität konstruktive und analytische Verfahren Informationen swt.cs.tu-berlin.de/lehre/mwsp 2

3 Motivation 3

4 Wozu benötigen wir explizite Qualitätssicherung? Wie hoch sind die höchsten Gebäude (habitable)? Taipei 101 in Taipei, Taiwan mit 460 Meter (508) Sears Tower in Chicago, USA mit 442 Meter (527) CN Tower in Toronto, Kanada mit 552 Metern (all man-made structures) Wieviel Programmzeilen hat ein modernes Betriebssystem? ca. 36 Millionen Zeilen Programmcode Das sind ca. 800 Zeilen Programmcode pro Zentimeter. 4

5 Wozu benötigen wir eine explizite Qualitätssicherung? Beispiel Windows notepad.exe einfacher Texteditor; in jeder Windows Distribution minimales Benutzerinterface erlaubt nur Basisoperationen wie Einfügen, Löschen, Speichern 5 Aufgabe 1 Markiere den Text im Editor 2 Ändere die Schriftgröße 3 Wähle im Menü Undo Was passiert? 1 die Größenänderung wird aufgehoben geändert 2 die Markierung wird aufgehoben 3 Markierung und Schriftgröße werden geändert 4... nichts von alledem passiert

6 Wozu benötigen wir eine explizite Qualitätssicherung? Einige Beispiele Was zeigen uns die Beispiele? Reale Systeme haben einen kaum noch vorstellbaren Umfang. Auch das kleinste reale System kann ein Labyrinth unerwarteter Kompliziertheit sein! Und nun die schlechte Nachricht Unser System ist das Cockpit eines Airbus A380!!! 6

7 Situation in der Softwareentwicklung Nich ganz ernst gemeint 7

8 Reale Softwareentwicklung? Real World: Projektunsicherheiten Anforderungen ändern sich mit beliebiger Häufigkeit Instabilität der Systemdefinitionen ist eine Invariante Real World: Budget und Zeitplan unendlich viele Zustände müssen mit endlich vielen Ressourcen überprüft werden Real World: Technische Einschränkungen Systemanforderungen können ein klares Design verhindern Vereinfachungen sind häufig nicht möglich Real World: Soziologie Anzahl der Kommunikationspfade wächst quadratisch mit der Anzahl der Teammitglieder (direkte) Kooperation und die Informationsteilung sinkt mit der Distanz 8

9 Reale Qualitätssicherung? Am Beispiel eines Projektmanagers bekommt einen Bonus, wenn er Termingerecht liefert bekommt (noch) keinen Bonus für Qualität ist nicht mehr für die Software verantwortlich, wenn sie produziert wird Was also tun? Lösche die Fehlerdatenbank, um die Software in Produktion zu bekommen! Erzähle den Testern, dass sie das Testen stoppen sollen, wenn sie (zu) viele Fehler finden! Denke, dass Qualitätssicherung etwas ist, was am Ende des Projektes gemacht wird... wenn dann noch Zeit ist!!! 9

10 Methoden und Werkzeuge zur Softwareproduktion - Qualitätssicherung - Dirk Seifert Fachgebiet Softwaretechnik Technische Universität Berlin Wintersemester 2006/

11 Organisatorisches 11

12 Veranstalter Dirk Seifert Art und Form 4 SWS Integrierte Veranstaltung seifert@cs.tu-berlin.de (FR5028) Studiengebiet Softwaretechnik und Systemgestaltung in SSG und PSS anrechenbar Zeit und Ort Dienstag 10-12, FR0512a und Mittwoch 10-12, FR3001 Voraussetzungen Basisveranstaltung Softwaretechnik Grundkenntnisse in der Softwareentwicklung (Java) 12

13 Vorlesung insgesamt 12 Vorlesungen Dienstag Vergabe der Plätze und Referatsthemen Einführung in die Qualitätssicherung Planspiel Weiterführende Themen Zusammenfassung und Fragestunde Rücksprachen (voraussichtlich am 13. und 14. Februar 2005) Referate 14 Referate (drei in Vierergruppen) 13

14 Prüfungsrelevante Studienleistungen 1 Referat mit schriftlicher Ausarbeitung (50 %) Gruppe von zwei bzw. vier Teilnehmern 60 Minuten Vortrag 30 Minuten Diskussion Vorbereitungstreffen Erinnerungsfragen Ausarbeitung eine Woche später (max. siebenseitig) 2 Rücksprache am Ende des Semesters (50 %) Themen der Vorlesungen und Referate einzeln 3 Übungsaufgaben (drei bis vier Aufgabenblätter) 4 regelmäßige Anwesenheit 14

15 Teilnehmerbeschränkung 34 Teilnehmer (im Losverfahren falls erforderlich) Anmeldung vom 17. (18:00 Uhr) bis zum 20. (12:00 Uhr) online: swt.cs.tu-berlin.de/lehre/lvreg 15

16 Referatsthemen 16

17 Referatsthemen 1 Agile Methoden der Softwareentwicklung 2 Reviewtechniken (zwei Termine) 3 Unit Testing mit JUnit (zwei Termine) 4 Zusicherungen, Design by Contract, JML 5 Zustandsbasierte Tests 6 Strukturbasierte Tests (zwei Termine) 7 Entscheidungstabellen zur Testdatenermittlung 17

18 Referatsthemen (Forts.) 8 Domaintest und Grenzwertanalyse 9 Category Partitioning und Klassifikationsbaummethode 10 Komponenten- und Integrationstest 11 Testorakel 12 Debugging 13 Evolutionärer Test 14 Mutationsbasierter Test 18

19 Thema heute: 1. Tips und Hinweise zu den Referaten und Ausarbeitungen 2. Vergabe der Referatsthemen Literatur: Software-Qualität Testen, Analysieren und Verifizieren von Software Peter Liggesmeyer Spektrum Verlag ISBN

20 Allgemeine Hinweise Hauptziel: Darstellung der Thematik Vorkenntnisse des Zielpublikums bestimmen Zuhörer soll den Stoff verstehen (können) der Rote Faden ist wichtig Einordnung in die Veranstaltung Abgrenzungen/Vergleiche zu anderen Referaten wichtige Punkte wiederholen Bilder verdeutlichen Zusammenhänge schwer erläuterbare Zusammenhänge Bilder sprechen nicht für sich selbst auf die Sprache achten verständlich sprechen langsam sprechen interessant sprechen 20

21 Anforderungen Einordnung in die Veranstaltung Anwendungsgebiet Bezüge zu anderen Themen Literaturangaben Eignung und Probleme Beispiele 21

22 Empfehlenswertes Vorgehen 1 Literatur lesen 2 Literatur lesen Struktur festlegen Gliederung Motivation Einleitung Hauptteil Zusammenfassung Ausblick Quellenangabe 5 Struktur mit Inhalt füllen 6 Literatur lesen

23 ... die Literatur lesen... Versuchen, die Kernaussage des Textes zu erkennen! Überblick über den Text verschaffen (überfliegen) Text einmal komplett lesen Fragen formulieren Text lesen und versuchen, die Fragen zu beantworten (Stellen markieren) Bezüge zu bekannten Themen suchen Wiedergabe des Textes mit eigenen Worten 23

24 Referat Referat gut vorbereiten nicht nur die Folien, sondern auch das, was man zu den Folien sagen möchte Folien nicht vorlesen, sondern mit ihr arbeiten zeigen, wo man sich befindet Vortrag und Folien müssen zusammengehören Zeit kalkulieren: nicht zu viele Folien, aber auch nicht zu wenige zum Publikum schauen; den Blick schweifen lassen Monotonie vermeiden, z.b. durch Medienwechsel üben, üben, üben... Wichtig ist: der Vortragende muss den Inhalt des Vortrages verstanden haben! keine Angst vor Fragen 24

25 Folien Zeitplanung Tip: 1 bis 3 Minuten pro Folie einplanen das Erklären von Bildern braucht Zeit große Schrift benutzen; maximal 13 Zeilen pro Folie Tip: ein DIN-A4 Blatt vierteln und in normaler Schriftgröße die Folien entwerfen auch die Beschriftung von Bildern muss man lesen können auf jeder Folie: Titel Namen Foliennummer Datum 25

26 Folien auf jeder Folie nur ein Thema restlichen Platz freilassen Tip: freien Platz für Grafiken nutzen jede Folie sollte eine Aussage haben nichtssagende Folien weglassen 26

27 Folien Schnickschnack vermeiden (Rahmen, Logos...) Der Inhalt soll dominieren!!! einheitliche Schrift verwenden Dies ist ein schlechtes Beispiel! serifenlose Schrift verwenden Farben sparsam einsetzen Dies ist auch ein schlechtes Beispiel! 27 Da der Inhalt auf einer Folie möglichst kurz und knapp gehalten werden sollte, sollte man lange Sätze, die zusätzlich mit näheren Erläuterungen angereichert sind, vermeiden und stattdessen Stichpunkte verwenden, die den eigentlichen Vortrag unterstützen und der Zuhörer sich somit auf den Vortragenden konzentrieren kann und sich nicht mit dem Lesen der Folien beschäftigt.

28 Ausarbeitung eigene Präsentation des Themas keine Übersetzungsarbeit Bezug zwischen Vortrag und Ausarbeitung Bildunterschriften, Nummerieung und Referenzierung Text am Ende auch mal selbst lesen Korrektur lesen lassen 28

29 Studienleistung Referat: jeweils zwei pro Vortrag 60 Minuten Vortrag 30 Minuten Diskussion und/oder Übung Vorbesprechung: mindestens eine Woche vorher sofortige Veröffentlichung (3 Tage Nachbearbeitung) Ausarbeitung: sieben Seiten (Schriftgröße zwischen 10 und 12 Punkte) spätestens eine Wochen nach dem Vortrag Die Dokumente hängen mit eurem Namen im Netz! 29

30 Referatsthemen : Agile Methoden der Softwareentwicklung : Reviewtechniken : Reviewtechniken : Unit Testing mit JUnit : Unit Testing mit JUnit : Zusicherungen, Design by Contract, JML : Zustandsbasierte Tests : Strukturbasierte Tests : Strukturbasierte Tests : Entscheidungstabellen zur Testdatenermittlung 30

31 Referatsthemen : Grenzwertanalyse und Domaintest : Category Partitioning / Klassifikationsbaummethode : Komponenten- und Integrationstest : Testorakel : Debugging : Evolutionärer Test : Mutationsbasierter Test 31

32 Thema heute: 1. Klassische Methoden der Softwareentwicklung 2. Einleitung Qualitätssicherung 32

33 Klassische Methoden der Softwareentwicklung 33

34 Klassische Softwareentwicklung / -technik Allgemeine Beschränkungen duch zwei Punkte 1 Stand der Technik 2 Angewandte Methode der Softwareentwicklung diese beschränken die lösbaren Probleme komplexere Aufgabenstellungen erfordern Arbeitsteilung und -organisation Lange Zeit praktiziert: Code and Fix code now; fix later keine feste Planungsphase heufig schlecht strukturierter Code = Vorgehensmodelle 34

35 LifeCycle-Modell eines Softwaresystems 1 Systems Engineering 2 Software-Anforderungsanalyse und -definition 3 Software-Entwurf 4 Implementierung 5 Test 6 Betrieb und Wartung (Weiterentwicklung) 35

36 Vorgehensmodelle Die chaotische Software-Bastelei soll ein Ende haben! Vorgehensmodelle ermöglichen 1 klare und systematische Vorgehensweise 2 zeitliche und inhaltliche Strukturierung 3 Zerlegung in Phasen mit Tätigkeiten und Ergebnissen Eigenschaften modellhaft: idealisiert und abstrakt eines der wichtigsten konstruktiven Qualitätssicherungsmaßnahmen 36

37 Vorgehensmodelle: Beispiele Sequentielles Modell Schleifenmodell: Wasserfallmodell V-Modell Sichtenmodell Spiralmodell Cleanroom / B-Methode 37

38 Wasserfallmodell Der Prozessablauf ist diszipliniert, sichtbart und kontrollierbar. iterativ: Phasen können mehrfach ausgeführt werden Vordergrund: Entwicklung und Pflege von Dokumenten (dokumentierte Softwareentwicklung) Probleme hohe Gewichtung auf der Dokumentation wenig Berücksichtigung von Risiken Reviews sehr Zeitaufwendig abgeschlossene Phase Voraussetzung für neue Phase Fehlersuche zieht sich durch mehrere Phasen Anforderungsänderung erfordert Rückschritt in die 1. Phase 38

39 Wasserfallmodell 39

40 V-Modell Ursprung vom Bund entwickeltes Modell (Voraussetzung für Aufträge) konstruktive und prüfende Aktivitäten Submodelle V-Modell und Qualitätssicherung Submodell Systemerstellung, das V-Modell linearer Entwicklungsverlauf eindeutige Zuordnung von Entwurfs- und Abnahmephasen Fehlersuche durch Rückschritte in die zugeordneten Phasen 40

41 V-Modell 41

42 V-Modell Submodell Qualitätssicherung Spezifikation der Testdokumentation QS Plan Prüfplan Prüfspezifikation Prüfprozedur Prüfprotokoll Probleme abgeschlossene Phase Voraussetzung für neue Phase Testphase erst spät im Entwicklungsprozess Anforderungsänderung erfordert Rückschritt in die 1. Phase 42

43 Spiralmodell Prinzip vier Entwicklungsphasen als Quadranten Entwicklungsprozess als Zyklus Risikoanalyse zur Bewertung erkannter Alternativen Prototypen als Iterationsziele Besonderheiten Vorgehen in der Entwicklung nicht in jeder Phase gleich iterative Erweiterung der Funktionalität steuerbare Entwicklung durch Bewertung von Alternativen kritisch: gute Risikoanalyse notwendig 43

44 Spiralmodell 44

45 Spiralmodell 45

46 Probleme der klassischen Softwareentwicklung Systemtests erst zum Ende der Entwicklungsprozesse Entwurfsfehler werden erst spät erkannt Änderungen der Anforderungen werden von den Modellen nicht berücksichtigt häufig dokumentenzentriert 46

47 Qualitätssicherung 47

48 Was ist Qualität? 48

49 Was ist Qualität? Brockhaus Qualität [lat. qualitas >Beschaffenheit<] 1) allg.: Gesamtheit der charakteristischen Eigenschaften (einer Person oder Sache), Beschaffenheit, Güte. 4) Wirtschaft: die Beschaffenheit einer Ware (Produkt-Qualität) oder einer Dienstleistung nach ihren Unterscheidungsmerkmalen gegenüber anderen Waren oder Dienstleistungen, nach ihren Vorzügen oder Mängeln. 49

50 Was ist Qualität? DIN Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines Produktes oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung festgelegter und abgeleiteter Erfordernisse bezieht. 50

51 Was ist Qualität? Brockhaus Unterscheidung von messbaren, stofflich- technischen Eigenschaften (objektive Qualität) und Eignungswert zur Befriedigung bestimmter Bedürfnisse (subjektive Qualität).... Als relative Qualität wird die Qualität im Vergleich zu Konkurrenten bezeichnet. Sie bestimmt u.a. den Markterfolg.... Für die gegenseitigen Ansprüche des Käufers und Verkäufers ist die vertragsgemäße Qualität maßgebend 51

52 Wie kann man Qualität bestimmen? 52

53 Qualitätsmerkmale Hesse et al. Ein Qualitätsmerkmal ist eine Eigenschaft, die zur Unterscheidung von Produkten, Bausteinen oder Herstellungsprozessen in qualitativer (subjektiver) oder quantitativer (meßbarer) Hinsicht herangezogen werden kann. 53

54 Qualitätsmaße Liggesmeyer Die konkrete Feststellung der Ausprägung eines Qualitätsmerkmals geschieht durch so genannte Qualitätsmaße. Dies sind Maße, die Rückschlüsse auf die Ausprägung bestimmter Qualitätsmerkmale gestatten. 54

55 Qualität 1 Qualität 2 Qualitätsmerkmal 3 Qualitätsmaß ist zumeist unbestimmt muss mit Hilfe von Merkmalen definiert werden und mit Hilfe von Maßen messbar sein Qualität ist abhängig vom Problem es ist nicht immer nötig/möglich, alle Qualitätsmerkmale zu optimieren 55

56 Was ist Softwarequalität? ISO/IEC-Norm 9126 Softwarequalität ist die Gesamtheit der Merkmale und Merkmalswerte eines Softwareprodukts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen. 56

57 Wodurch wird Qualität beeinflusst? Beispiel: Vertragsverhandlungen Kunde will mehr Security! Ansonsten soll der Vertrag unverändert gelten! Welche Vertragsänderung vorschlagen? four variables, [ Kent Beck, extreme Programming ] Zeit Funktionalität / Umfang Qualität Ressourcen 57

58 Wie ist Software? groß? komplex? kompliziert? Woran erkenne ich den Unterschied? 58

59 Qualitätsmerkmale von Software Korrektheit/Vollständigkeit Funktionalität Sicherheit/Zuverlässigkeit/Verfügbarkeit Benutzbarkeit/Effizienz Änderbarkeit/Übertragbarkeit Prüfbarkeit 59

60 Qualitätsmerkmale von Software Korrektheit Synonym für Fehlerfreiheit Übereinstimmung zw. beobacht. und gewünschten Verhalten Grad der Konsistenz zwischen Spezifikation und Programm Grad der Erfüllung der Benutzererwartung durch ein Programm Fehlerprioritäten Vollständigkeit alle geforderten Funktionalitäten sind realisiert sowohl Normalfälle als auch das Abfangen von Fehlersituationen 60

61 Qualitätsmerkmale von Software Funktionalität Richtigkeit (der Ergebnisse) Angemessenheit (Eignung für die Aufgaben) Interoperabilität (mit vorhandenen Systemen) Ordnungsmäßigkeit (Erfüllung von Normen, Vereinbarungen usw.) Sicherheit (Verhinderung des unberechtigten Zugriffs) 61

62 Qualitätsmerkmale von Software Sicherheit Risiko eines Personen- oder Sachschadens Abwesenheit von Gefährdungen safety Datensicherheit (Verlust, Zugriff) security Zuverlässigkeit Reife (Versagenshäufigkeit; MTTF oder MTBF) Wiederherstellbarkeit (Leistungsneveau und Daten; MTTR) Fehlertoleranz/Robustheit Verfügbarkeit Fähigkeit, zu einem gegebenen Zeitpunkt funktionstüchtig zu sein: ( ) MTBF MTBF +MTTR 62

63 Qualitätsmerkmale von Software Benutzbarkeit Verständlichkeit Erlernbarkeit Bedienbarkeit Effizienz Zeitverhalten (Antwort- und Verarbeitungszeit) Verbrauchsverhalten (Anzahl und Dauer der benötigten Betriebsmittel) 63

64 Qualitätsmerkmale von Software Änderbarkeit Analysierbarkeit (der Software zur Behebung von Mängeln und Fehlern oder zum Bestimmen von Änderungen) Modularisierung, Kapselung,... Lesbarkeit (des Codes) Dokumentation Übertragbarkeit Anpassbarkeit (an verschiedene Umgebungen) Austauschbarkeit 64

65 Qualitätsmerkmale von Software Prüfbarkeit testability, design for testability ausreichend Informationen über das Programm ausreichend Zugriff auf das Programm (Daten, Methoden...) Steuerbarkeit Beobachtbarkeit Achtung: testing = prüfen 65

66 Qualitätsmerkmale von Software Fehlerfreiheit/Korrektheit Sicherheit Zuverlässigkeit Wiederverwendbarkeit Flexibilität Änderbarkeit Benutzbarkeit Modularität Wartbarkeit Robustheit Portierbarkeit Verständlichkeit Angemessenheit Verfügbarkeit... und viele mehr... Kann man Interessengruppen unterscheiden? für den Anwender wichtig für den Entwickler wichtig 66 Wechselwirkungen und Zusammenhänge

67 Thema: 1. Qualitätssicherungsprinzipien 2. Klassifikation der Qualitätssicherungsmaßnahmen 67

68 Qualitätssicherungsprinzipien 68

69 Qualitätssicherungsprinzipien 1 es Besteht der Zwang zu hoher Produktivität 2 Produktivität bedingt aber Termintreue, minimale Kosten, zufriedenstellende Produktqualität,... Ziel ist immer die wirtschaftliche Softwareerstellung! Beachtung von gewissen allgemeinen Prinzipien auch bei der Qualitätssicherung! 69

70 P1: Konkrete operationalisierbare Qualitätsmerkmale Aufgabe: Qulitätsmerkmale spezifizieren Sichten: Auftraggeber, Benutzer konkret, möglichst quantifizierbar Merkmale für die einzelnen Phasen finden prozess- und produktorientiert 70

71 P2: Produkt- und projektabhängige Qualitätssicherung Aufgabe: Einordnung und Auswahl Fokus: Verwendungszweck, Lebensdauer, potentielle Benutzer Einfluss von Projektrisiken: z. B. Komplexität, Neuigkeitsgrad Einfluss von: z. B. Größe, Qualifikation Auswahl von Softwaremethoden und -werkzeugen Auswahl von Qualitätssicherungsmaßnahmen 71

72 P3: Rückkopplung der Ergebnisse der Qualitätsprüfungen Aufgabe: Qualitätslenkung Voraussetzung für erfolgreiche Qualitätslenkung Erkennung von Soll-Ist-Abweichungen mit entsprechenden Korrekturen Audits / Reviews zum Informationsgewinn 72

73 P4: N-Augenkontrolle bei Qualitätsprüfungen Aufgabe: Vertrauen in die Qualität erhöhen alle intellektuellen Fähigkeiten eins Team nutzen Zwischenprüfungen / Redundanz 73

74 P5: Maximale konstruktive Qualitätssicherung Aufgabe: Fehler im Entwicklungsprozess vermeiden Aufwand für Qualitätsprüfungen reduziert sich teilweise auch Voraussetzung für Qualitätsprüfungen (Pre/Post) 74

75 P6: Frühzeitige Entdeckung und Behebung von Fehlern und Mängeln Aufgabe: Kostenreduktion Anforderungsanalyse vs. Implementierung: Kostenfaktor von 100 (allg. exp.) Verbesserung der Qualitätslenkung 75

76 P7: Integrierte Qualitätssicherung Aufgabe: realistische Beurteilung des Projektfortschritts muss in den gesamten Prozess integriert sein muss geplant werden Unterscheidung von konstruktiver und analytischer Phase 76

77 P8: Unabhängigkeit bei der Qualitätsprüfung Aufgabe: Steigerung der Objektivität (kritische, destruktive Begutachtung) QS-Ingenieur darf nicht auch der Entwickler sein Ziel: Feststellung des tatsächlichen Ist-Standes Problem? 77

78 P9: Bewertung der eingesetzten Qualitätssicherungsmaßnahmen Aufgabe: Steigerung der Produktivität interne oder externe Qualitätsaudits Aktualisierung der Qualitätssicherungsmaßnahmen 78

79 Klassifikation der Qualitätssicherungsmaßnahmen 79

80 Qualitätsmanagement Qualitätsmanagement befasst sich mit organisatorischen Maßnahmen zur Erreichung und für den Nachweis von Qualität. Produktorientiertes Qualitätsmanagement Überprüfung von Softwareprodukten oder deren Zwischenergebnissen auf festgelegte Qualitätsmerkmale Prozeßorientiertes Qualitätsmanagement Überprüfung des Softwareherstellungsprozesses Verwendung von Methoden und Werkzeugen Einhaltung von Richtlinien und Standards 80

81 Qualitätssicherungsmaßnahmen 1 planerisch-administrative 2 konstuktive 3 analytische 4 psychologisch-orientierte 81

82 Planerisch-administrative Maßnahmen Aufbau, Einführung und Pflege eines Qualitätssicherungssystems drei Ebenen 1 projektübergreifend 2 projektspezifisch 3 phasenspezifisch 82

83 Konstuktive Maßnahmen Qualitätsgestaltend, d. h. präventiv (Mängel und Fehler vermeiden) Sicherstellen, dass das Produkt bzw. der Prozess bestimmte Eigenschaften besitzt (a priori) Einsatz technischer, organisatorischer oder psychologisch-orientierter Maßnahmen und Hilfsmittel (Prinzipien, Methoden, Formalismen, Werzeuge; Vorgehensmodelle, Planung; Schulungen) auch Maßnahmen zur Fehlerbehebung 83

84 Analytische Maßnahmen Messung und Bewertung des Qualitätsneveaus Erkennung und Lokalisierung von Mängeln und Fehlern Voraussetzung ist ein Qualitätsplan und daraus abgeleitete Prüfziele 84

85 Analytische Maßnahmen 1 Validation Übereinstimmung mit den Produktanforderungen 2 Verifikation Übereinstimmung mit den Ergebnissen vorangegangener Phasen 3 Zertifikation Erfüllung vorgegebener Anforderungen (z. B. Normkonformität) 85

86 Konstruktive vs. analytische Maßnahmen 1 konstruktive Maßnahmen erleichtern analytische Maßnahmen 2 fehlende konstruktive Maßnahmen erfordern einen höheren Aufwand bei den analytischen Maßnahmen Wieso wenden wir nicht ausschließlich konstruktive Maßnahmen an? 86

87 Psychologisch-orientierte Maßnahmen Betrachtung von nicht-technischen Aspekten Beachtung von unterschiedlichen Fähigkeiten / Persönlichkeiten Untersuchung des Projektumfeldes 87

88 Thema: 1. Total Quality Management 2. Assessments 3. Capability Maturity Model 88

89 Qualitätsmanagement 89

90 Qualitätsmanagement Befasst sich insbesondere mit den organisatorischen Maßnahmen zur Erreichung und für den Nachweis einer hohen Qualität. Total Quality Management Prozess-Assessments Capability Maturity Model TRILLIUM, BOOTSTRAP, Software Technology Diagnostics, Healthcheck (SPICE) 90

91 Total Quality Management Führungsmethode einer Organisation Mitwirkung aller Mitglieder Qualität steht im Mittelpunkt durch Zufriedenheit der Kunden langfristigen Geschäftserfolg 91

92 Total Quality Management Klassische TQM Qualitätssicherung Ziele Bessere Produkte Besseres Unternehmen Geringere Kosten Kundenzufriedenheit Flexibilität Orientierung Produkt Markt Prozess Organisation Starke Position der Alle Tätigkeiten sind Qualitätssicherung auf Qualität fokussiert Qualitätsverantwortung Qualitätsbeauftragter Linienmanagement Jeder Mitarbeiter Methode Messungen Kontrollen Fehlererfassung und Fehlerauswertung 92

93 93 1. Vorlesung 2. Vorlesung 3. Vorlesung 4. Vorlesung 5. Vorlesung 6. Vorlesung TQM: Vorläufer 1 Null-Fehler-Programm (P. B. Crosby) nur fehlerfreie Produkte sind akzeptabel Nicht die Erzeugung von Qualität verursacht Kosten, sondern die Nichterfüllung von Anforderungen. 2 Continuous Improvement Prozess (Kaizen, W. E. Deming) Prinzip der ständigen Verbesserung (Kaizen) Realisierung: Deming-Zyklus (Plan-Do-Check-Act) 14 Punkte Programm (Management-Prinzipien) 3 Total Quality Control Unterteilung von Marketing, Entwicklung, Produktion und Kundendienst 4 Company-Wide Quality Control Mitarbeiterorientierung: Qualitätszirkel, Fishbone Chart (Ishikava-Diagramme) 5 Qualitäts-Trilogie dreistufiger, systematischer, kontinuierlicher Prozess zur Qualitätssteigerung Planung des Prozess, Implementierung und Absicherung, Prozessverbesserung

94 TQM: Umsetzung Quality Function Deployment Statistische Prozesskontrolle Zuverlässigkeitsmodellierung Reviews, Inspektionen Qualitätszirkel Fehlermöglichkeiten- und Einflussanalyse Fishbone Chars (Ishikava-Diagramme) Pareto-Analyse Korrelationsdiagramme 94

95 Qualitätszirkel kleine Gruppe von Mitarbeitern regelmäßige Treffen um Qualitätsprobleme zu lösen Problemerkennung, Problemanalyse, Problemlösung Techniken: Ursache-Wirkungs-Diagramm (Fishbone-Chart, Ishikawa-Diagramm), Pareto-Analyse, Brainstorming 95

96 Ursache-Wirkungs-Diagramm Fishbone Charts, Ishikawa-Diagramme für ein Problem (Wirkung) werden die Ursachen gesucht Unterteilung in Hauptursachen und Nebenursachen Hauptursachen (6M-Methode: Mensch, Maschine, Methode, Material, Milieu, Messung) Nebenursachen (6W-Methode: Was, Warum, Wie, Wer, Wann, Wo) Ziel: tatsächliche Ursache identifizieren, Lösungsalternativen finden, Auswahl trefen 96

97 Process-Assessments 97

98 Prozess-Assessments Wirkungsanalyse Entstanden aus der Erkenntnis, dass Techniken allein die Probleme nicht lösen. Techniken müssen sich in einen Entwicklungsprozess einfügen. Die Technik muss in den Entwicklungsprozess passen, und die Mitarbeiter müssen die Technik akzeptieren und beherrschen. Verschiebung des Schwerpunktes in der Softwareentwicklung von Verfahren und Techniken hin zum Entwicklungsprozess. Tätigkeiten werden nicht den Techniken angepasst, sondern es werden Techniken ausgewählt, die zu den Aufgaben und Problemen des Prozesses passen. 98

99 Prozess-Assessments Wichtigste Voraussetzung ist die Kenntnis von Stärken und Schwächen des Prozesses. Reifegrad in fünf Stufen unterteilt Durchführung mit Frageliste (basierend auf dem Capability Maturity Model (CMM): 1 informell, ad-hoc 2 wiederholbar 3 definiert 4 gesteuert 5 kontinuierlich optimiert keine Kompensation möglich Nachweis der Qualität (heute: DIN-ISO-900X Normen) 99

100 Eigenschaften der Reifegradstufen Reifegrad 1: initial, chaotisch Prozess- Charakteristik Informaler ad hoc- Prozess 2: wiederholbar Projekt-Management ist institutionalisiert Techniken unterstützen einige Tätigkeiten Qualitative Basis für Techniken vorhanden 3: definiert technische Abläufe und Projekt- Management sind institutionalisiert 4: quantitativ Produkt und Prozess gesteuert sind unter quantitativer Kontrolle 5: optimierend Prozessverbesserung wird kontinuierlich durchgeführt Techniken Einführung von Techniken ist risokoreich Regelmäßige Chaosbeseitigung, geringe Effizienz Erfahrene Mitarbeiter stützen den Prozess quantitative Basis für Techniken vorhanden Techniken und Prozess unterstützen einander Mitarbeiter Definierter Prozess ist bekannt und wird beachtet Zusammenhänge werden quantitativ verstanden aktive Prozessoptimierung durch Mitarbeiter 100

101 Prozess-Assessments Nutzung von Prozess-Assessments 1 Reifegrad bestimmen 2 Stärken- und Schwächenprofil Vergleich mit den Inhalten des CMMs Beachtung von Zielgrößen (Einflussfaktoren und Priorisierung) Maßnahmenkatalog neuer Prozess 101

102 Prozess-Assessments Anmerkungen zeitlicher Aufwand erheblich (mehrere Jahre) Schwerpunkt auf technischer Seite (personalbezogene Aspekte?) wenig Erfahrung mit Reifegrad 4 und 5 Auswahl von Verbesserungen problematisch (nur Problembereiche) Einflussfaktoren: Organisationsgröße Anwendungsbereich (Domain) Aufwand andere Verfahren und Standards Abwandlungen: TRILLIUM, BOOTSTRAP, Healthcheck, SPICE 102

103 Capability Maturity Model 103

104 Capability Maturity Model Referenzmodell beschreibt Praktiken innerhalb der Softwareentwicklung Maturity Level und Key Process Areas Key Practices, Key Activities Maturity Level Key Process Areas 5 Defect Prevention, Process Change Management, Technology Innovation 4 Process Measurement and Analysis, Quality Management 3 Process Pocus, Process Definition, Training, Integrated SW Management, Product Engineering, Intergroup Coordination, Peer Reviews 2 Requirements Management, Quality Assurance, Project Tracking and Oversight, Project Planning, Subcontract Management, Configuration Management 1 none 104

105 Thema: 1. Zusammenfassung 2. Einordnung und Klassifikation der Prüftechniken 3. Prüfaktivitäten 4. Abschließende Bemerkungen 105

106 Zusammenfassung 106

107 Einordnung und Klassifikation der Prüftechniken 107

108 Statische Prüftechniken verifizierend formal Zusicherungsverfahren Algebraische Techniken Automatenbasierte Techniken symbolisch analysierend Maße Stilanalysen Grafiken und Tabellen Slicing Datenflussanomalieanalyse Inspektions- und Reviewtechniken 108

109 109 Dynamische Prüftechniken strukturorientiert kontrollflussorientiert datenflussorientiert funktionsorientiert Funktionale Äquivalenzklassenbildung Zustandsbasierter Test Test auf Basis von Entscheidungstabellen diversifizierend Back to Back-Test Mutationen-Test Regressionstest Bereichstest Partion-Analyse Statistischer Test (zufallsorientiert) Grenzwertanalyse Zusicherungstechniken

110 Könnt ihr euch ein dynamisches verifizierendes Verfahren vorstellen? 110

111 Prüftechniken (alternative Klassifikation) White-Box Tests (Glass-Box Tests) Testfälle werden auf Basis der Struktur des Programmcodes ermittelt Korrektheit wird anhand der Spezifikation ermittelt Problem: kein Bezug zur gewünschten Funktionalität Vorteil: aufspüren von Endlosschleifen, unerreichbare Pfade,... Black-Box Tests Testfälle werden auf Basis der Spezifikation ermittelt Kerrektheit wird anhand der Spezifikation ermittelt Vorteil: Aussagen bezüglich des Funktionsumfangs Nachteil: Unabhängigkeit vom Programmcode (Grey-Box Tests) 111

112 Prüfaktivitäten 112

113 Prüfaktivitäten 1 Was wird geprüft? Implementierung, Modell der Implementierung, (Spezifikation) 2 Wann wird geprüft? Phasen der Softwareentwicklung,... 3 Wie wird geprüft? Begutachtung, Ausführung,... 4 Wo wird geprüft? im Haus, beim Kunden, Versuchsgelände,

114 Testaktivitäten 1 Spezifikation: Sagt uns, was korrekt ist. 2 Testfall: Vorgehensbeschreibung für einen Test. 3 Testdaten: Konkrete Eingaben für einen Test.. Was benötigen wir im Allgemeinen noch, wenn wir testen wollen? 114

115 Testaktivitäten Spezifikation Programm Testfallermittlung Instrumentierung Testdatenbestimmung Sollwertbestimmung Testdurchführung Testauswertung Grimm et. al. 115

116 Testprozess Testaktivitäten plus: Testplanung Wer, Wann, Was, Wo... Testorganisation Vorbereitung des Setup Testdatenhaltung Wiederholbarkeit, Dokumentation Testdokumentation Nachweis, Auswertung 116

117 Anmerkungen zum Testen Wichtig: Ziel des Testen ist, Fehlverhalten aufzuzeigen. Ziel ist nicht, die Abwesenheit von Fehlverhalten zu zeigen. Dazu wird beim dynamischen Test die Software mit geeigneten Daten ausgeführt. vollständiger Test ist i. A. nicht möglich Testen hat Stichprobencharakter systematischer Test verlangt geeignete Bestimmung von Testfällen und Testdaten 117