Klausur

Question 1

Wie hoch ist der Wertschöpfungsanteil von Software im Automobilsektor?

Answer 1

Etwa 30% der Wertschöpfung im Automobilbereich ist der Software zuzuordnen

Question 2

Annual Percentage Value added in automotive industry

Answer 2

2020 - Software 26%, 2025 - 51% Software, 2030 - 69% Software

Question 3

Womit beschäftigt sich Software Engineerings als Teildisziplin der Informatik?

Answer 3

☐ Definition von Richtlinien („Guidelines“) für die Nutzung moderner Software (Falsch)
☐ Entwicklung und Anwendung von Prinzipien, Methoden und Werkzeugen zur Erstellung, zum Betrieb und zur Wartung von einfachen Softwaresystemen (Falsch)
☐ Erarbeitung neuer Programmiersprachen für komplexe Softwaresysteme (Falsch)
☐ Keine der oben genannten Antworten ist korrekt (Richtig)

Question 4

Software Engineering

Answer 4

Software Engineering ist die Teildisziplin der Informatik, welche sich mit der Erarbeitung und Anwendung von Prinzipien, Methoden und
Werkzeugen zur Entwicklung, zur Herstellung, zum Betrieb und zur Wartung von komplexen Softwaresystemen befasst.

Question 5

Wie unterscheidet sich ein „Sprint Review“ von einer „Sprint Retrospektive“ im Scrum?

Answer 5

Die Retrospektive dient der Überprüfung der Team-Zusammenarbeit während der Sprint Review der Inspektion des resultierenden Produktinkrements dient.

Question 6

Wofür eignet sich der Einsatz von Scrum nicht?

Answer 6

1. Zur frühen Lieferung von Features an den Kunden (Falsch)
2. Für die Bearbeitung mehrerer paralleler Softwareprojekte (Richtig)
3. Um einen Rahmen für Teams zu schaffen um adaptiv Lösungen zu entwickeln (Falsch)
4. Um gemeinsam mit dem Kunden eine Priorisierung der Backlog-Items vorzunehmen (Falsch)

Question 7

Wie kann sich das Fehlen eines WIP-Limits (Work in Progress) auf die Durchlaufzeit im Kanban auswirken?

Answer 7

• Es gibt keinen Zusammenhang zwischen einem fehlendem WIP-Limit und der Durchlaufzeit (Falsch)
• Die Durchlaufzeit erhöht sich bis zum Punkt, wo Kanban nicht effizient ist (Richtig)
• Durch ein fehlendes WIP-Limit reduziert sich die Durchlaufzeit (Falsch)
• Es wirkt sich gar nicht aus, da Kanban gar keine WIP-Limits hat (Falsch)

Question 8

Wofür steht SAFe (im Kontext der Vorlesung)?

Answer 8

• SAFe steht für „Scaled Agile Framework“

Question 9

Welcher der genannten Begriffe bezeichnet keine SAFe-Ausbaustufe?

Answer 9

• Essential SAFe
• Full SAFe
• Small Solution SAFe (bezeichnet keine SAFe Audbaustufe)
• Portfolio SAFe

Question 10

SAFe - Scaled Agile Framework

Answer 10

Ausbaustufen
▪ Essential SAFe
▪ Large Solution SAFe
▪ Portfolie SAFe
▪ Full SAFe

Full SAFe beinhaltet alle Stufen
▪ für globale Player (Konzerne) mit
großem Skalierungsbedarf
(Beispiel CARIAD / VW-Konzern)

Question 11

Übersicht der Ausbaustufen SAFe

Answer 11

Ausbaustufe/Ebenen/ Ziele,Eignung für Organisationen
1. Essential/Team- und Programmebene /Geeignet für Unternehmen, die schnell starten wollen.
2. Portfolio/Team-, Programm- und
Portfolioebene/Geeignet für Unternehmen die ihre Programme mit der Unternehmensstrategie abgleichen wollen.
3. Large Solution/Team-, Programm-, Portfolioebene und Large-Solution-Ebene/
Für Unternehmen mit großem Skalierungsbedarf.
4. Full / Team-, Programm-, Portfolioebene
und Large-Solution-Ebene (zzgl. weiterer organisatorischer Rahmen / Business-Ebene)/ Für globale Player mit großem Skalierungsbedarf – sowohl für Projekte als
auch für Mitarbeiter.

