Softwarequalität und Projektmanagement Zusammenfassung

[skka]

Da bald die Klausur ansteht hier meine Zusammenfassung. Ist zwar nicht ganz vollständig, aber was solls.

Code: Alles auswählen

*** SW-Qualitätssicherung
   ** Einführung
      * Wechselwirkt mit: Systemerstellung, Projektmanagement

      * Qualität (Begriff)
         * "Gesamtheit von Merkmalen einer Einheit bzgl. ihrer Eignung,
           festgelegte und vorausgesetzte Erfordernisse zu erfüllen" - ISO 8402
            * Einheit = Produkt, Prozess, ..
         * ist Zielerfüllung (explizite UND implizite Ziele)
         * ist RELATIV zum Geforderten (siehe oben)

      * Qualitätsmanagement (= Qualitätssicherung; Begriff veraltet)
         Durchführung mit Qualitätsmanagementsystem.

         * Qualitätspolitik
            Der Stellenwert der Qualität im Unternehmen.
            TQM (Totales Qualitäts Mgmt) = Qualität / Kundenzufriedenheit ist höchstes Ziel.

         * Qualitätsplanung
            Qualitätsziele festlegen, in quantifizierten Anforderungen.
            Bgzl. Software: Qualitätsmanagement ist quantifizierte Spezif. der Anf.

         * Qualitätslenkung / -prüfung
            Arbeitstechniken (analytisch / konstr.) zur Erfüllung der QAnf.

         * Qualitätssicherung / -management-Darlegung
            Vertrauen schaffen, dass QAnf. erf. werden (WTF?)

         * Qualitätsverbesserung
            Erhöhung: Effektivität & Effizient bzgl qualitätsbez. Tätigkeiten

         * Q-Mmgt-System
            Struktur, Verantwortlichkeiten, Mittel zur Verwirklichung des Q-Mmgt.

      * ???
         * Messen, Rückkopplung

      * Prozessqualität (Merkmale; Faktoren sollen alle HOCH sein für HOHE Quali)
         * Inverse Dauer, Inverser Aufwand, Termin-Einhaltung, Aufwandseinhaltung, Prozess-Transparenz,
           Baustein-Gewinn, Know-How-Gewinn, Projekt-Klima

      * Produktqualität
         * Spez. Vollständigkeit, Lokalität, Testbarkeit, Strukturiertheit, Simplizität, Knappheit,
           Lesbarkeit, Geräteunabhängigkeit, Abgeschlossenheit, Korrektheit, Ausfallsicherheit,
           Genauigkeit, Effizienz, Sparsamkeit, Leistungsvollständigkeit, Konsistenz,
           Handbuch-Vollständigkeit, Verständlichkeit, Einfachheit

      * Qualitätsfaktoren nach IEEE 610.12-1990
         * Korrektheit, Zuverlässigkeit, Effizienz, Integrität, Verwendbarkeit, Wartbarkeit, Flexibilität,
           Testbarkeit, Portabilität, Wiederverwendbarkeit, Verknüpfbarkeit

      * Mangel & Fehler
         * Mangel (ISO 8402) Nichterfüllung einer beabsichtigten Forderung / angemessenen Erwartung

         * Fehler (ISO 8402) Nichterfüllung einer festgelegten Forderung (z.B. Quali, Zuverlässigkeit)
              Mangel ist Fehler wenn erforderliche Leistung in Anfdef exakt festgelegt ist (?).

         * Mangel: Realisierung weicht von Anforderung ab.

         * Fehler: ugs. synonym mit Irrtum (falsche Kodierung), Defekt (fehlerhafter Code),
              Befund (Fund), Fehler (Laufzeitfehler), Ausfall

               Defekt verursacht (u.U. mehrere) Fehler
               Fehler verursacht u.U. Ausfall / Ausfälle

            * Arten
               Funktions-, Schnittstellen-, Algorithmus-, Zuweisungs-, Abfrage-,
               Synchronisations-, Konfigurations-, Dikumentationsfahler

            * Werden immer auf der Abstraktionsebene gefunden auf der sie begangen wurden
               Kodierungsfehler -> Codegen
               Analyse -> Betrieb
               Entwurf -> Integration
               ...

         * Fehlerkosten nehmen zu je später im Prozess sie gefunden werden


      * Qualitätssicherungsmaßnahmen
         organisatorische, konstruktive, analytische


      * Validierung & Verfifikation
         * Validierung "Tun wir das Richtige?"
         * Verifizierung "Tun wir es richtig?"

      * Prüfung
         * Nur gegen Vorgaben prüfen
         * Wohldefiniertes Verfahren und Reproduzierbarkeit
         * Dokumentation
         * Erkannte Fehler müssen anschl. korrigiert werden

      
   ** Statische Prüfung
      * Anforderungspezifikation
         * Dokumentiert Anforderungen an Software (präzise, vollständig, überprüfbar).
         * Minimalbadingung hinsichtlich Funktion & Qualität.
         * Def. WAS geleistet werden soll
         * Def NICHT WIE es geleistet werden soll (Lösungsunabhängigkeit)
         * Pflichtenheft ist vertragl. Ausgestaltung der Anf.spez.

         * Eigenschaften:
            zutreffend, vollständig, widerspruchsfrei, umsetzbar, neutral,
            prüfbar, notwendig, bewertbar

            leicht verständlich, präzise, leicht erstellbar, leicht verwaltbar,
            verfolgbar

         * Ist zwischen natürlichsprachlich und semiformal angesiedelt
            natürlich: jeder versteht's,  vage, unvollständig, widersprüchlich
            formal: def. Semantik, automatische Prüfung, nur Spezialisten verstehen's

         * Anforderung
            * funktionale Anforderung
               Ist als Ergebnis beobachtbar.
               (Die Software sortiert Arrays.)

            * nicht-funktionale Anforderung
               Ist eine Einschränkung des Freiheitsgrades der Software.
               (Das Ergebnis muss dem Benutzer in höchstens 20 Sekunden vorliegen.)

               * Unterkategorien: Qualität (Effizienz, Portabilität, ..),
                        Randbedingung für Entwurf (Umweltanf, Physikalische Anf ..),
                        Anf an Prozess (Vorgehensmodell, Support, Inbetriebnahme)

         * Aufbau (Pfichtenheft)
            * 1 Einleitung
               Zwecke & Ziele
               Benutzer des Prod.
               Annahmen & Abhängigkeiten
               Def & Namenskonv
            * 2 Produkt-Anforderungen
               Anw.bereich & Prod.abgrenzung
               Funkt. Anf.
               Anf an Daten
            * 3 Nichtfunktionale Anf.
               Benutzungsschnittstelle
               Handhabbarkeit
               Leistungsverhalten
               Wartbarkeit
               Sicherheit
               Anf an Entw.- & Zielplattform
               Sonstige Nichtfunktionale Anf.

         * Hinweise zur Formulierung
            * Exakt formulieren (nicht: mögl, kann, in den meisten Fällen)
            * Quantifizieren
            * Kennzeichnen / Nummerieren der Anf.
            * Grafiken zur Veranschaulichung
            * Begriffslexikon
            * <TBD> wenn Information noch nicht verfügbar
            * <NICHT ANWENDBAR> wenn Abschnitte nicht relevant, NICHT löschen

   
      * Prüfung natürlichsprachlicher Anforderungen
         Bei der Umwandlung von der Tiefenstruktur (was der Mensch meint) in
         naürlichsprachliche Anforderungen (Oberflächenstruktur) entstehen Defekte.
         Defekte, bzw. Hinweise auf Defekte:

         * Tilgung
            * unvollst. spez. Prozessworte
               * Im Aktiv Formulieren / Alle Akteure angeben
                  (das Pass wird an der Box angegeben -> das Pass wird von X an der Box angeg)
                  Aktiv formulieren hilft hierbei!!
                  => auf passive Formen achten
               * Vollverben nutzen
                  Vollverben verlangen oft weitere Satzbestandteile,
                  Adjektive/aufw. Phrasen verschleiern nur
                  ("einen Unterschied machen" -> "unterscheiden")
               * Prüfe ob der Satz mit mehr Akteuren Sinn macht
                  Falls ja, dann ist getilgt worden.
                  (siehe 2 Punkte weiter oben)

            * impl. Annahmen
               Anforderungen die weggelassen werden da für den Ersteller "zu banal".

            * unvollst Superlative (Steigerung), Komparative (Vergleich)
               * auf Bezugspunkt prüfen
                  (sonstige Bücher werden in Regal X eingeräumt => Was ist mit anderen Büchern?)
                  (Blabla soll leicht änderbar sein => im Vergl wozu?)

            * Modeloperatoren (Möglichkeit)
               * kann, darf, is (nicht) möglich
                  => Was ist im anderen Fall?

            * Modaloperatoren (Notwendigkeit)
               * muss, es ist notwenig, sollen
                  => prüfe ob Alternativfälle spezifiziert sind
                  (der Benutzer muss eingeloggt sein um Aktion X durchzuführen
                     => der Benutzer [..] durchzuführen, im anderen Fall erscheint
                        eine Fehlermeldung)

         * Generalisierung
            * Universalquantoren
               * alle, nie, immer, irgendeiner
                 Es wird eine Aussage auf eine Gruppe von Objekten generalisiert,
                 evtl. enthält diese aber Sonderfälle für die die Anforderung nicht zutrifft.
                 => prüfe auf Ausnahmen / Sonderfälle

            * unvollst. spez. Bed.
               * Struktur: WENN, DANN x, SONST y
                 => prüfe ob Struktur eingehalten wird, vllt wird etwas vergessen

            * Subsatntive ohne Bezugsindex
               * FAILBSP: Die Daten werden an X gegeben (Welche Daten?)
               * Unbestimmte Artikel nur bei Definition eines Objekts
               * Danach nur bestimmte Artikel


         * Verzerrung
            * Nominalisierung
               * evtl werden komplexe Vorgänge zu einmaligen Ereignissen
               * Test: Beschreibt das Substantiv etwas was man anfassen kann?
            * Funktionsverbgefüge
               * inhaltsarme Verben die erst durch weitere Substantive Sinn ergeben

         
      * Statische Prüfung durch Reviews
         Analytische Maßnahme, die Rückkopplung liefert und indirekt Qualität des Produkts erhöht.
         Prüfung eines Dokuments gegenüber Vorgaben / Richtlinien um Schwächen & Fehler zu finden (NICHT BEHEBEN).

         * Allg Vorgehen
            1. Erstelle Produkt
            2. Inspiziere
            3. Verbessere das Produkt
               falls nichts zu Verbessern weiter bei 4
               sonst weiter bei 2

         * Reviewarten (Inspection Review)
            * Technisches Review
               * Beteiligte Akteure
                  * Moderator
                     Planung (Einladung, Termin, Rollenverteilung), Leitung, neutral, kompetent
                  * Gutachter
                     Bewertet Prüfling, bereitet vor (besonders seinen zugeteilten Prüfungsaspekt),
                     2-5 Gutachter pro Review
                  * Protokollführer
                     Protokoliert festgestellte Mängel
                     Erstellt Reviewbericht (inkl. Empfehlung)
                  * Autor
                     stellt Prüfling
                     verhält sich passiv, greift nur bei Missverständniss ein
                  * Manager (steht außen vor)
                     hat Review veranlasst, nimmt nicht teil, plant Ressourcen,
                     gibt frei oder fordert nachbearbeitung
      
               * Ablauf (in etwa)
                  * Einladung
                  * 2 Wochen Vorbereitung
                  * 2h Sitzung
                  * 1h "Dritte Sunde"
                     festhalten eventueller "guter Ideen / Lösungen"
                     Beurteilung des Reviews
                     Diskussion mit Autor
                  * 2 Wochen Nachbearbeitung
                     Danach:
                        Falls nur kleine Mängel => Moderator überprüft Korrektur
                        Falls auch größere Mängel => Neue Review Sitzung
      
               * Welche Dokumente sollte man prüfen?
                  * Anforderungsdokument, Abnahmevorschrift, Benutzerhandbuch
                  * Systementwurf, Teilsystementwurf
                  * "technisches Neuland", Dokumente neuer Mitarbeiter
                  * Fehlermodul, Datenbankschnittstellen
                  * Zeit- Speicherkritische Teile
      
                  * 50% aller Arbeitsergebnisse sollten gereviewt werden.
                  * 10% des Arbeitsaufwandes sollte in Reviewsitzungen investiert werden.
      
               * Probleme bei Einführung von Reviews
                  <IMO NICHT INTERESSANT>

            * Schreibtischtest
               Der Autor prüft sein Dokument selbst während und nach der Erstellung gewissenhaft.
               Ist selbstverständlich!

            * Stellungnahme
               Autor gibt Dokument an selbst gewählte Personen und sammelt deren Meinungen
               zur Vergesserung.
               Sehr geringer organisatorischer Aufw.
               Es wird nichts dokumentiert.
               Autor kann Anmerkungen ignoereren.

            * Structured Walkthrough (mit bzw. ohne Vorbereitung)
               Autor geht mit einer kleinen Arbeitsgruppe sein Dokument
               schrittweise durch.
               Ähnlich zu technischem Review.

            * Design & Code Inspection
               Wie technisches Review, umfangreicher.
               Gutachter geben vorher Notizen aus Vorbereitung an Moderator.
               Vorleser liest Dokument Teil für Teil vor, nach jedem Teil werden
               Befunde vorgelesen.

            * Peer Review
               Gutachter prüfen Dokument alleine und liefern Bericht als Ergebnis.
   
   
   ** Testen
      * Software-Test - Einführung
         Programmausführung mit Abgleich der produzierten IST-Daten gegen gewünschte SOLL-Daten
         mit der Absicht so Fehler zu finden.

         * Ziel: Fehler entdecken

         * Testen sagt nichts über Korrektheit des Programms aus.
            Es werden Fehler gefunden, aber Fehlerfreiheit ist erst durch
            Abgleich mit ALLEN MÖGLICHEN Eingabeparametern zu garantieren,
            dies ist durch die hohe Anzahl an Eingabewerten praktisch unmöglich.

         * Test-Orakel
            * Liefert Soll-Werte
            * Darf nicht das Programm selbst sein
            * ACHTUNG: Auch Soll-Werte können fehlerhaft sein!

         * Vor- & Nachteile
            + Natürliches Verfahren
            + Reproduzierbar
            + inv. Aufw. mehrfach benutzbar (erstellte Testspezifikationen, Unit-Tests)
            - wird überschätzt (Korrektheit)
            - nicht alle Eigenschaften sind immer testbar
            - zeigt FehlerURSACHE nicht, nur Fehler

         * Arten
            Lauftest: (Entwickler) Program läuft und die Resultate sind nicht total absurd
            Wegwerf-Test: Einige Testdaten eingeben, einige Fehler erkennen
            Systematischer Test:
               Testspezifikation
               Ist-Soll-Vergleich
               Dokumentation von Prüfling, Testdaten, Resultaten

         * Prinzipien
            * Vollständigkeit ist unmöglich
            * Testen ist kreativ, soll geplant sein
            * Priorität von Terminen gegen Qualität abwiegen
            * Jeder Test hat ein Soll-Resultat
            * Entwickler sollten nicht selbst testen (Objektivität)
            * Testfälle auch für ungültige und unerwartete Eingaben

         * Testauswahl
            Exhaustive Testing ist praktisch nicht möglich.
            Deswegen Test wählen, so dass ein _Testauswahlkriterium_ erfüllt wird!

            * Testauswahlkriterium
               z.B. Alle Anweisungen vom Programm sollen einmal ausgeführt werden.

               * Zuverlässigkeit: Wenn alle Mengen von Testfällen die diesem Kriterium genügen
                  dieselben Fehler finden

               * Gültigkeit: Für jeden Fehler gibt es eine Menge von Testfällen, die den Fehler
                  finden.

               * Ist ein Kriterium zuverlässig und gültig, so werden alle Fehler gefunden.
               * Es gibt kein solches praktisch umsetzbares Kriterium.

            * Ein Programm ist bzgl. eines Kriteriums "angemessen getestet" wenn keine Fehler
               mehr gefunden werden.

            * Weyuker-Axiome (Angemessenheit)
               * Applicability (es ex. zu jeden Prog. angemessene Testfallmenge)
               * Non-Exhaustive-Applicability
               * Monotonicity: Übermengen angemessener Testfallmengen sind auch angemessen.
               * Inadequate Empty Set: Leere Menge ist nicht angemessen
               * Complexity: Für alle Prog ex n mit: Alle konformen Testmengen haben Kardinalität >= n
               * Statement Coverage: ist Tesftallmenge angemessen => jede Anweisung wird ausgeführt
               * Renaming: Umbenennung von Bezeichnern ändern an Testfallmenge nichts (WTF?)
               * Antiextensionalität:
                  Zwei Prog leisten semantisch das gleiche != gleiche Testfallmenge
               * Antidekomposition: Prog angemessen getestet =nicht!=> Komponenten sind angemessen getestet
               * Antikomposition: Komponenten sind angemessen getestet =nicht!=> Prog angemessen getestet

         * Testfälle müssen sein
            * repräsentativ
            * fehlersensitiv
            * redundanzarm
            * ökonomisch

         * Ziel: Möglichst wenige Testfälle, möglichst viele Fehler finden
               
         * Testarten
            * Blackbox Test
               Auswahl nach Spezifikation, Programmstruktur unbekannt
            * Whitebox Test / Glassbox Test
               Testauswahl anhand der Programmstruktur, Spezifikation ebenfalls bekannt
   

      * Black-Box Test
         Testfälle anhand Spezifikation aussuchen (Wogegen testen? Sollergebnisse.)

         + Überprüfung der spezifizierten Funktionalität.
         - Erreicht nicht die Anforderung des White-Box Tests: z.B. Zweig- / Codeüberdeckung

         * Testauswahlkriterien:
            * Funktionsüberdeckung (jede Fkt einmal ausf)
            * Eingabeüberdeckung (zu viele Eingaben)
            * Ausgabeüberdeckung

         * Myers Techniken zur Testauswahl:
            * Äquivalenzklassenbildung
               Fasse Eingaben mit ähnlichem Verhalten zusammen (z.B. Wertebereiche).

               * gültige & ungültige Äquivalenzklassen
               * Jede Klasse wird durch einen bzw. mehrere Representanten getestet

               * Testfälle sollen möglichst viele Äq-Klassen abdecken (eine bis mehrere).

            * Grenzwertüberprüfung
               * Sind Äq-Klasse geordnet => Grenzwertanalyse
               * Testfälle aus
                  Daten die an inneren Rändern von Äq-klassen liegen
                  (mögl. ungültige) Daten die an äußeren Rändern von Äq-Klasse liegen

            * Ursache-Wirkungs-Prinzip
               * Aufteilung von Faktoren in Graphen-Knoten
                  * Ursachen-knoten (z.B. Eingabe)
                  * Wirkung-knoten (z.B. Ausgabe)
               * Kanten im Graphen repräsentieren Abhängigkeiten (Kanten zwischen Ursache und Wirkung)
                  * Identität
                  * Negation
                  * Und
                  * Oder
               * Auftreten von Ursachen einschränken (Beziehung zwischen Ursachen)
                  * Exklusiv (höchstens eine Ursache kann gleichzeitig auftreten)
                     O---e---O
                  * Inklusiv (mindestens eine Ursache tritt auf)
                     O---i---O
                  * One And Only (immer genau eine Ursache tritt auf)
                     O---o---O
                  * Requires (Ursache verlangt dass andere erfüllt ist)
                     O------>O
                  * Masks (tritt Ursache A ein, impliziert das dass Ursache B nicht eintritt)
                     O---M-->O
               * Erzeuge Tabelle in der jede Ursachenkombination auftritt
                 und halte Wirkungen fest. Dies bringt neue Testfälle.

            * Error Guessing (intuitives Testen)
               Kein systematisches Verfahren, Ausprobieren!
   
      * White-Box-Test
         Einsicht in Programm. Testfälle werden so gewählt dass Programm
         systematisch überdeckt wird.
            * Anweisungsüberdeckung
            * Zweigüberdeckung
            * Pfadüberdeckung

         + formale Testauswahlkriterien lassen sich definieren
         - in der Spez. aufgeführte Funktionalität wird nicht erkannt

         * Programm darstellbar als Flussdiagramm
            * Anweisung = Knoten
               blablabla();
            * Zweig = Kante nach Bedingung
               if then, if then else, switch case, for, while
            * Pfad = Weg von Start bis zum Ende
               Alle Pfade <=> Jede mögliche Kombination aller Zweige bei
               maximalem Schleifendurchlauf

            Eine Überdeckung kann nur rechnergestützt ermittelt werden!

         * Anweisungsüberdeckung
            Testfälle durchlaufen alle Knoten (evtl Kanten ausgelassen)
         * Zweigüberdeckung
            Testfälle durchlaufen alle Kanten (evtl Pfade ausgelassen)
         * Pfadüberdeckung
            Alle Pfade (siehe oben)
         * Termüberdeckung
