SW-Lebenszyklus SW-Qualitätssicherung

DHBW Stuttgart, Informatik,SW-Engineering , Kapitel 1.2 Sep 2012

Seite 1

SW-LebenszyklusSW-Qualitätssicherung

(IV = Informationsverarbeitung)


Seite 2

• 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 3


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 4


• 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 5


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 6


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 7


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 8

SW-LebenszyklusBeispiel: SW-Qualitätsmodell

CBO=Coupling Between Object ClassesLCOM=Lack of Cohesion in Methods WMC=Weighted Methods per Class

Documents

SW-Lebenszyklus SW-Qualitätssicherung