Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Software Engineering > VL 2, Übung 2 > Flashcards

VL 2, Übung 2 Flashcards

1
Q

Prinzipien

A

Die Prinzipien im Software Engineering dienen als Leitlinien, um Softwareprojekte effektiv und effizient zu gestalten und qualitativ hochwertige, wartbare Software zu entwickeln.

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

Eigenschaften komplexer Systeme

A

▪ hoher Grad der Vernetzung
▪ emergentes Verhalten
▪ Unvorhersehbarkeit von Systemeigenschaften
▪ Nicht-Linearität von Wirkzusammenhängen
▪ Selbstorganisation & Adaptivität

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

Software Engineering hat wesentliche Schnittpunkte mit anderen Disziplinen

A

▪ User Experience Design
→ Human Factors
▪ Product Line Engineering
→ Portfoliomanagement (BWL)
▪ Requirements Engineering
→ Psychologie
▪ Formale Modellierung
→ Linguistik

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

wesentlicher Normen, Richtlinien und Standards

A

ISO 15288 „Software & System Lifecycle“
▪ Beschreibung Digitaler Modelle, Frameworks, Lebenszyklen für Systeme, Software und Softwaresysteme sowie Phasen der Produktentwicklung (Vorgehensmodelle)
VDI/VDE 2206 „Development of Mechatronic Systems“
▪ Einbettung von Software in mechatronische Systeme/Produkte, formales Rahmenwerk insbesondere bzgl. V-Modell für industrielle Anwendung
ISO 42100 „Architectural Descriptions“
▪ Definition und Hintergrund zu Kernbegriffen für Beschreibungen von Software- und Systemarchitekturen (z.B. Architecture Viewpoints/Views)
ISO 24641 „Tools and Methods for Model-Based Systems and Software Engineering“
▪ Beschreibung von Referenzprozessen für Model-Based Systems/Software Engineering, vollständige Nutzung von Konzepten der Modellierung, Digitaler Modell etc.

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

Verknüpfung von Aktivitäten zu Prozessen (картинка)

A

Softwareentwicklung in Unternehmen erfordert:

-Personen mit Kompetenzen (Experten mit den nötigen Fähigkeiten)
-Geeignete IT-Werkzeuge & Sprachen
-Methoden für einzelne Entwicklungsaktivitäten Prozess als Verknüpfungspunkt:
-Definiert notwendige Aktivitäten in der Entwicklung
-Bestimmt die Sequenz der SE-Aktivitäten (Workflow)
-Legt die benötigten Kompetenzen und Rollen fest
-Verwendet Standards, Richtlinien, Methoden und IT-Werkzeuge
Prozess verbindet alle Elemente (Menschen, Methoden und Werkzeuge) für eine erfolgreiche Softwareentwicklung.

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

Prozessmodell oder Vorgehensmodell

A

Ein Prozessmodell oder Vorgehensmodell zeigt die Reihenfolge der Schritte, die notwendig sind, um ein Produkt oder System zu entwickeln. Dabei beschreibt es, welche Aktivitäten in welcher Reihenfolge durchgeführt werden müssen.
Eine Anpassung (Tailoring) bedeutet, dass das Modell verändert wird, um besser zu den speziellen Bedürfnissen oder Bedingungen eines bestimmten Teams oder Unternehmens zu passen. So wird das Modell für die jeweilige Situation praktikabler.

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

Arten von Prozess-/Vorgehensmodellen

A

▪ Deskriptive Prozessmodelle beschreiben existierende IST-Prozesse
▪ Normative Prozessmodelle stellen dar, wie ein SOLL-Prozess gestaltet sein soll
→ in Vorlesung exemplarische Vertiefung etablierter normativer Prozessmodelle

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

Wasserfallmodell

A

Software wird in sukzessiven Stufen (Phasen) entwickelt
▪ Arbeitsergebnisse „fallen“ nach einer Phase in nächste
→ häufig für Entwicklung sehr große Softwaresysteme genutzt

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

Wasserfallmodell Charakteristika

A

▪ Top-Down Vorgehen
▪ Entwicklungsablauf sequentiell
▪ Dokumenten-getriebenes Modell
▪ Einfach und verständlich mit wenig Managementaufwand
▪ Kundenbeteiligung nur in Definitionsphase vorgesehen

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

Rücksprünge zwischen Phasen Wasserfall

A

