**Dies ist eine alte Version des Dokuments!**
Software-Qualität
Mögliche Klausurthemen
Inspection
Zuverlässigkeitsmetriken
Wartungsmetriken
Fahlertoleranzmaßnahmen
COCOMO
Halstead
Qualitätsmodelle
CMM Grundprinzip
Anforderungen → Volere
Function Points
Anforderungsanalyse
Qualitätssysteme
Wann ist ein System zuverlässig? Was macht die Qualität eines Systems aus?
Qualität ist die Übereinstimmung mit den Anforderungen
Nur auf Basis bekannter Anforderungen kann eine Aussage über Qualität getroffen werden, da sie sonst nur subjektiv bewertbar ist.
Unzuverlässigkeit entsteht durch Ausfälle. Diese sind zu definieren und Maßstäbe zu finden, anhand derer die Schwere der Ausfälle bewertet werden kann.
Ein System bietet system services (in der Anforderungsddefinition festgelegt) an und zwar mit einer gewissen quality of service.
Wie macht man ein System zuverlässig? Wie stellt man die Qualität eines Systems sicher?
Organisatorische Maßnahmen (Vorgehensweisen)
Analytische Maßnahmen (Test, Review)
Zusammenfassung: Konzeptionelles Vorgehen (Bild S.78)
Systemunzulänglichkeiten
Bewertungsmaßstäbe
Funktionsprofil: up/down (Reaktion: Reparatur ja/nein)
degradiertes System: nur Teile des Systems funktionieren
Anwendungsdauer: Zeitspanne des Einsatzes eines Systems unter vorgegebenen Bedingungen.
Lebensdauer: Zeitraum von Betriebsbeginn bis -ausfall bei nicht-reparierbaren Systemen.
Brauchbarkeitsdauer (technische Lebensdauer): Zeitraum von Betriebsbeginn bis zum Zeitpunkt, an dem eine Instandsetzung nicht mehr rentabel möglich ist.
MTTFF (mean time to first failure): Zeitraum von Systemstart bis zum ersten Ausfall.
MTBF (mean time between failure): Zeitraum zwischen zwei Ausfällen.
MDT (mean down time): Zeitraum, während dessen das System nicht zur Verfügung steht (Instandsetzung).
MTTR (mean time to restoration): Zeitraum, während dessen das System instandgesetzt wird.
datection time: Benötigte Zeit um den Fehler zu entdecken.
diagnosis time: Benötigte Zeit um die Ursache des Fehlers zu entdecken.
time for reconfiguration: Zeit für Rekonfiguration des Systems.
recovery time: Zeit für das Bereitstellen des reparierten/ersetzten Teils.
time for reintegration: Zeit für das Integrieren des reparierten/ersetzten Teils.
präventive Wartungsaktivitäten
MUT (mean up time) / MTTF (mean time to failure): Zeitraum, während dessen das System zur Verfügung steht.
weitere Begriffe der ITU
required time: Zeit, während der das System zur Verfügung stehen muss.
non-required time: Zeit, während der das System nicht zur Verfügung stehen muss.
up time: Zeit, in der das System funktionsfähig ist.
disabled time: Ziet, in der das System nicht funktionsfähig ist.
down time (internal down time): Zeit, in der das System ausfallen ist.
external disabled time (external loss time, external down time): Zeit, in der das System nicht zur Verfügung steht, weil externe Ressourcen nicht genutzt werden können.
undetected fault time: Zeit zwischen Ausfall und Erkennen der Störung.
administrative delay: Zeit, während der keine Wartung durchgeführt werden kann.
maintenance time: Zeit, während der Wartung durchgeführt wird.
active maintenance time: Zeit, während der aktiv Wartung betrieben wird (ohne logistische Wartezeiten).
preventive maintenance time: Zeit, während der präventive Wartung betrieben wird (inkl. logistische Wartezeiten).
logistic delay time: Zeit, während der aufgrund von fehlenden Ressourcen keine Wartung betrieben werden kann.
active preventive maintenance time: Zeit, die für präventive Wartung verwendet wird.
corrective maintenance time:
Überlebenswahrscheinlichkeit (reliability, reliability performance) R(t): System ist funktionstüchtig in [0;t] (exponentiell monoton fallend)
Kumulative Ausfall- / Fehlerwahrscheinlichkeit (cumulative failure distribution) F(t): System fällt in [0;t] aus: F(t) = 1 - R(t)
Ausfall- / Fehlerdichte (probability density function, PDF) f(t): Zeitableitung von F(t)
Ausfallrate delta(t): umgekehrt proportional zur MTTFF
Verfügbarkeit (availability) A(t): Wahrscheinlichtkeit, dass das System zum Zeitpunkt t funktionstüchtig ist.
Wartbarkeit (maintainability) M(t): Wahrscheinlichkeit, dass das System innerhalb der Zeitspanne t wieder instandgesetzt werden kann.
Reparaturrate (repair rate): entspricht Ausfallrate
Sicherheit (safety): Das System hat keine kritischen Ausfälle (kritische Funktionen). Zusammenhang zur Überlebenswahrscheinlichkeit (Leistung des Systems betreffende Funktionen)
Vertraulichkeit (security): Das System verhindert unerlaubten Zugriff (vertrauensrelevante Funktionen).
Performance: Beispiele sind Durchsatz oder Antwortzeit → Benchmarks
Qualitative Kenngrößen
Qualitätsanforderungen
Arten von Anforderungen
Anforderungsdefinitionsprozess
Grafik S. 64
Aufnahme der Bedürfnisse/Vorstellungen der Stakeholder
WICHTIG: verdeckte Anforderungen ermitteln
(iteratives) Extrahieren von Basisanforderungen aus den vorhandenen Anforderungsbeschreibungen
nicht-funktionale Anforderungen → Systemarchitektur
Maßnahmen
Fehlerverhütung
Fehlervermeidung
Fehlerbeseitigung
Fehlertoleranz
Wartung
Fehlertoleranz
Phasen
Redundanz
Systemaspekt
* strukturell
* funktional
* Informationsredundanz
* Zeitredundanz
* Aktivierung
* statisch
* dynamisch
* Fehlerart
* homogene Redundanz / Replikation -> Alterungsfehler
* diversitäre Redundanz / Diversität -> Designfehler
* Beispiele
Fehlerkorrektur (Prüfsummenbildung)
Informationsredundanz (Prüfsumme)
strukturelle Redundanz (Speicherung von Nutzdaten und Prüfsumme)
funktionale Redundanz (Funktionen codieren/decodieren)
Zeitredundanz (Zeit für codieren/decodieren)
Fehlermaskierung (TMR-System)
strukturelle Redundanz (drei Komponenten)
Informationsredundanz (Verteilung der Information auf drei Komponenten)
funktionale Redundanz (Voter)
Rückwärtsfehlerbehebung (recovery points)
strukturelle/Informationsredundanz (Speichern der alten Zustände)
funktionale Redundanz (Verwaltung der Zustände)
Zeitredundanz (Wiederholung bereits durchlaufener Schritte)
Vorwärtsfehlerbehebung
Rekonfiguration (TMR mit zwei Ersatzkomponenten)
Produktmetriken
Flesh-Kincaid-Verständlichkeitsgrad
Flesh-Kincaid-Lesbarkeitsgrad
Fog-Index
COCOMO
Entwicklungsaufwand in Mann-Monaten: PM (personal month)
* Entwicklungsaufwand in Monaten: TDEV (time of development)
* Entwicklungsaufwand in Personen: N (number of programmers)
* Function Point Verfahren (Albrechts-Metrik)
Festlegen der Systemgrenzen
Unadjusted Function Points ermitteln
Kategorisierung von Funktionen
Bestimmung des Komplexitätsgrades einer Funktion
Bestimmung des Funktionspunktwertes für eine Funktion der entsprechenden Kategorie mit vorgegebenem Komplexitätsgrad
Bestimmung des Funktionspunktewertes der gesamten Anwendung durch Analyse aller relevanten Funktionen
Adjusted Function Points ermitteln
Funktionskategorien (Datenbestände/Transaktionen)
externe Eingaben (external input EI)
* externe Ausgaben (external output EO)
* interne Dateizugriffe (internal logical file ILF)
* externe Dateizugriffe (external interface file EIF)
* externe Anfragen (external inquiry EQ)
* Elementarprozess / Transaktion
* Kleinste für den Benutzer bedeutende Verarbeitungseinheit.
* Eigenständig und in sich abgeschlossen.
* Hinterlässt konsistenten Systemzustand.
* Entwurfsstrukturmetriken von Blaschek
Höhenmaß, Breitenmaß, rel. Breitenmaß, Maß der Baumähnlichkeit
Modul-Bindungsmetrik
Bindung (cohesion)
Kopplung (coupling)
Bindungstypen: zufällig, logisch, zeitlich, prozedural, kommunikativ, sequentiell, informal, funktional
LOC-Maß
Software-Science / Halstead-Metriken
Vokabular
Programmlänge
Programmumfang
Schwierigkeitsgrad
Abstraktionsniveau
Programmieraufwand
Intellektueller Gehalt
Programmierzeit
mittlere Fehlermenge
McCabe-Metrik / Zyklomatische Zahl
* Test-Metriken
Wartungsmetriken
Fehlerbeseitigung, Optimierung, Portierung
Aufwandsmetriken (Lesbarkeit, Korrekturzeit, Fehlerbeseitigungszeit)
Änderungsbezogene Metriken (Lokalisierung, Perfektionierung, Wiederverwendbarkeit)
Fehlerbezogene Metriken (Fehlerhäufigkeit, Fehlerzuwachs)
Entwicklungseffektivität
Änderungsmetrik von Stahlknecht
Portabilitätsmetriken
Aufwandsmetriken
ToDo
Links
Lernziele
Verstehen, warum eine Betrachtung von (IT-)Systemen unter Qualitätsgesichtspunkten Voraussetzung für die Beschäftigung mit dem Thema Softwarequalität ist.
Verstehen des konzeptionellen Ansatzes zur Beantwortung der Fragen:
Wann bezeichnet man ein System als verlässlich oder zuverlässig? Was macht die Qualität eines Systems aus?
Wie macht man ein System verlässlich bzw. zuverlässig? Wie stellt man die Qualität eines Systems sicher?
Wissen wie Anforderungen ermittelt werden.
Wissen wie Defekte beschrieben werden.
Wissen wie Defekte bewertet werden können.
Wissen welche Maßnahmenkategorien und welche Maßnahmen zur Erreichung der geforderten Qualität eingesetzt werden können.
Anwenden der vorgestellten Methoden und Techniken zur Ermittlung von Anforderungen.
Anwenden der vorgestellten Methoden und Techniken zur Ermittlung von Bewertungsgrößen.
Wissen wie Systemunzulänglichkeiten beschrieben werden.
Wissen wie Systemunzulänglichkeiten bewertet werden können.
Verständnis, warum Produktmetriken für den Softwareentwicklungsprozess bedeutsam sind.
Kenntnis über vorgestellte im Softwareentwicklungsprozess einsetzbare Metriken. Wissen um den Beispielcharakter der vorgestellten Produktmetriken.
Anwenden der Metriken.
Aufgaben
Kapitel 1
\mbox{MTTFF} = \overline{T} = \int_{0}^\infty \mathrm R(t)\,\mathrm dt
\int{0}^\infty \mathrm R(t)\,\mathrm dt = \int{0}^\infty \mathrm 2e^{-0.1t\frac{1}{y}}-e^{-0.2t\frac{1}{y}}\,\mathrm dt
= \int{0}^\infty \mathrm 2e^{-0.1t\frac{1}{y}}\,\mathrm dt - \int{0}^\infty e^{-0.2t\frac{1}{y}}\,\mathrm dt
= [-20ye^{-0.1t\frac{1}{y}}]0^\infty - [-5ye^{-0.2t\frac{1}{y}}]0^\infty
= \left[\lim{t \to \infty}(-20ye^{-0.1t\frac{1}{y}}) - (-20ye^{\frac{0}{y}})\right] - \left[\lim{t \to \infty}(-5ye^{-0.2t\frac{1}{y}}) - (-5ye^{\frac{0}{y}})\right]
= \left[0 + 20y\right] - \left[0 + 5y\right]
= 20y - 5y
= 15y
</latex>
Für ein System ist gegeben: MDT = 2 Tage, MTBF = 365 Tage. Geben Sie die Verfügbarkeit für das System an!
MUT + MDT = MTBF → MUT = 365 - 2 = 363
A = MUT / MTBF = 363 / 365 = 99,452%
* Was ist ein "required constraint"?
Eine Basisanforderung, die keine funktionale Anforderung ist, wird als required constraint bezeichnet. RQs stellen Randbedingungen dar und wirken sich auf die Architektur des Systems aus. Sie lassen sich kategorisieren in physical, environmental, development und product assurance.
Wie ermitteln Sie aus Kundenwünschen Anforderungen? Beschreiben Sie den Prozess der Anforderungsermittlung!
In Gesprächen, Beobachtungen usw. werden initiale Anforderungen der Stakeholder erfasst und zu Papier gebracht (→ ablegen).
Diese Anforderungen werden nun genauer untersucht und Basisanforderungen abgeleitet (→ getrennt ablegen).
Die Basisanforderungen werden in funktionale Anforderungen und Randbedingungen aufgeteilt.
Funktionale Anforderungen werden (wenn sie nicht mehr weiter unterteilbar sind) in die Systemanalyse übernommen (→ getrennt ablegen).
Randbedingungen werden in die Systemarchitektur übernommen.
* Was ist Fehlertoleranz?
Fehlertoleranz bezeichnet die Fähigkeit eines Systems auch im Fehlerfall weiter seine Funktionalität anzubieten.
Phasen und Methoden siehe Skript S.68
* Welche Redundanzformen werden bei einem fehlerkorrigierenden Code (error correcting code) eingesetzt?
Informationsredundanz (Nutzdaten und Prüfsumme)
strukturelle Redundanz (Speicherung von Nutzdaten und Prüfsumme)
funktionale Redundanz (Funktion zum Codieren und Decodieren)
Zeitredundanz (Zeit zum Codieren und Decodieren)
Wie können Sie sich vor Design-Fehlern schützen?
Kapitel 2
\mbox{PM} = \alpha \cdot \mbox{KDSI}^\beta \cdot \prod{i=1}^{15} ai
\mbox{PM} = 3 \cdot 90^{1,12} \cdot 1
\mbox{PM} = 463,32
</latex>
Für eine Function Point Abschätzung sind folgende Werte vorgegeben: 2 Funktionen gehören zur Kategorie EI, 3 zu EO, 1 zu ILF, 2 zu EIF und 2 zu EQ. Der Schwierigkeitsgrad ist immer "mittel". Welcher Function-Point Wert ergibt sich?
UFP = 55
Was wird mit der Function Point Metrik gemessen?
Die Function Point Metrik steht für die voraussichtliche Größe des Projekts. Auf Basis dieses Wertes kann dann z.B. die erwartete Entwicklungsdauer ermittelt werden (z.B. über COCOMO).
* Wo kann die Metrik von Blaschek eingesetzt werden?
Die Metrik von Blaschek kann eingesetzt werden, um in der Entwurfsphase die Modulstruktur einer Software zu analysieren (Baumhöhe, -breite, -ähnlichkeit). Anhand von Vergleichen mit erfolgreichen Softwareprojekten kann dann die vorliegende Architektur bewertet werden.
Was ist der schwächste Typ einer Modulbindung?
Zufällige Bindung: Die zusammengefassten Module stehen in keinem logischen Zusammenhang zueinander.
* Was wird für das LOC-Maß berücksichtigt, was wird beim LOC-Maß gezählt?
Für das Zählen der LOC gibt es verschiedene Vorgehensweisen. Normalerweise sollten die Codezeilen ohne Kommentare und Leerzeilen gezählt werden.
Halstead Software Science: Welche Kenngrößen werden definiert durch: (a) N1 + N2 (b) n1 + n2
a) Länge des Programms (Gesamtzahl aller verwendeten Operatoren und Operanden)
b) Vokabular des Programms (Gesamtzahl aller möglichen Operatoren und Operanden)
Wie kommt man zu einem Grenzwert für die zyklomatische Zahl von Mc Cabe?
Man kann in der Wartungsphase früherer Projekte die Anzahl der benötigten Updates je Komponente und deren Komplexität ermitteln und dokumentieren. Aus diesen Werten kann man mit der Zeit eine Funktion ableiten, die das Verhältnis zwischen Komplexität und Fehlerzahl darstellt. Nun kann eine maximale Fehlerzahl festgelegt werden und die daraus resultierende maximale Komplexität ermittelt werden.