====== 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