Übung und Selbstkontrolle zu Software Engineering (SEA)

Prof. Dr.-Ing. Stefan Kreiser

1. Verständnisfragen
a) Siehe Folien zur Vorlesung.
b) Technisches System besteht aus Anteilen Software, mechanischer und elektronischer
Hardware. Je nach Anwendung können z.B. physikalische, biochemische oder andere Teil-
systeme wesentlich die Funktion des technischen Systems beeinflussen. Das Teilsystem
Software muss das bestimmungsgemäße Zusammenspiel aller Teilsysteme ermöglichen.
Der Softwareentwicklungsprozess muss also mit den Entwicklungsprozessen für die ande-
ren Teilsysteme gekoppelt werden. Die SW-Entwickler müssen die Aufgabenstellung des
Gesamtsystems verstehen. Zusatzhinweis: Aus betriebswirtschaftlicher Sicht gilt, dass ca.
15-20% der Gesamtprojektkosten, nämlich die Kosten für das Softwaresystem, über den Er-
folg oder Misserfolg des gesamten Projekts (!) entscheiden. Ohne funktionsfähiges Soft-
waresystem ist das Gesamtprodukt für den Kunden wertlos !
c) Siehe Tabelle
Qualitätsmerkmal Kommentar
Zuverlässigkeit Das Softwaresystem / Gesamtsystem verhält sich jederzeit korrekt
und insbesondere wie vom Anwender erwartet. Beispiel Schubum-
kehr beim Flugzeugtriebwerk wird nicht ausgelöst, wenn der Flug-
kapitän versehentlich den entsprechenden Steuerhebel bedient, die
Fluglage eine Schubumkehr aber nicht zulässt. Die Software teilt
den Grund der Funktionsablehnung klar verständlich mit.
Leistungsfähigkeit Das Softwaresystem steuert das technische Gesamtsystem derart,
dass es im vom Anwender geforderten Betriebsbereich mit höchster
Effizienz arbeitet. Beispiel: Eine Software sortiert und gruppiert die
eingehenden Proben für ein Messgerät so, dass sie mit höchstmög-
lichem Durchsatz gemessen werden können. Selten eintreffende
Notfallproben, d.h. Proben, die sofort gemessen werden müssen,
überholen die gebildeten Gruppen, so dass der Gesamtdurchsatz
kurzfristig abnimmt.
Flexibilität Das Softwaresystem optimiert den Produktionsprozess in Abhän-
gigkeit vom aktuellen Zustand der Produktionsanlage, von den Ei-
genschaften der zur Verfügung stehenden Vorstufen und vom ge-
forderten Produktionsergebnis. Beispiel: Berechnung der notwendi-
gen Vorverdünnung einer Blutprobe auf Basis einer ersten
(Fehl)Messung so, dass die zweite Messung im erlaubten Messbe-
reich liegt.
Robustheit Das Softwaresystem steuert das technische Gesamtsystem derart,
dass typischerweise messtechnisch nicht erfasste Umwelteinflüsse
(Störungen) die Leistungsfähigkeit des Gesamtsystems nicht merk-
lich beeinflussen.
 Übung und Selbstkontrolle zu Software Engineering (SEA)
Prof. Dr.-Ing. Stefan Kreiser

Qualitätsmerkmal Kommentar
Verfügbarkeit Das Softwaresystem liefert jederzeit die in diesem Moment vom
Nutzer geforderte Funktion. Ausfallzeiten, d.h. Zeiträume in denen
die geforderte Funktion nicht bereitgestellt werden kann, sind mini-
mal bzw. im Idealfall nicht vorhanden. Verfügbarkeit wird üblicher-
weise angegeben als Anteil der Betriebsstunden ohne Funktions-
einschränkung im Verhältnis zur Gesamtheit der Betriebsstunden im
Beobachtungszeitraum (typ. 99,98%). Der Verfügbarkeitstest erfolgt
über einen zuvor vertraglich vereinbarten Beobachtungszeitraum im
Rahmen der Systemabnahme ausschließlich mit Mitarbeitern des
Systembetreibers (Kunden). Mitarbeiter des Systemherstellers dür-
fen nicht in den Verfügbarkeitstest eingreifen, ohne dass dies als
Betriebszeit mit Funktionseinschränkung gewertet würde. Beispiel:
Selbstdiagnose der Motorsteuerung eines Kfz bei jedem Start ermit-
telt potenzielle Defekte, die ohne vorbeugende Wartung zukünftig
zum Ausfall des Kfz führen könnten.
Sicherheit Das Softwaresystem steuert das technische Gesamtsystem derart,
dass die zuvor im Rahmen der Risikoanalyse ermittelten potenziel-
len Gefahren für Menschen, Umwelt oder Vermögen nicht eintreten.
Beispiel: Nothaltfunktion beim Riss d. Zugseils einer Aufzugkabine.
Anpassungsfähigkeit Das Softwaresystem ist auf potenzielle zukünftige Kundenanforde-
rungen vorbereitet. Neue Kundenanforderungen können i.d.R.
durch Parametrierung der Software und Hinzufügen neuer Funktio-
nalität ohne oder mit geringer Softwarerestrukturierung in das be-
stehende Softwaresystem integriert werden. Beispiel: Die Aufnahme
neuer Produkte mit zugehörigem Produktionsverfahren ist nur dann
leicht möglich, wenn die Software bereits Produkte und Produkti-
onsverfahren als eigenständige Entitäten kennt, die bisherigen Pro-
dukte und Produktionsverfahren also nicht fest in der Software „ver-
drahtet“ wurden.

d) Hier wird unabhängig von technischen Details analysiert, welchen betriebswirtschaftlich

messbaren Wert eine Software für den Kunden im täglichen Produktionsprozess hat, d.h.
unter welchen Randbedingungen welcher messbare Gewinn bzw. welche realisierbare Ein-
sparung erreicht werden kann. Siehe auch Folien zur Vorlesung.
e) Bei steigender Systemkomplexität wird es immer problematischer, Softwareanforderungen
frühzeitig vollständig und widerspruchsfrei zu spezifizieren. Zudem werden die typischen
Projektlaufzeiten von Kundenseite nicht signifikant verlängert, was einerseits eine höhere
Effizienz im Entwicklungsprozess und andererseits eine größere Anzahl an Projektbeteilig-
ten erfordert. Der Entwicklungsprozess muss flexibel und schnell auf veränderte Systeman-
forderungen reagieren können, die Software sollte flexibel anpassbar und leicht restruktu-
rierbar sein. Der Entwicklungsprozess sollte also auf eine stärker modularisierte und verteil-
te Softwarearchitektur sowie eine starke Abstraktion der Module hinzielen, damit eine ne-
benläufige Entwicklung in verteilten Teams mit hoher Sicherheit zu einem funktionsfähigen
Softwaresystem führt.
 Übung und Selbstkontrolle zu Software Engineering (SEA)
Prof. Dr.-Ing. Stefan Kreiser

