DHBW Stuttgart Informatik SWEngineering Kapitel 1 2 Sep

DHBW Stuttgart, Informatik, SW-Engineering , Kapitel 1. 2 Sep 2012 SW-Lebenszyklus SW-Qualitätssicherung (IV = Informationsverarbeitung) Seite 1

DHBW Stuttgart, Informatik, SW-Engineering , Kapitel 1. 2 Sep 2012 SW-Lebenszyklus SW-Qualitätssicherung • • In der "Projekt-Phase" stehen Qualitätskosten in üblicher Höhe von 5 -10% der Entwicklungskosten Einsparungen bei der Fehlerbehebung in Höhe von ebenfalls ca. 5 -10% entgegen Qualitätskosten in Höhe von 5 -10% der Entwicklungskosten führen zu Einsparungen bei den Wartungskosten ("Betriebs-Phase") von ca. 40% Fehlerkosten = Behebungskosten + Kosten für Folgeschäden (z. B. Produktionsausfälle, Recovery-Massnahmen, Gewährleistungs-/Produkthaftung, Zinsverluste) Fehlerursachen: – Intrapersonelle Komm. -Probleme: Stress, Müdigkeit, mangelnde Motivation – Interpersonelle Komm. -Probleme: Erklärungs- und Übermittlungsirrtümer – Komplexitätsprobleme: zu viele Informationen gleichzeitig, parallele Abläufe – Mangelndes Problemverständnis Wie kann man diesen Ursachen entgegen wirken? Seite 2

DHBW Stuttgart, Informatik, SW-Engineering , Kapitel 1. 2 Sep 2012 SW-Lebenszyklus SW-Qualitätssicherung Fehlervermeidung durch Bekämpfen der Ursachen (konstruktive QS-Massnahmen): • Prototyping (zur Verbesserung der Kommunikation) • Schulung und Ausbildung der Beteiligten (zur Verbesserung des Problemverständnisses) • Einsatz von formalen Entwicklungsmethoden (zur Verringerung der Komplexität und Verbesserung der Kommunikation) • Einsatz von Entwicklungswerkzeugen zur Unterstützung der Methoden (zur Verringerung des Aufwands) Fehlerbeseitigung (analytische QS-Massnahmen): • Formale Prüfungen (bzgl. Vollständigkeit, Konsistenz, Verständlichkeit) • Inhaltliche Prüfungen: – Review – Inspektion – Test Seite 3

