SWEN2

System ist eine Abfolge von Datenbezogenen Transformationen

Batch Sequential und Pipes and Filters

Wir erschließen bessere Wege, Software zu entwickeln,
indem wir es selbst tun und anderen dabei helfen.
Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden,
schätzen wir die Werte auf der linken Seite höher ein.

1. Kunden zufriedenstellen durch kontinuierliche Auslieferung funktionierender Software
2. Veränderung sind in jeder Phase des Projekts willkommen
3. Funktionierende Software alle paar Wochen / Monate liefern (kürzere Zeitspanne besser)
4. Kunde und Entwicklern sollten täglich zusammenarbeiten.
5. Entwickeln mit motivierten Teams, diesen Vertrauen und ein gutes Umfeld schaffen.
6. Persönliche Kommunikation bevorzugen
7. Funktionierende Software als wichtigstes Fortschrittsmass
8. Nachhaltige Entwickelung => Kunde und Entwickler sollen das Tempo halten können
9. Ständiges Augenmerk auf teschnische Exzellenz und gutes Design
10. Einfachheit statt unnötiger Komplexität
11. Selbstorganisierte Teams
12. Regelmässige Reflektion

Kontinuierliche Auslieferung

Änderungen sind jederzeit willkommen und möglich

Kunde und Entwickler arbeiten täglich zusammen

Regelmässige Reflektion

Zentrale Aufgabe ist Zugriff und Aktualisierung von Daten eines Repositories

Repository / Blackboard

Robert C. Martin

Autor mehrerer Bücher zum Thema XP und Agiler Entwicklung. Gibt Vorträge und schreibt Artikel auf verschiedenen Plattformen. Seine Firma berät Firmen zu den Themen XP und agile.

Dave Thomas

War Mitautor von "The Pragmatic Programmer". Glaubt, dass das Herzen eines Projekts die Personen sind und nicht die Methode.

Alistair Cockburn

Bekannt für seine Interviews von Projektteams. Arbeitet an Empfehlungen für Agile Softwareentwicklung.

Martin Fowler

Chefwissenschaftler von Thoughtswork. Eine Firma für Softwareentwicklung und Beratung. Autor von mehreren Büchern über XP, Refactoring und UML

Ron Jeffries:

Autor von XP Büchern und gibt regelmässig Vorträge über XP. Ausserdem sehr aktiv in Online Foren.

Definition: Besteht aus einer beliebigen Anzahl miteinander kommunizierender Elemente. Die Synchronisation erfolgt ausschliesslich über die Kommunikationskanäle zwischen den Elementen und kann sowohl synchron als auch asynchron erfolgen.

Stil: Independent Components

Anwendung: Parallelverarbeitung. 

Beispiel: Springer Problem. Lösung durch Backtracking

+ Einfache Modellierung, Skalierbarkeit

- Komplexität der einzelnen Elemente

                            Agile Values

                            ----------

                          Prinzipien / Managment Practices!

             --------------------------------------------

                     Engineering Practices

--------------------------------------------------------------------------

Values:

Kommunikation, Funktionierende Software, Zusammenarbeit und Flexibilität

Prinzipien:

Die 12 Agile Prinzipien

Definition: Dieser Ereignisgesteuerte Architektur Stil definiert Architekturen, deren Prozesse über Events miteinander kommunizieren.

Stil: Independent Components

Anwendung: GUI, Real-time Systeme 

Beispiel: React, MVC

+ Unabhängigkeit der Elemente, Einfach zu ändern

- Non-Deterministisches Verhalten der Elemente

Risk:

Project cancelledSystem does not evolve gracefully (defect rate increases)Defect rateBusines misunderstoodBusiness changesFalse feature richStaff turnoverXP gibt uns Prinzipien und How-Tos, um mit diesen Risiken umzugehen

4 variables in Agile Development:

Zeit, Ressourcen, Qualit�t, Scope. Die ersten drei sind meistens fix. Daher sollte Scope flexibel sein!

Cost of Change:

