SWQM Prüfungsvorbereitung

History Lesson!
Dieser Artikel spiegelt sehr wahrscheinlich nicht mehr den aktuellen Stand wider, könnte aber trotzdem von Interesse sein.

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.

Reviews

• Ziel: Fehler früh finden und beheben

• Inspections
  • Fagan IBM
  • gut für Requirements, Design, Code, tests, plans...
  • jeder hat eine bestimmte Rolle, auf die er sich auch vorbereitet
• Walkthroughs
  • einer führt durch den Code in der Hoffnung, die Zustimmung der anderen zu kriegen
  • keine Vorbereitung nötig
  • v.a. für Requirements und Design geeignet
• personal reviews
  • für Requirements, Design und Code
  • Fehler sollen vorm ersten Compile gefunden werden

• Gründe für Reviews:
  • mehr Fehler in kürzerer Zeit finden
  • jede Phase (test, Compile, Review) findet immer nur einen Bruchteil der Fehler -> mehr Phasen heißt, mehr Fehler zu finden
  • Fehler früh finden ist billiger

• Code Review vor dem Compile: Dauert genauso lange wie nach dem Compile (man guckt sich ja eh alles an)
• Wenn dann noch viele Fehler im Compile gefunden werden, war das Review nicht gut genug

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

• großer Teil der theoretischen Basis aller anderen methoden
• man sucht sich einen "proxy" aus der einfacher vorstellbar ist als "die zeit die man braucht um das Produkt fertigzukriegen"
  • Sonst würde man gleich die Zeit schätzen
  • Der Proxywert muss gut mit der tatsächlich gebrauchten Zeit korrelieren
• dann schätzt man den Proxy (mit den historischen daten)
• und rechnet den um

• gute Proxies sollen:
  • gute korrelation zu der tatsächlich gebrauchten Zeit haben
  • automatisch zählbar sein (sonst sind die daten nicht konsistent)
  • gut darstellbar sein
  • an die speziellen bedürfnisse einer org. anpassbar sein (???)
  • sensitiv auf implementierungsunterschiede reagieren

• Mögliche Proxies
  • LOC
  • Objects
  • Normalized Object LOC (Object LOC / #methods)
  • Function Points (nicht soo gut, siehe kriterien)

• Vorteile
  • Einfacher als die gebrauchte Zeit direkt zu schätzen

• Nachteile
  • Aufgaben und Team-Spezifisch

PROBE

Eine Implementierung der Proxy-Methode

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 (yield, drl) vs Maße, die schon während des laufenden Prozesses angewendet werden können TODO

GQM (Goal Question Metric)

Um sinnig Daten zu sammeln:

• Ziele aufstellen (können auch vage sein)
  • Gibt Ziele der Firma, der Programmierer.... oft nicht scharf definiert, muss aber auch nicht, Fragen machen das dann
• Fragen definieren die für diese Ziele sinnvolle Daten liefern
• Diese Daten dann sammeln und auswerten
• Mit der Auswertung dann die Ziele verbessern, etc...

• 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

• Ziele:
  • Wie ist mein Prozess? 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?
  • Aber auch: Wie gut ist die Verbesserung die ich erreicht habe? Wie kann ich genauere Pläne machen?
• Fragen:
  • Welche messbaren Aspekte meiner Leistung sind wichtig? Wie messe ich die? Was war die beste Leistung die ich erreicht habe? Was kann ich von diesen Leistungen lernen? Was schaffen andere Leute? Was kann ich von deren Methoden übernehmen?

%-reused, %-new-reused

• Annahme: Reuse spart Entwicklungskosten

Yield

• Anteil der gesamten Fehler, die in einer bestimmten Phase gefunden werden
• kann erst nach Projektende bestimmt 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

• 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)
• im PSP also 2

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)

• Effektivität einer Phase bei der Fehlerbeseitigung
• Anzahl der behobenen Fehler einer Phase pro Stunde relativ zu einer anderen Phase (bei uns auf Test normiert)

LoC reviewed per hour

• korelliert zufriedenstellend mit Yield (besser als Defects/hour und Defects/kLoC) und ist noch während des Prozesses verfügbar
• variert sehr von Person zu Person
• ungefähr-Ziel für den PSP: weniger als 200 LoC/hour

Reuse

• mehr reuse -> weniger Zeit nötig

Verteilungen

• mit dazugehörenden Tests

Chi-square-Verteilung

Siehe Wikipedia

T-Verteilung

• Erklärung bei der Wikipedia
• ähnlich Normalverteilung, aber dickere Enden

Normalverteilung

Übersicht in der Wikipedia. Beschreibt wie "normalerweise" werte um einen Mittelwert schwanken. Je nach Streuung wird die Kurve dann natürlich flacher.

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