DHBW Stuttgart, Informatik, SW-Engineering , Kapitel 1. 2 Sep 2012 SW-Lebenszyklus SW-Qualitätssicherung • • Das Qualitätsmodell legt fest, welche Qualitätsmerkmale zu erreichen sind und wie ihre Erreichung sichergestellt und nachgewiesen werden kann Qualitätsmerkmale gemäß ISO/IEC 9126 sind (http: //de. wikipedia. org/wiki/ISO/IEC_9126): – Funktionalität (functionality), mit den Teilmerkmalen Angemessenheit, Richtigkeit, Interoperabilität, Anforderungstreue, Zugriffssicherheit – Zuverlässigkeit (reliability), mit den Teilmerkmalen Reife, Fehlertoleranz, Wiederherstellbarkeit – Verwendbarkeit (usability), mit den Teilmerkmalen Verständlichkeit, Erlernbarkeit und Benutzbarkeit – Effizienz (efficiency), mit den Teilmerkmalen Zeitverhalten und Ressourcenverhalten – Pflegbarkeit (maintenance), mit den Teilmerkmalen Analysierbarkeit, Änderbarkeit, Stabilität und Testbarkeit – Portierbarkeit (portability), mit den Teilmerkmalen Anpassbarkeit, Installierbarkeit, Einhaltung von Portierbarkeitsnormen und -konventionen, und Ersetzbarkeit. Seite 4

DHBW Stuttgart, Informatik, SW-Engineering , Kapitel 1. 2 Sep 2012 SW-Lebenszyklus SW-Qualitätssicherung Für jedes Qualitätsmerkmal wird folgendes (z. B. im Pflichtenheft) festgelegt: • Definition des Bewertungsmaßes: – Welches sind die messbaren Größen und Einheiten? • Definition der Erhebungsart – Mit welchen Hilfsmitteln wird gemessen? – Mit welchem Verfahren wird geprüft? – Wer misst/prüft wann und wie lange? • Definition des Erfüllungsmaßes: – Wann ist die Erfüllung des Merkmals gegeben? – Welche Grenzwerte gelten? – Welche Ausnahmen sind zulässig? – Welche Konsequenzen bestehen bei Nichterfüllung? Seite 5

DHBW Stuttgart, Informatik, SW-Engineering , Kapitel 1. 2 Sep 2012 SW-Lebenszyklus SW-Qualitätssicherung Noch ein paar Informationen zu den o. g. Qualitätsmerkmalen (Q-Merkmale): • Gemäß ISO 9241 -11 wird Usability wie folgt definiert: Das Ausmaß, in welchem ein Produkt durch bestimmte Benutzer in einem bestimmten Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv, effizient und zufrieden stellend zu erreichen. • Effizienz: Verhältnis zwischen dem erzielten Ergebnis und den eingesetzten Mitteln. (Im Unterschied zur Effektivität: Tun wir die richtigen Dinge? ) • Zur Effizienz gehören – Zeitverhalten: Antwort- und Verarbeitungszeiten sowie Durchsatz bei der Funktionsausführung. – Verbrauchsverhalten: Anzahl und Dauer der benötigten Betriebmittel bei der Erfüllung der Funktionen. Ressourcenverbrauch, wie CPU-Zeit, Festplattenzugriffe usw. • Zur Verfügbarkeit (als Teil der Zuverlässigkeit) gehören als Bewertungsmaß die MTBF (mittlere Zeit zwischen zwei Fehlern) und die MTTR (mittlere Reparaturzeit). • Hinweis: Sicherheit ist Teil der Funktionalität Welche Q-Merkmale sind für den Entwickler, welche für den Benutzer interessant? Seite 6

DHBW Stuttgart, Informatik, SW-Engineering , Kapitel 1. 2 Sep 2012 SW-Lebenszyklus SW-Qualitätssicherung Review • Zweck: inhaltliche, strukturierte, stichprobenhafte Gruppenprüfung besonders kritischer Projektergebnisse hinsichtlich ihrer Fehlerfreiheit (incl. Veranlassung der Fehlerbehebung) • Teilnehmer: Moderator (Protokoll, ordnungsgemäßer Ablauf), mind. 2 Inspektoren (Prüfung der Projektergebnisse), Autor (Erläuterung seiner Projektergebnisse) • Vorbereitung eines Reviews – Festlegen der Unterlagen (Projektergebnisse) und der Teilnehmer in Form von Abstimmungsgesprächen – Organisation des Treffens (incl. Einladung und Verschicken der Unterlagen) – Individuelle Vorbereitung (Durcharbeiten der Unterlagen) • Durchführung des Reviews – Feststellen der Prüffähigkeit – Vortragen der Projektergebnisse durch die Inspektoren, ggf. Erläuterungen durch die Autoren – Entscheidung der Inspektoren, wie mit dem Projektergebnis weiter verfahren wird: Freigabe bei Fehlerfreiheit (Inspektoren übernehmen Ergebnisverantwortung), Freigabe mit Auflage der Fehlerkorrektur (Normalfall), Ablehnung bei schwerwiegenden, konzeptionellen Fehlern mit Wiederholung des Reviews • Nachbereitung eines Reviews: Verteilung des Protokolls, ggf. neuer Reviewtermin, Korrektur der Fehler durch die Autoren, Überprüfung der Korrekturen durch die Inspektoren (ggf. mit Moderator) Seite 7

DHBW Stuttgart, Informatik, SW-Engineering , Kapitel 1. 2 Sep 2012 SW-Lebenszyklus Beispiel: SW-Qualitätsmodell CBO=Coupling Between Object Classes LCOM=Lack of Cohesion in Methods WMC=Weighted Methods per Class Seite 8