▪ Rückkopplung bzw. Rücksprünge möglich
▪ Rücksprünge vor allem, um entdeckte Fehler in vorausgehender Phase zu lösen
▪ Iteratives Durchlaufen von Schleifen bei Bedarf, z.B. Testen und Implementieren

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

Nachteile Wasserfall

A
  • unflexibles Vorgehen in Hinblick Änderungen bei Kundenanforderungen
    ▪ Phasen müssen in voller Breite und vollständig abgeschlossen werden
    ▪ Phasen müssen sequentiell durchlaufen werden, keine Möglichkeit für Parallelisierung
    ▪ produzierte Dokumentation ist treibendes Moment, Dokumente werden ggf. als wichtiger wahrgenommen als die tatsächliche Implementierung
    ▪ vorab nicht vorhersehbare Risikofaktoren nicht ausreichend berücksichtigt, da nur initiale Anforderungen bestehen bleiben
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Vorteile Wasserfall

A

✓ Klare Struktur mit festgelegten Abläufen
✓ Gute Dokumentation
✓ Abschätzung von Kosten und Zeitaufwand schon zu Beginn der Entwicklung möglich
✓ Gute Kalkulation des Arbeitsaufwands möglich

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

V-Modell

A

▪ Größere Erweiterung des Wasserfallmodells
▪ Integriert Qualitätssicherung in Wasserfallmodell
▪ Verifikation der Teilprodukte und Validierung Gesamtprodukt
V-Modelle geeignet für Entwicklung der meisten Arten von Produkten
▪ insbesondere für Entwicklung von softwareintensiven Systemen genutzt
▪ Iterationen / Schleifen zwischen einzelnen Phasen üblich

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

Nachteile V-Modell

A

-Mangelnde Flexibilität (ist es schwer, das Modell anzupassen, wenn unvorhergesehene Probleme oder Änderungen auftreten)
-Hohe Abhängigkeit von Testaktivitäten
-Hohe Dokumentationsanforderungen
-Nicht geeignet für unklare Anforderungen
-lange entwicklungszykles

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

Vorteile des V-Modells

A

✓ Strukturiertes Vorgehen
✓ Klare Verbindung von Anforderungen und Tests
✓ Nachvollziehbarkeit und Dokumentation

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

Übergang des V-Modells zum Prototypenmodell

A

Oft können die Anforderungen an ein System vom Auftraggeber zu Beginn nicht vollständig und explizit formuliert werden, was während der Entwicklung regelmäßiges Feedback zwischen Entwicklern und Anwendern erfordert, um die gewünschten Systemeigenschaften zu gewährleisten. In traditionellen Vorgehensmodellen endet das Feedback jedoch früh, sobald die Anforderungen dokumentiert sind, und die Entwicklungsabteilung zieht sich nach Abschluss der Anforderungsdefinition zurück, wobei das Ergebnis erst nach Fertigstellung präsentiert wird.

17
Q

Nutzen von Prototypen

A

▪ Experimentelle Erprobung mit Kunden
▪ Einbindung / Diskussion mit Kunden
▪ Klärung der Handhabung / Usability
▪ Untersuchung der Machbarkeit
▪ Bewertung von Lösungsalternativen
▪ Überzeugung des Kunden bei Akquise

18
Q

Vorteile Prototypenmodell

A

▪ starke Rückkopplung mit dem Kunden / Auftraggeber sowie Endanwender:innen
▪ Reduzierung des Entwicklungsrisikos und frühzeitige Zielklarheit
▪ verbesserte Planbarkeit und Steuerung von komplexen IT-Projekten
▪ Prototypen fördern Kreativität für Lösungsalternativen
▪ Prototypen können auch in andere Prozessmodelle integriert werden

19
Q

Nachteile Prototypenmodell

A

▪ höherer Entwicklungsaufwand, da Prototypen zusätzlich erstellt werden
▪ Gefahr, dass Wegwerf-Prototyp Teil des Endprodukts wird
▪ Verträge für Softwareentwicklung berücksichtigen meist keine Prototypen
▪ Prototypen oft als Ersatz für fehlende Dokumentation angesehen
▪ bei Prototypen Grenzen und Beschränkungen oft unbekannt

20
Q

Voraussetzungen für effiziente Anwendung Prototypenmodell

A

Für ein erfolgreiches Prototyping sind ausreichendes Wissen über den Anwendungskontext, eine gut geplante Dokumentation, geeignete Werkzeuge für Rapid-Prototyping, direkter Zugang und aktive Beteiligung der Anwender sowie regelmäßiges Feedback aus der Praxis erforderlich.