******************************* NOCHMAL ANSCHAUEN !! *******************************
         * Pfadüberdeckung
            Unrealistisch, zu viele Pfade.
         * Eingeschränkte Pfadüberdeckung
            Schleifenpfade werden nicht alle benutzt, nur solche,
            die eine Verhaltensänderung hervorbringen.
            * 0 Iterationen
            * 1 Iteration
            * 2 Iterationen
            * typische Anzahl von Iterationen
            * max. Antahl von Iterationen

         * Bewertung
            Anweisungsgrad: schwach, z.B. fehlende Anweisungen werden nicht entdeckt
            Zweigüberdeckung: in Praxis angestrebt
            Pfadüberdeckung: kaum erreichbar (oft wegen Schleifen)

         * Überdeckungsgrad: Prozentsatz der aussagt wie viel von der gewählten
            Überdeckung erreicht wurde
   
      * Beispiele für die Testauswahl
         (whitebox)
         * Anweisungsüberdeckung
         * Zweigüberdeckung
         * Termüberdeckung
         * Pfadüberdeckung
         
         (blackbox)
         * Eingabeüberdeckung
         * Ausgabeüberdeckung
         * Funktionsüberdeckung
   
      * Organisation von Tests

         * Testebenen
            Modultest (Unit test; gegen Modulentwurf prüfen)
            Integrationstest (Zusamenspiel von Modulen; Architekturentwurf)
            Systemtest (Gesamtsystem prüfen; Spezifikationen)
            Abnahmetest (Gesamtsystem; Kundenerwartungen)

         * Testablauf
            1. Planung (erhalte Prüfplan)
            2. Vorbereitung (erhalte Testfälle, Testvorschrift, Testgeschirr)
            3. Ausfürhung (erhalte Testprotokoll)
            4. Auswertung (erhalte Testbericht)
            5. Analyse

            * Planung
               Zeitplanung
               Personaleinteilung
               Welche Dokumente erstellen?
               Testdurchführung
               Kosten

            * Vorbereitung
               Testfälle auswählen
               Testumgebung bereitstellen
               Testvorschrift erstellen

            * Ausführung
               Testumgebung aufsetzen
               Testfälle ausführen
               Ergebnisse festhalten

            * Auswertung
               Testbefunde zusammenstellen
               Testbericht
               Empfehlung abgeben

            * Fehlerbehebung (kein BEstandteil des Tests!)
               Symptome analysieren
               Ursache finden
               Fixen

         * 829‐1998 IEEE Standard for Software Test Documentation
            1. Testplan
            2. Test Design Specification
            3. Testcase Specification
            4. Test Procedure
            5. Test Item Transmittal Report
            6. Test Log
            7. Test Incident Report
            8. Test Summary Report

         * Testplan
            * definiert zu testende & nicht zu testende Aspekte
            * legt Ressourcen fest
            * def welche Dok erstellt werden
            * Zeitrahmen
            * identifiziert zu testende Software
            * beschreibt kurz Testaktivitäten
            * Verantwortlichkeiten regeln

         * Testspezifikation
            * Festlegung von Testfällen
               sinnvoll strukturiert (hierarchisch)
               basierend auf Anforderungen
            * Festlegung der Prüfungsumgebung (Hardware / Software)

            * Hierarchie
               * Test Gruppe
                  Enthält Testsuiten die für einen Aspekt
                  (funktional / nicht funktional) entwickelt wurden.
               * Test Suite
                  Testfälle für einen Teilaspekt.
               * Testfall
                  <klar>

               * Bezeichnungsschema: TestGroup_TestSuite_TestCase


      * Wirtschaftlichkeit von Prüfungen
