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