Discussion Software Safety 2

Mid-Term Test

im Audimax
via Moodle, auch mit Free-Form-Fragen
halbe Stunde
BYOD, am besten Laptop (nur ein Gerät, nicht mehrere)
Material aus den Vorlesungen darf benutzt, aber sonst nichts

Quiz 2.1

Requirements sind die Informationen, was getan werden muss, damit die Software überhaupt das tut, was sie soll
- werden zusammen mit dem Kunden ausgearbeitet, damit die Entwicklungsfirma weiß, was der Kunde will
- unterschieden in F und NF Reqs
  - F was es tut
  - NF wie es das tut
Req Process erarbeitet die Reqs
- Elicitation
  - Interaktion mit Kunden, Anforderungen des Kunden kennenlernen
  - Stakeholder kennenlernen
    - nicht nur Kunden
    - grundsätzlich alle, mit denen man reden muss bzw. die man was fragen muss
    - z.B. auch Standards, Entwickler, andere Firmen, die irgendwie mit dem Produkt zu tun haben
  - Interaktionen mit anderen Komponenten
    - bspw. Kommunikationsbusse, Montage, APIs
  - grobe Reqs identifizieren
- Analysis
  - Reqs weiter verfeinern, Unklarheiten aufklären, Reqs möglicherweise aufsplitten, sodass jedes Req nur ein Thema abdeckt
  - Prioritäten von Qualitätsmerkmalen klären
- Specification
  - Übersetzung der Reqs in Dokumentation bzw. eine Form, die für Verständnis, Review und Benutzung geeignet ist bzw. eine Form, die für Verständnis, Review und Benutzung geeignet ist
  - Generierung des Req-Dokuments, was dann auch Teil des Vertrags mit dem Kunden wird
- Validation
  - Reqs immer wieder prüfen, ob die immer noch aktuell sind
  - ggf. Reqs nochmal neu spezifizieren etc.

Quiz 2.2

replication
- je nach Anforderungen wird auf Verfügbarkeit oder Zuverlässigkeit des Systems optimiert
  - Replication (also in mehreren Komponenten unabhängig voneinander die gleichen redundanten Berechnungen durchführen), damit man aus mehreren Ergebnissen auswählen kann
    - dadurch kann das System bspw. noch funktionieren, wenn manche Systeme nicht mehr richtig arbeiten
- optimistic replication
  - nicht immer müssen alle korrekt sein
  - lieber überhaupt ein Ergebnis als ein korrektes Ergebnis
  - solange überhaupt eine Komponente geht, kriegen wir ein Ergebnis
  - Availability ist hier natürlich top
- pessimistic replication
  - alle Komponenten müssen das gleiche Ergebnis liefern
  - weniger Verfügbarkeit, aber dafür hat man hohe Zuversicht, dass das Ergebnis korrekt ist
  - wenn die Ergebnisse nicht identisch sind, ist sehr wahrscheinlich ein System kaputt
    - damit wird Fehlerbehandlung möglich
  - Zuverlässigkeit top, aber Verfügbarkeit wird geopfert
recovery
- wiederherstellung eines zulässigen Zustands nach einem Fehlerzustand
- backward recovery: man geht zurück zum letzten bekannten safen zustand
  - problem: realität ist dann nicht mehr unbedingt in sync
  - embedded systeme können möglicherweise nicht mehr den alten sicheren zustand speichern oder zurückrollen, weil ressourcen nicht da sind
- forward recovery: zu einem neuen zustand springen, von dem man weiß, dass der safe ist
fehlertypen
- random
  - z.B. bit-flip
  - kann schon erkannt werden, indem mehrere identische Systeme arbeiten
- systematic
  - z.B. Bug in der Implementierung
  - gleicher Input wird zu gleichen Fehler in allen Systemen führen
    - kann zu gleichzeitigem Ausfall aller Systeme führen oder der Fehler kann nicht erkannt werden, weil alle das gleiche (falsche) Ergebnis liefern
  - kann durch Diversifizierung mitigiert werden
    - verschiedene Implementierung für das gleiche Modul
rejuvenation
- system wieder zurücksetzen (z.B. neustarten), bevor das Gerät in einen Fehlerzustand übergeht
  - z.B. bevor ein Integer Overflow auftrit

Quiz 2.3

verschiedene Methoden möglich
- waterfall sehr heavy weight
  - fester ablauf, siehe softwaretechnik
  - phasen nacheinander abarbeiten und möglichst abschließen
  - meist nicht realistisch, da man am ende teilweise erst sachen bemerkt, die am anfang falsch waren
  - prozesse werden in der realität doch nochmal iteriert
- extreme programming sehr light weight
  - man startet quasi direkt mit programmieren
  - möglichst viel throughput und lauffähiges system bereits am anfang
    - damit möglich, schon am anfang sachen auszuprobieren und feedback zu erhalten
  - nützlich, da kunden manchmal anfangs noch nicht so ganz wissen, was sie wollen
  - aber nicht so gut geeignet für safety-critical zeug
    - aber für so generelles unwichtiges kram sinnvoll