f) Siehe Folien zur Vorlesung mit Folgerungen für zu entwickelnde Softwaresysteme.

Folgerung Kommentar
Technisches Gesamtsys- Regelmäßig ist die Vollautomatisierung von Produktionspro-
tem betrachten zessen betriebswirtschaftlich nicht sinnvoll (falls überhaupt
technisch umsetzbar). Daher verursacht auch und gerade der
Mensch kritische Prozess- und Anlagenzustände. Ein gutes
Softwaresystem berücksichtigt auch durch den Menschen ver-
ursachte Fehler so weit wie möglich und sieht einfache Sys-
temwiederherstellungs-maßnahmen vor.
Mit Störungen in sicher- Potenzielle Störungen und Gefahrensituationen müssen im
heitskritischen Systemen Rahmen einer Risikoanalyse ermittelt und möglichst im Rah-
planvoll umgehen men des Automatikbetriebs eines Systems behandelt werden.
Nichtbehandlung oder manuelle Störungsbehandlung kann Re-
/
alzeitanforderungen verletzen und große Schäden verursachen.
Qualität durch automati- Die automatische Behandlung typischer Fehler mit hohem Ge-
sches Fehlermanage- fährdungsrisiko gehört zum „normalen“ Funktionsumfang eines
ment im Softwaresystem jeden Softwaresystems.
Redundanzkonzepte müssen die Fehlerursache am Fehlerort
bekämpfen.
Wiederverwendung von Jedes zur Wiederverwendung ausgewähltes Softwareartefakt
Softwareartefakten nur muss sein Ein- / Ausgangsverhalten vollständig offen legen
bei vergleichbarem Ein- (Schnittstelle, Parametrierung, Wertebereiche der Parameter,
satzzweck und vergleich- Zusicherungen etc.). Wiederverwendung nur bei exakter Über-
barer Einsatzumgebung einstimmung des vorhandenen Ein- / Ausgangsverhaltens mit
dem geforderten Verhalten. Immer vollständiger Funktions- und
Systemtest !!!
Nebenläufige Software- Regelmäßig ist die Synchronisation nebenläufiger Ablaufpfade
systeme erhöhen die An- erforderlich. Das Softwaresystem kann in Verklemmungssituati-
zahl potenzieller Ver- onen laufen, die bei monolithischer, also nicht nebenläufiger
klemmungssituationen Software nicht auftreten würden. Funktionstests für einzelne
Ablaufpfade sind im Debugger möglich, realistische Software-
tests sind nur durch „Tracing“ mit Hilfe von Ereignisprotokollen
möglich.
Verteilte Entwicklungs- Exakte Definition und Einhaltung von Software- und System-
teams schnittstellen zwingend erforderlich. Alle Softwaremodule müs-
sen das spezifizierte Verhalten exakt einhalten.
Höchste Codequalität Codierungsstandards einhalten. Kein überflüssiger Code. Ent-
wicklungswerkzeuge können das Codierungsergebnis beein-
flussen, sind also regelmäßig als Codebestandteil anzusehen,
auf Korrektheit zu überprüfen und mit dem Quellcode zu si-
chern.
Qualitätssicherung erfor- Prüfung hierarchisch durchführen: Modultests, Teilsystemtests,
dert Qualitätsplanung und Gesamtsystemtests unter „Reinraumbedingungen“, Gesamtsys-
systematische Tests temtests in realen Anwendungsszenarien. Ohne geplante Ge-
samtsystemtests keine Freigabe des Softwaresystems.
 Übung und Selbstkontrolle zu Software Engineering (SEA)
Prof. Dr.-Ing. Stefan Kreiser

g) Siehe Folie aus Einführungsvorlesung und persönliche Übungsmitschrift.

h) Aufgabenstellung und eine mögliche Lösung (Gateway):

PPS PPS
(Produktions-Planungs-System) (Produktions-Planungs-System)

alte Steuerung Gateway

Steuerung neuer Teil der

Produktionsanlage
alte Produktionsanlage alte Steuerung

verbindende Neuer Teil der

alte Produktionsanlage Fördertechnik Produktionsanlage

Vorteile der Lösung:

• Altes Produktionssystem (=Anlage und Steuerung) bleibt unverändert. Die direkte Ver-
bindung zwischen PPS und alter Steuerung wird getrennt.
• Ein mechanischer Gateway verbindet die neue und die alte Produktionsanlage. Dieser
Gateway und die neue Produktionsanlage werden von einer komplett neuen Steuerung
koordiniert (neue Rechnerhardware, neue Software). Ein ebenfalls auf dem neuen
Steuerrechner implementierter elektronischer Gateway entscheidet, ob eine Karosse in
der alten oder in der neuen Produktionsanlage lackiert werden soll.
• Keine Umbaukosten für die alte, schwer wartbare Steuersoftware eines Wettbewerbers.
Einsatz als Black-Box.
• Moderner, leistungsfähiger Steuerrechner für die neue Produktionsanlage und die Koor-
dination der beiden Produktionsanlagen.
• Kostengünstige Entwicklung.
Nachteil der Lösung: Kein durchgängiges Softwaresystem. Betreiber muss beide Systeme
verstehen, nutzen und warten.
 Übung und Selbstkontrolle zu Software Engineering (SEA)
Prof. Dr.-Ing. Stefan Kreiser

2. Modellnotationen
Siehe Übungsmitschrift.

3. Modellbildung mit UML

a) Siehe Folien zur Vorlesung.
b) Siehe Folien zur Vorlesung.
c) Das folgende Kontextdiagramm geht davon aus, dass alle Röntgen- und Analysengeräte
aufgrund ihrer unterschiedlichen Einsatzgebiete auch über unterschiedliche Außenschnitt-
stellen verfügen. Zudem wird erwartet, dass der Empfang mit mindestens einem PC und je-
der Behandlungsraum mit einem eigenen PC ausgestattet sind. Die PCs sind als externe
Bedienstationen der Praxisverwaltung mit einer jeweils zugeschnittenen Bediensoftware
anzusehen, sind also zusammen mit der Praxisverwaltung herzustellen (daher grau hinter-
legt). Aufgrund der unterschiedlichen Aufgaben im Empfang und in den Behandlungszim-
mern könnten die Schnittstellen zur Praxisverwaltung ggf. differieren.

Röntgen- Röntgen-
gerät 1 gerät 2

PC PC
PC
Behandlung Praxis- PC
Empfang
Behandlung verwaltung Empfang

mobiles mobiles mobiles

Analysen-
Analysen- Analysen- Analysen-
gerät 4
gerät 1 gerät 2 gerät 3
 Übung und Selbstkontrolle zu Software Engineering (SEA)
Prof. Dr.-Ing. Stefan Kreiser

d) Anwendungsfalldiagramm „Praxisalltag“

