VL 2, Übung 2 Flashcards
(36 cards)
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
