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)

• Multiple Regression: zu schätzende Größe muss mit jedem Maß korrelieren

Zeit

• berechnet sich aus geschätzter Größe und tatsächlicher Zeit TODO

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

• Wie haben wir es berechnet? TODO

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

GQM (Goal Question Metric)

• framework zum Sammeln von sinnvollen Daten
• Was sind die Ziele, die mit dem Sammeln der Daten verfolgt werden?
•  ??? VL6S20
• Welche Daten werden beötigt? Wie werden sie gesammelt und verarbeitet?

• beim PSP:
  • Wie gut ist mein Prozess? Wo kann er verbessert werden? Was ist die wichtigste Verbesserung, die ich jetzt machen kann? Was machen andere besser und wie kann ich von ihnen lernen?

LoC/hour

• bezieht sich auf Gesamtzeit, nicht nur die Zeit während des eigentlichen Codens
• nicht nur als Vergleichsmaß nutzbar, sondern auch als Fallback, wenn Regression nicht möglich

%-reused, %-new-reused

• Annahme: Reuse spart Entwicklungskosten

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
• unter 1: Projekt kostet mehr, als geschätzt
• über 1: Projekt kostet weniger als geschätzt

DRL (Defects Removal Leverage)

• TODO

Reuse

• mehr reuse -> weniger Zeit nötig

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

• Wie funktioniert das Integrieren?
  • zu integrierende Fläche in Teilstücke einteilen
  • Deren Flächinhalt approximieren + addieren
  • Flächen kleiner werden lassen, bis Veränderung des Ergebnisses unter ein bestimmtes Epsilon

• Erstellen von Plänen
  • wichtig? TODO