SoED

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.

Beschreibt die Anforderungen aus Sicht des Auftragnehmers.

Umsetzungs des Lastehefts. Wie wird das System die geforderte Leistung erbringen.

Creational Design Patterns

Dienen der Erzeugung von Objekten. Sie entkoppeln die Konstruktion eines Objekts von seiner Repräsentation.

Structural Design Patterns

Erleichtern den Entwurf von Software für Beziehungen zwischen Klassen.

Behavioral Design Patterns

Modellieren komplexes Verhalten der Software.

+ Wissenstransfer

+ Braucht weniger Zeit zum Suchen des richtigen Design Pattern

- Entwicklungscode und Komplexität nimmt zu

- Pattern kann nicht genau als Lösung für ein Problem verwendet werten

View

• ist für die Präsentation von Daten zuständig
• initialisiert, organisiert und speichert alle Oberflächen Elemente
• ist für Style und Layout zuständig

Controller

• verbindet View und Model
• enthält Steuerungslogik
• delegierte Geschäftslogik, enthält sie aber nicht!

Model

• speichert Daten
• besitzt nur Getter- und Setter-Funktionen

System infrastructure frameworks

Unterstützen die Entwicklung von Systeminfrastrukturen wie Kommunikation, Benutzeroberflächen und Compiler.

Middleware integration frameworks

Unterstützung der Komponentenkommunikation und des Informationsaustausches.

Enterprise application frameworks

Unterstützen die Entwicklung von spezifischen Geschäftsanwendungen wie Telekommunikation oder Finanzsysteme.

+ Geschwindigkeitsvorteil (Die Entwicklungszeit verringert sich. Dies wird hier mithilfe von vorgefertigten Funktionen und Codeblöcken umgesetzt.)

+ Kosten (Die meisten populären Frameworks sind kostenlos verfügbar und haben keine Lizenz. Auch billiger für den Endkunden.)

- Strukturelle Einschränkungen (Die Struktur ist vorgegeben. Das bedeutet, jedes Framework hat seine Grenzen und Sie müssen Ihre Arbeit diesen anpassen.)

- Codeballast (Arbeitet man mit einer vorgegebenen Struktur, nutzt man in den seltensten Fällen alle Möglichkeiten aus. So kann es zu Ballast kommen, den man ungenutzt herumschleppt.)

Model

Das Modell stellt die Logik der View dar. Über das Modell muss jedoch alle Funktionalität erreichbar sein, um die View betreiben zu können. Die Steuerung des Modells erfolgt allein vom Präsentator. Das Modell selbst kennt weder die View noch den Präsentator.

View

Die Ansicht enthält keinerlei steuernde Logik und ist nur allein für die Darstellung und die Ein- und Ausgaben zuständig. Sie erhält weder Zugriff auf die Funktionalität des Präsentators noch auf das Modell. Sämtliche Steuerung der Ansicht erfolgt vom Präsentator.

Presenter

Der Präsentator ist das Bindeglied zwischen Modell und Ansicht. Er steuert die logischen Abläufe zwischen den beiden anderen Schichten und sorgt dafür, dass die Ansicht ihre Funktionalität erfüllen kann.

Roles

• Product owner (Represent the customer, not necessarily is the customer)
• Scrum master (coach the team, arranges all scrum meeting, keep track of backlogs)
• Developer
• Cusomter, users (represent business and user interests)
• Managers (Gesundes Arbeitsumfeld schaffen und Ressourcenentscheidungen treffen)

Artifacts

• Product backlog (a list of user stories)
• Relase backlog (for large project, the product may be developed in several release cycles)
• Sprint backlog (breaks down items from product (release) backlog into implementation tasks)
• Burndown chart (visualisiert Restaufwand Schätzungen vs verbleibenden Ressourcen)
• Actual design models, code

Meetings

• Product planning (product owner presents product backlog)
• Release planning (if product is to be delivered in releases)
• Sprint planning (create sprint backlog for the upcoming cycle)
• Daily scrum (short daily meetings where team members share their progress, planning etc.)
• Code review (code review vom zugeteilten reviewer)
• Sprint, product review (developers demonstrate the current state of the product based on product (or release) backlog items)

1. Die anfängliche Phase ist eine outline planning phase, um die allgemeinen Ziele für das Projekt zu etablieren und die Softwarearchitektur zu entwerfen
2. Gefolgt von einer Reihe von Sprint-Zyklen, wo jeder Zyklus ein Inkrement des Systems entwickelt
3. Project closure phase wickelt das Projekt ein, vervollständigt die benötigten Dokumentation wie Systemhilfe und Benutzerhandbücher und bewertet dies lessons learned from the project.

(1) Folgen Sie Code-Konventionen (Formatierung, Benennung, Kommentierung)