Dir kosten kos änderungen sollen nur minimal steigern. Z.b. durch automatisierte tests.

Definition: Fixer Kommunikations-Mechanismus zwischen aufrufendem Element und aufgerufenen Element

Stil: Call-and-Return

Anwendung: Structured Programming, Client-Server

+ Definierter Kontrollfluss

- Skalierbarkeit, Anwendungsfreiheit

https://www.youtube.com/watch?v=y6RfqmTZejU

Cynefin wurde entwickelt um vier Arten von Probleme zu Unterscheiden:

Stil: Call-and-Return

Anwendung: Allgemeines Design, Client-Server

+ Universell

- Komplexität, Anwedungsfreiheit

Exaptation:

Ein Feature anders benutzen als es gedacht war. Statt etwas zu erfinden etwas bestehendes weiterentwickeln (beispiel Apple).

Cynfein:

Cynefin unterscheidet zwischen 4 + 1 verschiedenen Problemdomänen

• Obvious:
  • Probleme, deren Lösung schon bekannt ist und bei denen es keine vorhergehende Analyse bedarf
  • Sense - Categorize - Respond
  • Best Practice schon bekannt
• Complicated:
  • Probleme welche vorhersehbare Lösungen haben, aber von Experten gebaut werden müssen. (z.B: eine Login Form)
  • Sense - Analyze - Respond
  • Good Practice (Lösung grösstenteils bekannt)
• Complex:
  • Probleme welche noch nicht gelöst sind. Hier wird in einer "sicheren Umgebung" (z.B. Sprint in SCRUM) probiert und angepasst bis eine Lösung gefunden wurde. Die Methodik muss sich dem Problem anpassen können.
  • Probe - Sense - Respond
  • Emergent Practice (passt sich dem Problem an)
• Chaos:
  • In der Software Entwicklung bedeutet Chaos Probleme welche unvorhergesehen sind. z.B. Bugs welche sofort gefixt werden müssen
  • Act - Sense - Respond
  • Novel Practice
• Disorder:
  • Wenn unklar, in welche Domäne ein Problem fällt und man zu seiner favoritisierten Methoden zurückgreift um das Problem zu lösen.

Definition: Schichtenmodelle sind hierarchisch gegliedert und teilen die Aufgaben eines Gesamtsystems in Schichten auf. Das Spektrum der Elemente, die einer bestimmten Schicht zugeordnet werden können, wird eingeschränkt. 

Stil: Call-and-Return

Anwendung: Multi-tier-architecture. 

+ Konzeptionelle Integrität, Lokalität der Änderungen

- Komplexität, Anwendungsfreiheit

Definition: Eine abstrakte Maschine – also ein hypothetischer Computer mit den definierten Elementen für deren inneren Aufbau

Stil: Virtual Machine

Anwendung: Prozessor- und Betriebssystem-Simulation 

Beispiel: Java-VM

+ Portabilität, Flexibilität

- Performance

Eine der ersten agilen Entwicklungsmethoden. Es ist eine Methode um Probleme mit unklaren und sich verändernden Anforderungen zu lösen. Es stellt den Mensch und nicht das Produkt in den Mittelpunkt. XP ist ein Set von verschiedenen Werten, Praktiken und Prinzipien.

Der name extreme kommt daher, dass bestehende good practices auf ein extremes Level gehobern werden. Beispiel: Code Review findet nicht nur bei jedem PR statt sondern kann ständig durch Pair Programming stattfinden. Unit Tests werden nicht erst im nachhinein sondern zusammen mit der Software entwickelt (TDD).

Wie Scrums gibt es kurze Entwicklugnsphasen und häufige Releases. 

Definition: Generalisierung des Interpreter. Zentrale Eigenschaft ist die Trennung zwischen der Maschine an sich und den Regeln, die die Maschine beschreiben.

Stil: Virtual Machine

Anwendung: Expertensysteme

+ Flexibilität durch Regelwerk

- Komplexität, Performance

Features werden in einem Planning Game vom Entwicklerteam und mti dem User zusammen spezifiziert und abgeschätzt. 