Akteure:
• Arzthelfer <<Actor>> kommuniziert mit: Röntgengerät einrichten, Patient aufnehmen,
Behandlungstermin festlegen, Biowerte ermitteln, Voruntersuchung durchführen.
Hinweis: Rolle. Nutzt die Praxisverwaltung über den Empfangs-PC, ggf. auch über den
PC im Wartezimmer. Alle Aufgaben müssen auch vom Arzt selbst ausführbar sein.
• Arzt <<Actor>> kommuniziert mit: Therapie festlegen, Diagnose stellen, Untersuchung
durchführen. Hinweis: Rolle. Alle Arten von Befundung und Diagnose sind ausschließ-
lich dem Arzt möglich. Eingabe nur über PC im Behandlungsimmer.
• Röntgengerät (abstrakt) <<Actor>> kommuniziert mit: Röntgengerät einrichten. Genera-
lisierung: RG Typ 1, RG Typ 2
• Analysengerät (abstrakt) <<Actor>> kommuniziert mit: Biowerte ermitteln. Generalisie-
rung: mobiles AG Typ 2, mobiles AG Typ 1, mobiles AG Typ 3, AG Typ 4
 Übung und Selbstkontrolle zu Software Engineering (SEA)
Prof. Dr.-Ing. Stefan Kreiser

e) Aktivitätsdiagramme
Arzthelfer
Arzt Arzthelfer

Untersuchungsparameter
für Röntgengerät festlegen
Röntgenparameter aus
Konsultationsprotokoll entnehmen

Röntgenparameter im
Konsultationsprotokoll ablegen

Röntgengerät
vorbereiten

Röntgengerät
einric hten

Messung
durchführen

Röntgenbild dem
Konsultationsprotokoll anhängen

Röntgenergebni s
auswerten

Röntgengerät einrichten Röntgenuntersuchung durchführen

Arzt

[Anamnese erforderlic h]

[externe Untersuchung erforderlic h]

[Voruntersuchung erforderlich] [Röntgen erforderlich]

Arz tges präch Voruntersuc hung Röntgenuntersuchung externe Unters uchung

durchführen festlegen durchführen festlegen

Untersuchung durchführen
 Übung und Selbstkontrolle zu Software Engineering (SEA)
Prof. Dr.-Ing. Stefan Kreiser

f) Entitätendiagramm „Praxisverwaltung“
Arzt Patient

-Kuer zel : Text6 -Kennung : Text80

-er sterBesuch : Date
Person
-letzterBesuch : Date
-naec hsterBesuch : Date
-Name : Text80 * 1
-Mitgl iedsk ennungKr ankenkasse : T ext80 Krankenkasse
-Vorname : Tex t80
-Konsultationsprotokoll : Konsul tationsprotokoll
-GebDatum : Date
-Geschlecht : Sex
-Strasse : Text80 +an legen( )
-Wohnor t : Text80 Arzthelfer +f estlegen Untersuchungstermin( )
-PLZ : Text6 +ab sagenU ntersuch ungsterm in()
-angestelltVon : Date +ko nsult iereArzt()
+an legen( ) -angestelltBis : Date +b eenden Untersuchung( )
-Kuer zel : Text6 +au sstellenRezept()
-Profil : Tätigkei ten +ü berweisenFacharzt()
+g eheiltEn tlassen( )
+aen dernProf il()
1
+an legen( )

Röntgenuntersuchung
-Ergebnis : BLOB
-Röntgengerät : Röntgenger ät
+f estlegen Param eter()
+zuo rd nen Erg ebnis()
* -Röntgenunters uchung : Röntgenuntersuchung
1
1
Konsultationspr otokoll
Biowertuntersuc hung
0..1 1 *
-angelegt : TimeDate
-letzteAender ung : Ti meDate -Analysengerät : Analyseng...
-Diagnose : Text
-KonsultationsGr und : Tex t
-T herapie : Text +f estlegen Param eter()
+zuo rd nen Erg ebnis()
-Biowertunter suchung : Bio wertunters uchung
*

+an legen( )
RG Typ1 Röntgengerät +erstellen Diagn ose()
+f estlegen Therap ie()
-ID : Text6 +an ordnenRoentg enun tersuch ung ()
-aktiv : bool +an ordnenBiow ertu ntersu chun g()
RG Typ2

+akt ivieren ()

AG T yp1
0..1
1
2
1 1
AG T yp2 mobiles AG Analy sengerät
Röntgenr aum Labor
-ID : Text6
-aktiv : bool
-Röntgengerät : Röntgenger ät -Analysengerät : Analyse... AG T yp3
-gewähltes Röntgengerät : Röntgengerät +m essen()

+au swählenRöntg engerät ()

*
AG T yp4 festes AG

1
 Übung und Selbstkontrolle zu Software Engineering (SEA)
Prof. Dr.-Ing. Stefan Kreiser

g) Zustandsdiagramm zur Entität „Patient“

schliesseA kte()
überweisenFacharzt()

anlegen() aus stellenRezept() Untersuchung

angelegt
beendet

geheiltEntlass en()

festlegenUntersuchungstermin()

beendenUntersuchung()

abs agenUntersuchungstermin()

konsultiereArzt()
Termin v ereinbart Untersuchung läuft

4. Modellierung der Verwaltungssoftware für ein Flughafenparkhaus

Siehe Übungsmitschrift bzw. Modelle aus der Übung.

5. Softwareentwurf
a) Siehe Folien zur Vorlesung.
b) Design Prinzipien sind „best practice“, d.h. sie spiegeln Erfahrungswissen aus 100en Per-
sonenjahren Softwareentwicklung wieder. Für ein Softwareprojekt müssen zunächst die
Design Prinzipien ausgewählt werden, die für die Qualität für des Projekts / des Produkts
ausschlaggebend sind. Die Auswahl ist abhängig von der Aufgabenstellung und vom Pro-
jektumfeld im Unternehmen. Die ausgewählten Design Prinzipien sind allen an der Entwick-
lung beteiligten Personen in einem Richtliniendokument zu erläutern („die 10 Gebote“). Ggf.
kann eine Schulung die Auswahl und den Nutzen begründen.
c) Siehe Folien zur Vorlesung.
d) Ein verteiltes Softwaresystem basiert auf der Verarbeitung externer und interner Ereignisse,
d.h. ein verteiltes Softwaresystem kann wartende Rechenprozesse nicht ohne externe oder
interne Anregung fortführen und beenden. Das Prinzip „Quellereignisse vollständig prozes-
sieren“ weist darauf hin, dass Ereignisse zunächst hinsichtlich ihrer primären Aussage ver-
arbeitet werden sollen und anschließend alle indirekt beeinflussten Verarbeitungsschritte
ausgelöst werden sollen. Beispiel: Die Software eines Messsystems erhält eine Kalibrati-
onskurve zur Interpretation von Messkurven (Primäraussage = Kalibrationskurve gemes-
sen). U.U. liegen in der Software bereits Messkurven vor, die auf Basis dieser Kalibrations-
kurve ausgewertet werden können (indirekt auslösbare Verarbeitungsschritte), oder es war-
ten bereits Messaufträge, die nun prozessiert werden dürfen (indirekt auslösbare Verarbei-
tungsschritte).
 Übung und Selbstkontrolle zu Software Engineering (SEA)
