SWQM Prüfungsvorbereitung

2005-07-14T13:50:58Z

212.202.201.38: /* CPI */

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.

= Phasen =

== Code Review ==

= 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)

=== LoC ===

=== Zeit ===

=== 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

== Chi-square-Verteilung ==

== T-Verteilung ==
* ähnlich Normalverteilung, aber dickere Enden
*

== Normalverteilung ==

= 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

Psychologische Aspekte der Software-Ergonomie

2005-07-11T15:25:01Z

212.202.201.38: /* Beispiele für Prüfungsfragen */ noch ein paar mehr

<div id="klausuren" style="float:right; width:20%; margin:10px; padding:10px; background-color:#efefef;">
=== Klausuren ===
'''Bisher noch keine'''
</div>

== Psychologische Aspekte der Software-Ergonomie ==

ARPA Veranstaltung im [[Hauptstudium]].

== Inhalt ==
Die Vorlesung dient als überblick und einstieg in das Gebiet der Usabillity / Gebrauchstauglichkeit

== Beispiele für Prüfungsfragen ==
* Mittelfristige folgen schlechter Softwareergonomie
* Drei Perspektiven benennen (Technsiche, Arbeitspsychologische und Kognitionspsychologische)
* Interaktionsformen benennen
* Was sind die Vor- und Nachteile der Interaktionsform Kommandosprache
* ISO Norm: Was ist Aufgabenangemessenheit
* Vier Nievergelt Fragen, zusätzlich deren Bezug auf ISO Norm und Modelle
* Welcher Grundsatz der ISO-Norm passt zu welcher Nievergelt Frage?
* Was versteht man unter einer Organisationsschnittstelle
* Fehlerrobustheit: Definition und Anforderungen. Dazu Weitere ISO-Grundsätze, Selbstbeschreibungsfähigkeit
* Anforderungen und Struktur für Evaluationsleitfäden
* ISO-Norm: Selbstbeschreibungsfähigkeit
* Struktur und Anordnung: Speziell in Bezug auf Farben
* Aspekte der Tiefenwahrnehmung
* Unterschiede zwischen Informatik-Studenten und Büroangestellten in Bezug auf Umgang mit Rechner / Software
* Nennen Sie Regeln zur Nutzerqualifikation
* Nennen Sie gestaltpsychologische Aspekte, mit Beispielen
* Nennen Sie einige Gründe, wieso Softwarefirmen erhebliche Summen in Styleguides stecken
* Welche Anforderungen sind aus Software-Ergonomosicher Sicht an die richtige Gestaltung von Oberflächen (style-guides, guidelines, etc.) zu stellen?
* Was ist Erwartungskonformität, geben sie Bewertungsaspekte an

== Persönliche Kommentare ==
: (Nicht unterschriebene Kommentare werden gelöscht!)

Einen sehr guten Überblick über den Inhalt der Vorlesung kriegt man [http://www.fit-fuer-usability.de/1x1/uebersicht.html bei Fraunhofer FIT]. [[Benutzer:130.149.152.241|130.149.152.241]] 13:04, 11. Jul 2005 (CEST)

[[Kategorie: Lehrveranstaltungen]]
__NOTOC__

FreitagsrundenWiki - Benutzerbeiträge [de]

SWQM Prüfungsvorbereitung

Psychologische Aspekte der Software-Ergonomie