Software Engineering

• Bewertung, um festzustellen, ob Produkt Kundenbedürfnisse erfüllt --> Bauen wir das richtige Produkt?
• Verifikation: Bauen wird das Produkt richtig?

1. WER? Stakeholder definieren
2. WAS? Ziele definieren
3. WIE? Anforderungen definieren

• Benutzerklassen / Stakeholder identifizieren
• Benutzeraufgaben und -ziele und Geschäftsziele verstehen
• Umgebung, in der das Produkt eingesetzt werden soll, kennen
• mit Individuen, die jede Benutzerklasse repräsentieren, arbeiten + ihre funktionalen Bedürfnisse und Qualitätserwartungen verstehen

1. Vorbereitung: für Elicitation Scope und Agenda entscheiden, Ressourcen vorbereiten, Fragen vorbereiten
2. Durchführung: Elicitation Session durchführen
3. Follow Up: Notizen organisieren + teilen, offene Themen dokumentieren

• die von den Stakeholder erhaltenen Informationen analysieren, um ihr Aufgaben / Ziele von anderen Anforderungen zu unterscheiden
• High-Level-Anforderungen in ein angemessenes Level an Detail zerlegen
• Funktionsanforderungen ableiten
• Wichtigkeit von Qualitätsmerkmalen verstehen
• Anforderungen den in der Systemarchitektur definierten Softwarekomponenten zuweisen
• Implementierungsprioritäten verhandeln
• Lücken in den Anforderungen oder unnötige Anforderungen identifizieren

die gesammelten Nutzerbedürfnisse in geschriebene Anforderungen und passende Diagramme übersetzen, geeignet zum Verstehen, Überprüfen und Benutzen durch die beabsichtigte Zielgruppe

• vollständig
• korrekt
• gültig und aktuell
• vereinbart
• notwendig
• verständlich
• nachvollziehbar
• priorisierbar
• implementierbar
• konsistent
• klassifizierbar
• prüfbar
• eindeutig

• Format zum Erfassen von Nutzeranforderungen bei agilen Projekten in ein oder zwei Sätzen
• drückt Nutzerbedürfnis aus oder beschreibt eine Einheit von gewünschten Funktionalitäten
• legt den Nutzen der Funktionaltät dar

1. Wichtigkeit festlegen (muss, soll, wird)
2. Funktionalität identifizieren
3. Art der Funktionalität festlegen (- [selbstständige Systemaktivität], xy die Möglichkeit bieten [Benutzer-Interaktion], fähig sein [Schnittstellen-Anforderung])
4. Objekt identifizieren
5. logische und zeitliche Bedingungen formulieren
6. SOPHIST-Regelwerk anwenden

• ein Bild sagt mehr als 1000 Worte
• Information effizienter kommunizieren
• Diskussion erleichtern
• Dokumentation
• detaillierte Beschreibung

• Requirements Modelling Language
• Fokus: Bedürfnisse
• Ziele und Eigenschaften
• von Zielen zu konkreten Anforderungen
• RML: Startpunkt --> UML

• Objectives: Business Values, Eigenschaften / Features; z. B. Business Objective Model, Feature Tree
• People: Wer nutzt das System? z. B. Organisation Chart, Use Case
• Systems: Interface, Verhalten, Teile; z. B. User Interface Flow, Entscheidungstabelle, -bäume
• Data: Daten, Beziehungen; z. B. Data Flow Diagram, Zustandsdiagramm, -tabelle

• Unified Modelling Language
• Anwendungsstruktur, Verhalten, Architektur, Geschäftsprozesse, Datenstruktur

• Überprüfung der dokumentierten Anforderungen, um Probleme noch vor der Entwicklung zu korrigieren
• Entwicklung von Abnahmeprüfungen/Kriterien, um zu bestätigen, dass das Produkt die Bedürfnisse der Stakeholder erfüllen und die Geschäftsziele erreichen wird

• eine oder mehrere Personen, die nicht der Autor eines Arbeitsprodukts sind, untersuchen Produkt mit dem Ziel, Mängel und Verbesserungsvorschläge zu finden
• informell: Peer Deskcheck, Passaround, Walkthough
• formell: Inspektion

Bedingungen, die das Produkt erfüllen muss, um von dem Nutzer, Kunden, etc. akzeptiert zu werden

• wertet erwartete Nutzungsszenarien aus, um die Akzeptanz der Software festzustellen
• in agiler Entwicklung verwendet, um Details über eine User Story auszudrücken und festzustellen, ob eine User Story vollständig und richtig implementiert ist

• „Projects in Controlled Environments“
• skalierbare Projektmanagementmethode
• weltweit führend neben SCRUM
• freie Verwendung

• befristet
• einmalig
• unsicher
• Veränderungen
• bereichsübergreifend

• Zeit
• Kosten
• Qualität
• Risiko
• Umfang
• Nutzen

• 7 Grundprinzipien
• 7 Themen
• 7 Prozesse
• Tailoring

• Vermeiden
• Reduzieren
• Eventualplan erstellen („Plan B“)
• Übertragen (z. B. an Versicherung)
• Akzeptieren

• Ergreifen
• Ablehnen
• Steigern

• Abschätzung von Dauer und Aufwand/Kosten
• Beeinflussung von Projektplanung
• Unterstützung bei der Steuerung
• Erfolgsmessung nach Projektende

• magisches Dreieck (Time, Budget, Quality)
• unterschiedliche Komponenten einer Schätzung
  • Fachliche Konzeption
  • Technische Konzeption
  • Realisierung
  • Test & Qualitätssicherung, Dokumentation
  • Projektmanagement
  • Besprechung
  • Produktivsetzung & Systemunterstützung
  • Wartung
  • Risiko & Gewährleistung

• Dienstvertrag:
  • Pflicht zur Leistung (Auftragnehmer)
  • Pflicht zur Vergütung der Leistung (Auftraggeber)
  • keine Pflicht zum Erfolg für Auftragnehmer
• Werkvertrag
  • Pflicht zum mangelfreien Werk (Auftragnehmer)
  • Pflicht zur Abnahme & Zahlung (Auftraggeber)
• Risikokalkulation bei Softwareentwicklung
  • Dienstvertrag: erhöhtes Risiko beim Kunden
  • Werkvertrag: erhöhtes Risiko beim Lieferanten

• Klassendiagramm
• Paketdiagramm
• Objektdiagramm
• Kompositionsstrukturdiagramm
• Komponentendiagramm
• Verteilungsdiagramm
• Profildiagramm

• Use-Case-Diagramm
• Aktivitätsdiagramm
• Zustandsautomat

• Sequenzdiagramm
• Kommunikationsdiagramm
• Timingdiagramm
• Interaktionsübersichtsdiagramm

Was soll mein System für seine Umwelt leisten?

Wie realisiert mein System ein bestimmtes Verhalten?