SWQM Prüfungsvorbereitung

Für die mündliche Prüfung in Softwarequalitätsmangament sollte man u.a. alle behandelten Begriffen kennen und erklären können, sowie die Zusammenhänge der Begriffe untereinander verstanden haben. Hier eine Übersicht, natürlich ohne Garantie für Vollständigkeit oder Richtigkeit.

Die Prüfung bezieht sich auf den PSP 2, nicht auf die einfacheren Versionen.

Schätzungen

• Ressourcen schwer schätzbar, aber dafür: LoC, function points, Seiten, Bildschirme -> PSP benutzt LoC
• Größenmaß gut geeignet für Ressourcenschätzung, wenn:
  • am wichtigsten: hohe Relation zu Entwicklungskosten
  • präzise (Genauigkeit kann durch Regression erreicht werden)
  • maschinenzählbar
  • auch für frühe Planung geeignet
  • sollte Sprache und Entwicklungsprozess miteinbeziehen
• Die benötigten Ressourcen können auch von mehreren Faktoren / Größenmaßen abhängen
• Güte der Größenschätzung beeinflusst Güte der Ressourcenschätzung

• Manche Leute können Ressourcen (Zeit, Geld) direkt besser schätzen (anstatt erst Größen zu schätzen und daraus die Ressourcen zu berechnen) und sollten das dann auch tun

• Schätzfehler gleichen sich oft aus, wenn keine systematische Fehler im Spiel sind -> Schätzfehler summieren sich nicht einfach

Function Point Estimating

• unterschiedliche Anzahl Function Points für unterschiedliche Methodentypen (aus historischen Daten bestimmt)
• +- 35% Anpassung für Komplexität der Aufgabe
• Anzahl Methoden zählen und alle Function Points zusammenrechnen
• aus historischen Daten (bisherige Geschwindigkeit pro Function point) die geschätzte Zeit berechnen

• Vorteile:
  • sehr früh benutzbar
  • unabhängig von Programmiersprache und -methode
  • gut dokumentiert
  • viel historische Daten
  • aktive Benutzergruppe

• Nachteile:
  • Functions Points eines bestehenden Produktes können nicht direkt gemessen werden
  • ohne historische Daten nur schwer eine Verbesserung des Schätzskills möglich
  • unterschiedliche Sprachen, Stile etc. werden nicht berücksichtigt
  • meist nur für professionelle Datenverarbeitung geeignet (jedenfalls dafür designed)

Standard Component Sizing

• geeignete Komponenten wählen (z.B. input, output, control, computation, etc)
• historisches Min, Max und Mittel für jede Komponente bestimmten
• daraus die Min, Max und Mittel für die Komponenten des neuen Programms berechnen
• diese Werte addieren und entsprechend gewichten -> total LoC
• LoC +- Standardabweichung = Schätzintervall

• Vorteile:
  • basiert auf historischen Daten
  • einfach
  • sogar mit Schätzintervall
• Nachteile:
  • große Komponenten müssen früh im Projekt benutzt werden (??? TODO VL3S41)
  • begrenzte Daten für große Komponenten

Delphi Size Estimating

• viele Schätzer, die unabhängig voneinander schätzen
• Ergebnisse werden vom Koordinator verglichen
• Schätzer erhalten Mittelwert und andere Schätzungen zurück und dürfen nochmal schätzen
• Iteration bis sich Schätzungen stabilisiert haben
• Durchscnitt = Schätzwert; Min- und Max-Schätzungen = Schätzintervall

• Vorteile:
  • Genauigkeit
  • für Software jeder Größe anwendbar
• Nachteile:
  • hängt von wenigen Experten ab
  • zeitaufwendig

Size Estimating Proxies

TODO VL3 -> eher unwichtig, oder?

PROBE

Objektgrößenmatrix

• aus vorhandenen Datenpunkten Größenklassen für jeden Objekttyp (I/O, Computation etc) erstellen
  • Intervalle log-normal- und nicht normal-verteilt, damit:
    • keine negativen Werte
    • Größenklassen unterschiedlich groß
  • log aus loc/method nehmen
  • aus average und standardabweichung die log-Werte der Größenklassen berechnen
  • e hoch das Ganze -> Größenklassen
  • für jeden Objekttyp wiederholen