Prof. Dr.-Ing. Stefan Kreiser

e) Beispiele aus der Übung:

• Betriebsmittelabstraktion: Einfahrtschranke oder Ebenenschranke.
Begründung: Betriebsmittel sind von Rechenprozessen nur im gegenseitigen Aus-
schluss verwendbar.
• Abstraktes Betriebsmittel: Schrankenanlage verallgemeinert Einfahrtschranke und Ebe-
nenschranke.
Begründung: Ein abstraktes Betriebsmittel ist die Zusammenfassung von Betriebsmitteln
anhand eines gemeinsamen Ordnungskriteriums. Hier repräsentieren beide Betriebsmit-
tel eine Schrankenanlage, besitzen somit eine Untermenge gleicher Attribute und glei-
cher Operationen, die jeweils spezifisch für das konkrete Betriebsmittel implementiert
oder spezifisch erweitert werden.
f) Durch starke Kommunikation gebundene Softwareartefakte sollten aufgrund der erwartet
hohen Kommunikationslast zu einem Subsystem zusammengefasst werden, in dem die
Kommunikationskosten gegenüber anderen denkbaren Implementierungen minimal sind.
g) Siehe Folien zur Vorlesung.
h) Siehe Folien zur Vorlesung.
i) Die Navigierbarkeit der Assoziationen zwischen Entitäten sagt aus, ob die Entität die asso-
ziierte Entität kennt oder nicht. Einseitige Navigierbarkeit hat also den Vorteil, dass nur einer
der assoziierten Entitäten die andere Entität bekannt ist. Im Fall einer Änderung der Softwa-
restruktur ist der erforderliche Änderungsaufwand aufgrund der schwächeren inhaltlichen
Bindung geringer.
j) – o) Siehe Folien zur Vorlesung.
p) In verteilten Softwaresystemen spielt neben eventuellen Echtzeitanforderungen (Echtzeit-
system) die zeitliche Protokollierung von Verarbeitungsschritten eine entscheidende Rolle.
Ohne synchronisierte zeitliche Anordnung der Meldungsprotokolle in Subsystemen kann die
nachträgliche Untersuchung verteilter Vorgänge kaum korrekt durchgeführt werden.
q) Verteilte Systeme mit heterogener Systemhardware und heterogenen Betriebssystemen,
z.B. Linux, MacOSX oder Windows auf Intel, Solaris auf Sun Sparc, beliebige RTOS auf
µC-System, … .
r) Siehe Folien zur Vorlesung. Stichwort „Entwurfsprinzip: Problemgerechte Kommunikation“.
s) Siehe Folien zur Vorlesung. Stichwort „Entwurfsprinzip: Problemgerechte Kommunikation“.
Kommunikation findet nur dann statt, wenn der Empfänger die Daten auch benötigt. Bei Da-
tenabonnements signalisiert die Datenquelle (der Erzeuger) den Datensenken (den poten-
ziellen Nutzern, den Abonnenten) nur, dass neue Daten bereitgestellt wurden. Der Nutzer
holt die Daten nur bei Bedarf. Dadurch wird die Menge übertragener Daten gesenkt, wenn
Anwendungen nicht ständig aktiv sind.
t) Problemstellung: Empfänger darf nicht auf unvollständige bzw. inkonsistente Datendatei
zugreifen. Hinweis: Auf die Benachrichtigung des Empfängers (die Synchronisierung) kann
sogar verzichtet werden, wenn der Empfänger das Transferverzeichnis regelmäßig auf das
Vorhandensein einer Datei mit der vorgegebenen Bezeichnung für konsistente Datendatei-
en abfragt.
 Übung und Selbstkontrolle zu Software Engineering (SEA)
Prof. Dr.-Ing. Stefan Kreiser

Sender Empfänger

Empfangsverzeichnis auf
Zielcomputer er mitteln

temporäre Datei auf Zielverzeichnis

anlegen und Daten übertragen

aRemoteFile
übertragene Datei auf : RemoteFile
konsistenten Namen umbenennen [isCon sistent]

aRemoteFile
asynchrone Nachricht an Empfänger , : RemoteFile
dass neue Daten verfügbar sind [isActive]

konsistenten
Dateiinhalt lesen

u) Message Queue: Prinzipbild und Klassendiagramm

Schreiben Lesen
FIFO
Voll Leer
Datenwort 2
Datenwort 1
Datenwort k

n n
 Übung und Selbstkontrolle zu Software Engineering (SEA)
Prof. Dr.-Ing. Stefan Kreiser

MsgQueue
Slot
-head : Dezimal = 0
-msg : Zeichenkette
-tail : Dezimal = -1 -{geordnet} -msgLen : Dezimal = 0
-msgCount : Dezimal = 0
-maxlen : Dezimal = 0
-isFull : Boolesch = FALSE
1 1..* -sendState : Dezimal = 0
-isEmpty : Boolesch = TRUE
+pushMsg()
+send()
+popMsg()
+receive()

Lösungsidee Use-Case-Diagramm
Anwendungsfälle, Aktor = Empfänger: MsqQueue initialisieren, Nachricht empfangen
Anwendungsfälle, Aktor = Sender, Nachricht senden

Lösungsidee Aktivitätsdiagramme
Zum Anwendungsfall „MsqQueue initialisieren“: MsgQueue muss im Speicher angelegt und
mit sinnvollen Daten (vgl. Klassendiagramm) vorbelegt werden.
Zum Anwendungsfall „Nachricht empfangen“: Nachricht aus Slot [head] auslesen, falls
MsgQueue nicht leer ist. Prüfen, ob Nachricht beim Senden vollständig eingetragen worden
war (sendState). Kennzeichnen in isEmpty, falls MsgQueue nach Empfang leer ist.
Zum Anwendungsfall „Nachricht senden“: Nachricht in Slot [tail] schreiben, falls MsgQueue
nicht voll ist. Vermerken, ob Nachricht vollständig in den Slot übernommen wurde (sendSta-
te). Kennzeichnen in isFull, falls MsgQueue nach Senden voll ist.

v) – y) Siehe Folien zur Vorlesung.

6. Projektmanagement
a) Siehe Folien zur Vorlesung.
b) Siehe Folien zur Vorlesung.
c) Einige Denkanstöße.
Problemfeld Termine (Projekt- und Bereichsleiter).
• Fehlerhafte Zeitplanung: Ggf. werden Sie als Projekt- oder Bereichsleiter fehlerhaft über
den tatsächlichen Projektstand informiert. Abhilfe: schriftliche Reviews, die den Fertig-
stellungsgrad und die Qualität von Arbeitsergebnissen belegen.
• Geänderte Anforderungen im Projektverlauf (Mehrungen oder „nur“ Umstellungen): In
der Konsequenz sind bereits erarbeitete Lösungen wegzuwerfen und neue Lösungen
herzustellen. Abhilfe: Umstellungsaufwand ist immer Mehraufwand und verzögert daher
Terminpläne. Planen Sie genau, wie viel Mehraufwand ausgelöst wird und versuchen
Sie den Mehraufwand in Ihrem Fertigstellungstermin zu berücksichtigen.
• Fehlerhafte Lösungen erzeugen Folgefehler, so dass eine späte Korrektur nur mit er-
heblichem Personal- und Zeitaufwand realisierbar ist. Abhilfe: Qualitätskontrolle wichti-
ger Arbeitsergebnisse vor deren Weiterverwendung.
 Übung und Selbstkontrolle zu Software Engineering (SEA)
