1 / 162

Qualitätsmanagement in der Software-Entwicklung

Qualitätsmanagement in der Software-Entwicklung. Prof. Dr. Thomas Kudraß HTWK Leipzig. Seminar PC-Ware AG Leipzig, 26.01.2002. Motivation Kleine Bugs  Große GAUs. Ein paar falsche Zahlen oder Zeilen und schon passiert‘s: Explosion Ariane 5 (1996)

amena
Download Presentation

Qualitätsmanagement in der Software-Entwicklung

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Qualitätsmanagement in der Software-Entwicklung Prof. Dr. Thomas Kudraß HTWK Leipzig Seminar PC-Ware AG Leipzig, 26.01.2002

  2. MotivationKleine Bugs  Große GAUs • Ein paar falsche Zahlen oder Zeilen und schon passiert‘s: • Explosion Ariane 5 (1996) • Verlorengegangene Venus-Sonde Mariner1 (1962) • Koffer-Debakel am Flughafen Denver • Bank-Bugs • Neues Computer System bei US Fed (Fehlbuchungen 4 Mrd $) • Kundendaten frei im Internet bei Credit Suisse (Image-Schaden) • Wall-Street-Crash (1987) • Spendable Geldautomaten bei Postbank-Service Card (2002)

  3. Agenda • EINHEIT 1 • Einführung Qualitätsmanagement • EINHEIT 2 • Qualitätssicherung im Software-Entwicklungsprozess (V-Modell) • Beispiel • EINHEIT 3 • Qualitätssicherung in Analyse & Design A: Qualität von Business-Spezifikationen B: Manuelle Prüfmethoden (Reviews) mit Beispiel • EINHEIT 4 • Qualitätssicherung in der Programmierung: Test-Verfahren • Arten von Tests

  4. EINHEIT 1:Einführung Qualitätsmanagement • Qualitätsbegriff • Qualitätsmerkmale von Softwareprodukten • Qualitätsmodelle • Maßnahmen von Qualitätssicherung und Qualitätsmanagement • Prinzipien der Software-Qualitätssicherung • Organisatorische Einbettung der QS

  5. Was ist Qualität?Fünf verschiedene Ansätze • Transzendenter Ansatz • Produktbezogener Ansatz • Benutzerbezogener Ansatz • Prozessbezogener Ansatz • Kosten/Nutzen-bezogener Ansatz

  6. Produktbezogener Ansatz • Qualität = messbare, genau spezifizierbare Größe, beschreibt das Produkt • Keine Berücksichtigung von subjektiven Wahrnehmungen und Beobachtungen • Berücksichtigt nur das Endprodukt – nicht den Kunden! • Ermöglicht Ranking von Produkten gleicher Kategorie

  7. Benutzerbezogener Ansatz • Qualität durch den Benutzer festgelegt (fitness for use) • Unterschiedliche Wünsche und Bedürfnisse verschiedener Benutzer • Problem für Hersteller • Vage Vorstellungen der Anwender • Bedürfnisse der Benutzer rechtzeitig erkennen

  8. Prozessbezogener Ansatz • Qualität des Produkts hängt ab vom richtigen Prozess der Erstellung • Spezifikation und Kontrolle des Erstellungs-prozesses • Ständige Anpassung des Prozess an neue Kundenbedürfnisse

  9. Definition Qualität • Qualität [DIN 55350, Teil 11] Qualität ist die 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 [DIN ISO 9126] ist die Gesamtheit der Merkmale und Merkmals-werte eines SW-Produkts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen

  10. Aufbau von FCM-Qualitätsmodellen Software-Qualität Q-Merkmal 1 (factor 1) Q-Merkmal 2 (factor 2) Q-Merkmal n (factor n) ... Q-Teilmerkmal 1 (criterion 1) Q-Teilmerkmal 2 (criterion 2) Q-Teilmerkmal n (criterion n) Q-Teilmerkmal 3 (criterion 3) Q-Indikatoren (metrics)

  11. Qualitätsmerkmale für Software-Produkte • Funktionalität • Zuverlässigkeit • Benutzbarkeit • Effizienz • Änderbarkeit • Übertragbarkeit Quelle: DIN-Norm ISO 9126

  12. Funktionalität • Richtigkeit • Liefert richtige oder vereinbarte Ergebnisse • Angemessenheit • Eignung der Funktionen für spezifizierte Aufgaben • Interoperabilität • Zusammenwirken mit vorgegebenen Systemen • Ordnungsmäßigkeit • Erfüllung von Normen, Vereinbarungen, gesetzl. Vorschriften • Sicherheit • Unberechtigten Zugriff auf Programme und Daten verhindern

  13. Zuverlässigkeit • Reife • Geringe Versagenshäufigkeit durch Fehlerzustände • Fehlertoleranz • Bewahrt Leistungsniveau bei Fehlern oder Nichteinhaltung Schnittstelle • Wiederherstellbarkeit • Wiederherstellung des Leistungsniveaus bei einem Versagen • Wiedergewinnung der betroffenen Daten • Erforderliche Zeit und Aufwand berücksichtigen

  14. Benutzbarkeit • Verständlichkeit • Aufwand für den Benutzer, Konzept und Anwendung zu verstehen • Erlernbarkeit • Aufwand für den Benutzer, die Anwendung zu erlernen (z.B. Bedienung, Ein-/Ausgabe) • Bedienbarkeit

  15. Effizienz • Zeitverhalten • Antwort- und Verarbeitungszeiten sowie Durchsatz bei der Funktionsausführung • Verbrauchsverhalten • Anzahl und Dauer der benötigten Betriebsmittel für die Funktionen

  16. Änderbarkeit • Analysierbarkeit • Aufwand zur Fehlerdiagnose oder zur Bestimmung änderungsbedürftiger Teile zu bestimmen • Modifizierbarkeit • Aufwand für Verbesserung, Fehlerbeseitigung, Anpassung an Umgebungsänderungen • Stabilität • Wahrscheinlichkeit für unerwartete Wirkungen bei Änderungen • Prüfbarkeit • Aufwand zur Prüfung der geänderten Software

  17. Übertragbarkeit (Portierbarkeit) • Anpassbarkeit • Anpassung der Software an verschiedene, festgelegte Umgebungen (organisatorisch, Hardware, Software) • Installierbarkeit • Aufwand zum Installieren der SW in einer festgelegten Umgebung • Konformität • Erfüllung von Normen oder Vereinbarungen zur Übertrag-barkeit durch die Software • Austauschbarkeit • Verwendung der Software anstelle einer anderen in deren Umgebung

  18. FURPS Qualitätsmodell Entwickelt von HP 1985 Merkmale (stark kundenorientiert definiert) • Functionality • Usability • Reliability • Performance • Supportability

  19. GQM-Ansatz: Goal-Question-MetricVorgehensmodell • Definiere die Auswertungsziele für alle zu erfüllenden Qualitätsmerkmale • Leite alle Fragestellungen ab, die zu einer Quantifizierung dieser Ziele führen können • Leite alle Maße ab, die Informationen zur Beantwortung der Fragestellungen beitragen • Entwerfe einen Mechanismus zur möglichst genauen Erfassung der Messwerte • Validiere die Messwerte bezüglich aller primitiven Maße • Interpretiere die Messergebnisse zur Gesamtbewertung der Qualitätsziele

  20. Beispiel für ein Software-Bewertungsmodell Auswertungsziele (goals) Z1 Z2 Z3 Z4 Abgeleitete Frage- stellungen(questions) F1 F2 F3 F4 F5 F6 M1 M2 M3 M4 M5 Primitive Maße (metrics)

  21. G: Muster zur Formulierung von Zielen im GQM-Ansatz • Zweck der Studie • Prozess, Produkt, Modell, Maß • Blickwinkel der Studie • Entwickler, Manager, SW-QS, Auftraggeber, Firmenleitung • Umgebung der Studie • Aspekte des Prozesses, Personal, Anwendung, Methoden, Werkzeuge u.a. Faktoren

  22. Q1: Auswertungsfragen zur Charakterisierung von Prozessen • Qualität der Durchführung • Anwendungsbereich • Beurteile Objekte des Prozesses sowie Kenntnis des Personals darüber • Aufwand der Durchführung • Ergebnis der Durchführung • Rückkopplung von der Durchführung

  23. Q2: Auswertungsfragen zur Charakterisierung von Produkten • Definition des Produkts • Physische Eigenschaften, z.B. Umfang, Komplexität, Programmiersprache • Kosten, z.B. Zeitaufwand, Entwicklungsphasen, Aktivitäten • Änderungen, z.B. Fehlerursachen, Fehler, Fehlverhalten • Umfeld, z.B. zu erwartendes Benutzerprofil • Bewertung des Produkts • Relativ zu einem bestimmten Qualitätsmerkmal, z.B. Zuverlässigkeit, Korrektheit, Zufriedenheit der Benutzer

  24. Erweitertes GQM-Bewertungsmodell Ziel(goal) Wir untersuchen Produkte und ... Weitere Qualitätsbäume Qualitätsbäumefür jedes Zwischenprodukt Qualitätsbaum-Analyse Qualitätsbaum-Quellcode ... Testbarkeit Wartbarkeit ... ... Strukturiertheit ... Innere Struktur Fragen (questions) ... Größe des Programms? Kennzahlen (metrics) Lines of Codes

  25. Qualitätsbaum “Wartbarkeit“ SWS ist leicht wartbar WB SWS höchstmöglich standardisiert WB1 SWS leicht verständlich WB2 SWS gut änderbar WB3 SWS gut testbar TB Ist gut strukturiert WB31 Ist eindeutig interpretierbar WB21 Jede Kompo-nente in sich gut strukturiert WB311 Hält vereinbarte Standards voll-ständig ein WB11 Techniken zur Er-stellung des SWS angemessen WB32 SWS leicht verständlich WB22 Beziehungen zwischen den Komponenten einfach WB312 Ist möglichst ein-heitlich realisiert WB12 Umfang des SWS entspricht optimal der Aufgabe WB33 Ist gut dokumentiert WB23

  26. Qualitätszielbestimmung • Qualitätsstufen • Wertebereich auf einer Skala zur Klassifizierung von Software entspr. Qualitätsanforderungen [ISO9126] Sehr gut Gut annehmbar Messwert Normal Schlecht nicht annehmbar Maßskala Qualitätsstufen

  27. Qualitätsanforderungen • Ergeben sich aus den Qualitätszielen • Welche Qualitätsmerkmale relevant? • Welche Qualitätsstufe muss erreicht werden? • Auswirkungen auf den SW-Entwicklungsprozess • Produktorientierte Anforderungen • Einfluss auf: Methoden, Werkzeuge, Richtlinien, Checklisten im Entwicklungsprozess • Prozessorientierte Anforderungen • Änderung des SW-Entwicklungsprozesses

  28. Qualitätsmanagement vs. Qualitätssicherung • Qualitätsmanagement • Alle managementbezogenen Tätigkeiten, die Qualitätspolitik, Ziele und Verantwortungen im Rahmen eines QM-Systems festlegen • Mittel: Q-Planung, Q-Lenkung, Q-Sicherung, Q-Prüfung • Qualitätssicherung • Alle technikorientierten Aktivitäten innerhalb des QM-Systems zur Erfüllung der Qualitätsanforderungen • Analytische Maßnahmen in der SW-Entwicklung

  29. Produktorientiertes Qualitätsmanagement • Inhalt • Überprüfung von SW-Produkten und Zwischen-ergebnissen auf festgelegte Qualitätsmerkmale • Sind Gegenstand der Zertifizierung • Maßnahmen (Beispiele) • Templates für Pflichtenheft (Richtlinie) • Einsatz von Strukturierter Analyse (SA) (Methode) • Programmierrichtlinien • Kein GOTO • Überprüfung aller Eingabegrößen (defensives Programmieren) • Wiederverwendung von SW-Bausteinen bei OO Programmierung

  30. Prozessorientiertes Qualitätsmanagement • Inhalt • Bezieht sich auf den Erstellungsprozess der Software • Permanente Anpassung an dynamische Qualitätsanforderungen • Maßnahmen (Beispiele) • Standardisierter Entwicklungsprozess • Welche Teilprodukte (deliverables) wann und von wem? • Einsatz von Konfigurationsmanagement • Festlegung eines Vorgehensmodells

  31. Konstruktives Qualitätsmanagement • Maßnahmen, die a priori bestimmte Qualitäts-eigenschaften von Produkt / Prozess gewährleisten Konstruktives Qualitätsmanagement Organisatorische Maßnahmen Technische Maßnahmen Methoden Sprachen Werkzeuge Richtlinien Standards Checklisten

  32. Analytisches Qualitätsmanagement • Diagnostische Maßnahmen zur Prüfung und Bewertung der Qualität der Prüfobjekte • Messen vorhandenes Qualitätsniveau, Ausmaß und Ort der Defekte • Klassifikation • Bezug der Prüfung (Produkt- oder Prozessprüfung) • Automatisierungsgrad (manuell und/oder Einsatz von Software-Werkzeugen) • Nachvollziehbarkeit der Prüfung (Selbstprüfung oder Nachweisführung) • Einsatzbereich der Prüfung: Definitions-,Entwurfs-,Imple

  33. Maßnahmen zum analytischen Qualitätsmanagement Analysierende Verfahren Testende Verfahren Statische Analyse Dynamischer Test Animation Symbolischer Test Programmverifikation Simulation Review Schreibtischtest Inspektion Walkthrough Durchsprache = manuell Audit

  34. Aktivitäten des Qualitätsmanagement • Qualitätsplanung • Qualitätslenkung und –sicherung • Qualitätsprüfung

  35. Qualitätsplanung • Festlegung der Qualitätsanforderungen an Produkt und Prozess • Auswahl und Festlegung eines Qualitätsmodells • Festlegung von Soll-Qualitätsstufen für Qualitätsindikatoren • z.B. Zuverlässigkeit – Anzahl Fehler pro Monat – 0.01 • Festlegung von Prioritäten bei gegenläufigen Anforderungen • Festlegung von allgemeinen und produkt-spezifischen Q-Lenkungs- und –Sicherungs-Maßnahmen • z.B. Messpunkte im Entwicklungsprozess zur Vorhersage der Ziele, Auswahl von Methoden und Werkzeugen zur Erfassung der Messwerte

  36. Qualitätslenkung • Umsetzung der Qualitätsplanung • Steuert, überwacht und korrigiert den Entwicklungsprozess, um Q-Anforderungen zu erfüllen • Überwacht Qualitätsprüfung nach Plan • Auswertung der Ergebnisse durch Vergleich Soll-Ist • Eng verknüpft mit SW-Management

  37. Qualitätsprüfung • Führt die im Rahmen der Q-Planung festgelegten Maßnahmen durch zur Bestimmung Ist • Überwacht Umsetzung der konstruktiven Maßnahmen • Aktivitäten • Erfassung von Messdaten über Werkzeuge, Formblätter / Interviews • Test (zur Erfassung dynamischer Produktmerkmale) • Inspektionen, Reviews, Walkthroughs • Mängel- und Fehleranalysen auf Basis von Problemberichten

  38. Qualitätssicherungsplan • Was muss gesichert werden? • Identifizierung der relevanten Q-Merkmale und ihre Quantifizierung in Form von Metriken • Wann muss gesichert werden? • Festlegung der Zeitpunkte für Datenerfassung während Entwicklungsprozess • Wie muss gesichert werden? • Auswahl der Techniken und Methoden • Vonwem muss gesichert werden? • Festlegung von Verantwortlichkeiten (Rollen)

  39. Prinzipien der Software-Qualitätssicherung • Prinzip der produkt- und prozessabhängigen Qualitätszielbestimmung • Prinzip der quantitativen Qualitätssicherung • Prinzip der maximalen konstruktiven Qualitätssicherung • Prinzip der frühzeitigen Fehlerentdeckung und –behebung • Prinzip der entwicklungsbegleitenden, integrierten Qualitätssicherung • Prinzip der unabhängigen Qualitätssicherung

  40. Produkt- und prozessabhängige Qualitätszielbestimmung • Qualitätsziele explizit und transparent vor Entwicklungsbeginn festlegen • Vorteile für Auftraggeber (Kostentransparenz, Festlegung der Anforderungen) • Vorteile für Lieferant • Maßnahmen für Entwicklungsprozess und Q-Prüfung • Wahl geeigneter Methoden und Werkzeuge • Planungs- und Kalkulationssicherheit für beide

  41. Quantitative Qualitätssicherung • Messen ist zwar schwer, aber nützlich für ... • besseres Verständnis unterschiedlicher Q-Merkmale (deskriptive Modelle) • bessere Planung und Sicherung von Q-Merkmalen (präskriptive Modelle) • Verbesserung von Entwicklungsansätze • Methoden und Werkzeuge zur Planung und Durch-führung der Datenerfassung sowie zur statistischen Auswertung / Präsentation von Messdaten • Metriken sind ziel- und kontextabhängig!

  42. Maximale konstruktive Qualitätssicherung • “Vorbeugen ist besser als heilen!“ • Viel konstruktiv – wenig analytisch! • Beispiele: • Vollständige Zweigüberdeckung, wenn Verzweigungslogik nicht zu komplex • Explizite Vereinbarung aller Variablen mit Typfestlegung • Vorteile: • Direkte Verbesserung der Produktqualität • Reduziert und ermöglicht analytische Maßnahmen • Vermeidung von Fehlern

  43. Frühzeitige Fehlerentdeckung und -behebung • Fehler • Jede Abweichung von den Anforderungen des Auftraggebers • Jede Inkonsistenz in den Anforderungen • Jede Verzögerung bei Entdeckung  exponentieller Kostenanstieg • Ziel: QM-Maßnahmen (konstruktiv / analytisch) verstärkt am Beginn der SW-Entwicklung einsetzen • Vermeidung von Summationseffekten in nach-folgenden Phasen

  44. Summation von Fehlern und Mängeln Anforderungs- definition Korrekte Anforderungen Fehlerhafte Anforderungen Korrekte Spezifikation Spezifikations- fehler Induzierte Fehler aus Anforderungen System- spezifikation Korrekter Entwurf Entwurfs- fehler Induzierte Fehler aus Anforderungen | Spezifikation Entwurf Korrektes Programm Programm- fehler Induzierte Fehler aus Anforderungen | Spezifikation | Entwurf Realisierung Korrektes Verhalten Korrigierte Fehler Bekannte un- korrigierte Fehler Unbekannte Fehler Test und Integration

  45. Vorzeitige FehlerentdeckungVorteile • Vermeidung von Fehlern in späteren Phasen • Reduzierung von Kosten • 55% aller Fehler entstehen in der Anforderungs- und Entwurfsphase [IEEE Software, Jan.1985] • 35% dieser Fehler bei Abnahme / im Betrieb gefunden • Fehlerbeseitigung 100fach höher als in der Definitionsphase • Mit höherer Wahrscheinlichkeit Fehlerkorrektur richtig • Reduzierung der Fehlerfortpflanzung Fehler besser vermeiden – oder zumindest frühzeitig erkennen!

  46. Entwicklungsbegleitende, integrierte Qualitätssicherung • Q-Sicherung begleitet gesamte SW-Entwicklung in jeder Phase • Vorteile: • Einbettung der Q-Sicherung in das organisatorische Ablauf-modell der SW-Entwicklung • QS findet dann statt, wenn sie angebracht ist • QS natürlicher Teil der Software-Erstellung • Teilprodukt erst dann in der nächster Phase verfügbar, wenn eine bestimmte Qualität gesichert ist • Qualitätsniveau zu jedem Zeitpunkt sichtbar • Realistische Beurteilung des Entwicklungsfortschritts

  47. Entwicklungsbegleitende, integrierte Qualitätssicherung Software-Entwicklung Software-Entwicklung Definieren Definieren Definieren Änderungen QS- Plan Produktmodell Produktmodell Produktmodell Prüfen und freigeben Entwerfen Entwerfen Entwerfen Änderungen Produktarchitektur Produktarchitektur Produktarchitektur Prüfen und freigeben Implementieren Implementieren Implementieren Änderungen Produkt Produkt Produkt Prüfen und freigeben

  48. Unabhängige Qualitätssicherung • „testing is a destructive process, even a sadistic process,...“ [Myers, 1979] • 2 Alternativen • QS organisatorisch unabhängig von der Entwicklung • QS ist Teil der Entwicklung • Vor- und Nachteile beider Ansätze

  49. Alternative 1:QS unabhängig von Entwicklung • Vorteile • Entwicklung kann keinen Druck auf die QS ausüben • QS ist neutral • Klare Budgetaufteilung möglich • Bedeutung der QS (kein “Anhängsel“ der Entwicklung) • Nachteile • Gefahr der Isolierung von der Entwicklung • gleichmäßige Personalauslastung schwierig

  50. Alternative 2:QS Teil der Entwicklung • Vorteile • Personal kann flexibler eingesetzt werden • QS nicht im Abseits, sondern bekommt alles mit • Gemeinsame Teamarbeit und vertrauensvollere Zusammenarbeit leichter möglich • Nachteile • Entwicklungs-Management kann Druck auf die QS ausüben • Mögliche Umverteilung der Budgetmittel zugunsten der Entwicklung

More Related