Benutzer-Werkzeuge
se:softwarequalitaet
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
|
se:softwarequalitaet [2008-04-04 12:51] stefan |
se:softwarequalitaet [2014-04-05 11:42] (aktuell) |
||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| ====== Software-Qualität ====== | ====== Software-Qualität ====== | ||
| + | ===== Klausurvorbereitung ===== | ||
| + | ==== Mögliche Klausurthemen ==== | ||
| + | * Qualitätssysteme | ||
| + | * Zuverlässigkeitsmetriken | ||
| + | * Fehlertoleranzmaßnahmen | ||
| + | * Produktmetriken | ||
| + | * Wartungsmetriken | ||
| + | * COCOMO | ||
| + | * Halstead | ||
| + | * Volumen, Difficulty, Abstraktionsniveau (Herleitung) | ||
| + | * Function Points | ||
| + | * OO-Metriken | ||
| + | * Manuelle Prüfmethoden | ||
| + | * Inspection | ||
| + | * Anforderungsermittlung | ||
| + | * Anforderungen -> Volere | ||
| + | * Anforderungsanalyse | ||
| + | * Qualitätsmodelle | ||
| + | * Qualitätsmodelle | ||
| + | * CMM | ||
| + | * Prozessmetriken | ||
| + | * CMM Grundprinzip | ||
| - | ===== Mögliche Klausurthemen ===== | + | |
| - | * Inspection | + | ==== Wiederholung ==== |
| - | * Zuverlässigkeitsmetriken | + | |
| - | * Wartungsmetriken | + | === Qualitätssysteme === |
| - | * Fahlertoleranzmaßnahmen | + | * Wann bezeichnet man ein System als verlässlich oder zuverlässig? Was macht die Qualität eines Systems aus? |
| - | * Maßnahmen? | + | * Wie macht man ein System verlässlich bzw. zuverlässig? Wie stellt man die Qualität eines Systems sicher? |
| + | * Definition Qualität, Mangel/Defekt, Ausfall, Störung, Fehler | ||
| + | * Definition Anwendungsdauer, Lebensdauer, Brauchbarkeitsdauer, MTTFF, MTBF, MUT/MTTF, MDT, MTTR | ||
| + | * Aufteilung MDT | ||
| + | * Beispiele für ITU-Taxonomie | ||
| + | * Definition Überlebenswahrscheinlichkeit, kumulative Ausfallverteilung, Ausfalldichte, Ausfallrate, Verfügbarkeit | ||
| + | * Definition Wartbarkeit, Reparaturrate, Sicherheit, Vertraulichkeit, Performance | ||
| + | * Definition Verlässlichkeit, Verfügbarkeit, Zuverlässigkeit, Instandsetzbarkeit, Wartungsunterstützung | ||
| + | * ITU Kenngrößen Hierarchie mit Beispiel Bahn | ||
| + | * Klassifikation von Anforderungen | ||
| + | * Anforderungsermittlungsprozess | ||
| + | * Definition Fehlerverhütung, Fehlervermeidung, Fehlerbeseitigung, Fehlertoleranz | ||
| + | * Phasen der Fehlertoleranz (4) | ||
| + | * Methoden der Fehlertoleranz (8) | ||
| + | * Redundanzformen (8) und Beispiele (Prüfsumme, TMR) | ||
| + | |||
| + | |||
| + | === Produktmetriken === | ||
| * COCOMO | * COCOMO | ||
| - | * Halstead | + | * Entwicklungskomplexitäten |
| - | * Volumen, Difficulty, Abstraktionsniveau (Herleitung) | + | |
| - | * OO-Metriken | + | |
| - | * Qualitätsmodelle | + | |
| - | * Prozessmtriken | + | |
| - | * CMM Grundprinzip | + | |
| - | * Anforderungen -> Volere | + | |
| * Function Points | * Function Points | ||
| - | * Anforderungsanalyse | + | * Vorgehen (3 Schritte) |
| + | * Zählen der UFP (4 Schritte) | ||
| + | * Was ist ein Elementarprozess? | ||
| + | * Funktionskategorien Datenbestände/Transaktionen (5) | ||
| + | * Bindungsmetrik | ||
| + | * Was ist Kohäsion/Kopplung? | ||
| + | * Balzert: hohe Kohäsion/geringe Kopplung -> ausgeprägte Struktur/hohe Modularität -> geringe Komplexität, Einfachheit, Verständlichkeit | ||
| + | * Bindungsstärken (8) | ||
| + | * LOC | ||
| + | * Programmbereiche (2) | ||
| + | * Zeilentypen strukturell (4) | ||
| + | * Zeilentypen inhaltlich (5) | ||
| + | * Halstead | ||
| + | * Herleitung D, L, E, I | ||
| + | * übliche Werte für S | ||
| + | * McCabe | ||
| + | * Grenzwert für die zyklomatische Zahl | ||
| + | * Test-Metriken | ||
| + | * Formeln/Verständnis | ||
| + | * Wartungsmetriken | ||
| + | * Kostenverteilung Wartung | ||
| + | * Aufgaben in der Wartungsphase (3) | ||
| + | * Klassifizierung (3) | ||
| + | * Wertebereich E | ||
| + | * Stahlknecht Bedeutung | ||
| + | * Aufwandsmetriken | ||
| + | * Welche gibt es? | ||
| + | |||
| + | === Qualitätsmodelle === | ||
| + | * Grundidee der Qualitätsverbesserung | ||
| + | * Definition Qualitätsmodell | ||
| + | * Einordnung in das Qualitätsmodell | ||
| + | * Funktionen und Ziele | ||
| + | * Einsatz im Unternehmen (3 Gründe) | ||
| + | * Zusammenhang Prozessreife und Technologie | ||
| + | |||
| + | |||
| + | === CMM === | ||
| + | * Was ermittelt man mit CMM und wie geht man dabei vor? | ||
| + | * Definition Softwareprozess, Prozessbeherrschung, Prozessqualität, Prozessreife | ||
| + | * Wann liegt Prozessreife vor? (9) | ||
| + | * Stufen der Prozessreife (5) | ||
| + | * Verbesserungen durch höhere Stufen (3) | ||
| + | * Nutzung von CMM (4) | ||
| + | * Strategie von CMM (4) | ||
| + | * Aktivitäten-/Maßnahmenkategorien (5) | ||
| + | * Definition Schlüsselgebiet, Aufteilung Schlüsselgebiete (3) | ||
| + | * Schlüsselgebiete / Reifegrad | ||
| + | * repeatable (6) | ||
| + | * defined (7) | ||
| + | * managed (2) | ||
| + | * optimized (3) | ||
| + | * Definition Qualitätsziele (3) | ||
| + | * Definition Maßnahmenkategorien | ||
| + | * Durchführungsverpflichtung (2) | ||
| + | * Durchführbarkeit (3) | ||
| + | * Prozessbewertung (2) | ||
| + | * Verifikation (2) | ||
| + | * Durchzuführende Aktivitäten (5) | ||
| + | * Definition Handlungsanweisung (Beispiele) | ||
| + | * CMM Assessment | ||
| + | * formelles Assessment (6 Schritte) | ||
| + | * informelles Assessment (3 Bereiche, 6 Stufen) | ||
| + | |||
| + | === Anforderungsermittlung === | ||
| + | * Anforderungsermittlung (4 Schritte) | ||
| + | * Definition work scope, intended actors, adjacent systems, services, work area, outside world | ||
| + | * Definition Geschäftsvorfall (business), Geschäftsprozess (business workflow), task, stored data, Anwendungsfall | ||
| + | * Wie findet man Geschäftsvorfälle und Anwendungsfälle? | ||
| + | * Externe Systeme (3 Systeme, 3 Rollen) | ||
| + | * Optimales Produkt (6 Aspekte) | ||
| + | * Anforderungsermittlungsprozess | ||
| + | * Anforderungsdokumentation | ||
| + | |||
| + | === Manuelle Prüfmethoden === | ||
| + | * Taxonomie der Prüfmethoden | ||
| + | * Charakteristika (4) | ||
| + | * Ablauf einer Inspektion (11 Schritte) | ||
| + | * Eingangsprüfung (5 Kriterien) | ||
| + | * Planung (4 Schritte) | ||
| + | * Mögliche Rollen der Inspektoren (7) | ||
| + | * Einführungssitzung (4 Aufgaben) | ||
| + | * Vorbereitung | ||
| + | * Inspektionssitzung | ||
| + | * Teilnehmer | ||
| + | * Ablauf/Dauer | ||
| + | * Aufgaben (3) | ||
| + | * Prinzipien (4) | ||
| + | * Argumentationsprinzipien (4) | ||
| + | * Vorgehensweisen (4) | ||
| + | * Mögliche Ergebnisse (3) | ||
| + | * 3. Stunde | ||
| + | * Nachbereitung | ||
| + | * Ziele (3) | ||
| + | * Mögliche Metriken (8) | ||
| + | * Eigenschaften von Fehlern (5) | ||
| + | * Mängelbeseitigung | ||
| + | * Nachprüfung | ||
| + | * Wie viele Änderungen sind durchschnittlich fehlerhaft? | ||
| + | * Wann wird ein Prüfobjekt freigegeben? | ||
| + | * Wann wird eine Re-Inspektion durchgeführt? | ||
| + | * Teilnehmer (5) | ||
| + | * Autor (3 Aufgaben) | ||
| + | * Moderator (6 Aufgaben) | ||
| + | * Richtlinien und Regeln (5) | ||
| + | * Prüfkriterien (4) | ||
| + | * Basis-Checkliste (Beispiele für Prüfhinweise) | ||
| + | * Beispiele für Inspektionsrichtlinien (9) | ||
| + | * Prüfdokumente | ||
| + | * Erhebungsbogen (9 Angaben) | ||
| + | * Defekte (6 Angaben) | ||
| + | * Inspektionsprotokoll (4 Angaben) | ||
| + | * Defekte (6 Angaben) | ||
| + | * Metriken je Teilnehmer (3) | ||
| + | * Einsatz | ||
| + | * Wann sollten Inspektionen durchgeführt werden? | ||
| + | * Schwerpunkte (6) | ||
| + | * Vergleich der Verfahren | ||
| + | * Review (5 Punkte) | ||
| + | * Walkthrough (6 Punkte) | ||
| + | * Bewertung | ||
| + | * Vorteile (4) | ||
| + | * Lerneffekt (3 Punkte) | ||
| + | * Nachteile (1) | ||
| ===== Qualitätssysteme ===== | ===== Qualitätssysteme ===== | ||
| Zeile 26: | Zeile 182: | ||
| * **Wie** macht man ein System zuverlässig? Wie stellt man die Qualität eines Systems sicher? | * **Wie** macht man ein System zuverlässig? Wie stellt man die Qualität eines Systems sicher? | ||
| * **Konstruktive** Maßnahmen (Methoden, Techniken) | * **Konstruktive** Maßnahmen (Methoden, Techniken) | ||
| - | * **Organisatorische** Maßnahmen (Vorgehensweisen) | + | * **Organisatorische** Maßnahmen (Vorgehensweisen) |
| - | * **Analytische** Maßnahmen (Test, Review) | + | * **Analytische** Maßnahmen (Test, Review) |
| * Zusammenfassung: Konzeptionelles Vorgehen (Bild S.78) | * Zusammenfassung: Konzeptionelles Vorgehen (Bild S.78) | ||
| * Anforderungen <> Unzulänglichkeiten (Bewertungsmaßstäbe für Nichterfüllung, Maßnahmen zur Verbesserung) | * Anforderungen <> Unzulänglichkeiten (Bewertungsmaßstäbe für Nichterfüllung, Maßnahmen zur Verbesserung) | ||
| Zeile 37: | Zeile 193: | ||
| * **Defekt**: Jegliche Abweichung von den Anforderungen | * **Defekt**: Jegliche Abweichung von den Anforderungen | ||
| * nicht akzeptables Systemverhalten (tatsächliche Mängel des Systems) | * nicht akzeptables Systemverhalten (tatsächliche Mängel des Systems) | ||
| - | * Ausfall: Beendigung der Fähigkeit eine Leistung zu erbringen. | + | * **Ausfall**: Beendigung der Fähigkeit eine Leistung zu erbringen. |
| - | * Störung: Unfähigkeit des Systems eine Leistung zu erbringen (ohne Wartung etc.). Störungen können aufgrund von Ausfällen entstehen. | + | * **Störung**: Unfähigkeit des Systems eine Leistung zu erbringen (ohne Wartung etc.). Störungen können aufgrund von Ausfällen entstehen. |
| * latente Störung: Hat noch nicht zu einem Fehler geführt. | * latente Störung: Hat noch nicht zu einem Fehler geführt. | ||
| * Aktivierung: Latente Störung führt zu Fehler (etwa bei Benutzung des gestörten Systemteils). | * 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. | + | * **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 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). | * 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) | * nicht zufriedenstellendes Systemverhalten (Missverständnis des Benutzers) | ||
| + | * {{:se:defekteindersystementwicklung.jpg|}} | ||
| + | |||
| ==== Bewertungsmaßstäbe ==== | ==== Bewertungsmaßstäbe ==== | ||
| * Funktionsprofil: up/down (Reaktion: Reparatur ja/nein) | * Funktionsprofil: up/down (Reaktion: Reparatur ja/nein) | ||
| * degradiertes System: nur Teile des Systems funktionieren | * degradiertes System: nur Teile des Systems funktionieren | ||
| - | * Anwendungsdauer: Zeitspanne des Einsatzes eines Systems unter vorgegebenen Bedingungen. | + | * **Anwendungsdauer**: Zeitspanne des Einsatzes eines Systems unter vorgegebenen Bedingungen. |
| - | * Lebensdauer: Zeitraum von Betriebsbeginn bis -ausfall bei nicht-reparierbaren Systemen. | + | * **Lebensdauer T**: 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. | + | * **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. | + | * {{:se:zeitkenngroessen.jpg|}} |
| - | * MTBF (mean time between failure): Zeitraum zwischen zwei Ausfällen. | + | * **TTFF** (time to first failure): Zeitraum von Systemstart bis zum ersten Ausfall. Entspricht T für nicht-reparierbare Systeme. |
| - | * MDT (mean down time): Zeitraum, während dessen das System nicht zur Verfügung steht (Instandsetzung). | + | * **MTTFF** (mean time to first failure): mittlerer Zeitraum von Systemstart bis zum ersten Ausfall. Entspricht <latex>\overline{T}</latex> für nicht-reparierbare Systeme. Einheit: h. Nach MTTFF sind nur noch 36,8% aller Systeme intakt. |
| - | * MTTR (mean time to restoration): Zeitraum, während dessen das System instandgesetzt wird. | + | * **MTBF** (mean time between failure): mittlerer Zeitraum zwischen zwei Ausfällen. |
| + | * **MDT** (mean down time): mittlerer Zeitraum, während dessen das System nicht zur Verfügung steht (Instandsetzung). | ||
| + | * **MTTR** (mean time to restoration): mittlerer Zeitraum, während dessen das System instandgesetzt wird. | ||
| + | * {{:se:korrektivewartung.jpg|}} | ||
| * datection time: Benötigte Zeit um den Fehler zu entdecken. | * datection time: Benötigte Zeit um den Fehler zu entdecken. | ||
| * diagnosis time: Benötigte Zeit um die Ursache des Fehlers zu entdecken. | * diagnosis time: Benötigte Zeit um die Ursache des Fehlers zu entdecken. | ||
| Zeile 62: | Zeile 223: | ||
| * time for reintegration: Zeit für das Integrieren des reparierten/ersetzten Teils. | * time for reintegration: Zeit für das Integrieren des reparierten/ersetzten Teils. | ||
| * präventive Wartungsaktivitäten | * präventive Wartungsaktivitäten | ||
| - | * MUT (mean up time) / MTTF (mean time to failure): Zeitraum, während dessen das System zur Verfügung steht. | + | * {{:se:praeventivewartung.jpg|}} |
| + | * **MUT** (mean up time) / **MTTF** (mean time to failure): mittlerer Zeitraum, während dessen das System zur Verfügung steht. | ||
| * weitere Begriffe der ITU | * weitere Begriffe der ITU | ||
| + | * {{:se:itutaxonomie.jpg|}} | ||
| * required time: Zeit, während der das System zur Verfügung stehen muss. | * 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. | * non-required time: Zeit, während der das System nicht zur Verfügung stehen muss. | ||
| Zeile 85: | Zeile 248: | ||
| * fault correction time: Zeit für die Störungsbeseitigung. | * fault correction time: Zeit für die Störungsbeseitigung. | ||
| * check out time: Zeit zum Nachweis der Funktionsfähigkeit. | * 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) | + | * **Überlebenswahrscheinlichkeit** (reliability, reliability performance) **R(t)**: System ist funktionstüchtig (unter spezifizierten Betriebsbedingungen) in [0;t] (exponentiell monoton fallend) <latex>R(t) = e^{−\lambda \cdot t}</latex> |
| - | * Kumulative Ausfall- / Fehlerwahrscheinlichkeit (cumulative failure distribution) **F(t)**: System fällt in [0;t] aus: F(t) = 1 - R(t) | + | * **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) | + | * **Ausfall-/Fehlerdichte** (probability density function, PDF) **f(t)**: Zeitableitung von F(t), Einheit 1/h |
| - | * Ausfallrate **delta(t)**: umgekehrt proportional zur MTTFF | + | * **Ausfallrate** <latex>\lambda(t)</latex>: Ausfall im Intervall ]t, t + dt] wenn System vor t intakt, umgekehrt proportional zur MTTFF, Einheit 1/h oder Fit (<latex>10^{-9}\frac{1}{h}</latex>) |
| - | * Badewannenkurve: Frühausfälle, useful operating life, Spätausfälle | + | * 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. | + | * **Verfügbarkeit** (availability) **A(t)**: Wahrscheinlichtkeit, dass das System zum Zeitpunkt t funktionstüchtig ist. |
| * steady state availability: MUT / (MUT + MDT) | * steady state availability: MUT / (MUT + MDT) | ||
| - | * Wartbarkeit (maintainability) **M(t)**: Wahrscheinlichkeit, dass das System innerhalb der Zeitspanne t wieder instandgesetzt werden kann. | + | * **Wartbarkeit** (maintainability) **M(t)**: Wahrscheinlichkeit, dass das System innerhalb der Zeitspanne t wieder instandgesetzt werden kann. |
| - | * Reparaturrate (repair rate): entspricht Ausfallrate | + | * analog zur Ausfallverteilung |
| - | * Sicherheit (safety): Das System hat keine kritischen Ausfälle (kritische Funktionen). Zusammenhang zur Überlebenswahrscheinlichkeit (Leistung des Systems betreffende Funktionen) | + | * **Reparaturrate** (repair rate): erfolgreiche Reparatur im Intervall ]t, t + dt] wenn Reparatur vor t noch nicht abgeschlossen |
| - | * Vertraulichkeit (security): Das System verhindert unerlaubten Zugriff (vertrauensrelevante Funktionen). | + | * analog zur Ausfallrate |
| - | * Performance: Beispiele sind Durchsatz oder Antwortzeit -> Benchmarks | + | * **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**: Leistungsfähigkeit des Systems, Beispiele sind Durchsatz oder Antwortzeit -> Benchmarks | ||
| * Qualitative Kenngrößen | * Qualitative Kenngrößen | ||
| - | * Verlässlichkeit (dependability): Vertrauenswürdigkeit in die Leistung des Systems. | + | * **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. | + | * **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. | + | * **Zuverlässigkeit** (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. | + | * **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. | + | * **Wartungsunterstützung** (maintenance support performance): Fähigkeit der Wartungsorganisation, die benötigten Ressourcen für die Instandsetzung bereitzustellen. |
| - | * Quality of Service | + | * {{:se:itukenngroessen.jpg|}} |
| - | * 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 ==== | ==== Qualitätsanforderungen ==== | ||
| === Arten von Anforderungen === | === Arten von Anforderungen === | ||
| + | * {{:se:klassifikationvonanforderungen.jpg|}} | ||
| * Basisanforderung / primitive Anforderung: elementare Aussage, Satz mit Verb und Objekt (<> komplexer Text) | * Basisanforderung / primitive Anforderung: elementare Aussage, Satz mit Verb und Objekt (<> komplexer Text) | ||
| * funktional: beschreiben den Funktionsumfang des Systems (Aufgaben, Dienstleistungen) | * funktional: beschreiben den Funktionsumfang des Systems (Aufgaben, Dienstleistungen) | ||
| Zeile 130: | Zeile 282: | ||
| * implementation | * implementation | ||
| * test | * test | ||
| - | * Leistungsanforderungen: werden Basisanforderungen zugewiesen | + | * Leistungsanforderungen: werden Basisanforderungen zugewiesen und legen die erwartete Qualität der Basisanforderungen fest |
| === Anforderungsdefinitionsprozess === | === Anforderungsdefinitionsprozess === | ||
| - | * Grafik S. 64 | + | * {{:se:prozessderanforderungsdefinition.jpg|}} |
| - | * Aufnahme der Bedürfnisse/Vorstellungen der Stakeholder | + | * Aufnahme der Bedürfnisse/Vorstellungen der Stakeholder (WICHTIG: verdeckte Anforderungen ermitteln) -> Background |
| - | * WICHTIG: verdeckte Anforderungen ermitteln | + | |
| * (iteratives) Extrahieren von Basisanforderungen aus den vorhandenen Anforderungsbeschreibungen | * (iteratives) Extrahieren von Basisanforderungen aus den vorhandenen Anforderungsbeschreibungen | ||
| * ursprüngliche Texte aufbewahren! | * ursprüngliche Texte aufbewahren! | ||
| * funktionale Anforderungen -> Systemanalyse | * funktionale Anforderungen -> Systemanalyse | ||
| * nicht-funktionale Anforderungen -> Systemarchitektur | * nicht-funktionale Anforderungen -> Systemarchitektur | ||
| + | |||
| ==== Maßnahmen ==== | ==== Maßnahmen ==== | ||
| - | * Fehlerverhütung | + | * **Fehlerverhütung**: Eliminierung aller den ordnungsgemäßen Betrieb des Systems verhindernden Fehler vor Inbetriebnahme |
| - | * Fehlervermeidung | + | * **Fehlervermeidung**: Einsatz von konstruktiven Maßnahmen |
| - | * Fehlerbeseitigung | + | * **Fehlerbeseitigung**: Untersuchen des Systems auf Fehler und Beseitigung dieser vor Inbetriebnahme |
| - | * Fehlertoleranz | + | * **Fehlertoleranz**: Das System erhält auch im Fehlerfall seine Funktion aufrecht |
| - | * Wartung | + | * **Wartung**: Alle Aktionen, die auf die Aufrechterhaltung bzw. Wiederherstellung der Systemfunktionalität ausgerichtet sind |
| === Fehlertoleranz === | === Fehlertoleranz === | ||
| + | * {{:se:redundanzformen.jpg|}} | ||
| * Phasen | * Phasen | ||
| - | * error detection | + | * error detection: Finden des Fehlers |
| - | * damage confinement | + | * damage confinement: Schadensbegrenzung |
| - | * error recovery | + | * error recovery: System in fehlerfreien Zustand versetzen |
| - | * fault treatment / continued service | + | * fault treatment / continued service: Fehlerursache (Störung) beheben |
| * Methoden | * Methoden | ||
| - | * error processing | + | * error processing: Überführung der Störung in einen latenten Zustand -> fehlerfreies System |
| - | * error compensation | + | * error compensation: Auswirkungen eines fehlerhaften Zustandsübergangs ausgleichen |
| - | * error correction | + | * error correction: Korrektur des Fehlers (Prüfsummen) |
| - | * fault masking | + | * fault masking: Unterdrückung des Fehlers (TMR) |
| - | * error recovery | + | * error recovery: fehlerfreien Systemzustand wiederherstellen |
| * backward error recovery | * backward error recovery | ||
| * forward error recovery | * forward error recovery | ||
| - | * reconfiguration | + | * reconfiguration: Behebung der Störung |
| * gestörte Komponente deaktivieren | * gestörte Komponente deaktivieren | ||
| * gestörte Komponente ausgliedern | * gestörte Komponente ausgliedern | ||
| * Ersatzkomponente eingliedern | * Ersatzkomponente eingliedern | ||
| - | * Redundanz | + | * **Redundanz**: Vorhandensein von mehr funktionsfähigen Mitteln in einer Einheit, als für die Erfüllung der geforderten Funktion notwendig ist. |
| * Systemaspekt | * Systemaspekt | ||
| - | * strukturell | + | * strukturell: Erweiterung der Architektur |
| - | * funktional | + | * funktional: Erweiterung der Systemfunktionalität |
| - | * Informationsredundanz | + | * Informationsredundanz: Erweiterung der abgelegten Nutzinformationen um weitere Informationen |
| - | * Zeitredundanz | + | * Zeitredundanz: zusätzlicher Zeitaufwand zur Ausführung von Funktionen |
| * Aktivierung | * Aktivierung | ||
| - | * statisch | + | * statisch: aktiv während gesamter Laufzeit |
| - | * dynamisch | + | * dynamisch: aktiv im Bedarfsfall |
| * Fehlerart | * Fehlerart | ||
| * homogene Redundanz / Replikation -> Alterungsfehler | * homogene Redundanz / Replikation -> Alterungsfehler | ||
| Zeile 197: | Zeile 349: | ||
| * strukturelle Redundanz (Ersatzkomponenten) | * strukturelle Redundanz (Ersatzkomponenten) | ||
| * funktionale Redundanz (Austauschprozess) | * funktionale Redundanz (Austauschprozess) | ||
| + | |||
| ===== Produktmetriken ===== | ===== Produktmetriken ===== | ||
| Zeile 254: | Zeile 407: | ||
| * Aufwandsmetriken | * Aufwandsmetriken | ||
| * Produktgröße, -komplexität, Entwicklungsumgebung | * Produktgröße, -komplexität, Entwicklungsumgebung | ||
| + | {{:se:metrikenimentwicklungsprozess.jpg|}} | ||
| + | |||
| + | ===== Qualitätsmodelle ===== | ||
| + | * Softwarequalität hängt von der Qualität des Entwicklungsprozesses ab. | ||
| + | * **Zuerst die Qualität messen und dann gezielt Verbesserungen vornehmen.** | ||
| + | * Kriterien -> Assessment -> Ergebnis -> Maßnahmen zur Verbesserung | ||
| + | * **Qualitätsmodell**: Modell einer idealen Entwicklungsprozessstruktur. Prozessmetrik und Maßnahme zur Qualitätsverbesserung. | ||
| + | * Funktionen/Ziele von Qualitätsmodellen | ||
| + | * Messlatte zur Ermittlung der Prozessqualität | ||
| + | * Hilfestellung bei der Festlegung von Verbesserungsmaßnahmen | ||
| + | * Beispiele: CMM, CMMI, Spice, Bootstrap, ISO 9000 | ||
| + | * Unternehmensübergreifende Vergleiche werden möglich | ||
| + | * Technologiekompetenz und Prozessbeherrschung müssen stets gemeinsam verbessert werden. | ||
| + | * {{:se:qualitaetsmodelle1.jpg|}} | ||
| + | * {{:se:qualitaetsmodelle2.jpg|}} | ||
| + | * {{:se:prozessreifeundtechnologie.jpg|}} | ||
| + | |||
| + | ===== Capability Maturity Model ===== | ||
| + | * Ermittelt den **Grad der Prozessbeherrschung**, nicht jedoch die Qualität des Produktes. | ||
| + | * Ausgangspunkt ist ein Assessment anhand eines Fragebogens -> Prozessmetrik. | ||
| + | * Bietet einen Maßnahmenkatalog zur Prozessverbesserung. | ||
| + | * Anleitung | ||
| + | * SW-Entwicklungs- und 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, unter der Voraussetzung, dass eine definierte Vorgehensweise verfolgt wird. | ||
| + | * 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 (definiert, gesteuert, kontrolliert, effektiv) -> definierte Stufen. | ||
| + | * Reife liegt vor, wenn folgende Punkte zutreffen: | ||
| + | * firmenweite Methodik zur Organisation von SW-Entwicklung | ||
| + | * Rollen und Verantwortlichkeiten sind klar definiert | ||
| + | * die Beteiligten befolgen die disziplinierte Vorgehensweise aus innerer Überzeugung | ||
| + | * Arbeiten werden gemäß der Planung durchgeführt | ||
| + | * Prozess ist exakt erläuterbar | ||
| + | * Manager überwachen die Qualität des Prozesses | ||
| + | * es liegen objektive und quantifizierbare Kriterien zur Prozessanalyse vor | ||
| + | * Zeitplan- und Budget-Vorgaben sind realistisch und basieren auf Erfahrung | ||
| + | * es gibt festgelegte Verfahren zur Problemanalyse | ||
| + | * 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 | ||
| + | * {{:se:cmmreifegradstufen1.jpg|}} | ||
| + | * {{:se:cmmreifegradstufen2.jpg|}} | ||
| + | * **Verbesserungen** durch höhere Stufen | ||
| + | * Vorhersagbarkeit | ||
| + | * Kontrolle | ||
| + | * Effektivität | ||
| + | * {{:se:cmmreifegradstufen3.jpg|}} | ||
| + | * **Nutzung von CMM** | ||
| + | * Stärken/Schwächen des Unternehmens identifizieren | ||
| + | * Auswahl von Unterauftragnehmern | ||
| + | * Maßnahmen zur Prozessverbesserung erkennen | ||
| + | * Definition und Optimierung des eigenen Prozesses | ||
| + | * **Strategie** zum 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) | ||
| + | * {{:se:cmmstrategie.jpg|}} | ||
| + | * Schlüsselgebiete (Management, Organisation, Engineering) | ||
| + | * **Schlüsselgebiet**: Für die Verbesserung des Entwicklungsprozesses besonders wirksame Prozessbereiche. | ||
| + | * repeatable (Installation elementarer Projektkontrollinstrumente) | ||
| + | * Anforderungsmanagement | ||
| + | * SW-Projektplanung | ||
| + | * SW-Projektverfolgung | ||
| + | * Subcontractormanagement | ||
| + | * SW-Qualitätssicherung | ||
| + | * SW-Konfigurationsmanagement | ||
| + | * defined (Einführen einer Infrastruktur, die firmenweit über alle Projekte effektives SW-Engineering und Prozessmanagement erlaubt) | ||
| + | * firmenweite Prozessüberwachung | ||
| + | * firmenweite Prozessdefinition | ||
| + | * Ausbildungsprogramm | ||
| + | * ganzheitliche Prozessdefinition | ||
| + | * SW-Produktengineering | ||
| + | * Koordination zwischen Entwicklungsteams | ||
| + | * Reviews | ||
| + | * managed (Erzeugen eines quantitativ ausdrückbaren Verständnisses für den SW-Entwicklungsprozess und die SW-Produkte) | ||
| + | * Quantitatives Prozessmanagement | ||
| + | * SW-Qualitätsmanagement | ||
| + | * optimized (Es wird sowohl für das Firmenmanagement als auch für den Entwicklungsprozess das Ziel verfolgt, eine Einhaltung von kontinuierlicher und messbarer Prozessverbesserung zu erreichen) | ||
| + | * Defektverhinderung | ||
| + | * Technologieveränderungsmanagement | ||
| + | * Prozessveränderungsmanagement | ||
| + | * {{:se:cmmschluesselbereiche.jpg|}} | ||
| + | * **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**: Beschreiben das grundsätzliche Vorgehen bei der Institutionalisierung/Implementierung von Maßnahmen | ||
| + | * Infrastrukturmaßnahmen (Institutionelle Basis) | ||
| + | * Durchführungsverpflichtung | ||
| + | * Unternehmensphilosophie | ||
| + | * Managementunterstützung | ||
| + | * Durchführbarkeit | ||
| + | * Ressourcen | ||
| + | * Organisationsstrukturen | ||
| + | * Schulungen | ||
| + | * Prozessbewertung | ||
| + | * Stichproben | ||
| + | * Ermittlung der Ergebnisse/Wirksamkeit der Maßnahmen | ||
| + | * Verifikation | ||
| + | * Reviews | ||
| + | * Audits | ||
| + | * Aktivitäten (müssen implementiert werden) | ||
| + | * Durchzuführende Aktivitäten | ||
| + | * Planung | ||
| + | * Verfahren | ||
| + | * Durchführung der Arbeit | ||
| + | * Überwachung | ||
| + | * korrektive Maßnahmen | ||
| + | * 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 beschreibt 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 Fragebogens | ||
| + | * 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) | ||
| + | * {{:se:taxonomiepruefmethoden.jpg|}} | ||
| + | |||
| + | ==== 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 | ||
| + | * {{:se:ablaufinspektion.jpg|}} | ||
| + | * 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 | ||
| + | * Vorbereitungszeit / Inspektor | ||
| + | * Vorbereitungszeit / Seite | ||
| + | * Dauer der Inspektionssitzung(en) | ||
| + | * Gesamtzahl der inspizierten Seiten | ||
| + | * Seiten / Inspektionssitzung | ||
| + | * Dauer der Überprüfung einer Seite | ||
| + | * Anzahl der Fehler / Gesamtzeit der Inspektion | ||
| + | * gefundene Fehler / Seite | ||
| + | * 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 | ||
| + | * Adressat (Autor, Moderator) | ||
| + | * Absender (Gutachter) | ||
| + | * Prüfobjekt | ||
| + | * Abgabetermin | ||
| + | * Zeitaufwand | ||
| + | * Gesamteindruck | ||
| + | * Inspektionssitzung/Reviewsitzung notwendig / nicht notwendig / nicht sinnvoll | ||
| + | * Bemerkungen des Autors | ||
| + | * Unterschrift Prüfer und Autor | ||
| + | * Defekte | ||
| + | * laufende Nummer | ||
| + | * Zeile / Seite / Kapitel | ||
| + | * Problembeschreibung | ||
| + | * Problemart (inhaltliches Problem / formales Problem) | ||
| + | * Problemtyp schweres / mittleres / leichtes Problem | ||
| + | * Bemerkung für den Autor oder den Moderator | ||
| + | * Inspektionsprotokoll | ||
| + | * Inspektionsdatum | ||
| + | * Name des Moderators | ||
| + | * Prüfobjekt | ||
| + | * Referenzunterlagen | ||
| + | * Defekte | ||
| + | * Kurzbeschreibung des Defekts | ||
| + | * Ort des Defekts | ||
| + | * Bezug zu Regeln oder Checklisten | ||
| + | * Klassifikation | ||
| + | * Begründungen (für Defekte, die sich auf Regeln, Checklisten, Prozesse beziehen) | ||
| + | * Fragen an den Autor | ||
| + | * Metriken | ||
| + | * Vorbereitungszeit | ||
| + | * Dauer der Sitzung | ||
| + | * Nachbereitungsaufwand | ||
| + | * 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 | ||
| + | * {{:se:vergleichpruefmethoden.jpg|}} | ||
| + | * Bewertung | ||
| + | * **Vorteile**: Semantikprüfung, ganzes Team trägt Entscheidung, Mängel werden früh und effektiv gefunden, Lerneffekt bei Entwicklern | ||
| + | * 44% der Kosten eines Projekts entfallen auf Fehlerbeseitigung | ||
| + | * 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 | ||
| + | |||
| + | ===== Anforderungsermittlung ===== | ||
| + | * {{:se:anforderungsermittlungsprozess.jpg|}} | ||
| + | * Schritte | ||
| + | * Ermittlung des Umfangs der zu erbringenden Leistung bzw. Ermittlung der Aufgabenstellung. | ||
| + | * Partnersysteme und ihre Rollen ermitteln -> Kontextdiagramm | ||
| + | * Identifikation der Geschäftsvorfälle in Zusammenhang mit dem Leistungsangebot / der Aufgabenstellung. | ||
| + | * Geschäftsvorfall: Ein Geschäftsobjekt, das durch die in einem Geschäftsprozess beschriebenen Aktivitäten bearbeitet wird. Geschäftsvorfälle werden durch Ereignisse (Anfragen an das System) ausgelöst. Ergebnis: eine für den Anwender erkennbare Aktion. | ||
| + | * Geschäftsprozess: Fachlich zusammenhängende, organisatorisch jedoch evtl. verteilte, zeitlich und logisch zusammenhängende Aktivitäten, die notwendig sind, um einen Geschäftsvorfall ergebnisorientiert zu bearbeiten. | ||
| + | * Geschäftsvorfälle finden: Datenströme zum/vom System analysieren | ||
| + | * Externe Systeme: Organisationen, Personen, technische Systeme / aktiv, autonom, kooperativ | ||
| + | * Muss das System alle Aufgaben übernehmen, oder können vielleicht auch Personen Leistungen erbringen? | ||
| + | * Aspekte zur Ermittlung des "optimalen" Produkts | ||
| + | * Zweck des Produkts | ||
| + | * Umfang der Dienstleistung | ||
| + | * Existenz externer technischer Systeme | ||
| + | * Einflüsse externer Institutionen, Organisationen und Personen | ||
| + | * Auswirkungen der Produktdefinition auf Betroffene | ||
| + | * eigene Marktposition | ||
| + | * Festlegung der Rolle des künftigen Produktes bei der Erbringung der Leistung. | ||
| + | * Anwendungsfall: Beschreibung einer zu erbringenden Leistung. Er beschreibt eine Menge von Aktivitäten eines Systems, die für seine Akteure zu einem wahrnehmbaren Ergebnis führen. Wird durch einen Akteur initiiert, ist unteilbar | ||
| + | * Ermittlung von Anwendungsfällen: Geschäftsvorfälle -> Leistungen des Systems sind Anwendungsfälle | ||
| + | * Arbeitsumfang != Produktumfang | ||
| + | * Ableitung von Anforderungen zu jedem Anwendungsfall. | ||
| + | * Anforderungsdokumentation | ||
| + | * Zusatzinformationen zu den Anforderungen: Randbedingungen, Stakeholder, Leistungsumfang des Produkts -> Volere | ||
| + | |||
| + | |||
| ===== ToDo ===== | ===== ToDo ===== | ||
| - | * Volere Template lesen | + | * <del>Volere Template lesen</del> |
| - | * IEEE Testdokument lesen | + | * <del>IEEE Testdokument lesen</del> |
| - | * Beispielaufgabe Function Points | + | * <del>Beispielaufgabe Function Points</del> |
| - | * Formelsammlung ausdrucken und durchgehen | + | * <del>Formelsammlung ausdrucken und durchgehen</del> |
| - | * Grafik S. 156 | + | * <del>Grafik S. 156 anschauen</del> |
| - | + | * CMM | |
| + | * Beispiel ab S. 183 | ||
| + | * Tabelle S. 190 | ||
| + | * <del>unklare QM-Maßnahmen anschauen (S. 196)</del> | ||
| + | * <del>Checklisten S. 213</del> | ||
| + | * <del>Erhebungsbogen S. 215</del> | ||
| + | * <del>Prüfschwerpunkte S. 219</del> | ||
| + | * <del>Diagramm S. 253</del> | ||
| + | * <del>LOC/FP für Java, C++, C#</del> http://www.cs.helsinki.fi/u/taina/ohtu/fp.html | ||
| ===== Links ===== | ===== Links ===== | ||
| * Kapitel 1 | * Kapitel 1 | ||
| Zeile 288: | Zeile 822: | ||
| * Kenntnis über vorgestellte im Softwareentwicklungsprozess einsetzbare Metriken. Wissen um den Beispielcharakter der vorgestellten Produktmetriken. | * Kenntnis über vorgestellte im Softwareentwicklungsprozess einsetzbare Metriken. Wissen um den Beispielcharakter der vorgestellten Produktmetriken. | ||
| * Anwenden der Metriken. | * 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. | ||
| + | * Kenntnis über den Anforderungsermittlungsprozess. | ||
| + | * Kenntnis des Volere-Konzepts zur Anforderungsermittlung | ||
| + | * Fähigkeit das Volere-Template zur Anforderungsermittlung und -dokumentation einzusetzen. | ||
| + | | ||
| ===== Aufgaben ===== | ===== Aufgaben ===== | ||
| - | ==== Kapitel 1 ==== | + | ==== Qualitätssysteme ==== |
| * Grenzen Sie die Begriffe "Fehler", "Ausfall" und "Störung gegeneinander ab! | * 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). | * Ein Ausfall bezeichnet die Beendigung eines Elements, eine angeforderte Leistung zu erbringen (z.B. Hardware geht kaputt). | ||
| Zeile 343: | Zeile 888: | ||
| * Designfehlern lässt sich nur durch redundante Entwicklung von Systemkomponenten entgegenwirken (z.B. N-Version Programming) | * Designfehlern lässt sich nur durch redundante Entwicklung von Systemkomponenten entgegenwirken (z.B. N-Version Programming) | ||
| - | ==== Kapitel 2 ==== | + | ==== Produktmetriken ==== |
| * Wozu können Lesbarkeitsmetriken oder Verständlichkeitsmetriken eingesetzt werden? | * 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. | * 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. | ||
| Zeile 373: | Zeile 918: | ||
| * b) Vokabular des Programms (Gesamtzahl aller möglichen 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? | * 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. | + | * 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. | ||
| + | |||
| + | ==== Anforderungsermittlung ==== | ||
| + | * Geben Sie die vier Stufen der Anforderungsermittlung an! | ||
| + | * Ermittlung des Umfangs der zu erbringenden Leistung (Systemgrenzen ermitteln). | ||
| + | * Ermittlung von Geschäftsvorfällen im Rahmen der zu erbringenden Leistung (Datenströme ins/vom System). | ||
| + | * Festlegen der Rolle des Produkts / Abgrenzung zum System (Anwendungsfälle des Produkts). | ||
| + | * Ermitteln von Anforderungen für jeden Anwendungsfall. | ||
| + | * Was ist ein Geschäftsprozess? | ||
| + | * Ein Geschäftsprozess ist eine Menge an logisch und zeitlich zusammenhängenden, evtl. organisatorisch getrennten Aktivitäten, die durchgeführt werden, um einen fachlichen Geschäftsvorfall zu bearbeiten. | ||
| + | * Was ist ein Geschäftsvorfall? | ||
| + | * Ein Geschäftsvorfall ist ein Geschäftsobjekt, das durch die in einem Geschäftsprozess beschriebenen Aktivitäten bearbeitet wird. Ein Geschäftsvorfall wird durch ein Ereignis ausgelöst. | ||
| + | * Welche Typen von externen Systemen gibt es? | ||
| + | * Organisationen, Personen, technische Systeme | ||
| + | * aktive, autonome, kooperative | ||
| + | * Geben Sie für jeden Typ eines externen Systems ein Beispiel an! | ||
| + | * Organisation: Staat, Geschäftspartner | ||
| + | * Person: Bankkunde, Bediener | ||
| + | * technisches System: Kreditkartenvalidierer, Online-Banking | ||
| + | * aktiv: Person, Kunde | ||
| + | * autonom: Börsenkurssystem | ||
| + | * kooperativ: Schufa | ||
| + | * Was ist der Unterschied zwischen System und Produkt? | ||
| + | * System und Produkt können sich entsprechen, sie müssen es aber nicht. Das System kann außer dem Produkt noch andere Systeme oder Personen enthalten, die Aufgaben übernehmen, die das Produkt somit nicht anbieten muss. | ||
| + | * Wie können Anforderungen experimentell ermittelt werden? | ||
| + | * Durch das Erstellen eines Prototyps des Produkts kann zusammen mit den Benutzern experimentell erarbeitet werden, ob vorhandene Anforderungen stimmen oder sogar noch neue hinzukommen, die vorher nicht bedacht wurden. Bei der aktiven Arbeit am Prototypen fällt den Benutzern schnell auf, was noch nicht so umgesetzt ist, wie gewünscht. | ||
| + | * Welche Quellen nutzt man zur Wissensakquisition im Anforderungsermittlungsprozess? | ||
| + | * Liste der identifizierten Geschäftsvorfälle, die das System abdecken soll | ||
| + | * Kontext des Systems / Systemgrenzen | ||
| + | * Was ist ein Anwendungsfall? | ||
| + | * Ein Anwendungsfall ist die Beschreibung einer durch das Produkt zu erbringenden Leistung aus Sicht des Akteurs. Ein Anwendungsfall wird durch einen Akteur initiiert und führt zu einem für diesen wahrnehmbaren Ergebnis | ||
| + | * Wie hängen Anforderungen und Anwendungsfälle zusammen? | ||
| + | * Anforderungen werden aus Anwendungsfällen abgeleitet. | ||
se/softwarequalitaet.1207306292.txt.gz · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)
Seiten-Werkzeuge
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: CC Attribution-Noncommercial-Share Alike 4.0 International
