Qualitätssicherung von Software (SWQS)

Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 2.7.2013: Reifegradmodelle

Fragen zur Wiederholung • Was wissen Sie über die ISO 9000?

Wo stehen wir? • Einleitung, Begriffe, Software-Qualitätskriterien • Testverfahren, Teststufen, Testüberdeckung • automatisierte Testfallerstellung • Verifikation und Validierung, Modellprüfung • statische und dynamische Analysetechniken • Softwarebewertung, Softwaremetriken • Codereview- und andere Inspektionsverfahren • Zuverlässigkeitstheorie, Fehlerbaumanalyse • Qualitätsstandards, Qualitätsmanagement, organisatorische Maßnahmen

ISO 9000 - Kritikpunkte • “alles oder nichts”, Zertifizierungsaspekt • Schwerpunkt ist Prozessdokumentation, nicht die Angemessenheit der Prozesse • Prozess- statt Produktsicht

ISO 25000 “SQuaRE” • Software engineering – Software product Quality Requirements and Evaluation (Qualitätskriterien und Bewertung von Softwareprodukten) • 2500n – Qualitätsplanung und -management • 2501n – Qualitätsmodelle und Leitlinien • 2502n – Qualitätsmessung • 2503n – Qualitätsanforderungen • ... • Produkt- statt Prozessqualität • Produkt im Umfeld

Anwendungsbezogene Qualität • „Quality in use“

Produktqualität • „Internal software quality“

Referenzmodell zur Qualitätsmessung

Qualitätsanforderungen ISO 25000 identifiziert folgende Arten von Systemanforderungen: • Human business process requirements • Information system requirements • Computer system requirements • Computer hardware requirements • Operating system requirements • Application software requirements • Datra requirements • Mechanical system requirements

CMMI • Capability Maturity Model Integration, Reifegradsmodellintegration • Vorläufer: CMM • “Erfinder”: CMU SEI • Fokus auf Verbesserung der Prozesse • nicht: Fokus auf Bewertung • nicht: Fokus auf Personen (People-CMM) • nicht: Fokus auf Technologie • Ideologie (wie bei ISO9000) • Produktqualität wird überwiegend durch den Herstellungsprozess des Produktes bestimmt • Prozesse werden in Prozessgruppen eingeteilt und verbessert

Lesen (pp 1-70):http://www.sei.cmu.edu/library/assets/whitepapers/10tr033de_v11.pdf • Teil der Ablauforganisation • Strukturierung und Organisation des Projektablaufs („Softwareprozesse“) • Phaseneinteilung, Meilensteine • Berichtswesen und Dokumentation • Freigabeverfahren, Präsentation • ... • keine allgemeingültige Antwort auf die Frage „was ist das optimale Vorgehen?“ • abgeleitete Frage: „wie kann die Effizienz des Vorgehens beurteilt bzw. gesteigert werden?“

Historie des CMMI • Ausgangssituation: 1983 US DOD – 28 Monate-Projekt hat 20 Monate Verspätung, 4 Jahres-Projekt braucht 7 Jahre, kein einziges SW-Projekt rechtzeitig; 59 Milliarden US$ Verlust wegen Abbruch des A12 Flugzeugprojektes wg. Softwareproblemen • 1984 Gründung des SEI an der CMU • Mission: Probleme des Software Engineering und Lösungsvorschläge aufzeigen • 1987: CMM V 1, Fragebogen • 1991 V1.0, revidiertes Modell • 1997 V2.0 zurückgezogen, CMMI gestartet • 2002 freigegeben • 2010 V1.3 (CMMI-DEV, CMMI-ACQ, CMMI-SVC) ! Achtung, Folien beziehen sich teilweise noch auf CMM !

