Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 4.7.2013: Fazit."—  Präsentation transkript:

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

2 Folie 2 H. 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

3 Folie 3 H. 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

4 Folie 4 H. 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

5 Folie 5 H. 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

6 Folie 6 H. 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

7 Folie 7 H. 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

8 Folie 8 H. 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

9 Folie 9 H. 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

10 Folie 10 H. 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

11 Folie 11 H. 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

12 Folie 12 H. 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

13 Folie 13 H. 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

14 Folie 14 H. 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

15 Folie 15 H. 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

16 Folie 16 H. 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

17 Folie 17 H. Schlingloff, Software-Qualitätssicherung Erwartung der Leistungssteigerung Grafik: CMU SEI

18 Folie 18 H. Schlingloff, Software-Qualitätssicherung Grafik: CMU SEI

19 Folie 19 H. 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?

20 Folie 20 H. Schlingloff, Software-Qualitätssicherung Weitere kritische Fragen zum Reifegrad L2 L3 Werden Aufzeichnungen über die Größe jedes Softwarekonfigurationselements geführt? L2 L3 Werden Statistiken über Codefehler und Testfehler gesammelt? L3 L4 Werden Statistiken über Softwaredesignfehler gesammelt? L3 L4 Werden Maßnahmen, die aus Design-Reviews resultieren, auch tatsächlich umgesetzt (Anzahl der offenen Review-Findings)? L3 L4 Werden die Maßnahmen, die aus Code-Reviews resultieren, auch tatsächlich umgesetzt? L4 L5 Wird die Anzahl der Designfehler geschätzt und mit der Anzahl der tatsächlich aufgetretenen Fehler verglichen? L4 L5 Wird die Abdeckung des Designs und Codes durch Reviews gemessen und aufgezeichnet? L4 L5 Wird die Testabdeckung (C0, C1) in jeder Testphase gemessen und aufgezeichnet?

21 Folie 21 H. 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

22 Folie 22 H. Schlingloff, Software-Qualitätssicherung

23 Folie 23 H. 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

24 Folie 24 H. 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 (2012) Zielsetzung: Umfassender Rahmen, Integration verschiedener vorhandener Ansätze (ISO, CMMI, Bootstrap, …) Stark an CMM angelehnt Bewertung von Prozessen, nicht von Organisationen

25 Folie 25 H. 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)

26 Folie 26 H. Schlingloff, Software-Qualitätssicherung Struktur des Modells

27 Folie 27 H. Schlingloff, Software-Qualitätssicherung Prozess-Kategorien Process categoryBrief description Customer-SupplierProcesses that directly impact the customer EngineeringProcesses that specify, implement, or maintain a system and software product ProjectProcesses that establish the project, and co-ordinate and manage its resources SupportProcesses that enable and support the performance of the other processes on the project OrganizationProcesses 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

28 Folie 28 H. Schlingloff, Software-Qualitätssicherung Prozesse Kundenkategorie CUS.1Acquire software product and/or service CUS.1.1Identify the need CUS.1.2Define the requirements CUS.1.3Prepare acquisition strategy CUS.1.4Prepare request for proposal CUS.1.5Select software product supplier CUS.2Establish contract CUS.2.1 Review before contract finalization CUS.2.2Negotiate contract CUS.2.3Determine interfaces to independent agents CUS.2.4Determine interfaces to subcontractors CUS.3Identify customer needs CUS.3.1Obtain customer requirements and requests CUS.3.2Understand customer expectations CUS.3.3Keep customers informed CUS.4Perform joint audits and reviews … CUS.5Package, deliver, and install the software CUS.6Support operation of software CUS.7Provide customer service CUS.8Assess customer satisfaction

29 Folie 29 H. 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.

30 Folie 30 H. 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.1Establish 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.2Define quality metrics. Define metrics that measure the results of project activities to help assess whether the relevant quality goals have been achieved. PRO.5.3Identify 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.4Perform quality activities. Perform the identified quality activities. PRO.5.5Assess 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.6Take corrective action. When quality goals are not achieved, take corrective action.

31 Folie 31 H. 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.1Engineer the business ORG.2Define the process ORG.3Improve the process ORG.4Perform training ORG.5Enable reuse ORG.6Provide software engineering environment ORG.7Provide work facilities

32 Folie 32 H. Schlingloff, Software-Qualitätssicherung Reifegrade Unterschied zu CMM? Wieso?

33 Folie 33 H. Schlingloff, Software-Qualitätssicherung 2D-Architektur von SPICE

34 Folie 34 H. 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

35 Folie 35 H. 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 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)

36 Folie 36 H. Schlingloff, Software-Qualitätssicherung SPICE vs. ISO 9000 Etwas anderer Fokus (Verbesserung vs. Zertifizierung) SPICE etwas detaillierter und spezifischer, ISO allgemeiner ISO 9001 requirementsProcess categories and processes 4.1 Management responsibilityEngineer the business Manage quality (build project teams) Assess customer satisfaction 4.2 Quality systemManage quality Perform quality assurance Define the process (Improve the process) 4.3 Contract reviewEstablish contract Identify customer needs Develop system requirements and design Manage risks (Perform joint audits and reviews)

37 Folie 37 H. Schlingloff, Software-Qualitätssicherung Break

38 Folie 38 H. Schlingloff, Software-Qualitätssicherung Was haben wir erreicht? Feedback?

39 Folie 39 H. 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?

40 Folie 40 H. Schlingloff, Software-Qualitätssicherung Schöne Ferien!


Herunterladen ppt "Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 4.7.2013: Fazit."

Ähnliche Präsentationen


Google-Anzeigen