diff --git a/Assets/Softwaretechnik_ Analyseformen1.png b/Assets/Softwaretechnik_ Analyseformen1.png new file mode 100644 index 0000000..005181d Binary files /dev/null and b/Assets/Softwaretechnik_ Analyseformen1.png differ diff --git a/Assets/Softwaretechnik_ Analyseformen2.png b/Assets/Softwaretechnik_ Analyseformen2.png new file mode 100644 index 0000000..5209ddf Binary files /dev/null and b/Assets/Softwaretechnik_ Analyseformen2.png differ diff --git a/Assets/Softwaretechnik_Anforderungsentwicklung.png b/Assets/Softwaretechnik_Anforderungsentwicklung.png new file mode 100644 index 0000000..9095cd8 Binary files /dev/null and b/Assets/Softwaretechnik_Anforderungsentwicklung.png differ diff --git a/Assets/Softwaretechnik_Bruegge1.png b/Assets/Softwaretechnik_Bruegge1.png new file mode 100644 index 0000000..8190ab6 Binary files /dev/null and b/Assets/Softwaretechnik_Bruegge1.png differ diff --git a/Assets/Softwaretechnik_Bruegge2.png b/Assets/Softwaretechnik_Bruegge2.png new file mode 100644 index 0000000..f6abb54 Binary files /dev/null and b/Assets/Softwaretechnik_Bruegge2.png differ diff --git a/Assets/Softwaretechnik_Kano1.png b/Assets/Softwaretechnik_Kano1.png new file mode 100644 index 0000000..5deb6af Binary files /dev/null and b/Assets/Softwaretechnik_Kano1.png differ diff --git a/Assets/Softwaretechnik_Kano2.png b/Assets/Softwaretechnik_Kano2.png new file mode 100644 index 0000000..a2788dd Binary files /dev/null and b/Assets/Softwaretechnik_Kano2.png differ diff --git a/Softwaretechnik 1.md b/Softwaretechnik 1.md index 3911129..3f5107f 100644 --- a/Softwaretechnik 1.md +++ b/Softwaretechnik 1.md @@ -325,8 +325,452 @@ Nachteile UML - Grundlage zur Codegenerierung - # Analyse +- Einordnung in den Projektablauf +- Was ist eine Anforderung? + - Merkmal, Eigenschaft, Bedingung oder Einschränkung eines Systems + - Notwendig für die Akzeptanz vom Kunden + - Definition (IEEE 610.12-1990) + - Dokumentierte Darstellung einer Fähigkeit oder Eigenschaft + - von Anwender benötigt zur Problemlösung bzw. um Ziel zu erreichen + - Muss von System oder Komponente erfüllt werden, um Vertrag oder Standard zu erfüllen + +- Funktionale Anforderungen - Was soll es tun? + - „...Legt eine vom Softwaresystem oder einer seiner Komponenten bereitzustellende Funktion oder Service dar“ [Balzert] + - Was leistet das System + - Welche Funktionen bietet es + - Wie interagiert es mit der Umgebung + - Anforderungen an: + - Verhalten + - Struktur + - (Alternativ: Statik, Dynamik, Logik) +- Nichtfunktionale Anforderungen – Wie? + - „...legen qualitative oder quantitative Eigenschaften des Softwareprojektes oder einer Komponente fest“ [Balzert] + - Auch Bezeichnet als: + - Quality of Service + - Qualitätsanforderungen + - Arten - FURPS (ISO 9126): + - Functionality (Funktionalität) + - Usability (Benutzbarkeit) + - Reliability (Zuverlässigkeit) + - Performance (Effizienz) / Portability (Übertragbarkeit) + - Supportability (Änderbarkeit/ Wartbarkeit) + +- Funktionalität + - Angemessen, Genauigkeit + - Sicherheit: Vertraulichkeit, Informationssicherheit, Datenintegrität, Verfügbarkeit + - (Nicht ausreichend spezifizierte funktionale Anforderung) +- Benutzbarkeit + - Verständlichkeit, Erlernbarkeit, Bedienbarkeit, Attraktivität +- Zuverlässigkeit + - Reife (Fehler-Anzahl), Fehlertoleranz, Wiederherstellbarkeit +- Effizient/ Leistungsanforderungen + - Zeitverhalten, Verbrauchsverhalten, Wirtschaftlichkeit +- Portabilität + - Anpassbarkeit, Installierbarkeit, Koexistenz, Austauschbarkeit +- Wartbarkeit + - Analysierbarkeit, Änder- und Erweiterbarkeit, Stabilität (bei Änderungen), Testbarkeit +- Weitere: + - Konformität zu Konventionen und Bestimmungen + - Interoperabilität zu anderen Systemen + - Implementierungsanforderungen + - Schnittstellenanforderungen + - Skalierbarkeit (Änderungen des Problemumfangs) + - Betriebliche und rechtliche Rahmenbedingungen + - Liefer- und Verpackungsanforderungen + +### Nichtfunktionale Anforderungen +Schwierigkeit nichtfunktionaler Anforderungen +- Hängen oft von Verhalten ab: daher komplex und nicht direkt sichtbar +- „Das Auto hat vier Räder“ (Struktur) +- „Wenn der Blinker betätigt wird, blinkt das Auto dreimal wenn die Zündung an ist; ansonsten wird das Standlicht einseitig eingeschaltet“ (Korrektes Verhalten) +- „Das Motorsteuergerät darf innerhalb von 5 Jahren und 150.000km Laufleistung höchstens mit 0.1% Wahrscheinlichkeit ausfallen“ (Zuverlässigkeit) + +Umgang mit nichtfunktionalen Eigenschaften +- Nicht direkt „by construction“ zu realisieren +- Naive Herangehensweise: Ignorieren! + - Entwerfen und Implementieren der Software ohne + - Berücksichtigung nichtfunktionaler Eigenschaften + - Testen der nichtfunktionalen Eigenschaften + - Wenn nicht erfüllt: Entwurf und Implementierung ändern! +- Funktioniert nur bei sehr einfachen Systemen, bzw. wenn nichtfunktionale Eigenschaften nicht wichtig sind! + +Sinnvoller Umgang mit nichtfunktionalen Eigenschaften +- Untersuchung der Projektrisiken bereits in der Analysephase + - größte Risiken zuerst betrachten! + - Immer fragen: Geht das so überhaupt? + - Festlegungen des Entwurfs möglichst früh gegen Anforderungen prüfen – aber wie? +- Modellbasierter Entwurf + - Modellierung des Systems und seiner Umwelt + - Bewertung des Modells (Simulation) + - Lehrveranstaltungen Systementwurf, KIS, LTS + +Randbedingungen +- „... Eine Randbedingung ist eine organisatorische oder technologische Vorgabe, die die Art und Weise einschränkt, wie das betrachtete System realisiert werden kann.“ +- Werden nicht umgesetzt +- Schränken Lösungsraum ein +- Beispiele: + - Kosten + - Durchlaufzeit: Time to Market + - Vorgaben durch Marketing und Vertrieb + - Technische Randbedingungen (nichtfunktionale Anforderung) + +![Analysebaum von Sommerville](Assets/Softwaretechnik_%20Analyseformen1.png) +![Analysebaum von Sommerville](Assets/Softwaretechnik_%20Analyseformen2.png) + +Geforderte (Meta-)Eigenschaften +- Vollständig: alle Szenarien sind beschrieben +- Konsistent: keine Widersprüche +- Eindeutig: nur eine Interpretation möglich +- Korrekt: genaue und richtige Darstellung +- Realistisch: unter geg. Einschränkungen implementierbar +- Überprüfbar: durch Tests am Endprodukt nachweisbar +- Rückverfolgbar: Auswirkungen bis zur Implementierung nachvollziehbar (Testfälle, Auswirkung von Änderungen) +- Klassifizierbar (Risiko, Priorität, Dringlichkeit, Nutzen ...) +- Validierung mit dem Kunden + +- Requirements Engineering + - Ermittlung, Analyse und Verwaltung von Anforderungen + - Ausgangspunkt: Projektidee +- Anforderungsermittlung + - requirements elicitation, requirements definition + - Bestimmen und dokumentieren der Anforderungen an das geplante System + - Beteiligt: Entwickler, Kunde, Benutzer + - Ergebnis: Anforderungsspezifikation - Glossar, Vertrag, Lastenheft +- Anforderungs-Analyse + - requirements analysis, system modeling + - Beschreibung im Detail und formal strukturiert + - Beteiligt: Entwickler + - Ergebnis: funktionale Spezifikation - Produktdefinition, Analysemodell, Pflichtenheft + +![Anforderungsentwicklung von Balzert](Assets/Softwaretechnik_Anforderungsentwicklung.png) + +| | Anforderungsermittlung | Systemmodellierung | +| -- | -- | -- | +| Ergebnis | Anforderungsspezifikation im Lastenheft, Glossar, Lastenheft | funktionale Spezifikation in Produktdefinition, Analysemodell, Pflichtenheft | +| Notation | Text | Text + (semi-) formales Modell | +| Kommunikation | mit dem Kunden | zwischen Entwicklern | +| Sichtweise | des Anwenders | äußere Systemaspekte | +Vor allem: Kommunikationsleistung! + +Bedeutung: +- Falsche Anforderungen führen zu falschem System +- Frühe Fehler im Entwicklungsprozess sind teuer! + +Fehlerentstehung und Fehlerquellen bei Anforderungserfassung +- 83% sprachliche Fehler (Un- bzw. Missverständlich) +- 75% Logische Fehler (Widersprüchlichkeit, Redundanz) +- 73% Inhaltliche Fehler (Falsche Sachverhalte, Unvollständig) + +## Ermiteln von Anforderungen +Woher kommen Anforderungen? +- Ausgangspunkt + - Projektidee, schriftliche Skizze + - Kurz und knapp + - Stichpunkte der wichtigsten Funktionen + - Lastenheft (falls schon existiert) +- Interessenhalter (stakeholder) + - Identifizieren, Wichtigkeit bewerten (berücksichtigen?) + - Ansprechpartner? Interessen und Erwartungen + - Fachexperten, Verantwortliche, Betroffene + +Beteiligte Rollen +- Endbenutzer + - Aufnahme Ist-Zustand, Domänenwissen, Anforderungen +- Kunde + - Definiert Ziel des Systems, Vertragsverhandlung +- Konfigurationsmanager + - Revisionsgeschichte der Dokumente, Nachvollziehbarkeit +- Architekt + - Integration von Anwendungsfall- und Objektmodellen +- Analytiker + - Modelliert das System und erstellt Anwendungsfälle +- Redakteur +- Prüfer + +Wie ermittelt man Anforderungen? +- Problem: Entwickler müssen sich in Begriffs- und Denkwelt des Kunden einarbeiten, sonst Kommunikationsprobleme +- Systematische Vorgehensweise +- Kommunikation mit Kunden +- Geschäftsprozess (business process) + - fachlicher Ablauf, der Wert oder Kosten verursacht +- Akteur (actor) + - Benutzer, Schnittstelle nach außen +- Szenario (scenario) + - Interaktion mit System als Ablauf +- Anwendungsfall (use case) + - Automatisierter Arbeitsschritt, vom System ausgeführt +- Interviews mit Fachanwendern + - Mitschrift, später strukturierter Text und Tabelle +- Strukturierte Spezifikation + - Vorlagen / sprachliche Anforderungsschablonen + - Formulare + - Reduzierung sprachlicher Mehrdeutigkeiten +- Anwendungsfalldiagramm (Use-Case-Diagramm) + - Arbeitsschritt eines Geschäftsprozesses, der durch das System ausgeführt wird + - Anforderungen an das System modellieren – was soll das System leisten + - Systemgrenzen / Systemkontext festlegen + - Systembeteiligte modellieren + - Planbare Einheiten als Schritte für die Entwicklung + - Verwendung bereits ab Projektbeginn + - Keine Modellierung eines Ablaufs! +- Umgang mit Szenarien und Anwendungsfällen + - Zunächst nur zum Verständnis kurz aufstellen + - Systemgrenze definieren + - Beschreibungen verfeinern + - Änderungen mit Kunden abstimmen + - Prototypen nur zur visuellen Unterstützung + - Benutzungsschnittstelle erst beginnen, wenn funktionale Anforderungen in etwa klar sind + +Leitfaden für Anwendungsfälle +- Benennen mit Verbalphrasen, die Anwendersicht beschreiben (Simuliere) +- Akteure mit Substantiven benennen (Anwender) +- Systemgrenzen klären. Arbeitsschritte von Akteuren und System kennzeichnen +- Schritte im aktiven Stil beschreiben (Auto bremst) +- Ursächliche Beziehung zwischen Folgeschritten +- 1 Anwendungsfall = 1 vollständige Transaktion +- Normalfall darstellen; Ausnahmen gesondert beschreiben +- Nicht die Benutzungsschnittstelle beschreiben (statt dessen visuellen Prototypen verwenden) +- Übersichtlichkeit (max. 2-3 Seiten), sonst zerlegen + +- Typische Probleme + - Kommunikations- und Verständnisprobleme + - Viele verschiedene Beteiligte + - Kunden wissen nicht, was sie genau wollen und was geht + - Verwendung von Fachsprachen + - Widersprüchliche Anforderungen, verschiedene Interessen + - Nicht-technische organisatorische, historische oder rechtliche Rahmenbedingungen + - Zusätzliche Beteiligte können auftauchen + - Anforderungen ändern sich während der Entwicklung +- Anforderungsänderungen + - Sind die Regel +- Tätigkeiten der Anforderungsanalyse + - Anforderungen strukturieren + - Eigenschaften der Anforderungen bestimmen + - Anforderungen priorisieren + - Anforderungen in Textform, Grafiken, Modellen dokumentieren + - Anforderungen modellieren + - Anforderungen auf inhaltliche Qualität prüfen + - Auf Übereinstimmung mit den Zielen prüfen + - Ziel Abnahme der Anforderung + - Hängt mit Analyse des Systems zusammen +- Anforderungen strukturieren + - Unterteilung + - Funktional, Nichtfunktional + - Muss, Kann,... oder Haupt- und Nebenanforderung + - Hierarchische Zerlegung + - Unterteilen, Verfeinern + - Ordnung festlegen, eindeutig Nummerieren + - auf Einmaligkeit achten + - Beziehungen festhalten + - Verwendung von Werkzeugen + - MS-Project, Doors, Git issues, Trac, Bugzilla, MKS,... + - Modellierungswerkzeuge +- Eigenschaften bestimmen + - Wahl der Eigenschaften firmen- bzw. projektspezifisch + - Wichtige Eigenschaften + - Identifikationsnummer + - Kurzbezeichnung + - Beschreibung (Text, ggf. Grafik, Modell) + - Aufwand + - Priorität der Anforderung + - Bearbeitungsstatus / Restaufwand + - Zugeordnet (wer ist verantwortlich / bearbeitet) + - Querverbindungen zu anderen Anforderungen + - Ggf. zusätzliche Dokumente oder Bemerkungen + - Stabilität der Anforderung (Änderungswkt.) + - Kritikalität der Anforderung: Schäden bei Fehlern? + - Entwicklungsrisiko: Erfolgsaussichten der Umsetzung + - Abnahmekriterien / Erfüllungsnachweis durch? + - Anforderungstyp: Funktional, nicht funktional ,... + - Anforderungssicht: Dynamik, Statik, Logik, Struktur, Funktion + - Mögliche Konflikte + - Autor + - Quelle: Wer möchte die Anforderung umgesetzt haben? + - Status der Beschreibung: Idee, grober Inhalt, detailliert + - Anforderungsversion +- Anforderungen priorisieren + - MuSCoW-Priorisierung + - Muss-, Kann-, Optional, Nicht (Abgrenzungskriterien) (must, should, could, won‘t) + - Ad-hoc: Stakeholder priorisiert Anforderungen + - Priorisierungsmatrix / Kosten-Wert-Analyse + - Eigenschaften bewerten (Punkte vergeben) + - Werte gewichten + - Priorität berechnen $Prioritäten = \frac{Nutzen - Nachteil}{Kosten + Risiko}$ + - Kano-Klassifikation + - Basiseigenschaften: Werden vorausgesetzt (fehlen stört, wenig zusätzliche Zufriedenheit) + - Leistungseigenschaften: Sonderwünsche + - Begeisterungseigenschaften: Wird nicht erwartet + - Abfragen per Fragenkatalog + - Reihenfolge festlegen + + +![Kano Klassifikation von Balzert](Assets/Softwaretechnik_Kano1.png) +![Kano Klassifikation von Balzert](Assets/Softwaretechnik_Kano2.png) + +## Objektorientierte Analyse und Systemmodellierung +- Übersicht + - Aufgabe: Systemmodell erstellen, funktionale Spezifikation + - Beschreibung der Systembenutzung und des Verhaltens + - Was, nicht wie – Implementierungsaspekte ausklammern + - Nicht: Datenhaltung, Verteilung, Technologien, Architektur, .. + - Zusammenhang mit Anforderungsspezifikation + - OO: Modell des Anwendungsbereichs +- Analysemodell + - Korrekt, vollständig, konsistent und nachprüfbar + - Struktur und Verhalten + - Verschiedene Sichten (OO, Strukturiert, ...) +- Eingangsdokumente + - Lastenheft, Anforderungsspezifikation +- Typische Ergebnisse + - Funktionales Modell + - Geschäftsprozesse und Anwendungsfälle + - Objektmodell + - Dynamisches Modell – Systemverhalten + - Zustands- und Sequenzdiagramme + - Vor- und Nachbedingungen von Systemoperationen + - Prototyp / Spezifikation Benutzungsschnittstelle + - Pflichtenheft +- Objektorientierte Analyse nach [Brügge / Dutoit] + - Verdeutlicht iterativen Ablauf + - Unterteilung des Analysemodells in: + - Funktionales Modell (Anwendungsfälle) + - Objektmodell (Klassen und Objektdiagramme) + - Dynamisches Modell (Zustands- und Sequenzdiagramme) + - Unterscheidung der Objekttypen + +![Analyse nach Brügge/Dutoit](Assets/Softwaretechnik_Bruegge1.png) +![Analyse nach Brügge/Dutoit](Assets/Softwaretechnik_Bruegge2.png) + +- Heuristik Sprache $\rightarrow$ OO-Modell +- Objektarten im Systemmodell + - Entitätsobjekte – vom System verwaltete Informationen + - Grenzobjekte – Interaktion zwischen System und Akteuren + - Steuerungsobjekte – Durchführung der Anwendungsfälle +- Identifizierung von Entitätsobjekten + - Begriffe, die klargestellt werden müssen + - Wiederkehrende Substantive in Anwendungsfällen + - Heuristiken + - Reale Objekte, die das System kennen muss + - Reale Prozesse, die das System verfolgen muss + - Anwendungsfälle + - Datenquellen und -senken + - Artefakte, mit denen der Nutzer interagiert +- Identifizierung von Grenzobjekten + - Elemente der Benutzungsschnittstelle + - Formulare für Eingaben + - Nachrichten, Rückmeldungen + - Endgeräte + - In der Begriffswelt des Anwenders bleiben! + - Schnittstellen grafisch skizzieren bzw. Prototyp! +- Identifizierung von Steuerungsobjekten + - Koordination von Grenz- und Entitätsobjekten + - Abarbeitung von Anwendungsfällen + - Reihenfolge von Schritten + - Informationen übernehmen und weiterleiten + - Oft ein Steuerungsobjekt pro Anwendungsfall + - Beispiel: Simulationsszenario + - Verhaltensmodell sinnvoll! Im folgenden: dynamische Modelle + +- Abläufe der Anwendungsfälle modellieren + - Ziel - Objekte finden + - Klassen identifizieren + - Verhalten / Operationen finden +- Use Case durch Interaktion verfeinern + - einfacher kurzer Ablauf: textuelle Beschreibung, Aktivitätsdiagramm + - Ablauf mit Verzweigungen, Parallelitäten: Aktivitätsdiagramm (Kontrollflussmodellierung) + - datengetriebener Ablauf: Aktivitätsdiagramm (Objektflussmodellierung) + - Interaktion zwischen den Objekten wichtig: Kommunikationsdiagramm, Aktivitätsdiagramm (Aktivitätsbereiche), Sequenzdiagramm + - zeitliche Abfolge steht im Mittelpunkt: Sequenzdiagramm + - Zustandswechsel / zeitliche Abfolge von Zuständen: Zustandsdiagramm / Timing-Diagramm + - komplexe Abläufe mit Verzweigungen und Parallelitäten: Interaktionsübersichtsdiagramm + - komplexe Abläufe ohne Verzweigungen und Parallelitäten: weitere Verfeinerung durch Use-Case-Diagramm + - komplexer strukturierter Ablauf: Kollaboration aus dem Kompositionsstrukturdiagramm + +- Dynamische UML-Modelle + - Abläufe + - Aktivitätsdiagramm (activity diagram) + - Kommunikationsdiagramm (communication diagram) + - Sequenzdiagram (sequence diagram) + - Zeitdiagramm (timing diagram) + - Zustandsabhängiges Verhalten von Objekten + - Zustandsautomat (state chart diagram) + +- Aktivitätsdiagramm + - Aktion – einzelner Schritt + - Aktivität + - Beschreibt einen Ablauf / repräsentiert ein Verhalten + - Beinhaltet eine Folge Aktionen, Kontroll- oder Objektknoten + - Schachtelung von Aktivitäten und Aktionen + - Aktionen in Aktivitäten enthalten + - Aktionen durch Aktivitäten verfeinerbar + - Aktivitäten beschreiben / verfeinern + - Aktionen, Use Cases, Interaktionen, Operationen ... + - Ein- und Ausgabeparameter in Form von Objekten + - Parameterknoten entsprechend Pins der aufrufenden Aktion + - Alternativ: Parameterangabe mit Name und Typ + - Angabe von Vor- und Nachbedingungen möglich + - Optional: Parameter unter Aktivitätsnamen + +- Verfeinerung der Aktionen durch Aktivitäten +- Aktion durch Interaktionen verfeinern + - Detaillierte Diagramme + - Meist entwurfsnah +- Verfeinerung der Aktionen durch StateChart +- Objekte zusammenstellen und klassifizieren + - Toolunterstützung (Möglichkeiten stark toolabhängig) + - Objekte Ergebnis der Verhaltensmodellierung + - Ergebnis Verhaltensdiagramm: Operationen der Klassen + - Klassen generalisieren / spezialisieren $\rightarrow$ Klassenhierarchie +- Übergang zum Entwurf + - Klassenstruktur festlegen +- Spezifikation von Benutzungsschnittstellen + - Skizzieren, Prototyp generieren, Spezialwerkzeuge + - Klassen und Operationen in Funktionen + - Gestaltung MMI, style guides, Standards + +## Dokumentation von Anforderungen +- Lastenheft + - Gesamtheit der Forderungen eines Auftraggebers (AG) an die Lieferungen und Leistungen eines Auftragnehmers (AN), manchmal Vertragsbasis + - Muss-Kriterien, Kann-Kriterien, Abgrenzungskriterien +- Pflichtenheft + - Entwurf aus AN-Sicht, Umsetzung des Lastenhefts + - Meist Vertragsbasis +- Inhalt Anforderungsspezifikation + - Zielsetzung + - Allgemeine Beschreibung + - Umgebung, generelle Funktion, Restriktionen, Benutzer + - Spezifische funktionale Anforderungen + - möglichst quantitativ (z.B. Tabellenform) + - eindeutig identifizierbar (Nummern) + - Spezifische nicht-funktionale Anforderungen + - z.B. Antwortzeit, Speicherbedarf, HW/SW-Plattform + - Entwicklungs- und Produkt-Standards + - Qualitäts-Zielbestimmung + - Zu erwartende Evolution des Systems, Versionen + - Abkürzungsverzeichnis, Glossar, Index, Referenzen + + +Pflichtenheft (Beispiel) +1. Einleitung, Zielbestimmung +2. Übersicht + - Einsatzbereich, Zielgruppen + - Produkt-Umgebung + - Produkt-Funktionen + - Restriktionen + - Annahmen und Abhängigkeiten + - Vorhandenes System (ggf.) +3. Vorgeschlagenes System + - Übersicht + - Funktionale Anforderungen + - Benutzungsschnittstelle + - Nichtfunktionale Anforderungen + - Systembeschreibung + - Szenarien + - Anwendungsfälle +4. Glossar + + # Grobentwurf # Feinentwurf # Implementierung