Zielsetzung des CMMI • Keine “silver bullet”-Methoden, sondern nachhaltige Prozessverbesserungen (langfristiger Ansatz) • Bessere Vorhersagbarkeit der Prozesse • Geordnete Menge inkrementeller, bewährter Verbesserungen in logischer Abfolge • Spezialisierungen: • "CMMI for Development" (CMMI-DEV) • "CMMI for Acquisition" (CMMI-ACQ) • "CMMI for Services" (CMMI-SVC) • CMMI-DEV • 4 Fähigkeitsgrade • 5 Reifegrade • 18 “Key Process Areas”

Nutzungsvorteile Process improvement benefits fall into eight general categories: • improved schedule and budget predictability • improved cycle time • increased productivity • improved quality (as measured by defects) • increased customer satisfaction • improved employee morale • increased return on investment • decreased cost of quality • Staged representation vs. continuous representation

Begriffe des CMM (I) • Capability Level: Der Fähigkeitsgrad bezeichnet den Grad der Institutionalisierung eines einzelnen Prozessgebiets • Maturity Level: beschreibt den Reifegrad des Entwicklungsprozesses • Key Process Area: Mengen vonSchlüsselprozessen, die im entsprechenden Reifegrad durchgeführt werden • Common Features: Unterteilung der Schlüsselprozesse in gemeinsame Bereiche • Key Practices: konkrete Schlüsselpraktiken (Anweisungen), um die Schlüsselprozesse zu erfüllen

Fähigkeitsgrade CMMI kennt folgende Fähigkeitsgrade • 0 – Incomplete : Die Arbeit wird so durchgeführt, dass die fachlichen Ziele ("Specific Goals“) nicht erreicht werden • 1 – Performed : Die Arbeit wird so durchgeführt, dass die fachlichen Ziele erreicht werden • 2 – Managed : Die Arbeit wird vom Management geführt • 3 – Defined : Die Arbeit wird mit Hilfe eines angepassten Standardprozesses durchgeführt und die Arbeitsweise kontinuierlich verbessert Der Fähigkeitsgrad kann von einem Auditor bestätigt werden

Maturity Level (Reifegrade) • Stufen in der Entwicklung einer Organisation auf dem Weg zu optimalen Softwareprozessen • 5 Stufen definiert: initial, wiederholbar, definiert, beherrscht, optimierend (Definition siehe später) • Jeder Grad ist eine spezifische Schicht in der kontinuierlichen Prozessverbesserung, die mit definierten Schritten erreicht wird • Reifegrade können nur nacheinander durchlaufen werden

Key Process Areas • Jeder Reifegrad ist in Key Process Areas unterteilt • Key Process Areas identifizieren eine Menge von zusammenhängenden Aktivitäten, welche bestimmte Ziele verfolgen. • Es müssen alle Ziele einer Key Process Area über mehrere Projekte hinweg kontinuierlich erfüllt sein, damit die durch die Key Process Area definierten Fähigkeiten institutionalisiert sind. • Die Key Process Areas in höheren Reifegraden bauen auf den Key Process Areas niedrigerer Grade auf.

Common Features Die Key Process Areas sind jeweils in fünf Aufgabenbereiche (Common Features) untergliedert: • Unterstützung der Durchführung: Definition von Leitlinien, Unterstützung durch das Management • Fähigkeit zur Durchführung: Zuweisung von Ressourcen, Errichten von Organisationsstrukturen, Training • Durchzuführende Aktivitäten: Beschreibung der Schlüsselaufgaben • Bewertung und Analyse: Erhebung von Daten über die Umsetzung • Überprüfung der Umsetzung: Überprüfung durch die Qualitätssicherung und das Management

Key Practices Die Aktivitäten, Vorgehensweisen und Anweisungen innerhalb der Key Process Areas werden in den Key Practices beschrieben • Die Key Practices beschreiben dabei aber nur das ,,was” (Infrastruktur, Tätigkeiten usw.) und nicht das ,,wie” (Tools, Formate o.ä.) • Sie werden in jeder Key Process Area einem der Common Features zugeordnet.

Grafik: CMU SEI

Erwarteter Nutzen (Vorhersagbarkeit, Kontrolle, Effektivität) Grafik: CMU SEI

Qualitätssicherung von Software (SWQS)