Fehler-Möglichkeiten- und -Einfluss-Analyse (FMEA) - Methoden und Vorgehen

Fehler-Möglichkeiten- und -Einfluss-Analyse (FMEA)

• Fragestellung: induktiv („Was geschieht, wenn…?“)
• Vorgehen: Untersuchung jeweils einer Komponente zu einem Zeitpunkt, Verfolgung der Auswirkungen rekursiv auf der jeweils nächsthöheren Ebene
• Darstellung: als Tabelle
• Berechnung der Risikoprioritätszahl (RPZ): RPZ = A * B * E, wobei A = Auftrittswahrscheinlichkeit [1-10], B = Bedeutung („Schadensausmaß“) [1-10] und E = Entdeckungswahrscheinlichkeit [1-10]

Stärken-Schwächen-Chancen-Risiken-Analyse (SWOT)

• Ziel: Erarbeitung des Schlüsselprofils eines Unternehmens zur Strategieentwicklung (auch im Bereich Risiko)
• Zweck: Chancen- und Risikenanalyse, um sich der eigenen Stärken und Schwächen bewusst zu werden
• Entstehung: entwickelt in den 1960er Jahren an der Harvard Business School
• Positionierung: im strategischen Management
• Darstellung: als Matrix „externe Analyse“ vs.„interne Analyse“

Vorgehen beim Design unter Verwendung der UML

• Entwickeln des Komponentenmodells:
  • 1. Komponentenschnittstellen festlegen (Komponentendiagramm)
  • 2. wiederverwendete Komponenten festlegen (Komponentendiagramm)
  • 3. Strukturmodell verfeinern (Klassen-/Objektdiagramm)
  • 4. Attribute/Operationen ergänzen (Klassen-/Objektdiagramm)
  • 5. Gemeinsamkeiten ableiten (Klassen-/Objektdiagramm)
  • 6. Abhängigkeiten realisieren (Klassen-, Kollaborationsdiagramm)
  • 7. Kontrollfluss festlegen (Kollaborationsdiagramm)
  • 8. Steuer-/Zustandsvariablen eintragen (Klassendiagramm)
  • 9. Operationen spezifizieren (Zustands-/Aktivitätsdiagramm)
• Wichtig: Festlegen von Designkompromissen und Designprioritäten nötig!

(Benutzerschnittstellen-)Prototyping

• Beschreibungssprachen für Benutzerschnittstellen:
  • Textuelle Beschreibung des statischen Teils einer Benutzeroberfläche
• Werkzeuge des Compilerbaus:
  • Vielfach ist Programmablauf durch Strom der Eingabedaten gesteuert
  • Compilerbauwerkzeuge erstellen Parser etc.

Benutzerdokumentation

• Erste Version bereits während des Designs erstellt, um die Designergebnisse bei der Implementierung leicht zugänglich zu halten
• Bereits Reviews mit dem Auftraggeber möglich
• Checkliste für die Benutzerdokumentation:
  • Vollständigkeit
  • Verständlichkeit
  • Strukturiertheit
  • Modularität
  • Benutzbarkeit
  • Aktualität
• Unstimmigkeiten zwischen System und Dokumentation werden vom Auftraggeber am raschesten erkannt und sind kaum zu dementieren.

Einfügen logischer Bedingungen

• Assertionen sind logische Aussagen, die Bedingungen im Programm entsprechen:
  • Vorbedingungen
  • Nachbedingungen
  • Invarianten

Instrumentieren des Codes

• Versehen des Codes mit zusätzlichen Codeteilen zum:
  • Feststellen der Codelokalität zur Laufzeit
  • Prüfen der Pfadabdeckung
  • Dynamischen Analysieren (Profiling)
  • Prüfen der Testqualität (Bebuggen, Mutieren)
• Hauptprobleme:
  • Neue Codeteile können zusätzliche Fehler enthalten
  • Neue Codeteile verändern manchmal das Programmverhalten

Kontinuierliche Integration

• Engl.„continuous integration“ (CI): Jeder Entwickler pflegt kleine Codeänderungen laufend ein
• Voraussetzungen:
  • Eine gemeinsame Codebasis
  • Übersetzen und Binden auf Knopfdruck
  • Funktionale Tests hoch automatisiert
  • Neueste Programmversion laufend zugänglich

Erstellen von Testrahmen

• Zweck: Erstellen temporärer Programm(teile) und Daten zu Testzwecken
• Komponenten von Testrahmen:
  • Stumpf („stub“): Testcode für gerufene Routine
  • Treiber („driver “): Testcode für rufende Routine
  • Attrappe („mock-up“, „mock object“): Testcode für Komponenten
  • Dummydatei („dummy file“): Datei mit Testdaten

Testgesteuerte Entwicklung

• Idee (engl.Test-driven Development – TDD): Testfälle werden vor dem entsprechenden Programm(teil) erstellt (eigentlich programmiert)!
• Zweistufiges Vorgehen:
  1. Erstellen von Systemtests für Anwendungsfälle (idealerweise durch AG)
  2. Erstellen von daraus abgeleiteten Komponententests (durch AN)