Softwaretechnik- Praktikum: 12. Vorlesung Jun.-Prof Prof.. Dr. Holger Giese Raum E 3.165 Tel. 60-3321 Email: hg@upb.de Übersicht I II III IV V Einleitung Ergänzungen zur Software-Entwicklung Software Management Software Qualitätssicherung Zusammenfassung Zusatz: Praxisvorträge von dspace Hella V12-2 Softwaretechnikpraktikum: IV Software-Qualitätssicherung (Fortsetzung) Jun.-Prof Prof.. Dr. Holger Giese Raum E 3.165 Tel. 60-3321 Email: hg@upb.de IV Software-Qualitätssicherung IV.1 Grundlagen IV.2 Analytisches Qualitätsmanagement IV.2.1 Analysierende Verfahren IV.2.2 Testende Verfahren IV.3 Konstruktives Qualitätsmanagement IV.5 Prozessqualität IV.6 Diskussion & Zusammenfassung IV.7 Literaturhinweise V12-4 IV.3 Konstruktives Qualitätsmanagement Software-Entwicklung Notationen Methoden (1) Werkzeuge SE/TSE Modellbasierte Software- Entwicklung (siehe 2. Studienabschnitt) Infrastruktur (2) Prozeduren und Arbeitsanweisungen (3) Vorlagen und Checklisten (4) Mitarbeiter Schulung & Zertifizierung Versions- und Konfigurationsmanagement (s. 1. Vorlesung) (1) Werkzeuge Formen der Werkzeugunterstützung Auswirkung auf die Produktqualität Auswirkung auf die Qualität der Wartung Auswirkung auf das Projektmanagement V12-5 V12-6 1
Formen der Werkzeugunterstützung Traditionelle Werkzeuge unterstützen den Entwickler bei den Aktivitäten einer Phase des Software Lebenszyklus. Computer Aided Software Engineering (CASE) Werkzeuge unterstützen den Entwickler bei Arbeiten, die mehrere Phase des Software Lebenszyklus umfassen. Customer analyst Programmer Tester Requirements determination Customer s Analysis Traditional Design Detailed design doc. Coding Program code files Testing Installed code files and maintenance Customer analyst Programmer Tester Requirements determination Customer s Analysis Upper -CASE Design Upper -CASE Coding Lower - CASE Testing CASE testing tools and maintenance CASE tool-supported R e p o s i t o r y V12-7 V12-8 Auswirkung auf die Produktqualität Beitrag zur Qualität bzgl. der Fehlerursachen Ursachen von Softwarefehlern traditionelle Werkzeuge CASE Werkzeuge 1. Fehlerhafte Anforderungen - sehr gering 2. Fehler in der Kommunikation zwischen Kunde und Entwickler - sehr gering 3. Abweichung von den Anforderungen - 4. Logische Entwurfsfehler - 5. Programmierfehler sehr sehr 6. Abweichungen von Programmier- und Dokumentationsrichtlinien beschränkt sehr 7. Schwächen des Testprozesses 8. Fehler in der Benutzerschnittstelle oder Verfahrensfehlern beschränkt beschränkt 9. Fehler in der Dokumentation beschränkt sehr Auswirkung auf die Qualität der Wartung Für Korrektive Wartung: Mittels CASE Werkzeugen automatisch generierte Dokumentation führt zu einer einfacheren und zuverlässigeren Identifikation von Fehlerursachen (Querverweise, Erfassung der Korrekturen, ) Für Adaptive Wartung: Vollständige und immer aktuellen Dokumentation aufgrund von automatischer Generierung erlaubt es benötigte Anpassungsschritte besser zu planen. Für funktionale Erweiterungen bei der Wartung: Vollständige und immer aktuellen Dokumentation aufgrund von automatischer Generierung erlaubt es benötigte Änderungs- und Erweiterungsschritte besser zu planen. V12-9 V12-10 Auswirkung auf das Projektmanagement Verringerte Kosten Verringerte Entwicklungszeiten Weniger Abweichungen vom Plan da In der Regel geringeren Fehlerraten Geringere Korrekturkosten ABER: bisher sind Projektkontrolle und CASE nicht wirklich integriert (2) Prozeduren und Arbeitsanweisungen Vorteile: Ausführung von Aktivitäten auf die effektivste und effizienteste Art. Effektive and effiziente Kommunikation zwischen Entwicklern und Wartungspersonal, die zu weniger Missverständnissen und daraus folgenden Fehlern führt. Vereinfachte Koordination zwischen den Aufgaben und Aktivitäten verschiedener Teams führt zu weniger Fehlern. V12-11 V12-12 2
Was wird durch Prozeduren geregelt? Die Fünf W's: Welche Aktivitäten müssen ausgeführt werden? Wie sollen die Aktivitäten ausgeführt werden? Wann sollen die Aktivitäten ausgeführt werden? Wo sollen die Aktivitäten ausgeführt werden? Wer sollen die Aktivitäten ausführen? Quellen für Prozeduren Internationale oder nationale SQA SQA Prozeduren der Organisation SQA Richtlinien der Organisation SQA Arbeitsanweisungen V12-13 V12-14 Ausprägung und Weiterentwicklung von Prozeduren Relevante Faktoren für Prozeduren Typ der Software Kundenspektrum SQA Ansatz der Organisation Update wird notwendig aufgrund von technologischem Wandel Aufgabenverlagerung der Organisation Benutzervorschlägen Analyse der eigenen Projekte Externe Analyseergebnissen (3) Vorlagen und Checklisten Vorlagen Schematische Vorlage für Dokumente, die während der Softwareentwicklung benötigt werden (z.b. Pflichtenheft, Testbericht, ) Checklisten Liste von Teilaufgaben, die im rahmen einer Aktivität festzulegen oder zu erledigen sind. V12-15 V12-16 Vorteile von Vorlagen Für das Entwickler: Vereinfacht die Erstellung der Dokumente. Führt in der Regel zu vollständigeren Dokumenten. Vereinfacht die Integration neuer Teammitglieder. Vereinfacht den Review der Dokumente. Für das Wartungs: Ermöglicht die einfacher Lokalisierung von Informationen. Vorteile von Checklisten Für das Entwickler: Hilft dem Entwickler bei der Überprüfung der eigenen Ergebnisse. Hilft Entwicklern bei der Vorbereitung von Aufgaben. Für das Review: Garantiert die Vollständigkeit des Reviews. Erhöht die Effizienz des Reviews. V12-17 V12-18 3
(4) Vorteile: Anwendung des State of the Art bzgl. Methoden und Prozeduren. Besseres Verständnis und Koordination zwischen Entwicklers und Wartungss. Bessere Kooperation zwischen Entwicklern und externern Projektbeteiligten. Besseres Verständnis und Koordination zwischen Anbietern und Kunden durch Aufnahme von in den Vertrag. Arten von Charakteristika Zielgruppe Fokus Zielrichtung des Ziel des Qualitätsmanagement- Management der Softwareentwicklung und/oder Wartung sowie deren SQA Abteilung Organisation, Infrastruktur und Anforderungen an diese Was soll erreicht werden Prozessqualität Prozess- Produktqualität Teams, die für die Softwareentwicklung und/oder Wartung zuständig sind Methoden zur Durchführung von Softwareentwicklungsund Wartungsprojekten Das Wie der Ausführung V12-19 V12-20 Organisationen die SQA entwickeln IEEE (Institute of Electric and Electronic Engineers) Computer Society ISO (International Organization) DOD (US Department of Defense) ANSI (American National Institute) IEC (International Electrotechnical Commission) EIA (Electronic Industries Association) Prozess- IEEE Software Engineering : Struktur und Inhalt IEEE/EIA Std. 12207 Software life cycle processes IEEE Std. 1012 Verification and validation IEEE Std. 1028 Reviews V12-21 V12-22 Klassen von IEEE A Konzeptionelle Prinzipien und Gesamtansatz IEEE 1061 Software Quality Metrics Methodology IEEE/EIA 12207.0 Information Technology Software Life Cycle Processes B, die Vorgaben festlegen Vorgaben, die eingehalten werden müssen. IEEE 829 Software Test Documentation IEEE 1012 Software Verification And Validation IEEE 1028 Software Reviews C, die Anleitung zur Ausführung geben Umsetzung der der Klasse B IEEE 1233 Guide for Developing Requirement Specifications IEEE/EIA 12207.1 Guide, Information technology Software Life Cycle Processes Life CycleData IEEE/EIA Std 12207 - Information Technology Software Life Cycle Processes Etablierung eines international anerkannten Modells für Software Lebenszyklus Prozesse auf das die Softwareindustrie weltweit verweisen kann. Das Verständnis zwischen den verschiedenen Beteiligten durch Einführung allgemein anerkannter Prozesse, Aktivitäten und Aufgaben fördern. V12-23 V12-24 4
Tailoring Acquisition Supply Development Management Documentation Infrastructure Configuration management Improvement Quality assurance Training Verification Validation Joint review Audit Problem resolution Organizational processes Copyright 1992 IEEE. All rights reserved. Primary processes IEEE/EIA Std 12207 Software life cycle processes Supporting processes S o f t w a r e l if e c y c l e IEEE Std 1012 Verification and validation Ein allgemeines Framework für V&V Aktivitäten und Aufgaben für alle Software Lebenszyklus Prozesse. Festlegung von V&V Anforderungen inklusive der benötigten Eingaben und resultierenden Ausgaben. Festlegung von Software Integritätsstufen und der entsprechenden V&V Aufgaben. Festlegung des Inhalts des Software V&V Plans. V12-25 V12-26 IEEE Std 1028 Reviews Definition systematischer Review Prozeduren, die Durchgängig für alle Reviews im Lebenszyklus der Software anwendbar sind und Mit den Anforderungen anderen an Reviews vereinbar sind. Konzepte: gradig formales Vorgehen Reviewtypen: Management reviews, Technical reviews, Inspections, Walkthroughs, Audits Reviews werden im durch nachfolgende Überwachung der Korrekturen begleitet Softwaretechnikpraktikum: Aktuelle Aufgaben und Fragerunde V12-27 Aufgaben/Abgaben: Fragen? V12-29 V12-30 5