SoED

Design Thinking ist ein Software Engineering Prozess welcher auf Requirements Engineering und Prototyping fokussiert ist.

Eine funktionale Beschreibung des System aus der User Perspektive mit folgenden Informationen:

• Funktionell & nicht funktionale Requirements

• Domain Requirements

• Erste Ideen Sammeln für das UI

• Structural elements (class, object, use case)
• Annotational elements (note)
• Grouping elements (package, module)
• Behavioral elements (activity, state)

Sie zeigen, was außerhalb der Systemgrenzen liegt. Definition von "out of scope" auf Systemebene

Wird verwendet um komplexität zu verringern.

Verwendung von Vererbungen (Inheritance)

Beudeutet dass ein object attribut oder methode während laufzeit verscheidene varianten haben kann

Von dieser Klassen kann keine Instanz (Konstruktor) erstellt werden. Dient als Oberklasse von der dann geerbt wird. Z.B. Pizza wäre die Oberklasse und Margherita, Procuitto die Unterklassen die von Pizza erben. Public abstract class BLABLA

1. analysis and design view (logical view)

   1. Zeigt die Grund Abstraktionen, als Objekte oder Klassen, auf.

   2. Für funktionale Anforderungen.
       

2. process view

   1. Zeigt auf wie das System sich währen der Laufzeit verhält
      shows how, at run-time, the system is composed of interacting processes

   2. Für nicht funktionale Anforderungen
       

3. implementation view (development view)

   1. Zeigt auf wie die Software aufgebaut und aufgeteilt ist für die Entwicklung

   2. Für das Projekt Management
       

4. deployment view (physical view)

   1. Zeigt auf wie die Komponenten auf die Hardware verteilt wird

   2. Für die Entwicklung und verteilung der Software
       

5. relation of all views to use cases or scenarios (+1)

   1. Für User und System Anforderungen

OOD modelliert das System als zusammengesetzte Objekte. Das Informationsmodell (Systemzustand) wird somit auf verschiedene Objekte verteilt

1) Use Cases zu System Inhalt

2) System Inhalt zu Architektur

3) Architektur zu Klassen model

4) Klassen zu Design Model

5) Design Model zu Implementation

• Generische Produke (Build to stock, BTS) vs. Kunden spezifische („angepasste“) Produkte (Build to order, BTO)
  • BTS: Produkt wird hergestellt unabhängig davon ob ein Kundenstamm besteht
    • Lizenzen werden verkauft
    • SW Hersteller besitzt alle Lizenzrechte
      • Analogie: Automobil
  • BTO: Produkt wird für, und in Absprache mit Kunden hergestellt
    • Arbeitszeit wird verkauft
    • Kunde besitzt alle Lizenzrechte
      • Analogie: Bauvorhaben

Verifikation: Zeigen dass das System den Spezifikationen entspricht

Validation: Zeigen/Sicherstellen dass das System den Anforderungen des Verwenders entspricht

• Change anticipation: Entwicklungsprozess beinhaltet Aktivitäten die eine Prognose zu den geplanten Änderungen erzeugt (e.g. Erstellung eines Prototyps mit Hauptfunktionen)
• Change tolerance: Die Prozesse sind so implementiert, dass Änderungen zu relativ geringen Kosten (= Zeit) umgesetzt werden können. Setzt einen inkrementellen Entwicklungsprozess voraus.

• Ein Prototyp ist eine initiale Version eines verwendeten Systems benutzt um bestimmte Konzepte und neue design Optionen zu demonstrieren. Meist werden eigene Sprachen und Tools fürs schnelle Prototyping verwendet. Ein Prototyp umfasst nicht alle Funktionalitäten des Endprodukts (Meist nur Prozesse die man besser verstehen möchte).
  • Vorteile: Kostengünstige Tests und Kundenfeedback für neue Konzepte, Denken „Out of the Box“ (e.g. starke Umstrukturierung, neue Libraries) möglich
  • Nachteile: Gefahr des Abschweifens vom Wesentlichen, (= unproduktive Zeit) Kundenfeedback kann unwesentlich sein („Dieser Button geht nicht“ etc.)
  • Anwendung: Prototypen werde in den folgenden Phasen eingesetzt:
    • Requirements engineering: Besseres Verständnis der Anforderungen
    • Design: Design Optionen und UI Designs ausprobieren
    • Test: Interface Integration Tests (?)

• Prototypen können meist nicht so verändert werden, dass alle non-funktionalen Anforderungen getroffen werden
• Prototypen sind in der Regel nicht dokumentiert
• Die Struktur des Prototyps ist meist schlecht, weil schnelle Resultate zählen

Pro

• Kosten sind vorsehbar (Voraussetzung ist gute Planung)
• Einfach zu verwenden
• Kontrolle über die Fertigstellungszeit

Contra