(2) Kontrolle der Sichtbarkeit von Informationen in einem Programm

(3) Überprüfen Sie alle Eingaben auf Gültigkeit

(4) Überprüfen Sie die Array-Grenzen

(5) Timeouts einbinden beim Aufruf externer Komponenten

(6) Minimieren Sie die Verwendung von fehleranfälligen Konstrukten 

Unit Testing

Individuelle Programmeinheiten oder Klassen. Konzentrieren sich auf die Prüfung der Funktionalität von Objekten oder Methoden

2 verschiedene unit tests Typen

Verifikationstest: spiegelt den normalen Betrieb eines Programms wider und sollte zeigen, dass die Komponente wie erwartet funktioniert.

Defekttest: sollte explizit versuchen, Mängel aufzudecken, z. B. verwenden Sie abnormale Eingaben, um zu überprüfen, ob diese ordnungsgemäß verarbeitet werden und nicht die Komponente abstürzen

Component testing

Fokus auf das Testen von Komponenten-Schnittstellen

System testing

Einige oder alle Komponenten in einem System integriert sind und das System als Ganzes geprüft wird. Fokus auf das Testen von Komponenten-Interaktionen 

+ Code wird fortlaufend optimiert und ist leicht zu ändern.

+ Aktive Fehlervermeidung, Fehler werden früher entdeckt.

+ Leicht zu testende Software wird bevorzugt getestet und damit ausgiebiger.

- Man kann einfache Testfälle schreiben und die komplizierten weglassen

- Eine konsequente Durchführung ist notwendig.

- Akzeptanzprobleme: Wie soll man was testen, was noch nicht existiert?

BSD (Berkley Standard Distribution License)

• Eine Non-Copyleft-Lizenz
• Änderungen am ursprünglichen Code müssen deutlich gekennzeichnet sein
• Z.B. PHP Lizenz

Apache License 2.0

• Eine Non-Copyleft-Lizenz
• Wichtigstes Programm ist der Apache Webserver.

GPL (GNU General Public License)

• Eine Copyleft Lizenz

LGPL (GNU Lesser General Public License)

• Ist eine Variante der GPL-Lizenz, in der Sie Komponenten schreiben können, die mit dem LGPL-Quellcode verknüpft sind, ohne die Quelle dieser Komponenten veröffentlichen zu müssen

BSD und Apache: Resultat muss nicht OpenSource sein

GPL und LGPL: Resultat muss OpenSoure sein

+ Effizient

+ Wiederverwendung

+ 4-Augen-Prinzip

- Lizenzierung

- Weniger Support als von grossen Firmen, da entwickler kein Interesse

- OSS zu wenig bekannt, schlechtes Image

• black-box interface: typically public methods
  • integrated via association, aggregation, and implementation (for Java interfaces)
• white-box interface: typically protected methods
  • implemented via inheritance

▶ Analysis – investigating what the system should do;

▶ Specification – defining what the system should do;

▶ Design – defining the organization of the system;

▶ Implementation – implementing the system;

▶ Validation – checking that it does what the customer wants;

▶ Evolution – changing the system in response to changing customer needs.

1. Waterfall model (plan-dirven)
2. Incrementel model (plan-dirven or agile)
3. Reuse-oriented software engineering (plan-dirven or agile)

• Man hat was vor den Augen
• Kostengünstige Demo, damit alle vom gleichen sprechen
• Neue Ideen können nach dem prototyping auftreten
• Konstruktives Feedback vom Kunde

Eine disziplin um die Software von der Produktion bis hin zu wartung beim Kunden zu meistern

• Beinhaltet nicht nur das coding
• Projekt management inbegriffen
• Herstellung von Werkzeuge um Software herstellung zu unterstützen

• Erfüllt die funktionsanforderungen
• Keine Bugs
• Wartungsarm
• Einfach zu benutzen
• Änderbarkeit

• Technologie change
• Neue Requirements
• Security

• XP sagt aufwändige Softwarearchitektur bringt nichts, da es ja sowieso wieder ändert. Also einfach gleich anfangen.
• Konstantes Code improvement (refactoring) um Änderungen einzupflegen

In XP werden erst die Tests geschrieben, dann die Funktionalität. Der Unterschied ist dass man sich von Anfang an Gedanken macht wie das Ende aussehen soll.

Diese definieren Systemeigenschaften wie:

• Zuverlässigkeit,
• Reaktionszeit
• Speicherkapazität

Und constraints wie:

• I/0-Geräte-Fähigkeit,
• Bildschirmauflösung,

Nicht-funktionale Anforderungen können kritischer sein als funktionale Anforderungen. Wenn diese nicht erfüllt sind, kann das System nutzlos sein.