VL1 + 1 Übung Flashcards

1
Q

Produktentstehungsprozess (PEP)

A

Der Produktentstehungsprozess ist eine systematische Abfolge von Schritten und Aktivitäten, die zur Produktidee, Planung, Konzeption, Entwicklung, Herstellung und Wartung sowie dem Betriebsende eines neuen oder verbesserten Produkts führen. Dieser Prozess umfasst alle Lebensphasen eines Produkts und variiert je nach Branche.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Software Engineering

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

alle Lebensphasen eines Produkts
(картинка с 7 фазами проекта)

A

Produktidee, Produktplanung, Produktkonzept, Entwicklung, Herstellung, Betrieb/Wartung, Betriebs-/Lebenssende

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Softwaresystem

A

Softwaresystem ist ein System von miteinander kommunizierenden Komponenten auf Basis von Software und Teil eines Computersystems. Ein Softwaresystem besteht aus einer Reihe separater Programme, Konfigurationsdateien, System- und Benutzerdokumentation.
Merkmale von Softwaresystemen:
-kann vereinfacht in Systemsoftware, Betriebssysteme, Anwendungssoftware sowie weiterer Software kategorisiert werden (Могут быть упрощены и категоризированы как системное программное обеспечение)
-beschreibt Sicht eines Entwicklers auf Dekomposition einer Software mit Prinzipien des Software Engineering

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Bedeutung von Software Engineering für softwareintensive Systeme

A

Fehler in reinen Softwareprodukten häufig nicht sicherheitskritisch, z.B.
▪ Fahrplanapps/-auskünfte
▪ fehlerhafte Webseiten/-apps

Betrachtung softwareintensiver Systeme ggf. sicherheitskritisch, z.B.
▪ Flugzeuglandung LH 2904
▪ Selbstzerstörung Ariane 5

Softwareanteil in softwareintensiven Systemen (z.B. für Strahlentherapie, Fahrassistenz) birgt Gefährdungspotential ohne Software Engineering

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

softwareintensives System

A

Ein softwareintensives System ist ein System aus Soft- und Hardware, in der Software die bedeutende und essentielle Rolle für Betrieb, Funktionalität sowie Leistung spielt.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Case Trends

A

-Connected (Vernetzung des Fahrzeugs mit weiteren Fahrzeugen und Infrastruktur) –> Softwareanteil durch neue Dienstleistungen
-Autonomes (Autonomes Fahren und hochautomatisierte Fahrfunktionen) –> Softwareanteil steigt durch Fahrassistenz
-Shared (Mobilität als Dienstleistung, statt besitzt von Fahrzeugen/Hardware) —> Stellenwert der Hardware (z.B Design) sinkt
-Electric (Elektrische Fahrzeugantriebe und Reduktion der Antriebsstrangkomplexität) → mechanische Komplexität steigt kaum noch

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Annual Percentage Value Added in Automotive Industry

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Lines of Code als Softwaremetrik

A

▪ häufige Methode zur Messung der Komplexität
▪ reine Anzahl der Codezeilen keine genaue
Darstellung der tatsächlichen Komplexität

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Weitere Faktoren für Komplexität

A

▪ Code-Struktur, Algorithmen, Abhängigkeiten, Anzahl der Funktionen und Variablen
▪ Verschachtelung von Kontrollstrukturen, Wartbarkeit, Dokumentation, Designprinzipien
▪ statische Codeanalyse ermöglicht tiefgehende Untersuchung der Softwarestruktur

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Dimensionen der Komplexität (измерения сложности)

A

Durch Implementierung bedingt: Die Komplexität der Funktionen, die Komplexität der Datenstrukturen und die Komplexität der Algorithmen hängen davon ab, wie sie in das System eingebunden sind.
Durch Anwendungskontext bedingt: Die Komplexität des zeitabhängigen Verhaltens, die Komplexität der Systemumgebung und die Komplexität der Benutzerinteraktion hängen vom konkreten Einsatzgebiet und den Anforderungen ab.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Komplexität

A

Komplexität bezeichnet die Herausforderung, Software oder Softwaresysteme zu verstehen oder zu steuern, aufgrund der vielen verschiedenen Elemente im System, ihrer unterschiedlichen Wechselwirkungen und des oft unvorhersehbaren Verhaltens.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Systemumgebung

A