Prof. Dr.-Ing. Stefan Kreiser

Problemfeld Ressourcen (alle Projektbeteiligten).

• Forderung nach Austauschbarkeit von Personen bei Krankheit, Tod, anderes Projekt
(keine Zeit), Kündigung, ...: Abhilfe: z.B. Komponentenarchitektur, Dokumentation, Pro-
grammierrichtlinien, d.h. Wissen um die Software liegt nicht bei einzelnen Gurus, son-
dern beim gesamten Entwicklungsteam.
Problemfeld Finanzen (Bereichs- und Projektleiter).
• Fehlerhafte Aufwandsschätzung: Zeitüberschreitung bei einzelnen Aufgaben, beim Fer-
tigstellungstermin, Aufgabe nicht geplant, Zukaufkomponenten teurer als geplant. Abhil-
fe: Saubere Planung des Gesamtprojekts auf Basis von Erfahrungswerten aus ähnli-
chen Projekten.
• Fehlerhafte Verkaufsschätzungen: Erlös geringer als geplant. Abhilfe: professionelle
Marktstudien verringern das unternehmerische Risiko.
• Fehlerhafte Projektbearbeitung mit später und damit teurer Fehlerkorrektur. Abhilfe:
Fehlerhafte Lösungen durch Reviews frühzeitig erkennen und Fehler vor Weiterverwen-
dung der Lösung korrigieren.
d) Besondere Risiken in Entwicklungsprojekten
• Fehlerhafte Aufwandsschätzung: Technische Machbarkeit unklar. Abhilfe: Absicherung
technischer Risiken durch frühe Machbarkeitsstudien und Prototypen nachweisen.
“Projektiere nur, wovon Du sicher weißt, dass Du es technisch realisieren kannst.“ Be-
herrschen von Projekt- und Produktrisiken durch konsequentes Risikomanagement.
Abhilfe: Sichere Fallbackpositionen definieren. Probleme im Projekt frühzeitig diskutie-
ren. Ggf. hinsichtlich Zeit- und Kostenaufwand mit dem Auftraggeber nachverhandeln
oder das Projekt in einer frühen Phase einstellen.
• Fester Endtermin: Merke, der Endtermin steht immer zum Verhandlungsbeginn fest, un-
abhängig von der Dauer der Vertragsverhandlungen.
Obige Risiken treten in Softwareentwicklungsprojekten besonders stark auf, da sich die
Rahmenbedingung für Softwareentwicklung sehr schnell verändern (regelmäßig neue Ent-
wicklungsumgebungen, projektspezifische Zielsysteme und stark kundenspezifische Nut-
zungsumgebungen).
e) Nein, der Projektplan lebt während des gesamten Projektverlaufs. Beispiele: Detaillierun-
gen, Reaktion auf geänderte Rahmenbedingungen, fehlgeschlagene Aufgaben usw.
f) Siehe Folien zur Vorlesung.
g) Siehe Diagramme aus MS-Project (loesung_5g.pdf). Alle Zeitangaben sind absolut zum
Projektstartzeitpunkt.
 Übung und Selbstkontrolle zu Software Engineering (SEA)
Prof. Dr.-Ing. Stefan Kreiser

7. Vorgehensmodelle
a) Weil sich die Anforderungen an die Software über der Zeit ändern (Veränderte Produktions-
aufgabe beim Kunden) und daher die Software in ihrer ursprünglichen Form nicht mehr den
aktuellen Kundenerfordernissen entspricht. Konsequenz: Entweder SW wegwerfen und neu
programmieren oder SW evolutionär weiterentwickeln und an die neuen Anforderungen an-
passen.
b) Wenn die Kundenanforderungen vage sind und die sprachliche Verständigung mit dem
Kunden problematisch ist, d.h. der Kunde weiß, was er will, wenn er das Ergebnis sieht.
Abhilfe: Sprechen Sie die Sprache des Kunden und versetzen Sie sich in seine Lage. Er-
stellen Sie viele Prototypen anhand derer der Kunde seine Bedürfnisse erkennen kann.
c) Veränderung (Optimierung) einer gegebenen Softwarearchitektur, ohne die Softwarefunkti-
onalität aus Sicht des Nutzers zu verändern oder zu erweitern.
d) Risiko ist die (fehlende) Softwarearchitektur. Milderungsmöglichkeiten:
• Regelmäßiges Refactoring.
• Wegwerfen der Prototypen und Erstellung einer konsistenten System- und Software-
architektur bei geklärten Anforderungen.
e) Tabelle

Wasserfall- V-Modell Spiralmodell XP SCRUM

Modell
Optimale ?? mittel bis groß mittel (bis groß) klein klein bis mittel
Teamgröße (ca.10 Entw.) (3-15 Entw. je
SCRUM Team)
Komplexität klein (bis mittel) mittel bis groß mittel bis groß klein (bis mittel) mittel (bis groß)
(Produkt/ wg. fehlender (bürokratischer (bürokratischer wg. Handhab-
Projekt) Kontrollphasen Mindestaufwand) Mindestaufwand) barkeit im Team
Bekanntheit Voraussetzung Voraussetzung wesentliche Kern- Kern-
Anforder- Anforderungen anforderungen anforderungen
ungen
Variabilität minimal klein mittel groß groß
Anforder- (strikt top down) (top down) (Iterationen (Iterationen (Iterationen
ungen möglich) üblich) üblich)
Time To Spielraum gering Spielraum gering Spielraum mittel Spielraum groß Spielraum groß
Market (Produkt wird (Produkt wird (regelmäßige (tägliche (Produktversio-
erst am Ende erst am Ende Produktversio- Produktversio- nen alle 1 bis 4
fertig) fertig) nen) nen.) Wochen)
Dokumen- Vollständige vollständig, inkl. vollständig, inkl. nur Code vollständig, inkl.
tation Phasendoku- Qualitätsprüfun- Qualitätsprüfun- Qualitätsprü-
mentation gen gen fungen
IT Kenntnis- nicht nicht erforderlich nicht erforderlich essentiell nicht
se Kunde erforderlich erforderlich
Typ. Anzahl 1-2 1-3 3-5 > 10 > 10
Iterationen
 Übung und Selbstkontrolle zu Software Engineering (SEA)
Prof. Dr.-Ing. Stefan Kreiser