21
Q

Software-Prototyp

A

Ein Software-Prototyp ist eine frühe Version oder ein Modell einer
Softwareanwendung, um die Umsetzung von Anforderungen und
Entwürfen zu demonstrieren und mit ihnen zu experimentieren.
Der Software-Prototyp demonstriert nur bestimmte Eigenschaften
oder Aspekte der endgültigen Software.

▪ Prototypen werden vor Abschluss der Entwicklung erstellt werden
▪ dient der Entwicklung und den Auftraggebern sowie anderen Stakeholdern als Vorschau auf das zukünftige Produkt
▪ Protypen zum Testen/Evaluieren ausgewählter Softwarefunktionalitäten

22
Q

Arten von Prototypen

A

Bezug zu Zweck
▪ Demonstrationsprototyp
▪ Prototyp im eigentlichen Sinne
▪ Labormuster
▪ Pilotsystem
Bezug zu Softwarearchitektur
▪ Horizontaler Prototyp
▪ Vertikaler Prototyp

23
Q

Demonstrationsprototyp

A

Ein Demonstrationsprototyp ist eine frühe Version einer Softwareanwendung, die für die Auftragsakquisition erstellt wird. Ziel
ist es, dem Auftraggeber einen Eindruck davon zu vermitteln, wie das
endgültige Produkt für den Anwendungskontext aussehen könnte.
▪ Demonstratoren in der Regel schnell erstellt, oft unter Verwendung von Rapid-Prototyping-Methoden
▪ Fokus vor allem auf visuelle Darstellung des geplanten Produkts, um
einen ersten Eindruck der Benutzerschnittstelle zu vermitteln

24
Q

Protyp im eigentlichen Sinne

A

Ein Prototyp im eigentlichen Sinne ist eine vorläufige Version eines
Softwaresystems, die parallel zur Erhebung des Anwendungskontexts
entsteht. Ziel ist es, die Verfeinerung von Anforderungen zu unterstützen und den tatsächlichen Anwendungskontext zu analysieren.
▪ Teile der Funktionalität und bestimmte Aspekte der
Benutzerschnittstelle werden veranschaulicht
▪ frühzeitige Einblicke in das zukünftige Endprodukt für Entwickler:innen und Stakeholder, um Verbesserungspotentiale zu identifizieren

25
Q

Labormuster

A

Ein Labormuster ist ein Prototyp, der speziell entwickelt wird, um
lösungsbezogene Fragen und Alternativen zu beantworten. Dabei
werden verschiedene technische Lösungsvarianten analysiert, um die
optimale Implementierung für das spätere Produkt zu identifizieren.
▪ lediglich die technische Umsetzbarkeit des Produktmodells wird
demonstrieren und Prototyp ist nicht für Endbenutzer bestimmt
▪ Labormuster werden im Laborumfeld erstellt und getestet, um
technischen Herausforderungen während der Entwicklung zu prüfen

26
Q

Pilotsystem

A

Ein Pilotsystem ist Kern eines Softwareprodukts, um den Übergang
zum endgültigen Produkt zu erleichtern. Ziel ist es, die frühzeitige
Validierung des Softwareprodukts, um Sicherstellung, dass
Softwareprodukte den Anforderungen des Geschäftsumfeld entspricht.
▪ Pilotsystem wird speziell für Benutzung in der tatsächlichen
Einsatzumgebung bzw. dem Anwendungskontext entworfen
▪ Grenzen zwischen Pilotsystem und endgültigem Produkt sind aus Sicht von Nutzer:innen fließend, da Kernfunktionalitäten des Produkts enthalten

27
Q

Horizontaler und vertikale Prototypen

A

Horizontaler Prototyp
▪ nur spezifische Ebenen des Systems realisiert
▪ betreffende Ebene möglichst vollständig realisiert
Vertikaler Prototyp
▪ implementiert einen Durchstich durch alle Ebenen
▪ geeignet bei noch offenen Implementierungsoptionen

28
Q

Technology Readiness Level

A