Question 12

Welche Aussage ist korrekt für den „Test-First“-Ansatz im TDD (Test-Driven Development)?

Answer 12

• Der „Test-First“-Ansatz schafft ein Testportfolio mit vielen schnellen, automatisierten Entwicklungstests und weniger langsamen, manuellen End to End Tests (Richtig)
• Mit dem Ansatz wird beschrieben, dass Softwaretest erst nach Fertigstellung der vollständigen Implementierung eines Produkts erfolgen sollen (Falsch)
• Mit TDD hat der Test-First-Ansatz nichts zu tun (Falsch)
• Keine der oben genannten Antworten ist korrekt (Falsch)

Question 13

Welches der genannten Aspekte ist kein Nutzen/Ziel des Requirements Engineering?

Answer 13

• Umfang der Leistung und Lieferung definieren (bei Auftragsarbeiten oder Outsourcing) (Falsch)
• Verständlich und präzise beschreiben was das System leisten soll (Falsch)
• Die Spezifikation der konkreten, technischen Softwarelösung ( Richtig)
• Bedingungen und Kriterien für die Abnahme festlegen (Falsch)

Question 14

Nutzen/Ziel des Requirements Engineering

Answer 14

▪ gemeinsame Sprache für Kommunikation von Anforderungen
▪ gegenseitiges Verständnis der Interessen / akzeptierter Anforderungen
▪ verständliche und präzise beschreiben was das System leisten soll
▪ Definition von Umfang der Leistung und Lieferung
(bei Auftragsarbeiten oder Outsourcing)
▪ Bedingungen und Kriterien für die Abnahme einer Leistung / Lieferung

Anforderungen erfüllen verschiedene Funktionen
▪ Basis für einen Vertrag zur Lieferung von Software / Softwareprodukten
▪ Ausgangspunkt der Entwicklung von Komponenten / Produkten

Question 15

Welche semantische Relation charakterisiert die Beziehung zwischen „System Requirements“ (Systemanforderungen) und „System Architecture“ (Systemarchitektur)?

Answer 15

„realized by“: d.h. die Systemarchitektur wird durch die Systemanforderungen realisiert

Question 16

Nennen Sie vier Qualitätskriterien an „gute“ Anforderungen („Anforderungen an Anforderungen“).

Answer 16

