Benutzer-Werkzeuge

Webseiten-Werkzeuge


start

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
Letzte Überarbeitung Beide Seiten der Revision
start [2008-04-05 17:49]
stefan
start [2015-01-04 19:12]
62.156.60.137 Links angepasst weil Seiten im Wiki verschoben wurden
Zeile 1: Zeile 1:
-====== ​Software-Qualität ​======+Stefans Wiki 
 +============
  
-===== Mögliche Klausurthemen ===== +Das hier ist [[http://​blog.macke.it|mein]] privates Wiki.
-  * Inspection +
-  * Zuverlässigkeitsmetriken +
-  * Wartungsmetriken +
-  * Fahlertoleranzmaßnahmen +
-    * Maßnahmen?​ +
-  * COCOMO +
-  * Halstead +
-    * Volumen, Difficulty, Abstraktionsniveau (Herleitung) ​            +
-  * OO-Metriken +
-  * Qualitätsmodelle +
-    * Prozessmtriken +
-  * CMM Grundprinzip +
-  * Anforderungen -> Volere +
-  * Function Points +
-  * Anforderungsanalyse ​            +
  
-===== Qualitätssysteme ===== +Beliebte Seiten:
-  * **Wann** ist ein System zuverlässig?​ **Was** macht die Qualität eines Systems aus? +
-    * **Qualität ist die Übereinstimmung mit den Anforderungen** +
-    * Nur auf Basis bekannter Anforderungen kann eine Aussage über Qualität getroffen werden, da sie sonst nur subjektiv bewertbar ist. +
-    * Unzuverlässigkeit entsteht durch **Ausfälle**. Diese sind zu definieren und **Maßstäbe** zu finden, anhand derer die Schwere der Ausfälle bewertet werden kann. +
-    * Ein System bietet **system services** (in der Anforderungsddefinition festgelegt) an und zwar mit einer gewissen **quality of service**. +
-  * **Wie** macht man ein System zuverlässig?​ Wie stellt man die Qualität eines Systems sicher? +
-    * **Konstruktive** Maßnahmen (Methoden, Techniken) +
- * **Organisatorische** Maßnahmen (Vorgehensweisen) +
- * **Analytische** Maßnahmen (Test, Review) +
-  * ZusammenfassungKonzeptionelles Vorgehen (Bild S.78) +
-    * Anforderungen <> Unzulänglichkeiten (Bewertungsmaßstäbe für Nichterfüllung,​ Maßnahmen zur Verbesserung) +
-    * Unzulänglichkeiten können nicht abgestellt, aber beherrscht werden    +
-    * Bewertungsmaßstäbe müssen anforderungsbezogen eingesetzt werden +
-    * Maßnahmen müssen zielgerichtet eingesetzt werden+
  
-==== Systemunzulänglichkeiten ==== +[[job:fiae|Ausbildung zum Fachinformatiker Anwendungsentwicklung]] 
-  * **Defekt**: Jegliche Abweichung von den Anforderungen +[[windows:installation|Was sollte ich alles machen, wenn ich Windows neu installiere?​]] 
-    nicht akzeptables Systemverhalten (tatsächliche Mängel des Systems) +[[fhwt:phwt:skriptjava|Skript zur Vorlesung Grundlagen ​der Informatik I (Java)]]
-      * AusfallBeendigung der Fähigkeit eine Leistung zu erbringen. +
-      StörungUnfähigkeit des Systems eine Leistung zu erbringen (ohne Wartung etc.). Störungen können aufgrund von Ausfällen entstehen. +
-        * latente StörungHat noch nicht zu einem Fehler geführt. +
-        * Aktivierung:​ Latente Störung führt zu Fehler (etwa bei Benutzung des gestörten Systemteils). +
-      * Fehler: Unterschied zwischen dem berechneten und dem tatsächlichen Wert. Fehler sind Symptome von Störungen. +
-        * fehlerhafter Zustandsübergang:​ Systeminterner Zustandsübergang, ​der zu einem Systemausfall führen kann. +
-        * fehlerhafter Zustand: Systeminterner Zustand, der zu einem Systemausfall führen kann (auch bei weiteren korrekten Zustandsübergängen). +
-    * nicht zufriedenstellendes Systemverhalten ​(Missverständnis des Benutzers)+
  
-==== Bewertungsmaßstäbe ==== +Kategorien 
-  * Funktionsprofil:​ up/down (Reaktion: Reparatur ja/nein) +==========
-  * degradiertes System: nur Teile des Systems funktionieren +
-  * Anwendungsdauer:​ Zeitspanne des Einsatzes eines Systems unter vorgegebenen Bedingungen. +
-  * Lebensdauer:​ Zeitraum von Betriebsbeginn bis -ausfall bei nicht-reparierbaren Systemen. +
-  * Brauchbarkeitsdauer (technische Lebensdauer):​ Zeitraum von Betriebsbeginn bis zum Zeitpunkt, an dem eine Instandsetzung nicht mehr rentabel möglich ist. +
-  * MTTFF (mean time to first failure): Zeitraum von Systemstart bis zum ersten Ausfall. +
-  * MTBF (mean time between failure): Zeitraum zwischen zwei Ausfällen. +
-    * MDT (mean down time): Zeitraum, während dessen das System nicht zur Verfügung steht (Instandsetzung). +
-      * MTTR (mean time to restoration):​ Zeitraum, während dessen das System instandgesetzt wird. +
-        * datection time: Benötigte Zeit um den Fehler zu entdecken. +
-        * diagnosis time: Benötigte Zeit um die Ursache des Fehlers zu entdecken. +
-        * time for reconfiguration:​ Zeit für Rekonfiguration des Systems. +
-        * recovery time: Zeit für das Bereitstellen des reparierten/​ersetzten Teils. +
-        * time for reintegration:​ Zeit für das Integrieren des reparierten/​ersetzten Teils. +
-      * präventive Wartungsaktivitäten +
-    * MUT (mean up time) / MTTF (mean time to failure): Zeitraum, während dessen das System zur Verfügung steht. +
-  * weitere Begriffe der ITU +
-    * required time: Zeit, während der das System zur Verfügung stehen muss. +
-    * non-required time: Zeit, während der das System nicht zur Verfügung stehen muss. +
-    * up time: Zeit, in der das System funktionsfähig ist. +
-    * disabled time: Ziet, in der das System nicht funktionsfähig ist. +
-      * down time (internal down time): Zeit, in der das System ausfallen ist.  +
-      * external disabled time (external loss time, external down time): Zeit, in der das System nicht zur Verfügung steht, weil externe Ressourcen nicht genutzt werden können. +
-    * undetected fault time: Zeit zwischen Ausfall und Erkennen der Störung. +
-    * administrative delay: Zeit, während der keine Wartung durchgeführt werden kann. +
-    * maintenance time: Zeit, während der Wartung durchgeführt wird. +
-      * active maintenance time: Zeit, während der aktiv Wartung betrieben wird (ohne logistische Wartezeiten). +
-      * preventive maintenance time: Zeit, während der präventive Wartung betrieben wird (inkl. logistische Wartezeiten). +
-        * logistic delay time: Zeit, während der aufgrund von fehlenden Ressourcen keine Wartung betrieben werden kann. +
-        * active preventive maintenance time: Zeit, die für präventive Wartung verwendet wird. +
-      * corrective maintenance time: +
-        * logistic delay time +
-        * repair time: Zeit, in der korrektive Wartung betrieben wird (inkl. logistische Wartezeiten). +
-          * active repair time (active corrective maintenance time) +
-            * fault localization time (fault diagnosis time): Benötigte Zeit zur Fehlersuche. +
-            * technical delay: Zeit für zusätzlich notwendige technische Maßnahmen. +
-            * fault correction time: Zeit für die Störungsbeseitigung. +
-            * check out time: Zeit zum Nachweis der Funktionsfähigkeit. +
-  * Überlebenswahrscheinlichkeit (reliability,​ reliability performance) **R(t)**: System ist funktionstüchtig in [0;t] (exponentiell monoton fallend) +
-  * Kumulative Ausfall- / Fehlerwahrscheinlichkeit (cumulative failure distribution) **F(t)**: System fällt in [0;t] aus: F(t) 1 - R(t) +
-  * Ausfall- / Fehlerdichte (probability density function, PDF) **f(t)**: Zeitableitung von F(t) +
-  * Ausfallrate **delta(t)**:​ umgekehrt proportional zur MTTFF +
-    * Badewannenkurve:​ Frühausfälle,​ useful operating life, Spätausfälle  +
-  * Verfügbarkeit (availability) **A(t)**: Wahrscheinlichtkeit,​ dass das System zum Zeitpunkt t funktionstüchtig ist. +
-    * steady state availability:​ MUT / (MUT + MDT) +
-  * Wartbarkeit (maintainability) **M(t)**: Wahrscheinlichkeit,​ dass das System innerhalb der Zeitspanne t wieder instandgesetzt werden kann. +
-  * Reparaturrate (repair rate): entspricht Ausfallrate +
-  * Sicherheit (safety): Das System hat keine kritischen Ausfälle (kritische Funktionen). Zusammenhang zur Überlebenswahrscheinlichkeit (Leistung des Systems betreffende Funktionen) +
-  * Vertraulichkeit (security): Das System verhindert unerlaubten Zugriff (vertrauensrelevante Funktionen). +
-  * Performance:​ Beispiele sind Durchsatz oder Antwortzeit -> Benchmarks +
-  * Qualitative Kenngrößen +
-    * Verlässlichkeit (dependability):​ Vertrauenswürdigkeit in die Leistung des Systems. +
-      * Verfügbarkeit (availability performance):​ Fähigkeit des Systems, eine Leistung zu einem bestimmten Zeitpunkt zu erbringen. +
-      * Zuverlässigkiet (reliability performance):​ Fähigkeit des Systems, eine Leistung für einen vorgegebenen Zeitabschnitt zu erbringen. +
-      * Instandsetzbarkeit (maintainability performance):​ Fähigkeit des Systems, durch Wartung instandgehalten oder repariert werden zu können. +
-      * Wartungsunterstützung (maintenance support performance):​ Fähigkeit der Wartungsorganisation,​ die benötigten Ressourcen für die Instandsetzung bereitzustellen. +
-    * Quality of Service +
-      * servicability performance +
-        * service accessability performance +
-        * service retainability performance +
-        * service integrity performance +
-      * service support performance +
-      * service operability performance +
-      * service security performance +
-      * trafficability performance +
-        * resources and facilities +
-        * transmission performance +
-        * dependability +
-          * reliability performance +
-          * maintainability performance +
-          * maintenance support performance +
-          +
-==== Qualitätsanforderungen ​==== +
-=== Arten von Anforderungen === +
-  * Basisanforderung / primitive Anforderung:​ elementare Aussage, Satz mit Verb und Objekt (<> komplexer Text) +
-    * funktional: beschreiben den Funktionsumfang des Systems (Aufgaben, Dienstleistungen) +
-    * Rand-/​Zusatzbedingung:​ beeinflusst die Umsetzung der funktionalen Anforderungen +
-      * physical (Abmessungen) +
-      * environmental (Sahara <> Sibirien) +
-      * product assurance (MUT > 6000h) +
-      * development (Programmiersprache) +
-        * implementation +
-        * test  ​        +
-  * Leistungsanforderungen:​ werden Basisanforderungen zugewiesen+
  
-=== Anforderungsdefinitionsprozess ===   +Software-Engineering 
-  * Grafik S. 64 +-------------------- 
-  * Aufnahme der Bedürfnisse/​Vorstellungen der Stakeholder +{{page>se:​start&​nofooter}}
-  * WICHTIG: verdeckte Anforderungen ermitteln +
-  * (iteratives) Extrahieren von Basisanforderungen aus den vorhandenen Anforderungsbeschreibungen +
-    * ursprüngliche Texte aufbewahren! ​         +
-  * funktionale Anforderungen ​-> Systemanalyse +
-  * nicht-funktionale Anforderungen ​-> Systemarchitektur  ​+
  
-==== Maßnahmen ==== +Programmierung 
-  * Fehlerverhütung +-------------------- 
-    * Fehlervermeidung +{{page>​programmierung:​start&​nofooter}}
-    * Fehlerbeseitigung +
-  * Fehlertoleranz +
-  * Wartung ​    +
  
-=== Fehlertoleranz === +Linux 
-  * Phasen +------ 
-    * error detection +{{page>​linux:​start&​nofooter}}
-    * damage confinement +
-    * error recovery +
-    * fault treatment / continued service  ​  +
-  * Methoden +
-    * error processing +
-      * error compensation +
-        * error correction +
-        * fault masking +
-      * error recovery +
-        * backward error recovery +
-        * forward error recovery +
-    * reconfiguration +
-      * gestörte Komponente deaktivieren +
-      * gestörte Komponente ausgliedern +
-      * Ersatzkomponente eingliedern +
-  * Redundanz +
-    * Systemaspekt ​  +
-      * strukturell +
-      * funktional +
-      * Informationsredundanz +
-      * Zeitredundanz  ​            +
-    * Aktivierung +
-      * statisch +
-      * dynamisch +
-    * Fehlerart +
-      * homogene Redundanz / Replikation ​-> Alterungsfehler +
-      * diversitäre Redundanz / Diversität ​-> Designfehler ​    +
-  * Beispiele +
-    * Fehlerkorrektur (Prüfsummenbildung) +
-      * Informationsredundanz (Prüfsumme) +
-      * strukturelle Redundanz (Speicherung von Nutzdaten und Prüfsumme) +
-      * funktionale Redundanz (Funktionen codieren/​decodieren) +
-      * Zeitredundanz (Zeit für codieren/​decodieren) +
-    * Fehlermaskierung (TMR-System) +
-      * strukturelle Redundanz (drei Komponenten) +
-      * Informationsredundanz (Verteilung der Information auf drei Komponenten) +
-      * funktionale Redundanz (Voter) +
-    * Rückwärtsfehlerbehebung (recovery points) +
-      * strukturelle/​Informationsredundanz (Speichern der alten Zustände) +
-      * funktionale Redundanz (Verwaltung der Zustände) +
-      * Zeitredundanz (Wiederholung bereits durchlaufener Schritte) +
-    * Vorwärtsfehlerbehebung +
-      * funktionale Redundanz (Funktionen zum Bestimmen des Folgezustands) +
-    * Rekonfiguration (TMR mit zwei Ersatzkomponenten) +
-      * strukturelle Redundanz (Ersatzkomponenten) +
-      * funktionale Redundanz (Austauschprozess) ​     ​+
  
-===== Produktmetriken ===== +Windows 
-  * Flesh-Kincaid-Verständlichkeitsgrad +------- 
-  * Flesh-Kincaid-Lesbarkeitsgrad +{{page>​windows:start&​nofooter}}
-  * Fog-Index +
-  * COCOMO +
-    * Entwicklungsaufwand in Mann-Monaten: PM (personal month) ​        +
-    * Entwicklungsaufwand in Monaten: TDEV (time of development) +
-    * Entwicklungsaufwand in Personen: N (number of programmers) +
-  * Function Point Verfahren (Albrechts-Metrik) +
-    * Festlegen der Systemgrenzen +
-    * Unadjusted Function Points ermitteln +
-      * Kategorisierung von Funktionen +
-      * Bestimmung des Komplexitätsgrades einer Funktion +
-      * Bestimmung des Funktionspunktwertes für eine Funktion der entsprechenden Kategorie mit vorgegebenem Komplexitätsgrad +
-      * Bestimmung des Funktionspunktewertes der gesamten Anwendung durch Analyse aller relevanten Funktionen +
-    * Adjusted Function Points ermitteln +
-    * Funktionskategorien (Datenbestände/​Transaktionen) +
-      * externe Eingaben (external input EI)      +
-      * externe Ausgaben (external output EO)  +
-      * interne Dateizugriffe (internal logical file ILF) +
-      * externe Dateizugriffe (external interface file EIF) +
-      * externe Anfragen (external inquiry EQ) +
-    * Elementarprozess / Transaktion +
-      * Kleinste für den Benutzer bedeutende Verarbeitungseinheit. +
-      * Eigenständig und in sich abgeschlossen. +
-      * Hinterlässt konsistenten Systemzustand.  ​        +
-  * Entwurfsstrukturmetriken von Blaschek +
-    * Höhenmaß, Breitenmaß,​ rel. Breitenmaß,​ Maß der Baumähnlichkeit +
-  * Modul-Bindungsmetrik +
-    * Bindung (cohesion) +
-    * Kopplung (coupling) +
-    * Bindungstypenzufällig, logisch, zeitlich, prozedural, kommunikativ,​ sequentiell,​ informal, funktional +
-  * LOC-Maß +
-  * Software-Science / Halstead-Metriken +
-    * Vokabular +
-    * Programmlänge +
-    * Programmumfang +
-    * Schwierigkeitsgrad +
-    * Abstraktionsniveau +
-    * Programmieraufwand +
-    * Intellektueller Gehalt +
-    * Programmierzeit +
-    * mittlere Fehlermenge +
-  * McCabe-Metrik / Zyklomatische Zahl  ​    ​  ​  +
-  * Test-Metriken +
-    * nicht in der Formelsammlung +
-  * Wartungsmetriken +
-    * Fehlerbeseitigung,​ Optimierung,​ Portierung +
-    * Aufwandsmetriken (Lesbarkeit,​ Korrekturzeit,​ Fehlerbeseitigungszeit) +
-    * Änderungsbezogene Metriken (Lokalisierung,​ Perfektionierung,​ Wiederverwendbarkeit) +
-    * Fehlerbezogene Metriken (Fehlerhäufigkeit,​ Fehlerzuwachs) +
-    * Entwicklungseffektivität +
-    * Änderungsmetrik von Stahlknecht +
-    * Portabilitätsmetriken +
-  * Aufwandsmetriken +
-    * Produktgröße,​ -komplexität,​ Entwicklungsumgebung ​  ​  ​   ​+
  
-===== Qualitätsmodelle ===== +Vorträge 
-  * Softwarequalität hängt von der Qualität des Entwicklungsprozesses ab. +-------- 
-  * Zuerst die Qualität messen und dann gezielt Verbesserungen vornehmen. +{{page>vortraege:start&​nofooter}}
-  * Kriterien ​-> Assessment ​-> Ergebnis ​-> Maßnahmen zur Verbesserung  +
-  * Funktionen von Qualitätsmodellen +
-    * Messlatte zur Ermittlung der Prozessqualität +
-    * Hilfestellung bei der Festlegung von Verbesserungsmaßnahmen ​    +
-  * Beispiele: CMM, CMMI, Spice, Bootstrap, ISO 9000 +
-  * Technologiekompetenz und Prozessbeherrschung müssen stets gemeinsam verbessert werden. +
- +
-===== Capability Maturity Model ===== +
-  * Ausgangspunkt ist ein Assessment anhand eines Fragebogens ​-> Prozessmetrik. +
-  * Ermittelt den Grad der Prozessbeherrschung,​ nicht jedoch die Qualität des Produktes. +
-  * Bietet einen Maßnahmenkatalog zur Prozessverbesserung. +
-  * Anleitung +
-    * SW-Entwicklungsund Wartungsprozesse kontrollieren +
-    * kritische Bereiche erkennen +
-    * die Prozesse gezielt verbessern +
-  * Softwareprozess:​ Bündel von Aktivitäten,​ Methoden und Praktiken, die eingesetzt werden, um Software und Dokumentation zu entwickeln und zu pflegen (z.B. Projektpläne,​ Architektur,​ Entwurf, Code, Testspezifikation,​ Handbücher). +
-  * Software-Entwicklungskompetenz / Prozessbeherrschung versetzt in die Lage das Entwicklungsergebnis vorherzusagen. +
-  * Software-Entwicklungsleistungsfähigkeit / Prozessqualität misst das aktuelle Entwicklungsergebnis in Bezug auf Kosten, Termintreue,​ Funktionalität und Qualität. +
-  * Software-Prozessreife beschreibt den Reifegrad, den ein Entwicklungsprozess erreicht hat -> definierte Stufen. +
-  * Reife liegt vor, wenn folgende Punkte zutreffen:​ +
-    * firmenweite Methodik zur Organisation von SW-Entwicklung +
-    * Prozess ist exakt erläuterbar +
-    * Arbeiten werden gemäß der Planung durchgeführt +
-    * Rollen und Verantwortlichkeiten sind klar definiert +
-    * Manager überwachen die Qualität des Prozesses +
-    * es liegen objektive und quantifizierbare Kriterien zur Prozessanalyse vor +
-    * es gibt festgelegte Verfahren zur Problemanalyse +
-    * Zeitplan- und Budget-Vorgaben sind realistisch und basieren auf Erfahrung +
-    * die Beteiligten befolgen die disziplinierte Vorgehensweise aus innerer Überzeugung +
-  * Stufen +
-    * chaotisch / initial -> disziplinieren +
-      * Improvisation,​ häufige Krisen, Zeitpläne/​Budgets werden überschritten,​ Funktionalitätsreduzierung,​ keine objektiven Kriterien, keine festgelegten Vorgehensweisen,​ Erfolg beruht auf einzelnen Mitarbeitern +
-      * black box         +
-    * reproduzierbar / repeatable -> konsistent machen / standardisieren +
-      * Richtlinien (Projektstandards) sind vorhanden, Planung/​Organisation beruht auf Erfahrung, diszipliniertes Management, Projektleiter überwachen Kosten, Zeitpläne und Funktionalität +
-      * es gibt Phasen und Meilensteine,​ innerhalb der Phasen: black box        +
-    * definiert / defined -> vorhersagbar machen +
-      * Standard-Entwicklungsprozess ist etabliert und dokumentiert,​ SE-Prozessgruppe ist vorhanden, Projektleiter adaptiert das Modell, firmenweite Schulungen werden angeboten +
-      * organisationsweites Verständnis,​ Phasen -> transparent,​ Standardaktivitäten  ​      +
-    * gesteuert / managed -> weiterentwickeln / kontinuierlich verbessern +
-      * Qualitätsziele sind gesetzt, Prozesse werden überwacht und bewertet +
-      * quantifizierbare/​voraussagbare Ergebnisse +
-    * optimiert / optimized +
-      * Ausrichtung des Unternehmens auf ständige Verbesserung,​ Schwachstellen werden aufgedeckt und zukünftig vermieden +
-      * kontinuierliche Verbesserung +
-  * Verbesserungen durch höhere Stufen +
-    * Vorhersagbarkeit +
-    * Kontrolle +
-    * Effektivität +
-  * Nutzung von CMM +
-    * Stärken/​Schwächen des Unternehmens identifizieren +
-    * Auswahl von Unterauftragnehmern +
-    * Maßnahmen zur Prozessverbesserung erkennen +
-    * Definition und Optimierung des eigenen Prozesses +
-  * Erreichen eines höheren Reifegrades +
-    * Reifegrad -> Schlüsselgebiet -> Maßnahmenkategorie -> Handlungsanweisung +
-    * Ergreifen von Maßnahmen in Schlüsselgebieten um Ziele zu erreichen. +
-    * Aktivitätenkategorien -> Handlungsanweisungen (Aktivitäten oder Infrastrukturmaßnahmen) +
-  * Schlüsselgebiete (Management,​ Organisation,​ Engineering) +
-    * repeatable +
-      * Anforderungsmanagement +
-      * SW-Projektplanung +
-      * SW-Projektverfolgung +
-      * Subcontractormanagement +
-      * SW-Qualitätssicherung +
-      * SW-Konfigurationsmanagement +
-    * defined +
-      * firmenweite Prozessüberwachung +
-      * firmenweite Prozessdefinition +
-      * Ausbildungsprogramm +
-      * ganzheitliche Prozessdefinition +
-      * SW-Produktengineering +
-      * Koordination zwischen Entwicklungsteams +
-      * Reviews +
-    * managed +
-      * Quantitatives Prozessmanagement +
-      * SW-Qualitätsmanagement +
-    * optimized +
-      * Defektverhinderung +
-      * Technologieveränderungsmanagement +
-      * Prozessveränderungsmanagement  ​                                    +
-  * Qualitätsziele +
-    * Feststellung der erfolgreichen Etablierung des betroffenen Bereichs im Prozess +
-    * Stecken der Rahmen der Verbesserungsmaßnahmen ab +
-    * Ableitung von Handlungsanweisungen,​ Aktivitäten und Infrastrukturmaßnahmen +
-  * Maßnahmenkategorien +
-    * Aktivitäten +
-      * Durchzuführende Aktivitäten +
-    * Institutionelle Basis / Infrastrukturmaßnahmen +
-      * Durchführungsverpflichtung +
-      * Durchführbarkeit +
-      * Prozessbewertung +
-      * Verifikation +
-  * Handlungsanweisungen,​ Aktivitäten und Maßnahmen +
-    * Die Handlungsanweisungen beschreiben das Vorgehen um die Schlüsselbereiche möglichst effizient zu etablieren. Jede Handlungsanweisung kann in einem Satz definiert werden. Eine Handlungsanweisung beschreibet was zu tun ist, aber nicht wie im Einzelnen verfahren werden soll.     +
-  * Bewertung +
-    * Formelles CMM-Assessment +
-      * Software Prozess Assessment (Kooperation,​ offene Athmosphäre) +
-      * Bewertung der Software Prozessbeherrschung (eher offizielles Audit) +
-      * Schritte +
-        * Bewertungsteam zusammenstellen +
-        * Ausfüllen des Fragebogens +
-        * Auswertung des Fragsbogens +
-        * Besuch des zu bewertenden Bereichs -> Interviews, Inspektion, Übereinstimmung mit Zielen prüfen +
-        * Erstellen eines Bewertungsberichts -> Identifikation der Stärken und Schwächen -> Ableiten von Empfehlungen für Optimierung +
-        * Systematische Zusammenstellung der Ergebnisse für die einzelnen Bereiche +
-    * Informelles CMM-Assessment +
-      * Bewertung der Aktivitäten  +
-      * Bereiche +
-        * Erster Schritt +
-        * Einsatz +
-        * Ergebnisse +
-      * Stufen +
-        * poor, weak, fair, marginally qualified, qualified, outstanding  ​      +
- +
-===== Manuelle Prüfmethoden ===== +
-  * Konstruktive Qualitätsmaßnahmen +
-    * technisch (Methoden, Werkzeuge, Sprachen) +
-    * organisatorisch (Richtlinien,​ Standards, Checklisten) +
-  * Analytische Qualitätsmaßnahmen +
-    * analysierend (statische Analyse, Animation, Verifikation,​ Prüfmethoden) +
-      * automatisierbare Prüfmethoden (Syntaxprüfung,​ Konsistenzprüfung,​ Vollständigkeitsprüfung) +
-      * manuelle Prüfmethoden (semantische Prüfung)  +
-    * testend (Schreibtischtest,​ Simulation, symbolischer und dynamischer Test) +
- +
-==== Manuelle Prüfmethoden ==== +
-  * Typen +
-    * (Fagan-)Inspektion,​ Review, Walkthrough +
-  * Eigenschaften +
-    * mehrere Teilnehmer prüfen ein Prüfobjekt +
-    * möglichst schnell nach der Erstellung (-> mit Objekt soll weitergearbeitet werden) +
-    * in evtl. mehreren Sitzungen +
-    * gegen eine Vorgabe/​Referenz  ​    +
-  * Ablauf +
-    * Prüfobjekt vorlegen +
-    * Eingangsprüfung +
-      * Autor muss Prüfobjekt definitiv abgeschlossen haben +
-      * Prüfreferenzen liegen vor +
-      * Unterstützende Literatur liegt vor (Checklisten,​ Wörterbuch etc.)  ​        +
-    * Planung +
-      * Aufteilung in Teilobjekte für eine Sitzung (10-20 Seiten, 250 LOC) +
-      * Festlegen der Inspektoren +
-        * Inhalt +
-        * Vollständigkeit +
-        * Intervallgrenzen/​Fallunterscheidungen +
-        * Fehlerbehandlung +
-        * Test-/​Wartbarkeit +
-        * Szenarien (z.B. UseCases, Testfälle) +
-        * Einhaltung von Standards +
-      * Verteilen des Prüfobjekts und der nötigen Unterlagen +
-      * Inspektionsregeln und -ablauf bekanntgeben und evtl. Einführungssitzung vereinbaren  ​          +
-    * (Einführungssitzung) +
-      * Benötigte Unterlagen verteilen +
-      * Erläuterung der Rollen der Inspektoren +
-      * Überblick über Prüfobjekt durch den Autor -> Hinweis auf wesentliche/​kritische Teile des Objekts +
-      * Gäste sind erlaubt ​       +
-    * Vorbereitung +
-      * Inspektoren untersuchen das Prüfobjekt unter Berücksichtigung der Regeln und ihrer Rolle +
-      * Inspektoren erstellen Inspektionsreport (Fragen, klassifizierte Defekte, benötigte Zeit) +
-      * Üblich sind 1-4 Stunden Vorbereitungszeit je Inspektor  ​         +
-    * Inspektionssitzung +
-      * 3-7 Teilnehmer (mind. Autor, Inspektor, Moderator), kein Vorgesetzter des Autors, keine Gäste +
-      * Vorlesen durch Inspektor +
-      * Dauer 2-2,5 Stunden, Geschwindigkeit 5-10 Seiten/125 LOC pro Stunde ​       +
-      * Aufgaben +
-        * Identifikation von Defekten +
-        * Klassifikation des Defekts +
-        * Moderator erstellt Protokoll +
-      * Prinzipien +
-        * In Problemen denken, nicht in Lösungen! +
-        * Nicht Verbesserungen suchen! +
-        * Diskussion und Kommentierung ist nicht erlaubt! +
-        * Der Autor muss die Ausführungen verstehen! +
-      * Argumentationsprinzipien +
-        * Es geht um das Objekt, nicht um den Autor! +
-        * Sachlichkeit,​ nicht Emotionalität! +
-        * "​Ich-Formulierungen"​ verwenden! +
-        * Beim Thema bleiben!  +
-      * Vorgehen +
-        * statisch (linear, konsekutiv),​ Schnittstellen berücksichtigen +
-        * dynamisch (Szenarien) +
-        * Checklisten  ​      +
-      * Ergebnis +
-        * Freigabe mit Auflagen +
-        * Mängel beheben, Überprüfung durch Autor +
-        * Wiederholung der Prüfung (ab ca. 5% Änderungen am Prüfobjekt oder bei kritischen Objekten) +
-    * (3. Stunde) +
-      * Lösungsdiskussion ​    +
-    * Nachbereitung +
-      * Sinn +
-        * Nachweis der Effektivität der Inspektion +
-        * Aktualisierung der Checklisten +
-        * Verbesserung der Inspektionen +
-      * (mögliche) Metriken +
-        * gefundene Fehler / Seite +
-        * Gesamtzahl der inspizierten Seiten +
-        * Vorbereitungszeit / Inspektor +
-        * Vorbereitungszeit / Seite +
-        * Dauer der Inspektionssitzung(en) +
-        * Dauer der Überprüfung einer Seite +
-        * Seiten / Inspektionssitzung +
-        * Anzahl der Fehler / Gesamtzeit der Inspektion +
-      * Fehler +
-        * Phase, in der der Fehler gemacht wurde       +
-        * Phase, in der der Fehler gefunden wurde +
-        * Fehlergewicht (schwer, mittel, leicht) +
-        * Fehlertyp (falsch, fehlend, überflüssig,​ ungenau) +
-        * Fehlerklasse (Standard, Basis, zeitlich, ...) +
-    * Mängelbeseitigung +
-      * Aufwandsabschätzung +
-      * Änderungsanträge / Einbeziehen der Projektleitung -> Anpassen der Projektplans / Priorisierung  ​      +
-    * Überprüfung +
-      * ca. 1/6 der Korrekturen ist fehlerhaft +
-      * Prüfung durch Autor, ggf. Reinspektion +
-      * Für Freigabe: alle schweren/​mittelschweren Mängel beseitigt, alle offenen Punkte bearbeitet +
-      * Durchführung,​ falls Mängelbeseitigungskosten > Kosten für Reinspektion  ​          +
-    * Freigabe  ​      +
-  * Teilnehmer +
-    * Autor(en) +
-      * Fragen beantworten +
-      * nicht verteidigen +
-      * überarbeitung des Prüfobjekts +
-    * Moderator +
-      * bestimmt Inspektoren,​ Protokollführer,​ Vorleser +
-      * achtet auf Einhaltung der Regeln +
-      * entscheidet im Zweifelsfall,​ ob Defekt gezählt wird +
-      * fasst Ergebnis zusammen +
-      * entscheidet über weiteres Vorgehen +
-      * Schlüsselrolle,​ soziale Kompetenz +
-    * Inspektor(en) +
-      * fachliche Spezialisten +
-      * auch Anwender oder Auftraggeber möglich +
-      * Aufgabe: Fehler finden +
-    * Protokollführer +
-      * erfasst Mängel, Fragen und offene Punkte +
-    * Vorleser +
-      * einer der Inspektoren +
-      * liest laut das Dokument vor          +
-  * Richtlinien und Regeln +
-    * Prüfungen haben eine hohe Priorität +
-    * der benötigte Aufwand muss eingeplant werden +
-    * Vorgesetzte und Zuhörer dürfen nicht teilnehmen +
-    * Inspektoren müssen Pürfmethode beherrschen +
-    * Prüfkriterien +
-      * allgemein: Vollständigkeit,​ Produktlayout,​ Konsistenz, Eindeutigkeit,​ Rechtschreibung +
-      * entwicklungstechnisch:​ Konsistenz zur Vorgängerprodukten,​ Nachvollziehbarkeit,​ Methodenkonformität +
-      * produktspezifisch +
-      * system- oder anwendungsspezifisch:​ Integrierbarkeit,​ Einhaltung von Plandaten  ​          +
-  * Dokumente +
-    * Erhebungsbögen der Inspektoren +
-    * Inspektionsprotokoll +
-  * Einsatz +
-    * Nach jedem Prozessschritt,​ auf jeder Softwarearchitekturebene sollte das jeweilige Zwischenprodukt geprüft werden. ​      +
-    * Schwerpunkte:​ Konformität zu Vorgängerprodukten,​ Vollständigkeit,​ Struktur, Fehlerverhalten,​ Lesbarkeit und Verständlichkeit,​ Überflüssiges streichen +
-  * Vergleich +
-    * Review +
-      * weniger formal als Inspektion +
-      * Verbesserung des Entwicklungsprozesses nur nachrangiges Ziel +
-      * Rolle des Vorlesers nicht so wichtig +
-      * Geschwindigkeit etwas höher als bei Inspektion +
-      * Ergebnis ist lediglich Empfehlung an Projektleitung,​ keine formale Freigabe +
-    * Walkthrough +
-      * stark abgespeckt +
-      * Vorbereitung kann entfallen +
-      * Autor leitet Sitzung +
-      * keine formalen Elemente (Erhebungsbogen,​ Protokoll) +
-      * Ergebnis ist eine subjektive Freigabe +
-      * Offene Teilnahmemöglichkeit -> gut für Schulungen geeignet +
-  * Bewertung +
-    * 44% der Kosten eines Projekts entfallen auf Fehlerbeseitigung +
-    * Mängel werden durch manuelle Prüfmethoden früh gefunden +
-    * Kosten zu Beginn hoch aber durch weniger Fehlerbehebung am Ende relativiert +
-    * Aufwand für systematische Inspektionen:​ 15%-20% des Gesamtaufwands +
-    * 70%-80% aller Fehler können durch Inspektionen gefunden werden +
-    * Kosten/​Zeitüberschreitung lassen sich um 30% reduzieren +
-    * Lerneffekt bei den Entwicklern +
-      * breitere Wissensbasis,​ Methoden der Kollegen +
-      * verständlichere Formulierungen,​ da mehrere Personen das Dokument lesen +
-      * Steigerung der Qualität einzelner Autoren von Sitzung zu Sitzung +
-    * Risiko: trügerische Sicherheit, wenn Verfahren nicht beherrscht wird          +
- +
- +
-===== ToDo ===== +
-  * Volere Template lesen +
-  * IEEE Testdokument lesen +
-  * Beispielaufgabe Function Points +
-  * Formelsammlung ausdrucken und durchgehen ​  +
-  * Grafik S. 156 anschauen +
-  * CMM +
-    * Beispiel ab S. 183 +
-    * Tabelle S. 190 +
-  * unklare QM-Maßnahmen anschauen (S. 196) +
-  * Checklisten S. 213 +
-  * Erhebungsbogen S. 215 +
-  * Prüfschwerpunkte S. 219 +
- +
-===== Links ===== +
-  * Kapitel 1 +
-    * [[http://​www.hubertbecker-online.de/​log3_1_1.htm|Grundbegriffe Zuverlässigkeit]] +
-    * [[http://​kbs.cs.tu-berlin.de/​ivs/​Lehre/​SS02/​VS2/​Material/​VS2ft.pdf|Verteilte Systeme II]] +
-    * [[http://​www2.hs-fulda.de/​~grams/​Reliability/​R&​S-Terms1.html#​Fehler2|Reliability and Safety]] +
-    * [[http://​www.itu.int/​rec/​T-REC-E.800/​en|Recommendation E.800]] ​      +
-  * Kapitel 2 +
-    * [[http://​ls11-www.cs.uni-dortmund.de/​people/​rudolph/​teaching/​lectures/​EINI/​WS2007-08/​kap8c-quad.pdf|Binäre Bäume]] +
-    * [[http://​wwwai.wu-wien.ac.at/​~koch/​lehre/​inf-sem-ss-01/​pinterits/​text.html|Binärbäume und AVL-Bäume]] +
-    +
-===== Lernziele ===== +
-  * Verstehen, warum eine Betrachtung von (IT-)Systemen unter Qualitätsgesichtspunkten Voraussetzung für die Beschäftigung mit dem Thema Softwarequalität ist. +
-  * Verstehen des konzeptionellen Ansatzes zur Beantwortung der Fragen: +
-    * Wann bezeichnet man ein System als verlässlich oder zuverlässig?​ Was macht die Qualität eines Systems aus? +
-    * Wie macht man ein System verlässlich bzw. zuverlässig?​ Wie stellt man die Qualität eines Systems sicher? +
-  * Wissen wie Anforderungen ermittelt werden. +
-  * Wissen wie Defekte beschrieben werden. +
-  * Wissen wie Defekte bewertet werden können. +
-  * Wissen welche Maßnahmenkategorien und welche Maßnahmen zur Erreichung der geforderten Qualität eingesetzt werden können. +
-  * Anwenden der vorgestellten Methoden und Techniken zur Ermittlung von Anforderungen. +
-  * Anwenden der vorgestellten Methoden und Techniken zur Ermittlung von Bewertungsgrößen. +
-  * Wissen wie Systemunzulänglichkeiten beschrieben werden. +
-  * Wissen wie Systemunzulänglichkeiten bewertet werden können. +
-  * Verständnis,​ warum Produktmetriken für den Softwareentwicklungsprozess bedeutsam sind. +
-  * Kenntnis über vorgestellte im Softwareentwicklungsprozess einsetzbare Metriken. Wissen um den Beispielcharakter der vorgestellten Produktmetriken. +
-  * Anwenden der Metriken. +
-  * Verstehen der Bedeutung und des Zwecks von Qualitätsmodellen. +
-  * Wissen, welche Qualitätsmodelle in der Softwareentwicklung eine Rolle spielen oder gespielt haben. +
-  * Kenntnis des CMM-Modell-Konzepts. +
-  * Kenntnis der CMM-Modellkomponenten. +
-  * Kenntnis des Vorgehens bei der Bewertung von Softwareentwicklungsprojekten mit Hilfe des CMM-Modells. +
-  * Kenntnis über den Nutzen von Inspektionen. +
-  * Kenntnis über die Abgrenzung von Inspektion, Review und Walkthrough. +
-  * Fähigkeit zur Durchführung von Inspektionen. +
- +
-   +
-===== Aufgaben ===== +
- +
-==== Qualitätssysteme ==== +
-  * Grenzen Sie die Begriffe "​Fehler",​ "​Ausfall"​ und "​Störung gegeneinander ab! +
-    * Ein Ausfall bezeichnet die Beendigung eines Elements, eine angeforderte Leistung zu erbringen (z.B. Hardware geht kaputt). +
-    * Eine Störung bezeichnet die Unfähigkeit eines Elements, eine angeforderte Leistung zu erbringen. Störungen können durch Ausfälle verursacht werden (müssen es aber nicht, Bsp. Programmierfehler). +
-    * Ein Fehler ist jegliche Abweichung von berechneten,​ beobachteten oder gemessenen Werten von den tatsächlich gültigen (Grundlage: Theorie, Spezifikation). Fehler sind auf Störungen zurückzuführen (Indikatoren für Störungen). +
-  * Altert Software? +
-    * Software wird zwar mit der Zeit (wie alle Dinge) älter, verursacht aber keine altersbedingten Fehler, wie Hardware es tut. Daher müssen für Software keine Vorkehrungen getroffen werden, um Altersfehlern vorzubeugen (sofern das Soft-/​Hardwarekonstrukt gleich bleibt). ​  +
-  * Wie ist die Ausfallrate gamma definiert? Geben Sie die mathematische Formulierung an! +
-    * Siehe Kapitel 1.3.5 im Skript. ​  +
-  * Die Zuverlässigkeitsfunktion eines Systems ist: <​latex>​R(t) = 2e^{-0.1t\frac{1}{y}}-e^{-0.2t\frac{1}{y}}</​latex>. Geben Sie die kumulative Fehlerverteilung F(t) an und berechnen Sie den MTTFF-Wert! +
-    * <​latex>​F(t) = 1 - R(t) = 1 - 2e^{-0.1t\frac{1}{y}} + e^{-0.2t\frac{1}{y}}</​latex>​ +
-    * <​latex>​ +
- +
-\mbox{MTTFF} = \overline{T} = \int_{0}^\infty \mathrm R(t)\,​\mathrm dt +
- +
-\int_{0}^\infty \mathrm R(t)\,​\mathrm dt = \int_{0}^\infty \mathrm 2e^{-0.1t\frac{1}{y}}-e^{-0.2t\frac{1}{y}}\,​\mathrm dt +
- +
-= \int_{0}^\infty \mathrm 2e^{-0.1t\frac{1}{y}}\,​\mathrm dt - \int_{0}^\infty e^{-0.2t\frac{1}{y}}\,​\mathrm dt +
- +
-= [-20ye^{-0.1t\frac{1}{y}}]_0^\infty - [-5ye^{-0.2t\frac{1}{y}}]_0^\infty +
- +
-= \left[\lim_{t \to \infty}(-20ye^{-0.1t\frac{1}{y}}) - (-20ye^{\frac{0}{y}})\right] - \left[\lim_{t \to \infty}(-5ye^{-0.2t\frac{1}{y}}) - (-5ye^{\frac{0}{y}})\right] +
- +
-= \left[0 + 20y\right] - \left[0 + 5y\right] +
- +
-= 20y - 5y +
- +
-= 15y +
- +
-</​latex>​ +
-  * Für ein System ist gegebenMDT = 2 Tage, MTBF = 365 Tage. Geben Sie die Verfügbarkeit für das System an! +
-    * MUT + MDT = MTBF -> MUT = 365 - 2 = 363 +
-    * A = MUT / MTBF = 363 / 365 = 99,​452% ​    +
-  * Was ist ein "​required constraint"?​ +
-    * Eine Basisanforderung,​ die keine funktionale Anforderung ist, wird als required constraint bezeichnet. RQs stellen Randbedingungen dar und wirken sich auf die Architektur des Systems aus. Sie lassen sich kategorisieren in physical, environmental,​ development und product assurance.  +
-  * Wie ermitteln Sie aus Kundenwünschen Anforderungen?​ Beschreiben Sie den Prozess der Anforderungsermittlung! +
-    * In Gesprächen,​ Beobachtungen usw. werden initiale Anforderungen der Stakeholder erfasst und zu Papier gebracht (-> ablegen). +
-    * Diese Anforderungen werden nun genauer untersucht und Basisanforderungen abgeleitet (-> getrennt ablegen). +
-    * Die Basisanforderungen werden in funktionale Anforderungen und Randbedingungen aufgeteilt. +
-    * Funktionale Anforderungen werden (wenn sie nicht mehr weiter unterteilbar sind) in die Systemanalyse übernommen (-> getrennt ablegen). +
-    * Randbedingungen werden in die Systemarchitektur übernommen. ​    +
-  * Was ist Fehlertoleranz?​ +
-    * Fehlertoleranz bezeichnet die Fähigkeit eines Systems auch im Fehlerfall weiter seine Funktionalität anzubieten. +
-    * Phasen und Methoden siehe Skript S.68    +
-  * Welche Redundanzformen werden bei einem fehlerkorrigierenden Code (error correcting code) eingesetzt?​ +
-    * Informationsredundanz (Nutzdaten und Prüfsumme) +
-    * strukturelle Redundanz (Speicherung von Nutzdaten und Prüfsumme) +
-    * funktionale Redundanz (Funktion zum Codieren und Decodieren) +
-    * Zeitredundanz (Zeit zum Codieren und Decodieren) +
-  * Wie können Sie sich vor Design-Fehlern schützen?​ +
-    * Designfehlern lässt sich nur durch redundante Entwicklung von Systemkomponenten entgegenwirken (z.B. N-Version Programming) +
- +
-==== Produktmetriken ==== +
-  * Wozu können Lesbarkeitsmetriken oder Verständlichkeitsmetriken eingesetzt werden? +
-    * Da die Bewertung der Lesbarkeit und Verständlichkeit von Texten bei verschiedenen Personen subjektiv recht unterschiedlich ausfallen kann, werden die Metriken verwendet, um eine objektive Bewertung der Texte vorzunehmen. ​    +
-  * Geben Sie zwei Beispiele für eine Lesbarkeitsmetrik oder Verständlichkeitsmetrik an! +
-    * Flesh-Cincaid-Verständlichkeitsgrad ("​Schulnotensystem"​) +
-    * Flesh-Cincaid-Lesbarkeitsgrad (Skala von 1 bis 100)    +
-  * Ein Kassensystem hat 90.000 Quellcodezeilen. Es wird mittlere Entwicklungskomplexität angenommen. Die Einflussfaktoren tragen mit dem Nominalwert bei. Berechnen Sie den Entwicklungsaufwand in Personenmonaten! +
-    * <​latex>​ +
-     +
-\mbox{PM= \alpha \cdot \mbox{KDSI}^\beta \cdot \prod_{i=1}^{15} a_i +
- +
-\mbox{PM} = 3 \cdot 90^{1,12} \cdot 1 +
- +
-\mbox{PM} = 463,32 +
- +
-</​latex> ​   +
-  * Für eine Function Point Abschätzung sind folgende Werte vorgegeben: 2 Funktionen gehören zur Kategorie EI, 3 zu EO, 1 zu ILF, 2 zu EIF und 2 zu EQ. Der Schwierigkeitsgrad ist immer "​mittel"​. Welcher Function-Point Wert ergibt sich? +
-    * UFP = 55 +
-  * Was wird mit der Function Point Metrik gemessen? +
-    * Die Function Point Metrik steht für die voraussichtliche Größe des Projekts. Auf Basis dieses Wertes kann dann z.B. die erwartete Entwicklungsdauer ermittelt werden (z.B. über COCOMO). ​  +
-  * Wo kann die Metrik von Blaschek eingesetzt werden? +
-    * Die Metrik von Blaschek kann eingesetzt werden, um in der Entwurfsphase die Modulstruktur einer Software zu analysieren (Baumhöhe, -breite, -ähnlichkeit). Anhand von Vergleichen mit erfolgreichen Softwareprojekten kann dann die vorliegende Architektur bewertet werden.  +
-  * Was ist der schwächste Typ einer Modulbindung?​ +
-    * Zufällige Bindung: Die zusammengefassten Module stehen in keinem logischen Zusammenhang zueinander. ​  +
-  * Was wird für das LOC-Maß berücksichtigt,​ was wird beim LOC-Maß gezählt? +
-    * Für das Zählen der LOC gibt es verschiedene Vorgehensweisen. Normalerweise sollten die Codezeilen ohne Kommentare und Leerzeilen gezählt werden. +
-  * Halstead Software Science: Welche Kenngrößen werden definiert durch: (a) N1 + N2 (b) n1 + n2 +
-    * a) Länge des Programms (Gesamtzahl aller verwendeten Operatoren und Operanden) +
-    * b) Vokabular des Programms (Gesamtzahl aller möglichen Operatoren und Operanden) +
-  * Wie kommt man zu einem Grenzwert für die zyklomatische Zahl von Mc Cabe? +
-    * Man kann in der Wartungsphase früherer Projekte die Anzahl der benötigten Updates je Komponente und deren Komplexität ermitteln und dokumentieren. Aus diesen Werten kann man mit der Zeit eine Funktion ableiten, die das Verhältnis zwischen Komplexität und Fehlerzahl darstellt. Nun kann eine maximale Fehlerzahl festgelegt werden und die daraus resultierende maximale Komplexität ermittelt werden. +
- +
-==== Qualitätsmodelle ==== +
-  * Was verstehen Sie unter einem Qualitätsmodell?​ Welche Funktionen erfüllen Qualitätsmodelle?​ +
-    * Qualitätsmodelle sind Modelle idealer Entwicklungsprozesse,​ an denen sich die Prozessqualität eines Unternehmens messen lässt. Sie dienen zum Einen der Bewertung des aktuellen Standes des Entwicklungsprozesses und zum Anderen zum Ermitteln von sinnvollen Verbesserungsmaßnahmen. +
-  * Nennen Sie vier Beispiele für Qualitätsmodelle! +
-    * CMM, CMMI, Spice, Bootstrap, ISO 9000 +
-  * Was sind Risiken beim Einsatz eines Qualitätsmodells?​ +
-    * Unternehmen sollten sich nicht auf ein Qualitätsmodell als Allheilmittel verlassen. Die Prozessverbesserung muss immer auch mit einer verbesserten Technologiekompetenz einhergehen. +
- +
-==== CMM ==== +
-  * Geben Sie die Reifegradstufen im CMM Modell an und charakterisieren Sie jede Stufe kurz! +
-    * initial: Keinerlei Struktur, Erfolg abhängig von Individualleistungen +
-    * repeatable: Entwicklungsprozess mit klaren Phasen und Meilensteinen,​ Phasen sind black boxes +
-    * defined: Unternehmensweit einheitlich definierter Entwicklungsprozess +
-    * managed: Entwicklungsprozess wird anhand von festgelegten Kriterien kontrolliert und gesteuert +
-    * optimized: Entwicklungsprozess unterliegt einer ständigen Optimierung +
-  * Welche Bedeutung hat eine "key process area"?​ +
-    * Key Process Areas stellen wichtige Bereiche des Entwicklungsprozesses dar, denen im Rahmen der Optimierung des Prozesses eine besondere Aufmerksamkeit zuteil werden sollte. +
-  * Wie sind key process areas organisiert?​ Welcher Bezug besteht zu den Reifegraden?​ +
-    * KPAs werden aufgeteilt in die Bereiche Management, Organisation und Engineering. Für jeden Reifegrad sind unterschiedliche KPAs definiert, die berücksichtigt werden müssen. +
-  * Wie kann ein (informelles) Assesssment aussehen? +
-    * Sämtliche Aktivitäten werden mit Punkten zwischen 0 und 10 bewertet. Über die einzelnen Bereiche des Prozesses werden dann Durchschnittswerte gebildet. Ein Durchschnitt von über 8 deutet auf ein mögliches positives Prüfergebnis einer formellen Evaluierung hin. +
-  * Wie wirken sich Verbesserungen durch eine CMM-Strategie aus? +
-    * Durch einen höheren CMM-Level steigt die Vorhersagbarkeit der Prozessergebnisse,​ der Grad der Kontrolle über den Prozess und die Effektivität des Prozesses. +
- +
-==== Manuelle Prüfmethoden ==== +
-  * Geben Sie den Ablauf einer Inspektion in Form eines Ablaufdiagramms an! +
-    * siehe S. 200   +
-  * Wie viele Personen sollten an einer Inspektion teilnehmen? Welche Rollen übernehmen sie in einer Inspektionssitzung?​ +
-    * Mindestens Autor, Inspektor und Moderator, maximal 7 Personen, um eine optimale Kommunikation zu gewährleisten ​  +
-  * Wie lange sollte eine Inspektionssitzung dauern? +
-    * Max. 2-2,5 Stunden. Optional ist die "3. Stunde" ​  +
-  * Geben Sie vier Beispiele für Inspektionsregeln an! +
-    * Es sind keine Zuhörer erlaubt (Vorgesetzte/​Gäste) +
-    * Sachliche Diskussion über das Prüfobjekt,​ nicht den Autor (keine Verteidigung etc.) +
-    * Ein Inspektor (nicht der Autor) liest das Prüfobejkt vor +
-    * In Problemen denken, nicht in Lösungen. Keine Verbesserungen suchen! ​    +
-  * Wie beurteilen Sie den Nutzen von Inspektionen zur Qualitätssicherung?​ Bitte Begründung angeben! +
-    * Durch den gezielten Einsatz von Inspektionen mit geschulten Teilnehmern kann die Qualität der Software deutlich gesteigert werden. Fehler werden früh entdeckt und Beseitigungskosten können eingespart werden. Außerdem sind sie die einzige Möglichkeit,​ um eine semantische Prüfung der Prüfobjekte durchzuführen. Wichtig ist die Kompetenz der Teilnehmer, um nicht zu einem falschen Sicherheitsempfinden zu kommen.+
  
start.txt · Zuletzt geändert: 2015-01-04 19:16 von stefan