Die Systemumgebung ist die Gesamtheit aller externen Faktoren, die ein Softwaresystem oder softwareintensives System umgeben und das
Verhalten beeinflussen können. Die Berücksichtigung der
Systemumgebung ist für nutzergerechte Entwicklung, Herstellung, Wartung sowie den effizienten Betrieb von Software notwendig.
Beispiele externe Faktoren
▪ Hardware (z.B. Computerhardware) und Software (z.B. Betriebssystem)
▪ Menschen (Human Factors später vertieft) und organisatorische Aspekte
▪ Daten und Netzwerke, insbesondere bei hochvernetzen Systemen

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Herausforderungen bei hochvernetzten Systemen

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

System

A

Ein System ist eine Anordnung von Elementen, die gemeinsam ein Verhalten besitzen, die die Bestandteile nicht aufweisen (Emergenz). Es ist durch seine Systemgrenze von der Systemumgebung abgegrenzt, erfüllt einen definierten Zweck und besitzt eine vorgegebene Funktion.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Funktionales Konzept

A

Der Zweck des Systems wird von außen bestimmt.
Zweck des Systems: Wird von außen bestimmt, basierend darauf, wie es funktioniert und welche Zustände es hat.
Funktion des Systems: Entsteht durch Interaktionen mit der Umgebung (z. B. andere Systeme, Benutzer, Hardware).
Grenzen des Systems: Der Zweck und die Funktion werden an den Grenzen des Systems festgelegt, durch die Schnittstellen und Daten (Ein- und Ausgaben).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Strukturelles Konzept

A

Strukturelle Zusammensetzung des Systems
▪ Anordnung von Elementen und deren Relationen
▪ Elemente betrachtet als Blackbox sofern Zerlegung ausreichend für Verständnis des Systems / Zwecks

18
Q

Hierarchisches Konzept

A

Tieferes Systemverständnis durch Bildung von Teilsysteme
▪ Elemente können als Teilsysteme verstanden werden
▪ Betrachtung der Teilsysteme als Whitebox und Zerlegung
▪ Rekursive Anwendung des hierarchischen Konzepts
möglich (Systemanalyse)

19
Q

Holistisches Konzept

A

Entstehung von Emergenz
▪ Betrachtung des Systems als Ganzes und nicht nur als
Summe der Elemente
▪ Systemeigenschaften, über die die Elemente einzeln
betrachtet nicht verfügen
▪ Beispiel: Taschenlampe (Batterie und Lampe leuchten
einzeln betrachtet nicht)

20
Q

Emergenz

A

Emergenz ist das Phänomen, bei dem komplexe Systeme Eigenschaften, Muster oder Verhalten aufweisen, die auf der Ebenen ihrer Bestandteile nicht vorhanden oder nicht unmittelbar vorhersehbar sind. Diese Systemeigenschaften entstehen durch die Wechselwirkungen der einzelnen Elemente in einem System. (пример автомобиль)

21
Q

Systems Engineering

A

Systems Engineering ist ein transdisziplinärer und integrativer Ansatz, der sicherstellt, dass alle Teile eines Systems richtig zusammenarbeiten, um die gewünschten Ziele zu erreichen. Es bezieht sich auf die ganzheitliche Betrachtung eines Systems und berücksichtigt dabei alle technischen, wissenschaftlichen und organisatorischen Aspekte, um das System effizient zu entwickeln, zu betreiben und zu warten.

22
Q

Verifikation und Validierung

A

Verifikation und Validierung:

Verifikation bezieht sich auf den Prozess, durch den überprüft wird, ob das System spezifizierte Anforderungen erfüllt. Dies könnte beispielsweise bedeuten, dass die Softwarefunktionen gemäß den definierten Spezifikationen arbeiten. „Bauen wir das Produkt richtig?“
Validierung hingegen bezieht sich darauf, ob das entwickelte System tatsächlich die Bedürfnisse und Anforderungen des Kunden erfüllt. Es bestätigt, dass das entwickelte System das Richtige tut.„Bauen wir das richtige Produkt?“

23
Q

Was wird unter einem Softwareprodukt verstanden und grenzen Sie dies zum allgemeinen Begriff Software ab?

A

Ein Softwareprodukt ist das Ergebnis eines Entwicklungsprozesses, das für mehrere Kunden oder den allgemeinen Markt bestimmt ist. Im Gegensatz dazu bezeichnet der Begriff “Software” allgemein jede Art von Software, unabhängig davon, ob sie als Produkt oder Einzelanfertigung entsteht. Der Unterschied liegt darin, dass Softwareprodukte wiederholt verkauft werden, während einmalige Entwicklungen als Projekte bezeichnet werden.