• Funktioniert nur gut wenn sich Requirements nicht ändern. Wenn sie sich ändern ist es nicht empfehlenswert
• Fortschritt in den einzelnen Phasen schwer zu erkennen
• Falsche Zeiteinschätzung für die einzelnen Phasen kann grosse Zeitverschiebungen verursachen

Pro

• Zwischenversionen können Kunden gezeigt werden und wenn gefordert, angepasst werden.
• Kostengünstigere Anpassung von Anforderungen
• Debug und Testen ist in kleinen Iterationen viel einfacher

Contra

• Kann sein dass Kunde jeden Tag etwas anderes will. So kommt man nie zu einer finalen Version
• Nicht geeignet wenn Ergebnis schon klar definiert ist. Da ist Waterfall geeigneter.
• Der Projektstatus ist nicht klar ersichtlich

1. Inception (Anwendungsfall für das system definieren (eine analyse))
2. Elaboration (Verständniss der Business umgebung und system architektur)
3. Construction (System designen, programmieren, testen)
4. Transition (System in die Umgebung einbinden)

• Requirements im Dokument festhalten
• Wiederverwendbare Komponenten verwenden
• UML verwenden um Software abzubilden
• Kontrolle über Änderung der Software
• Softwarequalität sicherstellen

• Kunden involvieren (Im Entwicklungsprozess miteinbeziehen)
• Schrittweise Lieferung
• Leute nicht Prozesse (Mitglieder sollten frei sein zu programmieren)
• Veränderungen einbeziehen (Vorbereitet sein auf Systemänderungen)
• Einfachheit beibehalten (Komplexität verhindern im System)

Leute nicht Prozesse: Wenn „Cracks“ freie Hand haben heisst, das noch lange nicht das etwas Gutes dabei herauskommt.

User stories: Kunde wird in Entwicklung eingebunden. User stories oder scenarios als user requirements

Break down: Diese werden dann vom Entwicklerteam zu kleinen Tasks gebrochen

Plan release: Kunde wählt die zu umsetzende Story für den nächsten release

Develop: Keine Requiremets Festhaltung sondern nur Storyboard Implementierung

Evaluate: Feedback vom Kunden

• Benutzeranforderungen (Systembeschreibung aus Kundensicht, Lastenheft)
• Systemanforderungen (Systembeschreibung aus technischer Sicht, Pflichtenheft)

Funktionale Anforderungen

• Was soll das System leisten?

• Welche Dienste soll es anbieten?

• Eingaben, Verarbeitungen, Ausgaben

• Was es NICHT machen soll

Nicht-funktionale Anforderungen

Müssen messbar sein.

• Wie soll das System/einzelne Funktionen arbeiten?

• Qualitätsanforderungen wie Performanz und Zuverlässigkeit

Es gibt drei Haupttypen von nun-functional Requirements

• Produkt Anforderungen
  • Z.B. Antwortzeiten, Startzeiten, Ausfallsicherheit
• Organisatorische Anforderungen
  • z.B. Prozessstandards, Implementationsanforderungen
• Externe Anforderungen
  • z.B. Juristische Anforderungen, Kompatibilität mit Umsystemen

Die Domäne setzt neue Anforderungen am System

• z.B. Bremskraft eines Zuges muss im Regen anders gehandelt werden als im Sommer
• Domäne Requirements können wiederum neue functional Requirements sein
• ISO Standards

Wenn Domänenanforderungen nicht erfüllt sind, kann das System nicht funktionieren.

Szenariobeschreibung sollte enthalten:

• Die Ausgangssituation
• Der normale Fluss der Ereignisse
• Was kann schief gehen
• Gleichzeitige Tätigkeiten (falls vorhanden)
• Der Zustand, wenn das Szenario beendet ist

1. Scoping (Recherchemaßnahmen werden geplant und eingeleitet)
2. Research (Hier gilt es, die Zielgruppe und deren Bedürfnisse zu verstehen)
3. Synthesize (Durch Storytelling erzählen sich die Teammitglieder ihre Erkenntnisse und Erfahrungen
4. Design (Ziel ist das Produzieren von möglichst vielen Ideen anhand von Storyboards)
5. Prototype (Ideen anhand von Prototypen ausprobieren)

a.Low-Fidelity Prototyping

Bevorzugter Weg zum Prototypen in Design Thinking. Verwendet ein Medium, das im Gegensatz zum endgültigen Medium ist, z.B. Papier, Karton

b.Card-based Prototypes

Ausgehend von einem Storyboard, entwerfe eine Karte für jeden Schritt (Papierkarten). Oft für Software verwendet, wo der Benutzer durch verschiedene Fenster (Bildschirme) navigiert: Webseiten, mobile Anwendungen

1. Validate (Feedback von Zielgruppe für Verbesserungen, Prototyp kann hier verworfen werden)

Beschreibt die Anforderungen aus Sicht des Auftraggebers. Was soll das System können.