VL 2, Übung 2 Flashcards
Prinzipien
Die Prinzipien im Software Engineering dienen als Leitlinien, um Softwareprojekte effektiv und effizient zu gestalten und qualitativ hochwertige, wartbare Software zu entwickeln.
Eigenschaften komplexer Systeme
▪ hoher Grad der Vernetzung
▪ emergentes Verhalten
▪ Unvorhersehbarkeit von Systemeigenschaften
▪ Nicht-Linearität von Wirkzusammenhängen
▪ Selbstorganisation & Adaptivität
Software Engineering hat wesentliche Schnittpunkte mit anderen Disziplinen
▪ User Experience Design
→ Human Factors
▪ Product Line Engineering
→ Portfoliomanagement (BWL)
▪ Requirements Engineering
→ Psychologie
▪ Formale Modellierung
→ Linguistik
wesentlicher Normen, Richtlinien und Standards
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.
Verknüpfung von Aktivitäten zu Prozessen (картинка)
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.
Prozessmodell oder Vorgehensmodell
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.
Arten von Prozess-/Vorgehensmodellen
▪ Deskriptive Prozessmodelle beschreiben existierende IST-Prozesse
▪ Normative Prozessmodelle stellen dar, wie ein SOLL-Prozess gestaltet sein soll
→ in Vorlesung exemplarische Vertiefung etablierter normativer Prozessmodelle
Wasserfallmodell
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
Wasserfallmodell Charakteristika
▪ Top-Down Vorgehen
▪ Entwicklungsablauf sequentiell
▪ Dokumenten-getriebenes Modell
▪ Einfach und verständlich mit wenig Managementaufwand
▪ Kundenbeteiligung nur in Definitionsphase vorgesehen
Rücksprünge zwischen Phasen Wasserfall
▪ 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
Nachteile Wasserfall
- 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
Vorteile Wasserfall
✓ 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
V-Modell
▪ 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
Nachteile V-Modell
-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
Vorteile des V-Modells
✓ Strukturiertes Vorgehen
✓ Klare Verbindung von Anforderungen und Tests
✓ Nachvollziehbarkeit und Dokumentation
Übergang des V-Modells zum Prototypenmodell
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.
Nutzen von Prototypen
▪ 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
Vorteile Prototypenmodell
▪ 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
Nachteile Prototypenmodell
▪ 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
Voraussetzungen für effiziente Anwendung Prototypenmodell
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.
Software-Prototyp
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
Arten von Prototypen
Bezug zu Zweck
▪ Demonstrationsprototyp
▪ Prototyp im eigentlichen Sinne
▪ Labormuster
▪ Pilotsystem
Bezug zu Softwarearchitektur
▪ Horizontaler Prototyp
▪ Vertikaler Prototyp
Demonstrationsprototyp
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
Protyp im eigentlichen Sinne
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
Labormuster
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
Pilotsystem
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
Horizontaler und vertikale Prototypen
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
Technology Readiness Level
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
Minimal Viable Product
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
Entwicklung
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.
Normen und Standards
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.
Beschreiben Sie mögliche Konsequenzen einer fehlerhafte Anwenderdokumentation (nehmen Sie zur exemplarischen Erläuterung ein Softwareprodukt Ihrer Wahl)
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.
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
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.
Erläutern Sie 2 mögliche Gemeinsamkeiten (z.B. gemeinsame/ähnliche Aktivitäten bzw. Phasen), die alle klassischen Vorgehensmodelle prägen
-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.
Erläutern Sie zusätzlich kurz (2-3 Sätze) 3 wesentliche Unterschiede zwischen den Prozessmodellen.
-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.
Prototypen und TRL
Labormuster - TRL 4
Pilotsystem - TRL 7-8
Hor.Prototyp - TRL 3-4
Ver.Prototyp - TRL 5-6
Demonstrationsprototyp - TRL 4-5
Prototyp im eigentlichen Sinne - TRL 6
