Aktuelle Version vom 29. Februar 2024, 17:19 Uhr

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

SWQM Prüfungsvorbereitung: Unterschied zwischen den Versionen