Skriptum 05

• Zuverlässigkeit

• Effizienz

• Integrität

• Verwendbarkeit

• Wartbarkeit

Beschreibung:

Die Fähigkeit eines Systems, die verlangte Funktionalität unter gegebenen Randbedingungen für eine bestimmte Zeit zu erfüllen.

Metrik:

Mean Time Between Failures (MTBF), Fehlerhäufigkeit.

Beschreibung:

Das Ausmaß, in dem ein System seine Leistungen mit einem Minimum an Ressourcenverbrauch erbringt.

Metrik:

Antwortzeit, Ressourcennutzung (CPU, Speicher)

Beschreibung:

Das Ausmaß, in dem ein System unberechtigte Zugriffe auf Programme und Daten bzw. deren unberechtigte Veränderung verhindert.

Metrik:

Anzahl der erfolgreichen/fehlgeschlagenen unberechtigten Zugriffsversuche.

Beschreibung:

Die Leichtigkeit, mit der ein Benutzer die Bedienung eines Systems, die Vorbereitung von Daten dafür und die Interpretation seiner Ergebnisse lernen kann.

Metrik:

Benutzerzufriedenheit, Zeit zur Erledigung von Aufgaben, Fehlerquote bei der Benutzung

Beschreibung:

Die Leichtigkeit, mit der ein System geändert werden kann, um Fehler zu beheben, seine Fähigkeiten zu erhöhen oder es an eine veränderte Umgebung anzupassen.

Metrik:

Zeit zur Fehlerbehebung, Anzahl der gefundenen und behobenen Fehler

Die IEEE definiert Qualitätsfaktoren als die Eigenschaften eines Softwareprodukts, die erfüllt sein müssen, um eine hohe Qualität sicherzustellen.

Zu diesen Faktoren gehören:

• Korrektheit

• Zuverlässigkeit

• Effizienz

• Integrität

• Verwendbarkeit

• Wartbarkeit

• Flexibilität

• Testbarkeit

• Portabilität

= hierarchisches Modell zur Messung der Softwarequalität.

Es besteht aus drei Stufen:

• Konzeptuelle Stufe (Ziele):

  Festlegung von Zielen in Bezug auf Produkte, Prozesse oder Ressourcen unter Berücksichtigung aktueller Bedürfnisse und Sichtweisen.

• Operative Stufe (Fragen): Formulierung von Fragen, die das zu messende Objekt (Produkt, Prozess, Ressourcen) aus der benötigten Sichtweise charakterisieren.

• Quantitative Stufe (Metriken): Zuordnung konkreter gemessener Werte zu den Fragen, entweder subjektiv oder objektiv erfasst

Konstruktive Maßnahmen

• Vorgehensmodelle, Methoden und Werkzeuge, Richtlinien und Standards, die die Erzeugung qualitativ hochwertiger Software fördern.

Analytische Maßnahmen

• begleiten den gesamten Softwareentwicklungsprozess und umfassen Inspektionen, Reviews und Testmethoden zur Überprüfung der Übereinstimmung des Produkts mit den Soll-Vorgaben

Formelle Reviews:

• Strukturierte und dokumentierte Überprüfungen

• häufig durch ein Meeting (z.B., Inspektionen, Walkthroughs).

Einsatz:

Frühe Phasen: Anforderungs- und Design-Dokumente, um Fehler frühzeitig zu erkennen.

Informelle Reviews:

• Unstrukturierte Überprüfungen

• oft ohne Dokumentation (z.B., Ad-hoc Reviews).

Einsatz:

Späte Phasen: Code- und Testdokumente, um Implementierungsfehler zu identifizieren

• Software Requirements Review (SRR)

  Überprüfung der Anforderungsdokumente vor der Entwurfsphase.

• Preliminary Design Review (PDR)

  Überprüfung des Softwareentwurfs und der Architektur vor der detaillierten Ausarbeitung.

• Critical Design Review (CDR)

  Bewertung des detaillierten Designs vor der Implementierung.

• In-Process Review (IPR)

  Kontinuierliche Überprüfung während des Entwicklungsprozesses.

• Management Review (MR)

  Beurteilung des Projektstatus und der Managementaktivitäten.

• Code Walkthrough

  Überprüfung des Codes, um Fehler zu finden und zu beheben.

• Technical Review

  konkreten Bestandteil der Software zu bewerten, die Übereinstimmung von Spezifikation oder Standards mit dem Softwareprodukt selbst zu überprüfen und auch um Fehler zu finden

• Moderator

  • Organisation und den Ablauf der Review

  • Einhaltung des Prozesses und leitet die Diskussion.

• Leser

  • präsentiert das zu überprüfende Dokument

  • sorgt für die angemessene Geschwindigkeit des Reviews.

• Schreiber

  • protokolliert die Ergebnisse der Review-Sitzung

  • erstellt das Review-Protokoll

• Gutachter

  • bereitet sich auf die Review vor

  • beteiligt sich aktiv an der Überprüfung

• Autor

  • Ersteller des zu überprüfenden Dokuments

  • beantwortet Fragen

  • stellt Hintergrundinformationen bereit

1. Planung: Festlegung der Reviews im QS-Plan, Erstellung der Arbeitspakete und Bestimmung der Teilnehmer.

2. Initialisierung: Überprüfung der Eingangskriterien und Zusammenstellung des Review-Teams.

3. Vorarbeitung: Untersuchung des Prüflings durch die Reviewer und Markierung der Mängel.

4. Durchführung: Präsentation des Prüflings, Diskussion und Dokumentation der gefundenen Fehler.

5. Überarbeitung: Autor überarbeitet das Dokument basierend auf den gefundenen Fehlern.

6. Nachverfolgung: Überprüfung der Korrekturen und Entscheidung über eine mögliche Re-Inspektion.

Qualitätsmanagement

= umfasst die Planung, Steuerung und Überwachung aller qualitätsrelevanten Aktivitäten

Qualitätssicherung

= ein Teil des Qualitätsmanagements und beinhaltet konkrete Maßnahmen zur Sicherstellung der Produkt- und Prozessqualität.

• Modultest

  = Test einzelner Module gegen ihre Designvorgaben.

• Integrationstest

  = Aufdecken von Fehlern im Zusammenspiel mehrerer Module.

• Systemtest

  = Prüfung des Gesamtsystems gegen die Spezifikation.

• Alphatest

  = Anwender testen das Produkt in der Umgebung des Herstellers.

• Betatest

  = Ausgewählte Kunden testen das Produkt in ihrer eigenen Umgebung vor der Markteinführun.

Blackbox-Testfälle:

• Fokus: Überprüfung der Funktionalität ohne Kenntnis der internen Struktur

• Methode: Verwendung definierter Ein- und Ausgaben

Whitebox-Testfälle:

• Fokus: Untersuchung der inneren Struktur und der Programmwege.

• Methode: Überprüfung des Kontroll- und Datenflusses innerhalb des Programms.