SWAR

• Er organisiert den Entwicklungsprozess
• Er überwacht die Fortschritte
• Er kontrolliert die Kosten
• Er achtet auf Fristen
• Er vermietet das Personal
• Er kommuniziert mit dem oberen Management und dem Kunden Management

Software-Architektur ist eine Reihe von maßgeblichen Design-Entscheidungen über ein Software-System zu treffen.

• Er muss über die Architektur sprechen können und sich somit mit der Architektur auskennen
Denn er ist verantwortlich für die technische Qualität des Codes und die Architektur
• Er sollte gut kommunizieren können, besonders mit dem Produktmanager (od. Projektmanager?!), er kommuniziert auch an Kunden (Domain-Experte)
• Er muss die Anforderungen der Domäne verstehen und die Grenzen der Technik kennen
• Er muss sich gut mit Frameworks und Bibliotheken, allgemein Technologien auskennen, den er macht die Evaluierung/er wählt die geeignete Technologien aus
• Dokumentenverwaltung

• Ball of Mud – es gibt kein Konzept, alles entsteht so wie es kommt
• Schichten Architektur – Software wird in austauschbare Einheiten aufgeteilt die übereinander liegen.
• Komponentenbasierte Architektur – Software wird in austauschbare Einheiten aufgeteilt die mit einander verbunden werden können
• Product Line:  Gleiche Anwendung, aber § Unterschiedliche Hardware § Unterschiedliches FeatureSet § Unterschiedliche UI § Unterschiedliches Backend
• Product Family:  Ähnliche Anwendung, Aber § Verschiedene Datensätze § Verschiedene Abstraktionen 

• Ein Software-Architekt und ein Produkt-Manager, die sehr viel interagieren
• Das Team organisiert sich um die Beiden herum

• „Baumaterial“ ist im wesentlichen frei und extrem flexibel
• Änderung und Erweiterung ist möglich auch spät im Prozess
• eine neue Instanz (Kopie) zu schaffen, ist kostenlos
• Die Prüfung ist möglich, sofort und nahezu kostenlos
• Alle Kosten sind in direktem Zusammenhang mit menschlicher Arbeit 

Product Line

Gleiche Anwendung, aber

• Unterschiedliche Hardware
• Unterschiedliches Feature-Set
• Unterschiedliche UI
• Unterschiedliches Backend

Verursacht durch: Verschiedene Arten von Kunden, verschiedene Preismodelle, unterschiedliche rechtliche Beschränkungen

Product Family

Ähnliche Anwendung

• Ähnliche Domain
• Ähnliche Verfahren
• Ähnliche Schnittstellen
• Eine ähnliche Technologie

Aber: verschiedene Datensätze und verschiedene Abstraktionen
Verursacht durch Produktivitätsgewinne, wenn die Ähnlichkeiten extrahiert werden können

• Ähnliche Domaine
• Ähnliche Verfahren
• Ähnliche Schnittstellen
• Eine ähnliche Technologie

Beispiel:

-Web-System für Banken und Versicherungen

->Jeder Kunde hat einen anderen Satz von Abstrak6onen und Prozessen

->Aber die allgemeine Architektur ist die gleiche 

• Extreme Code Reviews durch Pair Programming
• Extreme Testing durch Testing-First
• Einfachheit (Simplest thing that could possibly work)
• Integration durch Continuous Integration und tägliche Builds
• Short Iterations (Minuten, Stunden, Tage)
• Continuous Feedback und Customer on Site

• Die linke Seite des „V“ steht für die Zersetzung von Anforderungen und Erstellung von Systemspezifikationen
(Anforderungsdefinition, Grobentwurf, Feinentwurf, Modulimplementierung)
• Die rechte Seite des „V“ stellt die Integration von Teilen und deren Validierung dar
(Modultest, Integrationstest, Systemtest, Abnahmetest)

Bei agilen Vorgehensmodellen sind/ist …

• Individuen und Interaktionen über Prozesse und Tool
• Lauffähige Software über eine umfassende Dokumentation
• Zusammenarbeit mit dem Kunden über Vertragsverhandlungen
• Auf Reaktion reagieren nicht nach Plan zu arbeiten

• Individuen und Interaktionen über Prozesse und Tools
• Lauffähige Software über eine umfassende Dokumentation
• Zusammenarbeit mit dem Kunden über Vertragsverhandlungen
• Auf Reaktion reagieren nicht nach Plan zu arbeiten

• der Product Owner ist verantwortlich für den Product Backlog, er sammelt hierfür Input von Kunden, dem Team und den Managern
• Aufbauend auf dem Product Backlog findet das Sprint Planung Meeting mit dem Team statt. Hier werden die Items geschätzt, woraus der Sprint Backlog folgt. Dieser gibt an, was das Team bis zum Sprint Ende zu schaffen hat.
• Ein Sprint dauert zwischen 1 und 4 Wochen
• Es finden tägliche Daily Standup Meetings statt
• Der Scrum Master.. …(keine Angabe in den Folien) -> ist für die Mitarbeiter im Team verantwortlich.
• Nach jedem Sprint findet sowohl ein Sprint Review als auch das Sprint Retrospektive statt
• Beim Sprint Review wird geprüft, inwiefern welche Items des Backlogs geschafft wurden
• Beim Sprint Retrospektive …(keine Angabe in den Folien)

• Design ändern
• Automatisiertes Testen aller Artefakte
• Automatisierte Konsistenz aller Artefakte
• Einfachheit

Vorteile: Kostenkurve wird flach gehalten, höhere Qualität, Erweiterbarkeit und Nachhaltigkeit der Software


Nachteile: Nicht geeignet für jedes Team, erfordert hohe Kompetenz und Kommunikationsfähigkeit

Das Wasserfallmodell ist ein lineares (nicht iteratives) Vorgehensmodell das in Phasen organisiert wird.

Jede Phase hat vordefinierte Start- und Endpunkte mit eindeutig definierten Ergebnissen.

In Meilensteinsitzungen am jeweiligen Phasenende werden die Ergebnisdokumente verabschiedet.

Problematik:

• Das Hauptproblem Sind nachgewiesene lange Feedback-Schleifen

• Probleme in späten Stadien Führen zu hohen Kosten

• Und Iterationen sind nie beschränkt 

• Um ein Problem zu analysieren und zu lösen erfordert dies a = x Minuten

• Um ein Problem zu finden und zu beheben werden Kosten p von >10*a benötigt

• Während dem Testen werden Kosten t von >10*p benötigt

• Behebung nach der Entwicklung benötigt Kosten f von >10*t

Schlussfolgerung:

- Treffen Sie Entscheidungen so früh wie möglich

- Erkennen Sie Probleme so früh als möglich

- Analysieren und Modellieren Sie alles intensiv

- Implementieren Sie genau was modelliert wurde