**************************** FOLIEN SPÄTER DURCHARBEITEN *************************************
   
      * Test objektorientierter Programme
         Neue Techniken / Möglichkeiten / Paradigmen:
         Vererbung, Kapselung, Kohäsion & Kopplung

         * Buzzwords die sinnlos auf den Folien stehen:
            OO Reengineering, Refactoring (Code, Design), OO Tests

         * Prinzipien bleiben unverändert, werden aber angepasst
            Was ist eine Unit in OO?
            Wie geht man mit Vererbung um?
            Teilweise neue Testverfahren nötig.

            * viele Klassen, jede Klasse aber überschaubar
            * Klassen müssen im Vererbungskontext gesehen werden
            * Klassen sind stark vernetzt
            * logische Komplexität gering, strukturelle hoch

            * Zweigüberdeckung
               ist leicht zu erreichen, da Klassenmathoden bei guter OO sehr simpel sind
               bei schlechter OO sinnvoll

            * Blackbox
               gut verwendbar, unterscheiden sich kaum zu klassischem black box
               Testfälle aus Analysedokument (Use Cases)
               Äquivalenzklassenbildung bzgl Klassenmethoden

            * Klassentest (Unit Test)
               * Probleme
                  Klassen benötigen zusätzliche Klassen zur Funktionalität
                  nur Schnittstellenoperationen sind testbar
                  Kapselung verhindert Hineinsehen in Klasse / Interna
                  Objekte verhalten sich wie Zustandsautomaten
                     !! Methodenergebnisse können je nach Zustand unterschiedlich sein !!
                     Gleiche Modsequenzen müssen mit unterschiedlichen Attrwerten getestet werden

            * Klasseneinteilung
               * Nonmodale Klassen
                  keine Einschränkung für Reihenfolge der Operationen (Person)
               * Unimodale Klassen
                  Methoden nur in fester Reihenfolge aufrufbar (Kartenspiel)
               * Quasimodale Klassen
                  Zustand der Klasse muss bei Aufruf berücksichtigt werden (Qeque)
               * Modale Klassen
                  Zustand der Klasse und feste Reihenfolge muss berücksichtigt werden

            * Richtlinien für Klassentest (nach Binder)
               * Jede Operation ausführen
               * all message parameters and exported attr are checked using equiv-classes ?!
               * every outgoing exception is raised and every incoming is handled
               * Jeder Zustand wird erreicht
               * Jede Operation wird in jedem Zustand ausgeführt
               * Jeder Zustandsübergang (auch unmodelierte / ungültige) wird getestet
                  um Schleichwege zu finden
               * Stress-, Performance- und "Verdachts"-Tests werden durchgeführt

            * Testbarkeit von OO Systemen
               wird beeinflusst vom Grad der KOPPLUNG und des INNEREN ZUSAMMENHALT (KOHÄSION)

            + Klassen haben klare Schnittstellen
            + Änderungen an Klassen können gemacht werden wenn wenn die Schnittstelle stabil bleibt
               und Test bleibt gleich

            * Testen nach Modifikation (Regressionstest)
               * Modultest & Integrationstest sind immer zusammen zu sehen
                  => Zusammenspiel der Klassen erneut testen
               * Vererbung
                  Klasse muss im Kontext ihrer Oberklasse betrachtet werden.
               * Antikomposition
                  Unterklassen veränderten Klasse müssen mit getestet werden.
               * Antidekomposition
                  Alle Operationen der Oberklasse der veränderten Klasse
                  müssen erneut getestet werden.
               * Redefinition v. Methoden
                  Wird Methode einer Oberklasse in Unterklasse redefiniert,
                  so müssen Testfälle im Kontext der Unterklasse neu erstellt werden,
                  d.h. neue Testfallmenge.
               * JoJo-Effekt (evil)
                  * Polymorphismus sorgt dafür dass zur Laufzeit richtige Impl. gewählt wird
                  * suche nach implementierung einer SELF-NACHRICHT beginnt bei empfängerklasse
                  * Rekursive Def können Operationen schaffen die ihre eigenen Vorgänger aufrufen

                  * Redefinieren kann bestehende Implementierungen ANDERER OPERATIONEN
                        in Wirkung verändern!
                     superclass { init(){ getBitmap(); getBitmap(){...} } }
                     subclass { init(){ super.init(); } }
                     subsubclass { init(){ super.init(); } }

                     superclass { init(){ getBitmap(); } getBitmap(){...} }
                     subclass { init(){ super.init(); } getBitmap(){...} }
                     subsubclass { init(){ super.init(); } }

                     nun wird subsubclass nicht mehr richtig initialisiert, da
                     in superclass.init{} nicht mehr das getbitmap von superclass
                     benutzt wird sondern von subclass

                  * Problem: Welche Operationen müssen nun getestet werden? Auch andere Operationen
                     werden in Verhalten manipuliert!
                     * Es müssen u.U. Operationen aller Oberklassen und aller Unterklassen
                        neu getestet werden!
                     * Es müssen Operationen der Unterklassen in ihrem Kontext neu getestet werden

               * Vollständiges Testen
                  Testen aller Klassen mit allen EIgenschaften (inkl geerbter Eigenschaften).
                  Es wird zu viel getestet.
                  Wiederverwertung von Testsuiten und -fällen wird verspielt.

               * Inkrementelles Testen
                  * Test-Suites als Eigenschaften einer Klasse betrachten
                  * Unterklassen erben Testsuites
                     * Automatisches Berechnen
                        * aller neuen Eigenschaften
                        * geerbten, aber im Kontext der Unterklasse geänderten Eigenschaften
                     * Modifikation der Testsuiten
                        * Welche Testsuites gelten auch für Unterklassen
                        * Welche nicht?
                        * Welche kommen neu hinzu?

                  + Es wird nur Nötiges getestet
                  + Es werden Testsuiten wiederverwendet

                  * Vorgehen
                     1. Für Wurzelklasse werden Testsuiten erstellt
                     2. Inkrementelles testen entlang der Vererbungsstruktur
                        * neue Methoden: Neue Testfälle
                        * Redefinieren: Neue Testfälle
                              Semantisch ähnliche Programmteile mit neuen Tests testen (?!)
                        * Geerbte Methoden: Tests neu ausführen im Kontext der Unterklasse

               * Testmethoden nach Forschungsstand
                  * Zustandsbasiert: Klassen sind Zustandsautomaten
                  * Inkrementell: Reduktion von Testfällen pro Klasse (Wiedervererbung)
                  * MM-Pfad und ASF: Test der Klassen entlang zentraler Nachrichtenstruktur
                  * Use Case basierter Test: Im Systemtest & Abnahmetest



      * Zustandsbasierter Klassentest
         Klasse <=> Zustandsautomat

         * Instanzvariablen legen Zustand fest
         * Allein Mehtoden verändern den Zustand
         * Zustand bleibt zwischen Mehtodenaufrufen bestehen

         * Methoden sehr einfach aufgebaut
            => testen einzelner methoden uneffektiv
            => testen von interaktion zwischen methoden
         * Jede Methode muss in jeden Zustand getestet werden


         * FREE Zustandsmodell (flattened regular expressions)
            * flattened => geerbte methoden / instanzvariablen werden in zustandsautomat
                  übernommen
            * neuer Zustand ist immer Ergebnis eines Meth.aufrufs
            * Automat nicht zwingend vollständig, aber EINDEUTIG (d.h. deterministisch)

            * Bilde Äquivalenzklassen wie zuvor, da sonst zu viele Zustände
            * Notation: UML Zustandsautomat

            * Bestandteile Zustandsübergang
               * akzeptierender Zustand und Folgezustand
               * auslösendes Ereignis (z.B. Nachricht, Exception)
               * optionale Bedingung (guard)
               * beliebige Anzahl von Aktionen (z.B. Antwort an Server, Antw. an Client)

            * alpha-Zustand: Zustand eines Objektes vor seiner Konstruktion
            * omega-Zustand: Zustand eines Obj nach seiner Vernichtung

            * Fehlermodell
               * Automatentheoretische Sicht
                  * falsche bzw keine Aktion wird ausgelöst
                  * falscher (fehlender) Zustandsübergang
                     * Übergang in falschen Zustand
                     * falsches Ereignis wird akzeptiert
                     * definiertes Ereignis wird nicht akzeptiert
               * Implementierungssicht
                  * korruper Zustand
                  * Schleichweg
                  * unerwartete Nachricht verursacht Programfehler
                  * Hintertür (akzepiert undef. Nachrichten)
               * beliebige Kombo dieser Fehler ist möglich

            * Zustandsbasierter Test analog Pfadtest
               * Test aller Zustandsübergänge praktisch nicht möglich

            * Testüberdeckungshierarchie
               * 0-Switch   Test jedes Zustandübergangs
                     * alle Aktions-, keine Übergangsfehler
               * 1-Switch   Test jeder Folge v. zwei Zustandsübergängen
                     * alle Aktions-, einige Übergangsfehler
               * 2-Switch   Test jeder Folge v. drei Zustandsübergängen
                     * alle Aktions-, einige mehr Übergangsfehler
                  ...

               * n-1-Switch   Test jeder Folge v. n Zustandsübergängen
                     * alle Aktions-, alle Übergangsfehler inkl Extrazustände
               * W-Methode   Gezielt berechnete Folgen auf Basis von Roundtrip-Folgen
                     * findet zusäzlichbegrenzte Zahlfehlender Zustände

            * N+ Teststrategie
               Zustandsautomat in UML Zustandsdiagramm

               * Ablauf
                  1. Free-Zustandsautomat für Klasse entwickeln
                  2. Bestimme Testfälle für alle Roundtrip-Folgen
                     * Abrollen des Free-Automaten
                     * d.h. von Startzustand alle Methoden aufrufen und in neue
                       Zustände expandieren, dann rekursiv.
                       Zustand nicht mehr expandieren wenn dieser zum zweiten
                       mal expandiert wurde
                  3. Bestimmt Testfälle für alle Schleichwege
                  4. Ermittele Testdaten zu jedem Testfall
                  5. Testfälle ausführen

               * N+ Überdeckung
                  * vollständihg wenn alle Testfälle durchgeführt
                  * findet alle Zustandssteuerungsfehler, Schleichwege,
                    sowie viele korrupte Zustände

            * Ereignis-Reaktions-Tabelle
               * Zeilenbeschriftung:      Zustandsübergänge / Methode & Guards (Bedingungen)
                 Spaltenbeschriftungen:   Zustände

               * Zelleninhalt:      Reaktion wenn Methode (aus Zeile) in Zustand (aus Spalte)
                        ausgeführt wird.

               * gültige Zelleninhalte:
                  * Erlaubt   von diesem zustand aus ist methodenaufruf ok
                  * Fehler   methodenaufruf nicht ok
                  * Unmöglich   guard der methode schließt zustand aus

            * Überprüfung des Zustands
               Woher weiß ich in welchem Zustand die Klasse ist?

               * Zustandsreporter
                  Methoden wie isOpen(), isLocked(), ...
                  erfordert Zugriff auf Implementierung, dafür praktikabel
               * Zustandssignatur
