qualitätssicherung von software (swqs) prof. dr. holger schlingloff humboldt-universität zu berlin...
TRANSCRIPT
Qualitätssicherung von Software (SWQS)
Prof. Dr. Holger Schlingloff
Humboldt-Universität zu Berlinund
Fraunhofer FOKUS
4.7.2013: Fazit
Folie 2H. Schlingloff, Software-Qualitätssicherung
CMMI: Prozess-Reifegrade
Stufe 1:
Initial
Stufe 2:
Wiederholbar
Stufe 3:
Definiert
Stufe 4:
Beherrscht
Stufe 5:
Optimierend
Projekt- management
Prozess- management
Quantitäts- management
Änderungs- management
Stabile
Umgebung
Gemeinsame
Prozesse
Änderungs-
kontrolle
Ständige
Entwicklung
Folie 3H. Schlingloff, Software-Qualitätssicherung
Stufe 1: Initial
• Merkmal: Keine stabile Umgebung, ad-hoc Durchführung
• Fokus: gute Mitarbeiter• Unvorhersagbares Ergebnis: bei erneuter
Durchführung des Projektes würde alles ganz anders laufen
• Brandbekämpfung statt Planung• Planabweichung in Krisensituationen• Gelingen des Projektes nur durch äußersten
Einsatz aller Beteiligter, hängt an Einzelpersonen
• Risikobehaftet, unplanbar und ineffizient
Folie 4H. Schlingloff, Software-Qualitätssicherung
Transparenz des Entwicklungsprozesses in Stufe 1
• In Stufe 1 ist der Prozessablauf von außen nicht einsichtig. Die Ergebnisse sind sporadisch und nicht wiederholbar.
Grafik: CMU SEI
Folie 5H. Schlingloff, Software-Qualitätssicherung
Stufe 2: Wiederholbar (repeatable)
•Merkmal: Selbe Anforderungen ergeben selbe Resultate
•Fokus: Projektmanagement Richtlinien für SPM existieren und werden
umgesetzt Überwachung von Zeit, Kosten,
Produktqualität
•Basierend auf früheren Projekten•Softwarestandards,
Konfigurationsmanagement•Stabiler Prozess
Folie 6H. Schlingloff, Software-Qualitätssicherung
Transparenz des Entwicklungsprozesses in Stufe 2
• In Level 2 werden Kundenanforderungen und Arbeitsprodukte kontrolliert und es bestehen grundlegende Managementtechniken.
• Einsichtnahme und Reaktion auf Abweichung durch das Management oder den Kunden zu bestimmten Zeitpunkten innerhalb des Projekts möglich (Meilensteine)
• Abläufe zwischen den Meilensteinen werden nicht betrachtet.
Grafik: CMU SEI
Folie 7H. Schlingloff, Software-Qualitätssicherung
Key Process Areas in Stufe 2
• Anforderungsmanagement: Erfassen und Verwalten der Anforderungen an das System, Reaktion auf Anforderungsänderungen
• Projektplanung: Aufwandsabschätzung, Zeit-, Budget- und Ressourcenplanung, Risikoanalyse
• Projektüberwachung: Berichtswesen, Soll-/Ist-Vergleiche, Fortschrittskontrolle, Korrekturmaßnahmen
• Subkontraktmanagement: Auswahl von Partnern, Vergabe von Aufgaben an Partner. Planung, Durchführung, Kontrolle und Berichtswesen wird von den Partnern durchgeführt
• Qualitätssicherung: Erstellen von Qualitätssicherungsplänen, Prüfung von Prozess- und Produktqualität, Berichte an das Management
• Konfigurationsmanagement: Planung und Durchführung der Verwaltung aller Produkte im Entwicklungsprozess
Folie 8H. Schlingloff, Software-Qualitätssicherung
Stufe 3: Definiert (defined)
•Merkmal: Wohldokumentierte Prozesse
•Fokus: Organisationsunterstützung Stabile und wiederholbare SE- und SPM-Prozesse Abnahmekriterien, Standards, QS-Maßnahmen
definiert und dokumentiert Möglichkeit der Anpassung von Standards
•Rolle des Softwareprozess-Verantwortlichen
•Weiterbildungsmaßnahmen eingeplant
•Regelmäßige Expertenbegutachtung
Folie 9H. Schlingloff, Software-Qualitätssicherung
Transparenz des Entwicklungsprozesses in Stufe 3
• Im Gegensatz zu den Prozessen in Stufe 2 sind jetzt auch die Teilaktivitäten zwischen den Meilensteinen vom Management und anderen Gruppen aus sichtbar.
• Es herrscht Einverständnis über die Rollen und Verantwortlichkeiten der am Prozess Beteiligten.
Grafik: CMU SEI
Folie 10H. Schlingloff, Software-Qualitätssicherung
Key Process Areas in Stufe 3
• Organisationsprozesse: Etablieren von Verantwortlichkeiten, Koordination der Prozessverbesserung
• Prozessdefinition: Entwicklung des Standardsoftwareprozesses und Vorgaben für die projektspezifischen Anpassung
• Training: Planung und Durchführung von formellen und informellen Trainingsprogrammen
• Integriertes Softwaremanagement: Anpassung des Standardsoftwareprozesses an die Projektgegebenheiten, Planen und Managen des projektbezogenen Softwareprozesses (Aufbauend auf der Projektplanung und -überwachung aus Level 2)
• Ingenieurmäßige Produktentwicklung: Umsetzung des projektbezogenen Softwareprozesses
• Gruppenkommunikation: Aufrechterhaltung der Kommunikation zwischen den beteiligten Gruppen, Verständigung über Anforderungen und Aufgaben
• Peer Reviews: Planung und Durchführung von Expertenbegutachtungen, Identifikation und Entfernung von Fehlern
Folie 11H. Schlingloff, Software-Qualitätssicherung
Stufe 4: Beherrscht (managed)
•Merkmal: Quantitativ messbare Prozesse
•Fokus: Produkt- und Prozessqualität Leistungsmessung von Produktivität und
Qualität Metriken für Software
•Messbare, vorhersagbare Prozesse in definierten Grenzen
•Messbare, vorhersagbare Produktqualität
•Steuerungsmöglichkeit bei Schwankungen
Folie 12H. Schlingloff, Software-Qualitätssicherung
Transparenz des Entwicklungsprozesses in Stufe 4
• Ähnlich wie in Stufe 3 sind nun auch die Zwischenphasen anderen Gruppen (Management, Kunden) gegenüber transparent.
• Weiter sind nun auf der Basis der quantitativen Ergebnisse Korrekturen auch in den Zwischenphasen möglich.
Grafik: CMU SEI
Folie 13H. Schlingloff, Software-Qualitätssicherung
Key Process Areas in Stufe 4
•Quantitatives Prozessmanagement: Quantitative Kontrolle der Prozesse, Identifikation von Abweichungen
•Qualitätsmanagement: Entwicklung eines quantitativen Verständnisses für Prozess- und Produktqualität
Folie 14H. Schlingloff, Software-Qualitätssicherung
Stufe 5: Optimierend (optimizing)
• Merkmal: Gesamte Organisation fokussiert auf kontinuierliche Prozessverbesserung
• Fokus: Ständige Evaluation und Einführung neuer Technologien und Verbesserungsmöglichkeiten
• Möglichkeit zur Stärken/Schwächenanalyse
• Proaktive Fehlervermeidung
• Dauernde Implementierungsmöglichkeit für Verbesserungen der Softwareprozesse (direkte Einbringung von Verbesserungsvorschlägen)
• Verbesserungen auf der Meta-Ebene
Folie 15H. Schlingloff, Software-Qualitätssicherung
Transparenz des Entwicklungsprozesses in Stufe 5
• Basierend auf der quantitativen Analyse aus Stufe 4 kann der Entwicklungsprozess abgeändert und optimiert werden. Dies betrifft nicht nur einzelne Zwischenphasen, sondern auch den gesamten Entwicklungsprozess
Grafik: CMU SEI
Folie 16H. Schlingloff, Software-Qualitätssicherung
Key Process Areas in Stufe 5
•Fehlervermeidung: Identifikation von Fehlerquellen, Änderung des Entwicklungsprozesses, Übernahme der Änderungen in den Standardsoftwareprozess
•Technologiewandel: Identifikation und Einführung nützlicher neuer Techniken
•Prozeßwandel: Verbesserung des Entwicklungsprozesses
Folie 17H. Schlingloff, Software-Qualitätssicherung
Erwartung der Leistungssteigerung
Grafik: CMU SEI
Folie 18H. Schlingloff, Software-Qualitätssicherung
Grafik: CMU SEI
Folie 19H. Schlingloff, Software-Qualitätssicherung
Fragen zur Bestimmung des Reifegrades
Fragen zur Stufe 2• Werden quantifizierte Vergleiche des Ist-Personaleinsatzes mit
dem Soll-Personaleinsatz durchgeführt?• Werden Statistiken über den Testfortschritt und die Lieferung der
Softwarekomponenten aufgezeichnet?• Werden Statistiken erstellt, die den Zusammenhang zwischen
dem Umfang / Inhalt eines Software-Release und dem Aufwand aufzeigen?
• Werden Statistiken über die geplanten und tatsächlich aufgetretenen Fehler verglichen?
• Werden Statistiken über Softwareeinheiten in der Modul-/Programmtestphase erstellt?
• Wird die Speicherplatzbelegung gemessen und aufgezeichnet?• Wird der Datendurchsatz gemessen und aufgezeichnet?• Wird die Performance der Hardware gemessen und
aufgezeichnet?• Werden Softwareproblemberichte, die aus der Testphase
resultieren, bis zu ihrem Abschluss verfolgt?
Folie 20H. Schlingloff, Software-Qualitätssicherung
Weitere kritische Fragen zum Reifegrad
• L2L3 Werden Aufzeichnungen über die Größe jedes Softwarekonfigurationselements geführt?
• L2L3 Werden Statistiken über Codefehler und Testfehler gesammelt?
• L3L4 Werden Statistiken über Softwaredesignfehler gesammelt?• L3L4 Werden Maßnahmen, die aus Design-Reviews resultieren,
auch tatsächlich umgesetzt (Anzahl der offenen Review-Findings)?• L3L4 Werden die Maßnahmen, die aus Code-Reviews resultieren,
auch tatsächlich umgesetzt?
• L4L5 Wird die Anzahl der Designfehler geschätzt und mit der Anzahl der tatsächlich aufgetretenen Fehler verglichen?
• L4L5 Wird die Abdeckung des Designs und Codes durch Reviews gemessen und aufgezeichnet?
• L4L5 Wird die Testabdeckung (C0, C1) in jeder Testphase gemessen und aufgezeichnet?
Folie 21H. Schlingloff, Software-Qualitätssicherung
Unmöglichkeit des Stufenspringens
• Organisationen niedrigerer Stufe können auch Prozesse höheren Reifegrades durchführen
• Prozessfähigkeiten werden stufenweise aufgebaut, weil sie teilweise voneinander abhängig sind
• Jede Stufe ist notwendige Grundlage für die Verbesserungen auf der nächsten Stufe, z.B. Ingenieursmäßige Softwarekonstruktion (3) ohne
entsprechendes etabliertes Management (2) zwecklos Metriken (4) ohne definierte Prozesse (3) überflüssig Verbesserungsvorschläge gehen bei
nichtwiederholbaren Prozessen verloren
Folie 22H. Schlingloff, Software-Qualitätssicherung
Folie 23H. Schlingloff, Software-Qualitätssicherung
Fallstudien
• Bereits Stufe 2 bringt 30% Produktivitätszuwachs• Motorola halbiert die Zahl der Softwarefehler auf jeder
Stufe• In jedem Fall langfristige Amortisation der Kosten• Zahl der Anwender des CMM verdoppelt sich alle 5
Jahre (seit 1987)• Software-Qualitätssicherung ist die größte
Herausforderung beim Aufsteigen zur Stufe 2• Organisationsprozess-Definition ist eine der größten
Herausforderungen beim Aufsteigen zur Stufe 3• Durchschnittswerte:
25 Monate von Stufe 1 nach 2 22 Monate von 2 nach 3 36 Monate von 3 nach 4
• Änderung der Unternehmenskultur
Folie 24H. Schlingloff, Software-Qualitätssicherung
SPICE (ISO 15504)
SPICE: Software Process Improvement Capability Determination
• SPICE ist ein Projekt der ISO zur Entwicklung eines Standards für Software Process Assessments erstmals 1998 als technischer Bericht publiziert Standard aktuell überarbeitet: ISO IEC 15504 (2012)
• Zielsetzung: Umfassender Rahmen, Integration verschiedener vorhandener Ansätze (ISO, CMMI, Bootstrap, …) Stark an CMM angelehnt Bewertung von Prozessen, nicht von Organisationen
Folie 25H. Schlingloff, Software-Qualitätssicherung
Charakteristika von SPICE
• Abdeckung einer weiten Spanne von SW-Organisationen und Anwendungen
• Referenzmodell• Vergleichbarkeit, Wiederholbarkeit, Objektivität• keine weiteren Voraussetzungen• praktische Durchführbarkeit, Effizienz
• „can be used by organizations involved in planning, managing, monitoring, controlling and improving the acquisition, supply, development, operation, evolution and support of software“
• Aspekte Bewertung (Assessment) Verbesserung (Improvement) Beurteilung (Determination)
Folie 26H. Schlingloff, Software-Qualitätssicherung
Struktur des Modells
Folie 27H. Schlingloff, Software-Qualitätssicherung
Customer-Supplier
Engineering
Project
Organization
Support
Prozess-Kategorien
Process category Brief description
Customer-Supplier Processes that directly impact the customer
Engineering Processes that specify, implement, or maintain a system and software product
Project Processes that establish the project, and co-ordinate and manage its resources
Support Processes that enable and support the performance of the other processes on the project
Organization Processes that establish the business goals of the organi-zation and develop process, product, and resource assets which will help the organization achieve its business goals
> 200 einzelne Prozesse in diesen Kategorien, die bewertet werden
Folie 28H. Schlingloff, Software-Qualitätssicherung
Prozesse Kundenkategorie
• CUS.1 Acquire software product and/or service CUS.1.1 Identify the need CUS.1.2 Define the requirements CUS.1.3 Prepare acquisition strategy CUS.1.4 Prepare request for proposal CUS.1.5 Select software product supplier
• CUS.2 Establish contract CUS.2.1 Review before contract finalization CUS.2.2 Negotiate contract CUS.2.3 Determine interfaces to independent agents CUS.2.4 Determine interfaces to subcontractors
• CUS.3 Identify customer needs CUS.3.1 Obtain customer requirements and requests CUS.3.2 Understand customer expectations CUS.3.3 Keep customers informed
• CUS.4 Perform joint audits and reviews …
• CUS.5 Package, deliver, and install the software• CUS.6 Support operation of software• CUS.7 Provide customer service• CUS.8 Assess customer satisfaction
Customer-Supplier
Engineering
Project
Organization
Support
Folie 29H. Schlingloff, Software-Qualitätssicherung
Prozesse Entwicklungskategorie
• ENG.1 Develop system requirements and design• ENG.2 Develop software requirements• ENG.3 Develop software design• ENG.4 Implement software design• ENG.5 Integrate and test software• ENG.6 Integrate and test system• ENG.7 Maintain system and software
• ENG.1.1 Specify system requirements. Determine the required functions and capabilities of the system and document in a system requirements specification.
Note: the system requirements specification describes such things as– functions and capabilities of the system;– performance of the system;– safety;– reliability;– security;– human engineering;– interface;– operations, and maintenance requirements;– design constraints and qualification requirements.See CUS.3 for discussion of customer requirements used as an input to system requirements
analysis.
Customer-Supplier
Engineering
Project
Organization
Support
Folie 30H. Schlingloff, Software-Qualitätssicherung
Prozesse Projektkategorie
• PRO.1 Plan project life cycle• PRO.2 Establish project plan• PRO.3 Build project teams• PRO.4 Manage requirements• PRO.5 Manage quality• PRO.6 Manage risks• PRO.7 Manage resources and schedule• PRO.8 Manage subcontractors
• Beispiel: PRO.5.1 Establish quality goals. Based on the customer's requirements for quality,
establish quality goals for various checkpoints within the project's software life cycle. PRO.5.2 Define quality metrics. Define metrics that measure the results of project
activities to help assess whether the relevant quality goals have been achieved. PRO.5.3 Identify quality activities. For each quality goal, identify activities which
will help achieve that quality goal and integrate these activities into the software life cycle model.
PRO.5.4 Perform quality activities. Perform the identified quality activities. PRO.5.5 Assess quality. At the identified checkpoints within the project's software
life cycle, apply the defined quality metrics to assess whether the relevant quality goals have been achieved.
PRO.5.6 Take corrective action. When quality goals are not achieved, take corrective action.
Customer-Supplier
Engineering
Project
Organization
Support
Folie 31H. Schlingloff, Software-Qualitätssicherung
Prozesse Unterstützungs- und Organisationskategorie
• SUP.1Develop documentation• SUP.2Perform configuration management• SUP.3Perform quality assurance• SUP.4Perform problem resolution• SUP.5Perform peer reviews
• ORG.1 Engineer the business• ORG.2 Define the process• ORG.3 Improve the process• ORG.4 Perform training• ORG.5 Enable reuse• ORG.6 Provide software engineering environment• ORG.7 Provide work facilities
Customer-Supplier
Engineering
Project
Organization
Support
Folie 32H. Schlingloff, Software-Qualitätssicherung
Reifegrade
• http://www.q-labs.de/images/user/Management_SW_Lieferanten_VW.pdf
Unterschied zu CMM? Wieso?
Folie 33H. Schlingloff, Software-Qualitätssicherung
2D-Architektur von SPICE
Process category/process
CF
CF
CF
CF
CF
CFCL3
CL4
CL5
CF
CF
CFCL1
CL0
1.1
2.1
2.3
3.1
3.2
4.1
4.2
5.1
5.2
Customer-supplier Engineering Project Support Organization
CUS.1Customer needs CUS.8 ENG.1 ENG.7 PRO.1 PRO.8 SUP.1 SUP.5 ORG.1 ORG.7
Trac
kin
g pe
rfo
rman
ce
Pla
nn
ed
-an
d-t
rack
ed
Ca
pa
bili
ty le
vel /
Co
mm
on
fea
ture
Process - common feature intersection
- represents the base practices for the process and the generic practices of the common feature
Folie 34H. Schlingloff, Software-Qualitätssicherung
Varianten und Erweiterungen
•Der Standard stellt ein Metamodell für die Bildung von Varianten zur Verfügung Erweiterungen dürfen die Basis nicht
beeinträchtigen Varianten sind ausgewählte wohldefinierte
Teilmengen Rückverfolgbarkeit, Dokumentation,
Abhängigkeiten
•Beispiel: Automotive-SPICE
Folie 35H. Schlingloff, Software-Qualitätssicherung
SPICE vs. CMMI
• CMMI und SPICE sind ähnlich aufgebaut• CMMI erfüllt die Vorgaben von SPICE bzgl. der
Methodik und Strukturen, um Bewertungen von Softwareprozessen durchzuführen
• Das Prozessmodell von SPICE ist feiner gegliedert• Die Detaillierungstiefe und Ausführlichkeit ist bei
CMMI größer (ca. 1000 Seiten gegenüber 360 Seiten)
• SPICE enthält Inhalte, die bei CMMI nicht enthalten sind (z.B. „Identify Interfaces“ in Project Management)
• CMMI enthält Inhalte, die bei SPICE nicht enthalten sind (z.B. Intergroup Coordination)
Folie 36H. Schlingloff, Software-Qualitätssicherung
SPICE vs. ISO 9000
• Etwas anderer Fokus (Verbesserung vs. Zertifizierung)• SPICE etwas detaillierter und spezifischer, ISO allgemeiner
ISO 9001 requirements Process categories and processes
4.1 Management responsibility Engineer the business
Manage quality
(build project teams)
Assess customer satisfaction
4.2 Quality system Manage quality
Perform quality assurance
Define the process
(Improve the process)
4.3 Contract review Establish contract
Identify customer needs
Develop system requirements and design
Manage risks
(Perform joint audits and reviews)
Folie 37H. Schlingloff, Software-Qualitätssicherung
Break
Folie 38H. Schlingloff, Software-Qualitätssicherung
Was haben wir erreicht?
•Feedback?
Folie 39H. Schlingloff, Software-Qualitätssicherung
Was kommt als Nächstes?
•Studien-, Diplom-, Bachelor- und Master-Arbeiten: Es gibt immer was zu tun… Bitte sprechen Sie mich direkt an!
• Jobs, Industriepraktika usw.: Ihre Kenntnisse sind sehr gefragt! Bewerbungsschreiben erwünscht
•Und sonst?
Folie 40H. Schlingloff, Software-Qualitätssicherung
Schöne Ferien!