• überprüfen, ob vorhandene Datenpunkte in Größenklassen passen (die meisten müssten in und im "mittel" liegen)
• Schätzung für neues Produkt (quasi mittels Fuzzy Logic): Einzelteile idenifizieren, deren Objekttypen und dann deren Größenklasse bestimmen
• Anzahl der Methoden mit den LoC der jeweiligen Größenklasse verrechnen -> Resultat: erste Schätzung

• Vorteile Fuzzy Logic:
  • einfach, kein spezielles Training erforderlich
  • basiert auf historischen Daten
  • gute Schätzungen, wenn neues Programm mit historischen Programmen vergleichbar
• Nachteile
  • viele Datenpunkte nötig, damit das ausreichend gut funktioniert (besser 20 und mehr)
  • neue Programme müssen mit alten vergleichbar sein (Typ, Größe)

Regression

• bestimmt eine optimale Gerade bezüglich eines Fehlermaßes
• gleicht bisherige systematische Schätzfehler aus
• es existiert meist nicht eine eindeutige Lösung
• TODO Möglichkeiten zur Regressionsberechnung siehe Table C irgendwas im Buch

• Resultate sind korrigierbar, wenn sie offensichtlich Unsinn oder wahrscheinlich falsch sind (wenn z.B. der Prozess geändert wurde)

Korrelation

• Wie stark beeinflusst ein Parameter einen anderen?
• brauchbar: Korrelation zum Quadrat größer 0,5
• gut: TODO
• nötige Anzahl an Datenpunkten: TODO
• wenn Korrelation ungenügend oder nicht möglich: TODO

Signifikanz

• Wie wahrscheinlich ist es, dass eine beobachtete Korrelation nicht nur zufällig zustande kam?
• brauchbar: kleiner 0,2
• gut: kleiner 0,05
• nötige Anzahl an Datenpunkten: TODO

Koinfidenzintervall

• Ist das Intervall um den aktuellen Schätzwert, in dem sich (auf Grundlage der bisherigen Schätzungen) der tatsächliche Wert mit einer bestimmten Wahrscheinlichkeit befindet (meist 70% oder 90%)
• Werte müssen korrelieren, ansonsten kann man es nicht angeben
  • bei der Zeit kann man höchstens noch aus der bisherigen minimalen und maximaleb Produktivität ein Intervall bilden

Qualität, Produktivität

• Was ist Qualität (auch die Folien, die non-Humphrey-Folien!) TODO
• Prozess- vs. Produktqualität TODO
• ex post Maße vs Maße, die schon während des laufenden Prozesses angewendet werden können TODO

LoC/hour

• Geschwindigkeit beim Programmieren
• bezieht sich auf Gesamtzeit, nicht nur die Zeit während des eigentlichen Codens

Yield

• Anteil der gesamten Fehler, die in einer bestimmten Phase gefunden werden
• sollte schon während der Appraisal-Phasen möglichst hoch sein, da dort Fehler i.d.R. schneller gefunden werden (und auch mehr)

Defects/kLoC

• Fehlerdichte (Fehler pro 1000 Zeilen)
• je weniger, desto besser
• 15 oft als sehr guter Wert bezeichnet
• ideal: 0 sichtbare oder beim Anwender auftretende Defects/kLoC
• im PSP: bezieht sich meist auf die entdeckten Fehler, also die (hoffentlich) behobenen
• höhere Fehlerdichte -> geringere Produktivität, da mehr Zeit für die Fehlerfindung nötig ist

A/F Ratio

• CoQ-Maß
• Appraisal: Frühe Fehlerfindephasen (Code, Code Review etc)
• Failure: Späte Fehlerfindephasen (Compile, Test, nach PM)
• sollte möglichst groß sein (d.h., mehr Fehler sollten früh gefunden werden), da Fehler in der Appraisal-Phase i.d.R. schneller gefunden werden (und auch mehr)

CPI (Cost Performance Index)

• Geplante Zeit / tatsächliche Zeit
• ideal: nah an der 1

DRL (Defects Removal Leverage)

• TODO

Verteilungen

• mit dazugehörenden Tests

T-Verteilung

• ähnlich Normalverteilung, aber dickere Enden

Weitere mögliche Fragen

• Was ist das Ziel des PSP?
  • bessere Produktqualität (weniger Fehler)
  • gute Schätzungen abgeben (Planungssicherheit)
• Sinn von Counting/Coding Standards
  • logische LoC auf automatisch messbare physische LoC abbilden
• Testen TODO