24
Q

Erklären Sie, warum professionelle Softwareentwicklung nicht nur die Programme einschließt, die für Kunden entwickelt werden.

A

Professionelle Softwareentwicklung umfasst nicht nur die Erstellung von Kundensoftware, sondern auch verschiedene Methoden und Prinzipien, um qualitativ hochwertigen und wartbaren Code zu gewährleisten. Da die Entwicklung oft vom Budget, Zeitrahmen und Projektumfang des Kunden abhängt, erfordert sie auch sorgfältige Planung und Projektmanagement, um die gewünschten Ziele effizient zu erreichen.

25
Q

Warum ist es effizienter, Pair Programming zu nutzen, als zwei unabhängige Programmierer?

A

Pair Programming ist effizienter als zwei unabhängige Programmierer, da es die Fehlerrate reduziert und die Qualität des Codes verbessert. Durch die Zusammenarbeit können Probleme schneller erkannt und behoben werden, da beide Programmierer kontinuierlich Code überprüfen und Feedback geben können, was zu robusterem und wartungsfreundlicherem Code führt.

26
Q

Anwendungskontext und Branchen

A

Software ist relevant für Produktentwicklung in allen Branchen. Anwendungsbereiche neben reinen softwarebasierten IT-Produkten z.B. Luftund Raumfahrt, Verteidigung, Medizintechnik und Automobilindustrie. Model-Based Software Engineering als Schlüsselkompetenz für Komplexitätsbeherrschung in Entwicklung von Softwaresystemen und softwareintensiven Systemen → meist Software im Anwendungskontext

27
Q

Systemdenken

A

▪ Systemdenken ist als Prozess und Ansatz zur Problemlösung definiert
▪ Systemische Analyse / Synthese, um in Systemen Wechselwirkungen
zwischen Elementen zu untersuchen
Kernbegriffe:
▪ Systemgrenze / Systemumgebung
▪ Elemente / Wechselwirkungen (Relationen)
▪ Systemeigenschaften / Funktionen
▪ Digitale Modelle / Systemmodell
▪ Blackbox / Greybox / Whitebox

28
Q

Trennung von Problem- und Lösungsraum

A

Problemraum
▪ dient dem Erfassen, Analysieren und Verstehen
des zu lösenden technischen Problems
▪ Anwendungskontext und Zweck definieren
▪ Formulierung lösungsneutraler Anforderungen
Lösungsraum
▪ dient zur Beschreibung und technischen
Darstellung einer Software-/Systemlösung
▪ Fokus liegt auf Software-/Systemfunktionen
▪ Definition logischer und technischen
Komponenten / Module sowie Schnittstellen

29
Q

Funktionale Dekomposition

A

Die funktionale Dekomposition ist ein Prinzip, bei dem diese Funktionen des Systems in kleinere, handhabbare Teilfunktionen zerlegt werden, die unabhängig entwickelt und gewartet werden können.
Angewandte Systemkonzepte:
▪ Funktionales Konzept
▪ Hierarchisches Konzept

30
Q

Modularisierung

A

▪ Gliederung von Elementen von Software / System nach ähnlichen Merkmalen
▪ im Software Engineering ist ähnliches Merkmal meist die Funktionalität:
- Gliederung nach Input / Output-Verhalten
- Gliederung nach funktionalen Schnittstellen
▪ Komplexität wird gekapselt und extern nur über Schnittstellen kommuniziert
Angewandte Systemkonzepte: Funktionales Konzept

31
Q

Strukturierung

A

Strukturierung im Software Engineering ist das Prinzip, Software in logische, funktionale Module zu unterteilen, um Komplexität zu reduzieren und die Wartbarkeit zu verbessern. Jedes Modul hat klare Schnittstellen, die den Austausch von Daten und Funktionen ermöglichen, wodurch das System flexibler und erweiterbar wird.
▪ Angewandte Systemkonzepte
- Strukturelles Konzept
- Holistisches Konzept

32
Q

Kombination einzelner Prinzipien

A

▪ Kombination möglich z.B.
▪ Trennung von Problem- und Lösungsraum
▪ funktionale Dekomposition
▪ Modularisierung & Strukturierung
→ ermöglicht rekursive Spezifikation des Softwaresystems („Zig-Zagging-Approach“)
▪ Kombinationen je nach konkreter Aktivität in Prozessmodellen
▪ „Prinzipien-Baukasten“ als Metamodell für Software Engineering Aktivitäten

33
Q

Methoden

A