8. Anforderungsanalyse
a) Der Systementwurf soll möglichst viele Freiheitsgrade nutzen können, damit die erarbeitete
Lösung so einfach wie möglich und so komplex wie nötig sein kann (Designprinzip KISS =
Keep It Simple Stupid). Implementierungsanforderungen schränken die Lösungsvielfalt ein.
Sie sind oft unnötig, z.T. sogar kontraproduktiv, da die Auslöser / Ersteller der Anforderungen
(Kunden, Marketing, ... ) i.d.R. keine Systementwickler sind und ihnen daher das Know How
für eine unter den gegebenen Randbedingungen optimale Lösung fehlt.
b) Abhängigkeitsmatrix ermöglicht formalisierte Überprüfung auf inhaltliche Abhängigkeiten, ins-
besondere unter dem Aspekt der Konsistenzsicherung / Widerspruchsauffindung. Problem:
Bei n Anforderungen: n*n/2 Felder zu füllen. Inhaltlich für große Systeme kaum überschau-
bar.
c) Anordnungen der DIRs im Lastenheft, Vorteile (V), Nachteile (N):
• Unstrukturierte Anordnung
V: Einfaches Ordnungssystem, auch von verteilten Projektgruppen ohne großen Aufwand
anwendbar.
N: Strukturlosigkeit erhöht Risiko für Widersprüche, Duplikate und missverständliche Anforde-
rungen, insbesondere bei hohem Detaillierungsgrad von Anforderungen. Schwer auf Konsis-
tenz etc. zu prüfen, da prinzipiell zwischen allen Anforderungen Abhängigkeiten bestehen
können. Der Einsatz einer Datenbank zur Verwaltung der DIRs kann zur Konsistenzprüfung
hilfreich sein (Volltextsuche nach verschiedenen Kriterien).
• Strukturierte Anordnung nach Anforderndem (nach Sicht auf das System)
V: Konsolidierung der Anforderungen einzelner Rollen (Sichten), ggf. auch in verschiedenen
Kundensegmenten. Wahrscheinliches Ergebnis ist eine verringerte Anzahl abstrakterer An-
forderungen. Kundenreviews aufgrund des direkten Kundenbezugs gut durchführbar.
N: Vorsortierung und Abstrahierung der einzelnen Anforderungen durch ein Kernteam erfor-
derlich. Beschränkung auf Sichten (Rollen) erlaubt nur mittlere Abstraktion
• Strukturiert nach Dienstleistungen, die das System zur Verfügung stellt.
V: Konsolidierung der Anforderungen aller Rollen (Sichten), ggf. auch über verschiedene
Kundensegmente. Wahrscheinliches Ergebnis ist eine nochmals verringerte Anzahl noch
abstrakterer Anforderungen. Eindeutige Hierarchisierung der Anforderungen nach System-
diensten möglich. Dadurch Einschränkung der zu untersuchenden Kombinationen in der Ab-
hängigkeitsmatrix (schwach besetzte Matrix)
N: Vorsortierung und Abstrahierung der einzelnen Anforderungen durch ein Kernteam erfor-
derlich. Deutlich erhöhter Aufwand. Kundenreviews aufgrund des indirekten Kundenbezugs
erschwert durchführbar.
d) Allgemein: Wenn Sie Nachfragen zu diesem Punkt für wahrscheinlich halten, also z.B. wenn
• die Anforderung sehr abstrakt ist und ihr Ursprung nicht sofort ersichtlich ist, bzw. wenn die
Notwendigkeit der Anforderung nicht unmittelbar nachvollziehbar ist.
• die Implementierung der Anforderung teuer ist (z.B. Zeit-, Implementierungsaufwand).
• die Anforderung Ihrem bisherigen Verständnis des Anforderungsbereiches widerspricht.
• die Anforderung eine wesentliche Erweiterung des Anwendungsbereiches ermöglicht (neue
Produktkategorie).
 Übung und Selbstkontrolle zu Software Engineering (SEA)
Prof. Dr.-Ing. Stefan Kreiser

e) Alle Quellen für Anforderungen (Wer stellt die Anforderung?), d.h.

• Kunden / Rollen. Typisches Vorgehen:
In sogenannten Focus Sessions mit Kunden, werden fokussiert die Anforderungen einzel-
ner Kunden, Kundensegmente und Rollen auf Korrektheit, Vollständigkeit und Konsistenz
überprüft.
• Ersteller der Formulierung für die Anforderung, z.B. Kernteam.
• jeder andere Auslöser von Anforderungen, z.B. Verantwortlicher für TÜV-Abnahmen, be-
hördliche Abnahmen etc., Standardisierer (Entwicklung, Produktion) usw.
f) Beispiele für Personengruppen (Rollen) und deren Anforderungen
• Betreiber:
# Buchungsvorgänge analysieren, z.B. zeitliches Auftreten der Buchungen, Fahrziele, Art
des Fahrscheins, Art der Bezahlung.
# Fahrscheinmissbrauch minimieren, z.B. fälschungssichere Fahrscheine verwenden.
• Service:
Wartungsfreundlichkeit und Zuverlässigkeit sicherstellen, z.B. Verfügbarkeit erhöhen, De-
fekte und Materialverbrauch minimieren, SW-Update, Ferndiagnose und Fernwartung er-
möglichen.
• Bestandskunde:
Bedienbarkeit. Spezieller Aspekt: Schnelle und sichere Abwicklung regelmäßig wiederkeh-
render Kaufgeschäfte.
• Umsteiger:
Bedienbarkeit Spezieller Aspekt: geführte und sichere Abwicklung einmaliger Kaufgeschäfte
/ der optimalen Fahrkarte.
• Fremdkunde:
Bedienbarkeit und Wegweisung. Spezieller Aspekt: geführte und sichere Beschaffung der
richtigen Fahrkarte / der optimalen Fahrkarte unter Berücksichtigung der Sprachanforde-
rungen.
Zunächst müssen die Rollen mit ihren Nutzungsprofilen exakt spezifiziert werden, z.B. durch
Langzeitstudie zu Fahrgästen. Anschließend sollten die ermittelten Anforderungen der ein-
zelnen Rollen z.B. anhand eines Fahrgastfragebogens validiert werden.
Nutzungsdauer 10 Jahre: Welchen Einfluss hat diese Anforderung auf Ihr Lastenheft?
Die Anforderungen für die aktuelle Produktversion müssen, soweit möglich, bereits spätere
Produktversionen berücksichtigen, d.h. eine aktuelle Lösung darf zukünftig erwarteten Anfor-
derungen nicht entgegenstehen. Zukünftig erwartete Anforderungen können durch Vorgabe
einer Schnittstelle zu erweiterten Dienstmerkmalen aufgenommen werden. Diese Schnittstel-
lenanforderung erhält niedrige Priorität, braucht also in der aktuellen Version nicht implemen-
tiert werden. Die aktuelle Lösung muss eine spätere Implementierung der Anforderung aller-
dings leicht möglich machen.