Anforderungen sollen
▪ verständlich sein aus Sicht des Anwenderkreises und oder Entwickler:innen
▪ möglichst eindeutig sein (genau eine Interpretation besitzen)
▪ widerspruchsfrei sein (Konsistenz)
▪ minimal sein (Überspezifizierung vermeiden)
▪ überprüfbar und umsetzbar sein
▪ Anforderungen sollen Entwurf und konkrete Implementierung nicht
unnötig vorwegnehmen bzw. einschränken
→einige Kriterien qualitativ hochwertiger Anforderungen gelten nicht für Stakeholder Requirements (z.B. Quantifizierbar- und Messbarkeit

Question 17

Welche der genannten Anforderungsarten gehören nicht zu den nicht-funktionalen Anforderungen?

Answer 17

• Anforderungen an Speicher- und Laufzeiteffizienz (ist nicht funktionale)
• Anforderungen zur Beschreibung der Funktionalität aus Sicht des Anwenders - FUNKTIONALE
• Anforderungen in Hinblick auf die Benutzbarkeit des Systems („Usability“) (ist nicht funktionale)
• Anforderungen mit einer Festlegung der zu verwendenden Technologie (ist nicht funktionale)

Question 18

Welche der genannten Aussagen ist nicht korrekt bezüglich Mängel an Anforderungen?

Answer 18

• Nutzung von Generalisierungen (alle, immer, stets) ist zielführend bei der Anforderungsdefinition (ist nicht korrekt, richtige Antwort)
• Füllwörter (etc., bzw., auch, z.B.) sollten in Anforderungen vermieden werden (Ist Mangel)
• Weak Words (schnell, einfach, effizient, wartbar) sind zu vermeiden (Ist Mangel)
• Nicht testbare Anforderungen, z.B. „Das Gerät soll gut aussehen“, sollten vermieden werden (Ist Mangel)

Question 19

Welches der genannten Aspekte/Themen ist kein Bestandteil von „Modeling Guidelines“?

Answer 19

• Festlegung einer Methodik (ist Bestandteil von MG)
• Handhabung von Anforderungen (ist Bestandteil von MG)
• Namenskonvention („Naming Convention“) (ist Bestandteil von MG)
• Beschreibung der Rolle des Modellierers und dessen Verantwortlichkeiten (ist kein Bestandteil von MG)

Question 20

Welche der unten genannten Aussagen trifft nicht auf den Begriff „Viewpoint“ zu?

Answer 20

• Ein Viewpoint ist gleichbedeuten mit einem Diagramm (richtige Antwort)
• Ein Viewpoint kann als „Standpunkt“ bzw. Ausblickspunkt verstanden werden um auf eine Softwarearchitektur zu blicken (ist Viewpoint)
• Der Viewpoint ist vergleichbar mit dem Metamodell eines UML/ SysML Diagramms (Ist Viewpoint)
• Viewpoints dienen der Spezifikation von Views (Ist Viewpoint)

Question 21

Welche der Aussagen beschreibt den Begriff Whitebox-Modell?

Answer 21

• Das Whitebox-Modell ist eine Annahme, die die innere Struktur und die Wirkzusammenhänge innerhalb einer Systemgrenze als unbekannt voraussetzt (falsch)
• Ein Whitebox-Modell setzt voraus, dass ein System innerhalb seiner Systemgrenze bekannt ist (richtig)
• Bei der Annahme eines White-Box Modells wird vorausgesetzt, dass die Struktur eines Systems zwar bekannt ist, aber nicht die funktionalen Wirkzusammenhänge (funktionale Architektur unbekannt) (falsch)
• Keine der oben genannten Antworten ist korrekt (falsch)

Question 22

Welches der genannten Diagrammtypen ist nicht Bestandteil der UML-Spezifikation?

Answer 22

• Requirement Diagram (richtig, ist nicht in UML)
• Use Case Diagram
• Object Diagram
• Package Diagram

Question 23

Welche der genannten Methoden wird nicht für ein „Product Line Variability Model“ genutzt?

Answer 23

• Orthogonal Variability Model (OVM) - wird genutzt
• Decision Model - wird genutzt
• Feasibility Model - wird nicht genutzt
• Feature Model - wird genutzt

Question 24

Welches der genannten Prozessschritte gehört nicht zum ISTQB-Prozess (International Software Testing Qualifications Board)?

Answer 24

• Domain Design - gehört nicht zum ISTQB-Prozess
• Auswertung und Bericht - gehört zum ISTQB-Prozess
• Testplanung - gehört zum ISTQB-Prozess
• Testspezfikation - gehört zum ISTQB-Prozess

Question 25

Welche Aussage bezieht sich auf den Begriff HiL (Hardware-in-the-Loop)?

Answer 25

• Test und Validierung der Funktion in einer virtuellen Umgebung während früher Entwicklungsphasen - falsch
• Kombination eines Simulationsmodells eines Systems mit tatsächlicher physischer Hardware - richtig
• Es wird ermöglicht ein reales System vollständig auf eine Darstellung (Modell) abzubilden - falsch
• Test und Validierung von zielspezifischem Quellcode auf einer Ersatzplattform zu Testzwecken - falsch

Question 26

Nennen und beschreiben Sie drei Arten von „X-in-the-Loop“ Tests (aus der VL).

Answer 26

Hardware-in-the-Loop (HiL)
▪ Integration der Software mit echter Hardwareumgebung (z.B.
Sensoren, Aktuatoren und Steuergeräte = Testumgebung), um im
Anwendungskontext einer realistischeren Umgebung zu testen

Software-in-the-Loop (SiL)
▪ Test und Validierung der Funktion zielspezifischen Quellcodes
auf virtueller Ersatzplattform bzw. in Modell (Testumgebung)

Model-in-the-Loop (MiL)
▪ Test und Validierung der Funktion eines ausführbaren Modells
(Funktionsmodell, Regelalgorithmus) in virtueller Umgebung

Question 27

Nennen Sie vier Herausforderungen an Software Engineering im Anwendungskontext (aus der VL)

Answer 27

Hohe Vernetzung mit externen Systemen
▪ Dynamisches Umfeld während Laufzeit
▪ Co-Entwicklung Software und externe
Systeme mit verschiedenen Reifegraden
▪ Anforderungen im nicht-funktionalen
Bereich („Qualitätsanforderungen“)
▪ Hohe Notwendigkeit für frühes Testen
▪ Hohe Anforderungen an funktionale
Sicherheit bei Vielzahl Abhängigkeiten

Zeitdruck und die Notwendigkeit, Software schnell zu entwickeln, sind in der Tat eine häufige Herausforderung im Software Engineering, insbesondere bei komplexen Systemen, in denen die Entwicklung mehr Zeit in Anspruch nehmen kann als erwartet.

Die hohe Notwendigkeit für frühes Testen ist ebenfalls eine bedeutende Herausforderung. Die frühzeitige Identifizierung von Fehlern kann dazu beitragen, Probleme in späteren Phasen des Entwicklungsprozesses zu vermeiden oder zu reduzieren.

Die Anforderungen an funktionale Sicherheit sind ebenfalls relevant, insbesondere in sicherheitskritischen Anwendungen oder in Branchen wie der Luft- und Raumfahrt, der Medizin oder der Automobilindustrie, in denen Fehler katastrophale Folgen haben können.

Die hohe Vernetzung mit externen Systemen stellt eine weitere Herausforderung dar, da sie zusätzliche Komplexität und potenzielle Fehlerquellen mit sich bringt. Die Interoperabilität und Sicherheit zwischen verschiedenen Systemen müssen sorgfältig berücksichtigt werden, um reibungslose Abläufe zu gewährleisten.

Question 28

Nennen Sie vier Nachteile des Wasserfall-Modells.

Answer 28

1. Unflexibles Vorgehen in Hinblick auf Änderungen bei Kundenanforderungen: Das Wasserfallmodell ist linear und erfordert, dass alle Anforderungen frühzeitig und vollständig spezifiziert werden. Änderungen können daher schwierig und kostspielig sein, da das Modell nicht gut auf Anpassungen während des Entwicklungsprozesses ausgelegt ist.
2. Phasen müssen in voller Breite und vollständig abgeschlossen werden: Jede Phase des Wasserfall-Modells muss vollständig abgeschlossen sein, bevor mit der nächsten Phase begonnen werden kann. Dies kann zu Verzögerungen führen, insbesondere wenn Probleme oder Änderungen während einer Phase auftreten.
3. Phasen müssen sequenziell durchlaufen werden, keine Möglichkeit für Parallelisierung: Im Wasserfall-Modell gibt es keine Möglichkeit, Phasen parallel durchzuführen. Dies kann zu längeren Entwicklungszeiten führen, insbesondere bei großen Projekten, da jede Phase nacheinander durchlaufen werden muss.
4. Produzierte Dokumentation wird als treibendes Moment betrachtet, Dokumente werden ggf. als wichtiger wahrgenommen als die tatsächliche Implementierung: Im Wasserfall-Modell wird oft viel Wert auf die Dokumentation gelegt, was zu einem Fokus auf die Erstellung von Dokumenten führen kann, anstatt sich auf die tatsächliche Implementierung zu konzentrieren. Dies kann dazu führen, dass die Entwicklung langsamer vorangeht und dass die tatsächlichen Bedürfnisse des Kunden nicht ausreichend berücksichtigt werden.

Question 29

Woher stammt die Bezeichnung bzw. der Name „Spiralmodell“?

Answer 29

Das Spiralmodell verdankt seinen Namen seinem iterativen Charakter, der durch eine spiralartige Darstellung des Entwicklungsprozesses veranschaulicht wird. Es wurde von Barry Boehm 1986 in seinem Artikel eingeführt. Die Spiralform symbolisiert die sich wiederholenden Schritte, die während des Softwareentwicklungsprozesses durchlaufen werden, wobei jede Umdrehung der Spirale für eine Iteration steht, bei der das Produkt weiterentwickelt und verbessert wird.

Question 30

Nennen Sie die vier Arten von Prototypen nach dem Protypen-Vorgehensmodell.

Answer 30

Kategorisierung der Arten von verschiedenen Prototypen
Bezug zu Reifegrad und Zweck
▪ Demonstrationsprototyp
▪ Prototyp im eigentlichen Sinne
▪ Labormuster
▪ Pilotsystem
Bezug zu Softwarearchitektur
▪ Horizontaler Prototyp
▪ Vertikaler Prototyp

Question 31

Nennen und beschreiben Sie die drei Merkmale mit dem ein Modell gekennzeichnet ist

Answer 31

1. Abstraktion: Ein Modell ist eine vereinfachte Darstellung eines Systems, eines Prozesses oder eines Phänomens in der realen Welt. Es entfernt unwichtige Details und konzentriert sich auf diejenigen Aspekte, die für das Verständnis oder die Analyse relevant sind. Durch Abstraktion werden komplexe Zusammenhänge vereinfacht und leichter erfassbar gemacht.
2. Vereinfachung: Ein Modell reduziert die Komplexität des realen Systems, indem es nur die wichtigsten Eigenschaften und Interaktionen darstellt. Diese Vereinfachung ermöglicht es, das System besser zu verstehen, Vorhersagen zu treffen und Entscheidungen zu treffen, ohne von unwesentlichen Details überwältigt zu werden.
3. Repräsentation: Ein Modell stellt das reale System symbolisch oder formal dar, sei es durch Grafiken, mathematische Gleichungen, Simulationen oder andere Darstellungsformen. Die Repräsentation eines Modells sollte den wesentlichen Charakter des Systems widerspiegeln und es ermöglichen, Informationen darüber zu gewinnen oder Schlussfolgerungen zu ziehen.

Zusammenfassend kann man sagen, dass Modelle abstrahieren, vereinfachen und das Wesentliche eines Systems repräsentieren, um dessen Verhalten oder Eigenschaften zu verstehen, zu analysieren oder vorherzusagen.

Question 32

Sie entwickeln mit Ihrem Team bereits einige Zeit ein Softwaresystem im Kundenauftrag und sind kurz vor der Fertigstellung. Der Kunde möchte das System zur Verwaltung von Daten in seinem Unternehmen
einsetzen. Das System soll nach Auslieferung beim Kunden vor Ort auf einem Server betrieben werden. Demnächst finden erste Tests beim Kunden vor Ort statt. Sie nutzen hierfür reale Datenbestände vom
Kunden, die er Ihnen zur Verfügung stellt, da er erwartet, dass Sie prüfen, ob das System die Kundenanforderungen erfüllen kann. Entspricht der aktuelle Entwicklungsstand Ihrer Software TRL 3-4 oder
TRL 6-8? Führen Sie durch das Testen eine Verifikation oder Validierung durch?

Answer 32

Basierend auf der Beschreibung Ihres Szenarios scheint der aktuelle Entwicklungsstand Ihrer Software eher TRL 6-8 (Technology Readiness Level) zu entsprechen.

Die Gründe dafür sind:

Sie sind kurz vor der Fertigstellung des Softwaresystems. Dies deutet darauf hin, dass das System bereits weitgehend entwickelt ist und sich in einem fortgeschrittenen Entwicklungsstadium befindet.

Sie führen erste Tests beim Kunden vor Ort durch, was darauf hindeutet, dass das System bereits in einer realen Umgebung implementiert und getestet wird.

Sie verwenden reale Datenbestände vom Kunden für Ihre Tests, um zu überprüfen, ob das System die Kundenanforderungen erfüllen kann. Dies zeigt, dass das System in einem fortgeschrittenen Stadium der Entwicklung steht und bereits an die spezifischen Bedürfnisse des Kunden angepasst wurde.

In Bezug auf die Art der Tests führen Sie sowohl Verifikation als auch Validierung durch:

Verifikation: Durch die Tests überprüfen Sie, ob das Softwaresystem gemäß den spezifizierten Anforderungen entwickelt wurde. Dies beinhaltet die Bestätigung, dass das System bestimmte Funktionen ordnungsgemäß ausführt und den erwarteten Output liefert.

Validierung: Durch die Tests stellen Sie sicher, dass das Softwaresystem den tatsächlichen Anforderungen und Bedürfnissen des Kunden entspricht und in der Lage ist, die gewünschten Aufgaben in der realen Umgebung erfolgreich zu erfüllen.

Da Sie Tests mit realen Datenbeständen des Kunden durchführen, um die Erfüllung der Kundenanforderungen zu überprüfen, handelt es sich um eine Art von Validierungstest. Sie bestätigen damit, dass das System die beabsichtigten Zwecke in der realen Umgebung erfüllen kann.

Question 33

Sie arbeiten als Softwareentwickler in einem Unternehmen, dass eine Vielzahl Kunden mit Varianten eines bestimmten Produkts beliefert. Die Varianten werden immer dadurch ausgeprägt, dass es einen erfahrenen Kollegen gibt, der anhand einer Konfigurationsdatei eine große Zahl an Softwareparametern manuell anpasst. Die fertige Software wird aus diesen Konfigurationsdateien automatisiert erzeugt. In einigen Jahren verlässt der erfahrene Kollege altersbedingt das Unternehmen. Sie werden daher von der Geschäftsführung gebeten sein Konfigurationswissen in Regeln zur Wiederverwendung der bestehenden Software abzubilden. Welcher Wiederverwendungsansatz wird aktuell eingesetzt? Welche beiden Wiederverwendungsansätze
sind geeignet, um nach Ausscheiden des Kollegen weiterhin Produkte ausliefern zu können?

Question 34

Relationen im Requirement Diagram

Answer 34

deriveReqt - Requirement to Requirement
refine - Use Case to Requirement
verify - Test Case to Requirement

Question 35

Mit welcher Relation werden technische Anforderungen aus Stakeholder-Anforderungen abgeleitet?

Answer 35

Satisfy

Question 36

Was bedeutet die Angabe 1..* in dem oben dargestellten Use Case Diagram?

Answer 36

Die Angabe “1..” in einem Use Case Diagramm ist eine Multiplizität. Sie beschreiben die Anzahl an Elementen, die zu jeder Zeit in jeder Situation vorhanden sein müssen.

Question 37

Modelelement „Actor“

Answer 37

Akteur kann eine Person, eine Gruppe von Personen, eine andere Softwareanwendung oder ein externes System sein, das mit dem betrachteten System kommuniziert oder mit ihm interagiert, um bestimmte Ziele zu erreichen.

Question 38

Use Case

Answer 38

Ein Use Case beschreibt typischerweise eine bestimmte Funktionalität oder ein bestimmtes Verhalten des Systems aus der Sicht eines Benutzers.

Question 39

System Boundary

Answer 39

Trennt das System gegen die Umwelt ab. Umschließt die Use Cases. Der Name der Systemgrenze ist ein Nomen, zeigt die späteren Schnittstellen zwischen System und Umwelt.

Question 40

Welchen wesentlichen Unterschied gibt es zwischen der «include» und «extend» Relation?

Answer 40

“Include” bindet einen Use Case in einen anderen ein, um Wiederverwendung darzustellen und wiederholte Modellierung zu vermeiden, wobei der eingebundene Use Case immer mit dem übergeordneten Use Case ausgeführt wird, während “Extend” optional eine zusätzliche Funktionalität unter Bedingungen in einen Use Case einbindet.

Geld abheben include Pin eingeben

Pin eingeben Extension Point ( Pin Eingabe fehlgeschlagen) extend Karte einziehen

Ein Extension Point ist ein spezifischer Punkt innerhalb eines Use Cases, an dem eine Erweiterung stattfinden kann, und dient als Auslöser für die Ausführung eines erweiternden Use Cases.

Question 41

Voraussetzungen für Model-Based Engineering (Bild Dreieck: Sprache/ IT - Tool, Prozess)

Answer 41

Voraussetzung zur Erstellung digitaler
Modellen im Model-Based Engineering
▪ geeignete Sprache zur formalisierten
Beschreibung von Modellen
▪ zweckmäßige Methode bzw. einen
Prozess zur Modellierung
▪ angepasstes IT-Werkzeug für Pflege /
Generierung von Modellinformationen

Question 42

Priorisierungsmatrix

Answer 42

Quadrant A (Hohes Einfluss, Hohes Konfliktpotenzial): Gebäudetechnikspezialisten und IT-Sicherheitsexperten haben beide einen hohen Einfluss auf das Projekt und könnten aufgrund ihrer spezifischen Anforderungen potenziell höheres Konfliktpotenzial verursachen.

Quadrant B (Hohes Einfluss, Niedriges Konfliktpotenzial): Endbenutzer haben einen hohen Einfluss auf das Projekt, aber ihr Konfliktpotenzial wird als niedrig betrachtet.

Quadrant C (Niedriges Einfluss, Hohes Konfliktpotenzial): Energieeffizienzbeauftragte und Facility-Manager haben möglicherweise nicht den höchsten Einfluss, aber ihre spezifischen Anforderungen könnten dennoch zu Konflikten führen, daher befinden sie sich in diesem Quadranten.

Quadrant D (Niedriges Einfluss, Niedriges Konfliktpotenzial): Da Sie keine spezifischen Stakeholder für diesen Quadranten genannt haben, bleibt er unbesetzt.

Question 43

Nicht-funktionale Anforderungen an die Firmware/Betriebssystem der Room Control Unit

Answer 43

Leistungseffizienz:
Die Firmware muss ressourceneffizient arbeiten und sicherstellen, dass die
Raumkontrolleinheit mit minimaler Energieverbrauch betrieben wird.
*
2. Benutzerfreundlichkeit:
Die Benutzerschnittstelle der Firmware muss intuitiv und benutzerfreundlich gestaltet sein,
um eine einfache Bedienung durch Endbenutzer zu gewährleisten.
*
3. Sicherheit und Datenschutz:
Das Betriebssystem muss höchste Sicherheitsstandards einhalten, um den Datenschutz der
Benutzer zu gewährleisten, insbesondere bei der Erfassung und Speicherung von sensiblen
Gesundheitsdaten.
*
4. Zuverlässigkeit:
Die Firmware muss hochzuverlässig sein und sicherstellen, dass die Raumkontrolleinheit
kontinuierlich und stabil arbeitet, um Ausfälle und Unterbrechungen zu minimieren.
*
5. Wartbarkeit:
Das Betriebssystem muss leicht wartbar sein, um Softwareupdates und Fehlerbehebungen
effizient durchführen zu können

Question 44

Constraints

Answer 44

“Constraints” sind Beschränkungen oder Einschränkungen, die die Möglichkeiten oder Handlungsfähigkeit in einem gegebenen Kontext begrenzen. Sie können verschiedene Formen annehmen, einschließlich finanzieller Einschränkungen, zeitlicher Zwänge, Ressourcenknappheit oder technischer Begrenzungen.
6. Hardwarekompatibilität:
* Constraint-Kategorie: Ressourcen-Constraint
Die Firmware muss mit den vorhandenen Hardwarekomponenten der Raumkontrolleinheit
kompatibel sein.
*
7. Minimale Reaktionszeit für Benachrichtigungen:
* Constraint-Kategorie: Leistungs-Constraint
Die Firmware muss sicherstellen, dass Benachrichtigungen bei länger geöffneten Fenstern mit
minimaler Verzögerung auf dem Handy der Benutzer angezeigt werden.
*
8. Betriebstemperaturbereich:
* Constraint-Kategorie: Umwelt-Constraint
Die Raumkontrolleinheit muss in einem definierten Temperaturbereich betrieben werden, um
eine optimale Leistung zu gewährleisten.
*
9. Begrenzte Speicherkapazität:
* Constraint-Kategorie: Ressourcen-Constraint
Die Firmware muss sich darauf beschränken, die historischen Daten aufgrund begrenzter
Speicherkapazität für genau 12 Monate zu speichern.
*
10. Authentifizierungsverfahren:
* Constraint-Kategorie: Sicherheits-Constraint
Der Zugriff auf abgespeicherte Benutzerdaten muss durch ein sicheres
Authentifizierungsverfahren eingeschränkt werden

Question 45

Definieren Sie kurz in eigenen Worten funktionale Anforderung, Qualitätsanforderung und Randbedingung

Answer 45

Funktionale Anforderungen: spezifische und messbare Beschreibungen von Funktionen oder
Dienstleistungen, die ein Softwareprodukt bereitstellen muss. Sie definieren, welche Aufgaben das
System erfüllen soll, welche Funktionen es haben muss und wie es auf bestimmte Eingaben
reagieren sollte.
Qualitätsanforderungen (auch nicht-funktionale Anforderungen genannt): betreffen Eigenschaften
der Software, die nicht unmittelbar mit spezifischen Funktionalitäten verbunden sind. Dazu gehören
Leistungsmerkmale, Sicherheit, Benutzerfreundlichkeit und Zuverlässigkeit. Diese Anforderungen
legen die Standards und Kriterien fest, anhand derer die Leistung und Qualität des Systems bewertet
werden.
Randbedingungen (Constraints): Randbedingungen setzen Einschränkungen oder Vorgaben für die
Entwicklung und den Betrieb der Software. Diese können technischer, finanzieller oder zeitlicher
Natur sein und beeinflussen die Möglichkeiten und Entscheidungen im Entwicklungsprozess.
Constraints legen die Rahmenbedingungen fest, innerhalb derer die Software entworfen und
implementiert werden muss.

Question 46

Checklisten zur Prüfung der Einhaltung von Best Practice Regeln:

Answer 46

während der Überprüfung werden Anforderungen anhand (mindestens) definierter Regeln untersucht:
▪ Anforderungen sind nicht mit Schlüsselwörtern formuliert
▪ eine Anforderung pro Satz
▪ möglichst keine passive Formulierung
▪ Vermeidung von Weak Words
▪ Beschreibung rechtlicher Haftung:
▪ Zwingend – muss
▪ Empfehlung – sollte
▪ Wunsch – wird

Rule ✓ x
1. The requirement is documented in one
sentence.
2. The requirement is not formulated in keywords.
3. The requirement is formulated in an active form.
4. The requirement use no “Weak-Words”.
5. Numbers in a requirement are associated with a unit
(e.g mm or kg).
6. Abbreviations in a requirement are defined
in a glossary.
7. A requirement has a legal bindingness.

Question 47

In der Vorlesung haben sie die Betrachtungsweisen Blackbox, Greybox und Whitebox kennengelernt. Informieren Sie sich über die Merkmale dieser und überlegen Sie sich Beispiele für diese drei Betrachtungsweisen anhand der Analyse eines Systems bzw. einer Software

Answer 47

Die Betrachtungsweisen Blackbox, Greybox und Whitebox beziehen sich auf unterschiedliche
Herangehensweisen bei der Analyse von Systemen oder Software. Hier sind ihre Merkmale und
Beispiele:
1. Blackbox-Analyse:
Merkmale: Bei der Blackbox-Analyse betrachtet man das System von außen, ohne Kenntnisse über
die interne Funktionsweise zu haben. Man konzentriert sich auf die Eingaben und erwarteten
Ausgaben.
Beispiel: Wenn man z.B. einen Webbrowser verwendet, kennt man die Funktionsweise des Codes
nicht. Man gibt jedoch eine URL ein (Eingabe/Input) und erhält eine angezeigte Webseite
(Ausgabe/Output), ohne die internen Abläufe verstehen zu müssen.
2. Greybox-Analyse:
Merkmale: Die Greybox-Analyse kombiniert Elemente von Blackbox- und Whitebox-Methoden.
Softwaretechnik Seite 3
Merkmale: Die Greybox-Analyse kombiniert Elemente von Blackbox- und Whitebox-Methoden.
Der/Die Analyst:in hat teilweisen Zugriff auf interne Informationen, aber nicht vollständig.
Beispiel: Bei der Überprüfung der Sicherheit eines Softwareprodukts könnte u.a. ein
Sicherheitsexperte einige Kenntnisse über die interne Struktur haben, aber nicht den gesamten
Quellcode kennen.
3. Whitebox-Analyse:
Merkmale: Bei der Whitebox-Analyse hat der/die Analyst:in vollständigen Zugriff auf interne
Strukturen und den Quellcode des Systems. Diese Methode ermöglicht eine detaillierte Inspektion.
Beispiel: Ein Entwickler, der den Quellcode einer Software liest und analysiert, um mögliche Fehler
zu finden oder die Effizienz zu verbessern, führt eine Whitebox-Analyse durch.

Question 48

Blackbox/Greybox/Whitebox

Answer 48

Blackbox: Ein Ansatz, bei dem das Innere eines Systems nicht betrachtet wird, sondern nur seine Ein- und Ausgänge. Es wird angenommen, dass das System als “Schwarzkasten” funktioniert.

Greybox: Ein Ansatz, bei dem einige Informationen über das Innere eines Systems vorhanden sind, aber nicht alle. Es liegt zwischen dem Blackbox- und dem Whitebox-Ansatz.

Whitebox: Ein Ansatz, bei dem das Innere eines Systems vollständig bekannt ist und analysiert wird. Es ermöglicht ein detailliertes Verständnis der Funktionsweise des Systems.