******************************************** NOCHMAL DURCHARBEITEN **********************************************

            * Diskussion
               * ist effektiv
               * theoretisch fundiert
               * aufwand hängt direkt von größe des zustandsautomaten / klasse ab
               * nur für modale klassen sinnvoll
               * test der interaktion zweier (/mehrerer) klassen erfordert produktautomaten


         * ASTOOT - ATD-basierter Klassentest (a set of tools for object oriented testing)
            * blackbox verfahren für klassentest
            * adt spez als grundlage
            * automatisiertes verfahren
            * testet folge von methodenaufrufen statt einzelner methoden
               schaut ob objekt in gleichem zustand bleibt oder wechselt
            * keine kentnisse der internen impl nötig

            * verhalten eines atd, methoden: observer (getter methoden),
                         konstruktoren,
                         transformierer (zustandsüberführer)
            * algebraische spezifikation (syntaktik=schnittstelle,semantik=methodenrümpfe)
               * syntax beschreibt die schnittstelle eines atd
               * semantik beschreibt verhalten des atd
               * muss konsistent sein (kein widerspruch)
               * muss vollständig sein

            * Äquivalenz
               Zwei Objete sind beobachtbar äquivalent wenn sie sich nicht durch
               Methodenaufrufe unterscheiden lassen (gleiches Verhalten).
               * Äquivalenter abstrakter Zustand !

            * Korrektheit einer Klasse
               Eine Klasse C ist korrekte Iple eines ATD T wenn, wenn:

               * operationen von T sind signaturerhaltend auf C anwendbar
               * für ein operations-paar bzgl T, die anwendung auf C die entsprechende
                 nachrichtenfolge beobachtbar äquiv objekte liefert (von T und C)
               * und umgekehrt

               * 1:1 beziehung zwischen abstrakten zuständen von T und C


            * ASTOOT Testfall: Nachrichtenfolge (S1,S2)
               * Ausführung S1 wird auf Objekt1, S2 auf Objekt2 ausgeführt
                 Testen ob Objekte beobachtbar äquivalent sind

               * Wiederholung für alle S1, S2 Kombinationen
                  Zeigt Korrektheit der Implementierung
                  praktisch nicht möglich

            * ASTOOT löst Orakelproblem

   
      * Testautomatisierung - JUnit
            
            * Motivation
               Entwickler verändern Code laufend
               Test wiederverwandbar (manueller regressionstest ist in der praxis eine illusion)


            * Automatisierbarkeit
               * Identifikation, Entwurf und Implementierung sind nicht gut automatisierbar
               * Testausführung und -vergleich sind gut automatisierbar
               * Impl. ist halbautomatisierbar / manchmal automatisierbar


            - Grenzen der Automatisierbar
               * Erfahrener menchl. Tester
                  erkennt intuitiv fehler auch wenn daten korrekt
                  ist intelligent, kann auf unerwartete situationen reagieren
               * Automatisierung nicht sinnvoll
                  wenn nur einmal getestet wird
                  häufige grundlegende änderungen an der software
                  guis (schwer für maschine)
                  physische interaktion erforderlich (z.b. ec-kartenleser)

            + Vorteile
               * Minimaler aufwand zum Testen neuer Softwareversionen
               * Höhere Effizienz (schneller, öfter testen), mehr Vertrauen
               * Tests mögl die von Hand unmögl (test mit 200 benutzern)
               * bessere nutzung der ressourcen (langweiliges manuelles testen) (zuverlässiger) (über nacht testen)
               * bessere testwiederverwendung

            - Nachteile
               * trügerische sicherheit (falls keine fehler entdeckt werden; unvollständige tests)
               * veränderung der sofware erfordert veränderung der testfälle

            * Testgeschirr
               Daten und Werkzeuge die für Test nötig

               * Setup
               * Testausführung
               * Vergleich
               * Cleanup
               * Protokoll


            * JUnit
               Framework zum Testen in Java.

               * Testfälle werden direkt in Java programmiert
               * Idee: Inkrementell zum Coding werden Tests geschrieben

               * Test Unit ist generell eine Klasse, dies ist aber nicht zwingend,
                 alles kann getestet werden.


               * XP Philosophy
                  * Implement tests first, then write the Code
                  * Entwicklungsstand anhand der Tests sichtbar
                  * Testen mehrmals täglich

               * Entwurfsziele
                  * Simpel
                  * Automatische Testausführung
                  * Hohe Wiederverwendbarkeit
                  * Klare Struktur

               * Testfälle sind abgeleitet von TestCase
                  * Testmehoden nennen sich testXXXX
                  * enden mit assert(condition);

                  * Assertions
                     assert(cond)
                     assert(failstring,cond)
                     fail() //schlägt immer fehl
                     assertequals(obj,obj) obj äquivalent?
                     assertequals(int,int) analog für long, float, boolean, ..
                     assertNotNull(bla)
                     assertNull
                     assertSame(obj,obj) obj identisch?

                  * wiederverwendung
                     * setUp() stellt gleiche umgebung für mehrere testfälle in einer
                       klasse dar; muss nur einmal implementiert werden.
                     * tearDown() räumt nach jeden test auf

                  * TestSuite ist composite-klasse für testcases,
                     so kann man tests zusammenfügen

   
      * Configuration & Change Management

         * Dokumente: Softwareentwicklung erzeugt Dokumente (Code, Klassen, Spezifikationen, ..)
            * Dokumentarten:
               * Projektdokumentation
                  Projektauftrag
                  Abschlußbericht

                  Zweck:      Führung des Projekts
                  Leser:      Linien- & Projektmanager
                  Betrachtet:   Verlauf des Projekts
                  Aktualisierung:   unerwünscht
                  Aufbewahrung:   bis Projektende + n Jahre
               * Systemdokumentation
                  Anforderungsspezifikation
                  Abnahmevorschrift
                  Testspezifikation
                  Entwurfsbeschreibung
                  Codelisting

                  Zweck:      Transfer des KnowHow über das System
                  Leser:      Entwickler, Wartungsingenieure, Tester
                  Betrachtet:   Beschr. des Systems
                  Aktualisierung:   erforderlich
                  Aufbewahrung:   bis Ende Nutzung
               * Qualitätsdokumentation
                  Abnahmebericht
                  Testprotokolle
                  Reviewberichte

                  Zweck:      Führung des Projekts
                  Leser:      Linien- & Projektmanager
                  Betrachtet:   Resultat einer Prüfung
                  Aktualisierung:   verboten
                  Aufbewahrung:   bis Ende Nutzung
               * Prozessdokumentation
                  Richtlinien
                  Handlungsanweisungen
                  Guidelines
                  Standards
                  Musterdokumente

                  Zweck:      Konsens über Arbeitsweise festhalten
                  Leser:      alle am Projekt beteiligten
                  Betrachtet:   Abläufe, Mehtoden, Hilfsmittel, Konventionen
                  Aktualisierung:   erwünscht
                  Aufbewahrung:   bis Ende Nutzung, so lange es Firma gibt

         * In der Entwicklungsgeschichte werden Dokumente erstellt & verändert
            Fehler dabei:

            * falsche Komponenten werden integriert
            * Teile werden übersehen, mehrfach entwickelt
            * Dokumentänderungen gehen verloren, von Entwicklern überschreiben


         * Softwareeinheit
            * Jedes Dokument, jede Komponente die erstellt wird
            * Ist ein Atom (Papierdokumente & Dateien)

            * Version: definierter Änderungszustand einer SWEinheit; Versionen folgen aufeinander
            * Revision: Version die eine vorherige Version ersetzt
            * Variante: Version die eine Alternative zur Vorgängerversion ist

         * Konfiguration:
            Eine Menge von Softwareeinheiten in jeweils einer bestimmten Version.
            Softwareinheiten passen konsistent zusammen.
            Wird für bestimmten Zweck gebildet (Demo, Kunde X).

            * Baseline (Spezialfall einer Konfiguration)
               * wird definiert um änderungen bis zu einem wohldef Ausgangspunkt zurückverfolgen zu können
               * nicht notwendigerweise lauffähig

            * Release
               * eine Baseline mit dem Zweck sie an den Kunden auszuliefern
               * ist IMMER ein lauffähiges system

         * Konfigurationsverwaltung
            Gesamtheit der Verfahren / Methoden um zum bestimmten Zeitpunkt die Konfiguration
            eines Softwaresystems _eindeutig zu kennzeichnen_

            * überwacht alle änderungen an software
            * stellt konsistenz sicher
            * jederzeit rückverfolgung möglich


            * Ziele der Konfigurationskontrolle (Details in Folien)
               * Versionskontrolle
               * Konfigurationskontrolle
               * Änderungskontrolle
   
            * Bezeichnungsschemata
               * hierarchisch LTS.BDS.ENT.004 "Produkt (LTS), Teilsystem (BDS), Phase (ENTwurf), Laufnummer (004)"
               * linear LTS.013 "Produkt (LTS) und Laufnummer (013)"
   
               Die Wahl hängt davon ab, ob die Software-Einheiten zentral für mehrere Produkte
               (hierarchisch) oder dezentral für jedes Produkt (linear) registriert werden
   
   
            * Umgebung
               Bereich in dem sich Softwareeinheit befindet
   
               * Entwicklungsumgebung
               * Referenzumgebung
                  Konfigurationsverwalter hält die Einheiten, können nicht mehr modifiziert werden
               * Prüfumgebung
               * Releaseumgebung
               enthält die zur auslieferung bestimmte konfiguration (release)


         * Change Request Management
            Grund für Änderung an Software ist für
               Konfigurationsverwaltung unwichtig, aber für
               administrative / finanzielle Behandlung wichtig.

            * Situationen
               * neue Anforderung / bestehende Anforderung ändern
                  neue Entw.kosten sollten sepaat berechnet werden
               * Schnittstellenänderung
                  es muss vertraglich geregelt sein wie kosten zu behandeln sind
               * Fehler
                  aufwand den fehler zu beheben trägt zu fehlerkosten bei

            * Ziel: Anderungsanträge erfassen, analysieren, bearbeiten
               Welche Infos muss ein Änderungsantrag beinhalten?
               Wie werden Anträge behandelt?
               Wer ist an Änderung beteiligt?

            * Anforderung
               Damit Änderungen systematisch erfasst und verarbeitet werden müssen
               Äanforderungen in einheitlicher Form eingehen.

               Kategorien:
                  * Fehler
                     Änderungsantrag muss dazu führen dass sie schnell behandelt werden
                  * Wünsche
                     kann herrsteller auf marktwünsche hinweisen, sorgt aber nicht für
                     unmittelbare reaktion
                  * Irrtümer & Fehlbedienungen
                     werden antragsteller mitgeteilt, damit in zukunft vermieden
                     software muss nicht geändert werden

            * Change Request Prozess notwendig
               Wer ist wann wofür zuständig (Workflow)

               * Gliederung
                  1. Analyse
                     Fehlermeldung, Irrtum, Änderungswunsch, ..
                  2a. Fehlerbehebung
                  2b. Wunschbehandlung

               * Änderungsantrag kann verschiedene Zustände haben;
                 bestimmte Rollen von Mitarbeitern sind an diese Zustände gebunden

                  Rollen:
                  * Antragsteller
                  * Change Control Board
                     Entscheidet über Änderungsanträge
                  * Produkt Manager
                     ist für Produkt verantwortlich und ist oft Mitglied des CCB
                  * Entwickler
                     führt änderungen durch
                     testet änderung



   
      * Gastvorlesung: Erfahrungen mit dem TPI-Modell
   
   
   ** Metriken
      * Metriken - Grundlagen
         Messen ist das Abbilden von Attributen von Objekten auf Nummern um deren Eigenschaften zu beschreiben.

         Ziele:
         * Quantifizieren
         * Entscheidungsgrundlagen
         * Prognosen erstellen
         * Qualität lenken

         Ohne Messung:
         * keine Definition messbarer Ziele (ist Produkt wirklich zuverlässen/wartbar/..?)
         * kostenfaktoren können nicht zugeschrieben werden (wie groß ist das anteil am projekt?)
         * qualitative eigenschaften können nicht quantifiziert werden
         * wirksamkeit von technologien nicht einschätzbar (z.B. "effizienz durch oo ist um 150% gestiegen")

         Modell
         * Modell ist Abbild eines Originals
         * Modell ist vereinfacht, beschränkt sich auf relevante Attribute
         * gezeigte Attribute hängen vom Einsatzzweck des Models ab

         Einsatz von Modellen:
         * Wenn Realität zu komplex
         * Wenn Objekte verglichen werden sollen die IRL unvergleichbar sind
         * Wenn Änderung am Originalobjekt zu riskant / teuer / .. ist

         Messen ist Modellbildung
         * Eigenschaften eines Originals auf Modell abbilden (numerische Systeme)
         * Abbildung eines Attributes in einen Wertebereich unter einer Abbildungsvorschrift

         * Abbildung in ein empirisches Rleationsmodell, dann Abbildung in ein numerisches Relationsmodell

         Empirisches Relationsmodell
         ERC = (C,R) mit C ist Menge von Entitäten, R ist Menge von Relationen.
         Achtung, hier gibt es keine Wertebereiche, es wird zunächst nur ein Modell gebildet.

         * Attribut über das eine Aussage gemacht werden soll (Größe)
         * Entitäten die Attribut besitzen (Mensch, Gorilla, Haus)
         * Relationen zwischen Entitäten unter Berücksichtigung der Attributwerte
            (Mensch x ist größer als y, falls x größer als y ist) !!! SPRACHLICHE BESCHREIBUNG !!!

         Numerisches Relationsmodell
         NRS = (N,R) mit N Zahlenmenge, R Relationsmenge.
         Hier wird die jeweilige Ausprägung der Attribute hin abgebildet (in numerisches System).

         * (x,y) in R3   falls x>y    !!! NUMERISCHE BESCHREIBUNG !!!


         * Maß
            Definition
            * Ist eine Abbildung von C nach N
            * ordnet Entitäten aus C Zahlen aus N zu
            * bildet relation aus ERM nach NRM ab
            * respektiert relationen

         * Skala
            (ERM, NRM, M) mit ERm Empirisches Relationsmodell, NRM numerisches Relationsmodell, M Maß
            ist eine Skala.

            Arten:
            * Nominalskala
               kategorisierung von Werten. Können gleich oder ungleich sein. keine ordnung.
            * Ordinalskala
               totalordnung. median möglich.
            * Intervallskala
               totalordnung. mittelwert möglich. distanz zwischen werten bestimmbar. willkürlicher nullpunkt.
            * Verhältnisskala
               total geordnet, additiv. absoluter nullpunkt. prozentsätze ermittelbar.
            * Absolutskala
               absolute werte, in keine andere skala umrechenbar. sonst wie verhältnisskala.

         * Metrik (Definition)
            Abbilden von Software / Prozess auf skalare oder vektorielle Größe und
            Anleitung zur Interpretation der Größen.

            Produkte und Prozesse messbar.

            Klassifikationen:

            * einfache Metriken
              leicht messbar, kein arithmetischer aufwand, keine klare aussage
               * lines of code
               * anzahl der module
               * anzahl der prozessaufrufe
               * speicherbedarf

            * berechnete Metriken
              benötigen klare modellbildung, verlmüpfen direkt messbare / geschätzte größen mit vorgegebenen algorithmen
               * Fertigstellungsgrad

            * desktriptive Metriken
              liefern charakterisierung die software knapp charakterisiert
               * zyklometrische zahl

            * exakte metriken
              werden nach einem algorithmus erhoben

            * geschätzte metriken
              basieren auf subjektiven bewertungen
               * lesbarkeit

            * prognostische metriken
              liefern vorhersage von metriken die erst später direkt gemessen werden können
               * kostenschätzung

            * robuste metriken
            * unterlaufbare metriken
            * modell-basierte metriken
            * empirische metriken
            * kostenmetriken
            * fehlermetriken

            * komplexitätsmetriken / allg metriken
              aussagen über dei komplexität von programmen


         * Entwicklung einer Metrik

            * Konstruktiv
            1. identifikation eines relevantes aspekts
            2. modellierung des relevanten aspekts
               abstrahierung der realität
            3. reduktion des modells auf skalare zahl
            4. angabe von mess- & berechnungsvorschrift
            5. kalibrierung; vergeleich vin metrikresultat mit intuition / anderen daten


            * Empirisch
            schritte werden umgedreht

            1. sammlung von daten, ohne interpretation
            2. messung / subjektive beurteilung eines relevanten aspekts
            3. bildung einer theorie zur beziehung zwischen daten und aspekt

   
      * Metriken - Beispiele


         Wichtigste Metriken in Praxis:
         * Umfang derProgramme in DLOC (Delivered Lines Of Code, loc der an kunden geht)
         * Erstellungsaufwand (Personentage)
         * Preis (USD / EUR)
         * Fehlerzahl (absolut oder in fehler pro 1000 dloc)

         * ISO 9126 Qualitätsmodell
            Definiert Merkmale und Submerkmale, aber keine METRIKEN zum Messen

            * Quality
               * Functionality
               * Reliability
               * Usability
               * Efficiency
               * Maintainability
                  * Analysbility
                  * Changability
                  * Stability
                  * Testability
               * Portability

         * Qualität - Wartbarkeit (BAUM)
            Kriterien:
            * Analysierbarkeit
               Metrik:
               * Komplexität
               * A_Anweisung
               * Kommentarrate
               * Anweisungslänge
            * Änderbarkeit
               Metrik:
               * Anweisungslänge
               * Sachtelungstiefe
               * GOTO
               * Vokabel_Freq
            * Stabilität
               Metrik:
               * GOTO
               * A_IN/OUT
               * Vokabel_Freq
               * A_Aufrufe
            * Testbarkeit
               Metrik:
               * Komplexität
               * Schachtelungstiefe
               * GOTO
               * A_Aufrufe


         * Basismetriken
            * Cyclomatic Number (VG)
            * Number Of Statements (N_STMTS)
            * Comment Frequency (COMM_F)
            * Average Size Of Statements (ABG_ST)
            * Number Of Nested Levels (N_NEST)
            * Number Of Goto (UNCOND_JUMP)
            * Vocabulary Frequency (VOC_F)
            * Number Of Entry And Exit Nodes (N_IN/N_OUT)
            * Number Of Direct Calls (DRCT_CALLS)
            * Number Of Specific Branchings (COND_STRUCT)


         * Werte die Merkmale und Metriken im Baum und propagiere Messergebnisse nach oben (siehe Foliensatz Seite 7)

         * Oft: Wenige schlechte Funktionen machen einen Großteil des Systems aus

         * Komplexität IEEE
            * degree to which a system / component has a design or impl. that is difficult to understand
              and verify
            * sollte im interesse der wartberkeit möglichst gering sein !

         * Zyklomatische Komplexität - Komplexität nach McCabe
            Idee:
            * Sequenz hat Komplexität 1
            * Jede Verzweigung / Schleife erhöht die Komplexität um 1

            G = (V,E) ist ein Verzweigungsgraph für Programm
            cyclomatic complexity = |E| - |N| +  p
            wo p die anzahl der verbindungen nach außen sind (d.h. i.d.R. 2; programmeintritt, programmaustritt)

         * Prozessmetrik: Fertigstellungsgrad (Berechnung trivial)
            Wird benötigt um Projektfortschritt zu überwachen.

         * Objekt Orientierte Metriken

            * müssen berücksichtigen
               * Lokalität
               * Information Hiding
               * Vererbung
               * Abstraktion
                  Fokusierung auf wichtige Details eines Konzepts

            * Klassifikation
               * Methodenebende
               * Klassenebene
               * Vererbungshierarchien
               * Aggregatiosnhierarchien

            * Metrik Suite von Chidamber & Kemerer
               Wurden konstruktiv entwickelt und empirisch überprüft

               * WMC - Weighted Methods Per Class
                  WMC(C) = k(m1) + k(m2) + ...
                  mit k z.B. zyklometrische Komplexität

                  * Hinweis wie schwer Klasse zu verstehen ist.
               * DIT - Depth in Inheritance Tree
                  Länge des maximalen Weges von der Wurzelklasse zur betrachteten Klasse
                  * Je größer, desto komplexer.
               * NOC - Number Of Children
                  Anzahl der direkten Unerklassen
                  * Betrachtet Fehlerfortpflanzung auf Unterklassen.
                  * Je höher, desto höher die Wiederverwertbarkeit.
               * CBO - Coupling Between Object classes
                  Anzahl der Klassen mit der Klasse kommuniziert (benutzt-Beziehung)
                  (sowohl eingehende, als auch ausgehende Benutzung)
                  * Je höher die Kopplung, desto schwerer die Klasse zu verstehen.
                     * Schlechter wiederzuverwerten
                     * schwieriger zu testen
                     * anfälliger auf äderungen
               * RFC - Response For a Class
                  Anzahl der Methoden die bei Nachrichteneingang potentiell ausgeführt werden können.
                  Alle Methoden die direkt aufgerufen werden,
                  alle Methoden die durch Kopplung an andere Klasse erreichbar sind.

                  * Wenn RFC größer, dann Klasse komplexer implementiert
               * LCOM - Lack of Cohesion in Mehtods
                  Anzahl der Paare von Methoden ohne gemeinsamen Instanzvariablen
                  minus Paare von Methoden mit gemeinsamen Inst.var.

                  * Immer >= 0
                  * Je kleiner LCOM desto größer der Zusamenhalt der Klasse
                  * Wenn LCOM groß, kann Klasse möglicherweise aufgeteilt werden.

               * Law of Demeter
                  Kopplung zwischen Klassen klein halten - "only talk to your friends"

                  Es ist verboten Nachrichten an eine Klasse zu schicken, die dann weitergeleitet
                  an eine andere Klasse wird.

                  D.h. kein this->mySystem.getView().getOpenDocument().getTitle() !
                  Korrekt: this->mySystem.getOpenedTitle() implementieren!

               * GQM Ansatz (Goal-Question-Metrik)
                  Welche Metriken machen SINN und was soll gemessen werden?

                  1. Definiere für ein Projekt relevante ZIELE
                  2. Leite FRAGESTELLUNGEN ab die beantwortet werden müssen
                     um Ziele zu überprüfen
                  3. Entscheide welche Metriken dazu beitragen


                  + es wird nur das gemessen was dazu beiträgt ziele zu erreichen
                  + es wird interpretation der metriken festgelegt
                  + eine metrik kann für mehrere fragestellungen relevant sein

                  Beispiele aus Folien nachleden; DO IT FAGGOT



   ** konstr. / org. Maßnahmen // Prozessbewertung


      * Bewertung von Entwicklungsprozessen - CMMI

         * Prozess
            Sequenz von Schritten um ein bestimmtes Ziel zu erreichen.
         * Softwareentwicklungsprozess
            Transformation von Kundenbedürfnissen in Softwareprodukt.
            Kundenwünsche -> Software Requirements
            Software Req. -> Design
            Design -> Code
            Code Testen
            Installation (manchmal)
         * Softwareprozess Modell
            Abstrakte Beshcreibung ähnlicher Softwreprozesse, also MUSTER.


         * Aktivitäten Orientierte Prozessmodelle
            * Code & Fix
               Kodieren & Korrektur im Wechsel mit ad-hoc Tests.
            * Wasserfall Modell
               * keine (bzw. wenig) Iteration
               * Sequentielle abarbeitung der Stufen bis zum Projektende
               * bei Fehler wird in Phase zurückgegangen

               Systemanalyse -> Systemspez -> Systementwurf -> Modulspez und Entwurf
               -> Codierung, Modultest -> Integration & Systemtest -> Einsatz und Wartung

         * Phasenmodelle
            Ist aktivitäten-orientiertes Modell !!
            
            mein gott sind die folien schlecht. 0% win.

            * Standardphasenmodell
               siehe wasserfall
            * Spiralenmodell (Boehm)
               siehe grafik
            * V-Modell (Bundesbehörde)
               siehe grafik



         * Bewertung von SW-Prozessen
            Hohqualitatives Produkt durch hochqualitativen Prozess.
            Bewertet wird der Prozess, nicht das Produkt.


            * CMMI - Capatibility Maturity Model Integration
               Integriert vorhergehende Modelle:
               Software Engineering, Systems Engineering, Integrated Product Development

               Bestimmt den Reifegrad von Software-entwicklungs-prozessen.

               Annahmen wenn höhere CMMI-Stufe:
               * Vorhersagbarkeit steigt
               * Risiko Ziele nicht zu erreichen sinkt
               * Qualität der Produkte steigt
               * Produktivität steigt, Entwicklungszeit sinkt

               Beschreibt welche Fähigkeiten nötig sind um bestimmte Stufen zu erreichen.
               Keine spezifischen Methoden / Werkzeuge vorgegeben.

               * Reifegrade können nicht übersprugen werden, sie bauen aufeinander auf!!


               Stufen:
               1. Initial
                  ungeplant, chaotisch, erfolge nur dirch persönlichen einsatz
               2. Managed
                  Management ausgebildet, institutionalisiert,
                  Projekte werden geplant
                  Anforderungen systematisch erhoben
                  Kontrollmechanismen (Qualität, Zeit, Budget, Kosten)
                  Versions- Konfigurationskontrolle
                  Fähigkeit Prozesse und Projekte zu messen
               3. Defined
                  Prozess ist definiert und standardisiert, unternehmensweites prozessmodell
                  alle projekte verwenden diesen prozess, passen ihn evtl an
               4. Quantitatively Managed
                  detailierte maße (metriken) für produkte und prozesse
                  produkt & projekt können über maße überwacht werden
               5. Optimizing
                  mit hilfe der maße wird prozess permanent verbessert
                  neue methoden techniken werden eingesetzt, wirkung kann überprüft werden


               Maturity levels erreichbar durch Process Areas (Teilaspekte; Zeilen in Tabelle)

               Beispiel: Stufe 2 (managed) braucht Process Areas
                  * Req management
                  * Prokjektplanung
                  * Projektverfolgung und Steuerung
                  * Messung und Analyse
                  * QS von Prozessen & Produkten
                  * Konfigurationsmanagement
                  * Management von Lieferantenvereinbarungen




*** Projektmanagement

   ** Project Management Introduction

   ** Foundations of Project Planning s