Der Kunde schätzt den Businessvalue eines Features und das Entwicklerteam die technischen Kosten.

KERMF!!

Core Values:

• Kommunikation
  • Gemeinsam die Lösung finden, direkte Kommunikation im Team und mit dem Kunden
• Einfachheit
  • Geschaffenen Wert im Verhältnis zum Aufwand maximieren.
• Feedback
  • Software regelmässig vorführen und Feedback einfliessen lassen und ggf. Prozess adaptieren.
• Mut
  • Wahrheit über den Fortschritt eines Projekts aussprechen
• Respekt
  • Gegenseitiger Respekt im Team und Respekt dem Kunden gegenüber.

Definition: Die Transformationen auf den Daten erfolgen durch voneinander unabhängige Elemente dieses Architektur Stils. Dies bedeutet, dass die Daten als ganzes eingelesen werden, um dann transformiert und anschliessend wieder als Ganzes abgelegt zu werden.

Stil: Data Flow

Anwendung: Host Systeme

+ Datensteuerung

- Flexibilität, Interaktion

Definition: : Die Transformationen auf den Daten erfolgen lokal (Filters) mittels Streaming (Pipes). Dies bedeutet, dass ein eingehender Data Stream laufend in einen ausgehenden Data Stream umgewandelt wird

Stil: Data Flow

Anwendung: Software Converter, Compiler

+ Flexibilität, Verteilung

- Komplexität

Fundamentale Prinzipien:

• Rapid Feedback
  • schnellst mögliche Rückmeldung
• Assume simplicity:
  • Davon ausgehen, dass eine einfache Lösung existiert
• Incremental change:
  • Änderungen erfolgen in der Regel inkrementell
• Embracing change:
  • Änderungen sind zu erwarten und vorzusehen
• Quality work: 
  • Bestmögliche Lösung

Definition: In Repository Architecture Style, the data store is passive and the clients (software components or agents) of the data store are active, which control the logic flow. The participating components check the data-store for changes.

Stil: Data Centered

Anwendung: Stammdatenverwaltung

+ Einfach

- Single Point of Failure

• Pair Programming
• TDD
• Keine Überstunden
• Wöchentlicher Zyklus
• CI / CD
• Inkrementelles Design
• Informativer Arbeitsplatz

Definition: In Blackboard Architecture Style, the data store is active and its clients are passive. Therefore the logical flow is determined by the current data status in data store. It has a blackboard component, acting as a central data repository, and an internal representation is built and acted upon by different computational elements.

Stil: Data Centered

Anwendung: Datengesteuerte Kontrollsysteme

+ Skalierbarkeit

- Anwedung Eingeschränkt

Jedes sollte so klein wie möglich sein und möglichst viel Businessvalue beeinhalten / die wichtigsten Requirements abdecken. Lieber häufiger Releasen statt nur einmal pro Jahr. Jedes Release sollte komplett funktionieren.

Jedes im Team inklusive dem Kunden muss das System welches entwickelt wird verstehen und über ein gemeinsames Vokabular verfügen.

Das beste Design ist das, welches keine doppelten Code hat, alle Tests laufen und möglichst wenige Klassen und Methoden beinhaltet. Kein grosses Design im voraus sondern inkrementeller Aufbau.

Features existieren nicht ohne automatisierte Tests. 

Development cycle: Requirements => Tests => Code => Refactor

TDD = zuerst Tests schreiben und dann entwickeln (Test driven development)

• Automatisierte Tests erlauben Refactoring ohne Angst. 
• Bestehenden Code ständig verbessern.

Aller Code wird zu zweit geschrieben, ein Programmer entwickelt und der andere denkt über den grösseren Kontext und refactoring nach. Teams häufig wechseln.

Jeder Code darf ohne Nachfrage verbessert werden. Jeder weiss wie jeder Teil eines Systems funktioniert.

Build Prozess muss automatisiert sein und mindestens einmal am Tag laufen.

Keine Überstunden. Ziel: jeden Morgen frisch sein und jeden Abend zufrieden.