TRL-Stufen
TRL 1: Beobachtung und Beschreibung des Funktionsprinzips
TRL 2: Beschreibung der Anwendung einer Technologie
TRL 3: Nachweis der Funktionstüchtigkeit einer Technologie
TRL 4: Versuchsaufbau im Labor
TRL 5: Versuchsaufbau in Einsatzumgebung
TRL 6: Prototyp in Einsatzumgebung
TRL 7: Prototyp im Einsatz (1–5 Jahre)
TRL 8: Qualifiziertes System mit Nachweis der Funktionstüchtigkeit im Einsatzbereich
TRL 9: Qualifiziertes System mit Nachweis des erfolgreichen Einsatzes

29
Q

Minimal Viable Product

A

Ein Minimal Viable Product (MVP) ist eine frühe Version eines Produkts,
die nur über die grundlegenden Funktionen verfügt, um den
frühestmöglichen Markteintritt zu ermöglichen. Ziel ist es, schnell
einen Markt zu erschließen und Feedback von Nutzer:innen zu erhalten
▪ mit Feedback der Nutzer:innen basierend auf echten Erfahrungen (User Experience) wird MVP nachträglich verbessert und erweitert
▪ minimiert Risiko durch Fokus auf wesentliche Funktionen (priorisierte
Features) und Aufwand für unwichtige Funktionen vermieden wird

30
Q

Entwicklung

A

Entwicklung ist der Prozess, in dem Software von der Idee bis zur
funktionsfähigen Anwendung erstellt wird. Dabei geht es um das Design, die Programmierung und das Testen der Software.

31
Q

Normen und Standards

A

Normen und Standards sind festgelegte Regeln und Richtlinien, die
sicherstellen sollen, dass Software von hoher Qualität und sicher ist und dass sie kompatibel mit anderen Systemen ist.

32
Q

Beschreiben Sie mögliche Konsequenzen einer fehlerhafte Anwenderdokumentation (nehmen Sie zur exemplarischen Erläuterung ein Softwareprodukt Ihrer Wahl)

A

Fehlerhafte Anwenderdokumentation in einer Navigations-App könnte zu Verwirrung und Fehlbedienungen führen, was die Benutzererfahrung beeinträchtigt. Langfristig könnte dies das Vertrauen in die App verringern und Nutzer zu Konkurrenzprodukten treiben.

33
Q

Inwiefern unterstützt ein strukturiertes Vorgehen die professionelle Softwareentwicklung, d.h. welche Gründe gibt es für die Nutzung von Vorgehensmodellen aus Ihrer Sicht

A

Ein strukturiertes Vorgehen in der Softwareentwicklung durch Vorgehensmodelle ermöglicht eine bessere Ressourcen- und Budgetverwaltung, effektives Risikomanagement, Nachvollziehbarkeit, Skalierbarkeit und Wiederverwendbarkeit der Software, wodurch die Wahrscheinlichkeit eines erfolgreichen Projekts und die Qualität der Software erhöht werden.

34
Q

Erläutern Sie 2 mögliche Gemeinsamkeiten (z.B. gemeinsame/ähnliche Aktivitäten bzw. Phasen), die alle klassischen Vorgehensmodelle prägen

A

-Phasenorientierung: Alle Modelle unterteilen den Softwareentwicklungsprozess in klar definierte Phasen, um den Ablauf systematisch zu gestalten.
- Alle klassischen Modelle integrieren eine separate Testphase oder Tests in jeder Phase der Entwicklung, um sicherzustellen, dass die Software den definierten Anforderungen entspricht und Fehler frühzeitig entdeckt und behoben werden.

35
Q

Erläutern Sie zusätzlich kurz (2-3 Sätze) 3 wesentliche Unterschiede zwischen den Prozessmodellen.

A

-Das Wasserfallmodell folgt einem linearen, sequenziellen Ablauf, bei dem jede Phase vollständig abgeschlossen sein muss, bevor die nächste beginnt.
-Das Prototypenmodell fokussiert sich auf die schnelle Erstellung von Prototypen, die mit den Nutzern getestet werden, um Anforderungen iterativ zu verfeinern.
-Das V-Modell verknüpft jede Entwicklungsphase direkt mit einer Testphase, sodass Tests parallel zur Entwicklung durchgeführt werden, um Fehler frühzeitig zu identifizieren.

36
Q

Prototypen und TRL

A

Labormuster - TRL 4
Pilotsystem - TRL 7
Hor.Prototyp - TRL 3-4
Ver.Prototyp - TRL 5-6
Demonstrationsprototyp - TRL 1
Prototyp im einetlichen Sinne - TRL 3

Software Engineering (9 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2025 Bold Learning Solutions. Terms and Conditions