Abgeschlossenes Vorgehen zur Anwendung in
spezifischen Situationen. In Software beschreibt es einen Teilalgoritmus. Kann auch als strukturierte Vorgehensweise verstanden werden.

34
Q

3 Gemeinsamkeiten und 3 Unterschiede zwischen Software Engineering und Programmierung

A

Gemeinsamkeiten
1. Ziel der Softwareerstellung: Beide wollen funktionierende Software entwickeln, die den Nutzern passt.
2. Nutzung von Programmiersprachen: Sowohl im Software Engineering als auch in der Programmierung werden Programmiersprachen verwendet, um die Software zu schreiben.
3. Problemlösung: Beide konzentrieren sich darauf, konkrete Probleme zu lösen und passende Lösungen zu erstellen.
Unterschiede:
1. Software Engineering beinhaltet unter Anderem die strukturierte Planung, Analyse, Umsetzung und Abnahme von Software, während Programmierung sich nur mit der Umsetzung beschäftigt.
2. Programmierung kann als Teil des Software Engineerings betrachtet werden, das wiederum eine Disziplin der Informatik ist.
3. Software Engineering bezieht sich oft auf das Entwickeln von großen, komplexen Systemen, die Teamarbeit und Koordination erfordern. Programmierung hingegen wird oft als Einzelaktivität betrachtet, die in kleineren Aufgaben durchgeführt wird.

35
Q

Mars Climate Orbiter

A

Die Sonder der NASA kam bei einer Mission dem Mars zu nah und wurde durch die Reibungshitze mit der Atmosphäre zerstört. Grund war eine Konstante, die statt im metrischen im imperiellen Maßsystem verwendet wurde. Der Fehler entstand durch eine fehlerhafte Kommunikation mit dem US-amerikanischer Rüstungs- und Technologiekonzern Lockheed Martin, der für das Navigatinossystem zuständig war.

36
Q

Flugzeuglandung LH 2904

A

Der Hersteller ging davon aus, dass das Flugzeug den Boden erst richtig berührt, wenn das Fahrwerk mit mindestens 12 Tonnen belastet wird und die Räder sich drehen. Auf der nassen Landebahn war aber so viel Wasser auf der Fläche, dass das Flugzeug zwar landete, die Räder sich aber sehr langsam drehten. Deshalb dachte der Bordcomputer, das Flugzeug sei noch nicht richtig auf dem Boden, und verhinderte, dass die Bremsen aktiviert wurden.die Bedingungen in der Software berücksichtigten nicht alle möglichen Szenarien. Insbesondere wurden Bedingungen wie Aquaplaning auf nassen Landebahnen nicht richtig erfasst.

37
Q

Absturz der Ariane 5

A

Der Jungfernflug der Ariane 5-Rakete endete in einer Explosion. Grund dafür ist ein Fehler in einem Programm. Bei dem Startvorgang kamm es zum arithmetischen Überlauf einer Variable, was zu dem Absturz des
Navigationscomputers führte. Die daraufhin ausgegebenen diagnostischen Daten wurden als massive Kursabweichung interpretiert. Daraufhin zerriss die Rakete beim Versuch den vermeidlichen Fehler zu korrigieren, was wiederum die Selbstzerstörung auslöste. Nicht nur der Überlauf der Variable, sondern
auch der darauf folgende Absturz der Systeme sind Fehler in der Software.

38
Q

Therac-25

A

Der Softwarefehler betraf ein Flag, das die Positionsprüfung des Wolframtargets signalisieren sollte, aber es wurde während der Einstellungsphase ständig erhöht und bei einem Überlauf auf 0 zurückgesetzt. Wenn der Bediener zu diesem Zeitpunkt die Datenübernahme startete, übersprang das System die Prüfung, ob das Wolframtarget im Strahlengang war.

39
Q

Softwareintensive Systeme sind gekennzeichnet…

A

Softwareintensive Systeme sind gekennzeichnet durch die Komplexität der Algorithmen, der Systemumgebung und des zeitabhängigen Verhaltens.

39
Q

Herausforderungen von softwareintensive Systeme

A

Herausforderungen
▪ Entwicklung, Betrieb und Wartung von Softwarekomponenten in softwareintensiven Systemen erfordert sorgfältige Anwendung von Software Engineering Prinzipien
▪ Zusammenarbeit zwischen Softwareingenieuren und weiteren Fachexperten ist aufgrund Komplexitätsbeherrschung für Zuverlässigkeit, Sicherheit und Effizienz notwendig