Können Sie die nötige Flexibilität in Ihrer Lösung bereits im Lastenheft erzwingen? (Wie?)
Durch ein höheres Abstraktionsniveau der Anforderungen / der angeforderten Dienstmerkma-
le wird die aktuelle Anforderung zu einer speziellen Ausprägung einer Klasse von Anforde-
rungen (sinnvolles Ordnungskriterium für die Abstraktion suchen).
 Übung und Selbstkontrolle zu Software Engineering (SEA)
Prof. Dr.-Ing. Stefan Kreiser

Exemplarische Anforderungen an die Software des Fahrkartenautomaten.

• Priorität: 1
Produkteigenschaft: Auswahl der optimalen Fahrkarte
Leistungsdaten: Der Kunde kann an jedem Fahrkartenautomaten eine Fahrkarte von jedem
beliebigen Startpunkt zu jedem beliebigen Zielpunkt des Tarifgebietes kaufen. Der Automat
ermöglicht eine fehlertolerante Eingabe von Start- und Zielpunkt. Er schlägt verschiedene
Mengentarife für diese Strecke vor, z.B. Einzel- und Mehrfahrtenfahrschein etc.
Begründung: Ein Fremdkunde soll geführt die optimale Fahrkarte erhalten. Das Verständnis
für das Tarifsystem ist nicht erforderlich.
Prüfvorschrift: 100 Testkunden kaufen jeweils unterschiedliche Fahrscheine. Prüfkriterien:
Wurde der korrekte / der optimale Fahrschein ausgegeben ?
Rolle: Fremdkunde
• Priorität: 1
Produkteigenschaft: Bedienbarkeit des Fahrkartenautomaten
Leistungsdaten: Die Bedienoberfläche des Fahrkartenautomaten ist jederzeit durch einen
einzigen Bedienereingriff in deutscher, englischer, französischer und spanischer Sprache
verfügbar.
Begründung: Sprachumfang deckt die europäischen Sprachgruppen ab. Andere Sprach-
gruppen können sich i.d.R. in einer der europäischen Sprachen verständigen.
Prüfvorschrift: Prüfung der Sprachversionen auf Vollständigkeit, Korrektheit und Verständ-
lichkeit jeder einzelnen Aussage der Bedienoberfläche. Ausgangspunkt ist die Sprache, in
der die Bedienoberfläche entwickelt wurde.
Rolle: Fremdkunde
• Priorität: 2
Produkteigenschaft: Bedienbarkeit des Fahrkartenautomaten
Leistungsdaten: Die Bedienoberfläche des Fahrkartenautomaten ist in türkischer und russi-
scher Sprache verfügbar.
Begründung: Sprachumfang deckt die wesentlichen Sprachgruppen im Tarifgebiet ab.
Prüfvorschrift: s.o.
Rolle: Fremdkunde
g) Siehe Folien zur Vorlesung.

9. Systementwurf und Risikoanalyse

a) Das gewählte System- und Softwaredesign soll die ermittelten Risiken minimieren, die prin-
zipiell durch den Betrieb des Produktes ausgelöst werden. Ohne Berücksichtigung der Er-
gebnisse der Produktrisikoanalyse würde ein Serienprodukt ggf. nicht behördlich zum Ver-
kauf zugelassen bzw. der Betrieb würde nicht freigegeben.
b) Siehe Unterlagen zur Vorlesung.
c) Siehe Unterlagen zur Vorlesung.
d) Beschreibung von System- und Teilsystemgrenzen
• Angaben zu Schnittstellen im Pflichtenheft
# Endpunkte der Datenübertragung.
# Übertragene Informationen. Angabe typischer Werte, Grenzwerte, Übertragungsrichtung.
# Übertragungsprotokoll(e).
# Erläuternde Szenarien.
 Übung und Selbstkontrolle zu Software Engineering (SEA)
Prof. Dr.-Ing. Stefan Kreiser

• Schnittstellenmodelle
# Spezialform des Klassenmodells der UML
# XML zur Darstellung von Datenstrukturen (alternativ auch JSP-Notation, M. Jackson)
# Spezifikation von Übertragungsprotokollen z.B. als Zustandsdiagramm

e) Siehe Folien zur Vorlesung.

f) Siehe Folien zur Vorlesung.
g) Die RPZ berücksichtigt gegenüber der Risikokennzahl R zusätzlich die Entdeckbarkeit ei-
nes Fehlers. Grundsätzlich hängt die Entdeckbarkeit jedoch von der Ausbildung des Nut-
zers und der Gesamtsituation ab, in der der Fehler auftritt. Somit ist die Entdeckbarkeit ge-
rade in Stresssituationen eventuell nicht gegeben, bzw. dem Nutzer ist in Stresssituationen
nicht zuzumuten, dass der Fehler erkannt wird und zudem eine korrekte Fehlerbehebungs-
maßnahme eingeleitet wird. Somit ist anzunehmen, dass die Entwickler des Standards ISO
14971:2000 auf die Verwendung der RPZ verzichtet haben, da Medizingeräte ein prinzipiell
hohes Betriebsrisiko haben und daher Fehlervermeidung oberste Priorität hat.
h) Damit Risiken bereits im Produktdesign gemildert oder verhindert werden können. (vgl. 8a).
i) Bei Altprodukten bzw. bereits fertig gestellten Produkten, wenn z.B. eine frühere Risikoana-
lyse ergänzt oder auf Basis erster Betriebsdaten validiert werden soll. Oft liegt für Altproduk-
te noch keine Risikoanalyse vor. In diesem Fall dient die retrospektive Risikoanalyse insbe-
sondere dazu, das Risiko eines weiteren unveränderten Einsatzes des Altprodukts im Markt
einzuschätzen und ggf. durch Schulung und Service auf potenzielle Risiken hinzuweisen.
j) Bei Neuprodukten und im speziellen bei völlig neuen Produkttypen liegen keine gesicherten
statistischen Messungen oder ausreichendes Expertenwissen zu Fehlerraten vor. Auch
kann eine Simulation des Produkts zu unbrauchbaren Fehlerraten führen, da i.d.R. der Ein-
satz des Produkts bei den einzelnen Kunden nicht genau bekannt ist (jeder Kunde nutzt ei-
ne andere Untermenge an Produktfunktionen, diese Untermenge dann aber intensiv und
ggf. nach seinem eigenen Geschäftsprozess). Daher kann die Bestimmung der Auftretens-
wahrscheinlichkeit mit sehr großen Unsicherheiten behaftet sein. In diesen Fällen sollte
man von einer maximalen Fehlerrate ausgehen und versuchen, die Fehlerschwere deutlich
zu reduzieren.
k) Der Fehlerschweregrad ist abhängig vom geschädigten Objekt (z.B. Personen, Umwelt,
Vermögen).
l) Wenn (weitere) Milderungsmaßnahmen, die das Risiko in die Region akzeptabel überführen
können, technisch-wirtschaftlich nicht sinnvoll umsetzbar sind und der Nutzen des Produkts
klar die Risiken überwiegt (z.B. wenn Ihr neues Produkt lebensverlängernde Maßnahmen
für Patienten mit tödlicher Erkrankung ermöglicht, aber das Risiko besteht, dass die Patien-
ten durch z.B. Fehldiagnosen oder Fehlbehandlung doch vorzeitig sterben). Risiken dieser
Art sollten unbedingt mehrfach in fachlichen Reviews, ggf. auch mit Experten der Anwen-
dungsdomäne, diskutiert werden. Alle Argumente für die Tolerierung des Risikos sowie die
Begründung sollten unbedingt schriftlich niedergelegt und der Projektdokumentation beige-
fügt werden (-> Produkthaftung).
m) Siehe Folien zur Vorlesung.
n) Eine Beispiel-FMEA zur Aktivität Röntgenbild dem Kommunikationsprotokoll anhängen.
 Übung und Selbstkontrolle zu Software Engineering (SEA)
Prof. Dr.-Ing. Stefan Kreiser

Fehlermöglichkeit: fehlerhafte Ergebniszuordnung

Effekt / Gefahr: Röntgenbild wird anderem Patienten zugewiesen / falsch zugeordnetes
Röntgenbild wird nicht erkannt und führt zu einer Fehldiagnose und in der Konsequenz zu
erneutem Röntgen (erhöhte Strahlenbelastung) oder zu unpassender Therapie.
Ursache: Röntgenbild wird einem falschen Konsultationsprotokoll zugeordnet.
Ziel: Gesundheit des Patienten
initiales Risiko: A=2, S=5, E=3, RPZ=30, Kat= ALARP
Milderungsmaßnahme: nach Übernahme der Röntgenparameter aus dem Konsultationspro-
tokoll (manuell oder automatisch) bleibt das Konsultationsprotokoll solange offen und 1:1
dem aktiven Röntgengerät zugeordnet, bis das Röntgenergebnis dem Konsultationsproto-
koll beigelegt ist (manuell oder automatisch).
Restrisiko: A=1, S=5, E=3, RPZ=15, Kat= tolerabel
o) – r) Siehe Folien zur Vorlesung.

10. Implementierung
a) Siehe Folien zur Vorlesung. Bei Änderung der Schnittstelle eines Softwaremoduls muss zu-
nächst das Softwaredesign in Abstimmung mit dem Projektteam angepasst werden. Da-
raufhin müssen die Updates der Designdokumente freigegeben werden. Erst danach darf
die neue (geänderte) Schnittstelle verwendet werden.
b) – d) Siehe Folien zur Vorlesung.
e) Scriptsprachen besitzen i.d.R. sehr ausgefeilte Textverarbeitungs- und Ein-/ Ausgabefunkti-
onen und erlauben einen einfachen Zugang zu Betriebssystemfunktionen. Somit lassen sich
mit sehr geringem Aufwand Rechenprozesse starten und beenden, standardisierte Daten-
austauschprotokolle des Betriebssystems nutzen (FTP, rsh etc.), Datendateien einlesen, in-
terpretieren und aufbereiten etc.
f) Siehe Folien zur Vorlesung.
g) Siehe Folien zur Vorlesung.
h) Redundante Funktionen binden unnötigen, potenziell fehlerhaften Code in ein Softwaresys-
tem. Zudem wird durch jede Verwendung einer Bibliotheksfunktion die Abhängigkeit des
Softwaresystems von der Bibliothek erhöht. Falls u.U. regelmäßige Updates einer Bibliothek
im Softwaresystem nicht nachgeführt werden (bei hohem Gefährdungsrisiko durch die
Software teuer, aber für den Kunden nutzlos), kann es dazu kommen, dass eine später ge-
wünschte Produktpflege nicht durchgeführt werden kann, da die Produktpflege Kosten er-
zeugen würde, die den Kosten einer Neuentwicklung entsprechen.
i) – l) Siehe Folien zur Vorlesung.
 Übung und Selbstkontrolle zu Software Engineering (SEA)
Prof. Dr.-Ing. Stefan Kreiser

11. Verifizierung, Validierung, systematisches Testen

a) Siehe Folien zur Vorlesung. Eine besondere Herausforderung bei der Validierung einer
Software im Kundenakzeptanztest ist es, den Kunden zum regelmäßigen Einsatz der Soft-
ware in seinem Routineumfeld zu bewegen. Für kritische Softwaresysteme, z.B. medizindi-
agnostische Softwaresysteme, erlaubt der Gesetzgeber oft den Routineeinsatz von behörd-
lich noch nicht zugelassener Software nicht. Ein Kunde, der die Software trotzdem im Rou-
tineeinsatz verwendet macht sich ggf. strafbar und haftbar. Andererseits ist ein aussagefä-
higer Akzeptanztest aus Aufwandsgründen und wegen begrenzter Mengen an Probenmate-
rial meist nicht parallel zum Routinebetrieb mit zugelassenen Softwares möglich.
b) Nein, das Softwaresystem muss nur den bestimmungsgemäßen Gebrauch bei angemesse-
nem Risiko für Mensch, Umwelt und Vermögen ermöglichen.
c) Statischer Test = Review (z.B. Papierdokument), dynamischer Test = Test bei Ausführung
des Prüflings in einer echten oder künstlichen Prüfumgebung.
d) – i) Siehe Folien zur Vorlesung.

short sendFIFO(FIFO* fp, char* msg) {

// Anweisungsblock 1
char *MsgBuf; 1
short *psts, *plen, error = SEND_ERR_ISFULL;
// Entscheidung 2
if (fp->isFull != 1) { FIFO voll
// Entscheidung 3 2
if (++fp->usedCount >= MAXSLOT) { sonst
// Anweisungsblock 4 FIFO füllt sich
fp->isFull = 1; 3
}
// Anweisungsblock 5 sonst 4
plen = &fp->MsgLen[fp->tail];
psts = &fp->status[fp->tail]; 5
MsgBuf = fp->buf[fp->tail];
// Entscheidung 6 Msg zu lang
if ((*plen = strlen(msg)) > SLOTWIDTH) { 6
// Anweisungsblock 7
*plen = SLOTWIDTH; sonst
error = *psts = SEND_ERR_MSG_TRUNCATED;
} else { 8 7
// Anweisungsblock 8
*psts = OK;
error = OK; 9
}
// Anweisungsblock 9
memcpy(MsgBuf, msg, *plen); FIFO war leer
// Entscheidung10 10
if (fp->isEmpty) { sonst 11
// Anweisungsblock 11
fp->isEmpty = 0; 12
fp->head = fp->tail;
}
// Anweisungsblock 12
fp->tail = ++fp->tail % MAXSLOT;
} 13
// Anweisungsblock 13
return(error);
}
 Übung und Selbstkontrolle zu Software Engineering (SEA)
Prof. Dr.-Ing. Stefan Kreiser

j) Zur Verifizierung von sendFIFO ist ein C1-Test ausreichend. Beim C0-Test werden nicht al-
le Kanten durchlaufen.
k) Siehe Folien zur Vorlesung. C4-Test mit 100% Pfadabdeckung für sendFIFO durchführbar,
da keine Schleifen enthalten.
l) – q) Siehe Folien zur Vorlesung.