briefings Architekturen zähmen leicht gemacht
Architekturen zähmen leicht gemacht
Methodiken nicht nur für Software, um aus dem Anforderungs-Dschungel einen übersichtlichen, wohlgepflegten Garten zu gestalten. Egal ob du erst den Debugger fürs Leben gefunden, der Coding-Ninja des Projekts bist oder noch keine Berührungspunkte mit Softwareentwicklung hattest - in diesem Talk gibt es das nötige Toolset und Roadmap um Projekte zu planen, effektiv zu dokumentieren und zu managen.
Architekturen
zähmen leicht gemacht
Vom Anforderungs-Chaos zu strukturiertem Code
Warum Architektur?
- Unvermeidbare Basis jeder Software
- Frühzeitige Fehlererkennung durch geplante Strukturen
- Vermeidung von unkontrollierbarer Legacy-Software
- kontinuierliche Anpassung
Warum Architektur?
Haus der Geschichte, Darmstadt
Internetfund, toter Vogel
Methoden zur Architekturgestaltung
Wo fängt man an?
Wie startet man?
Was soll dokumentiert werden?
Grundelemente
- Unabhängige Bausteine
- Beziehungen/Relationen über definierte Schnittstellen
- Konzepte und Prinzipien
Kontext
- Anpassung an Geschäftsziele und -umfeld
- rechtliche und technische Rahmenbedingungen
- Balancierung konkurrierender Projektfaktoren
1. Stakeholder-Prio-Matrix
1. Stakeholder-Prio-Matrix
begleitend zur Matrix eine übersichtliche Tabelle
Beispiel:
| Rolle | Beschreibung | Ziel/Intention | Kontakt | Prio | Infobedarf |
|---|---|---|---|---|---|
| Auftraggeber | Dagobert Duck | Ertrag erzielen | …@e.mail | Hoch | aktueller Stand |
| Betreiber | Rechenzentrum | SaaS anbieter | …@e.mail | Medium | Betriebshandbuch |
| Besucher | Kunde | Dienst nutzen | Medium | FAQ | |
| … |
2. Architectural Significant Requirements
- Funktionelle Anforderungen
- Randbedinungen
- Nicht-Anforderungen
- Qualitätsanforderungen
2. Architectural Significant Requirements
Hilfestellung ISO25010 und Qualitätsbaum
2. Architectural Significant Requirements
Beispiel
| Funktionell | Randbedingung | Nicht-Anforderungen | Qualitätsanforderungen |
|---|---|---|---|
| Profil Nutzer (F1) | mehrere Nutzer (R1) | Dezentrales System (N1) | Skalierbar auf ca 300-3 Mio. Nutzer, R1 (Q1) |
| Registrierung/Login (F2) | Personenbezogene Daten (R2) | MFA/2FA (N2) | Transportsicherheit, F1, F2, R2 (Q2) |
| Bilder Upload (F3) | Nicht-technik-affine Nutzer (R3) | iOS App (N3) | Bearbeitung vollständig in GUI, R3 (Q3) |
| … | … | … | … |
3. Kohäsionskriterien
Clustern der ASR nach Kriterium
- Funktion
- Eigenschaft
- Inhalt
- Services
- …
keine Kriterien mischen!
3. Kohäsionskriterien
Beispiel
4. Architecture Decision Record
- in Architektur dreht sich alles um Entscheidungen
- Entscheidungen diskutieren und mit Anforderungen abgleichen
- Entscheidungen systematisch festhalten
- Regel: Kill your Darlings
4. Architecture Decision Record
Grundlegender Aufbau:
| ADR | #Nr |
| Warum: | (Um was geht es?) |
| Einflüsse: | (Stakeholder) |
| Kriterien: | (Anforderungen) |
| Alternativen: | (Vergleichen) |
| Konsequenzen: | (Positiv/Negativ) |
4. Architecture Decision Record
Beispiel 1/3:
| ADR | #1 |
| Warum: | Basis Aufbau der Anwendung |
| Einflüsse: |
|
4. Architecture Decision Record
Beispiel 2/3:
| Kriterien: |
| ||||||||||||||||||||
| Alternativen: |
=> Wahl fällt auf Client-Server |
4. Architecture Decision Record
Beispiel 3/3:
| Konsequenzen: |
|
Agile Architektur
Dokumentation
- Klarheit und Konsistenz
- Anpassung an die Bedürfnisse verschiedener Stakeholder
- Wartung der Dokumentation als Teil des Entwicklungsprozesses
Dokumentation
- Angemessenheit
- Korrektheit
- Wartbarkeit
- Verständlichkeit
Arc42
Cards42
Blickrichtung ändern, neue Wege und Lösungen finden
iSAQB
Viele Fachartikel, Podcast & Fortbildungen
Roadmap.sh
Guter Startpunkt, mehr technische Anforderungen & Verständnis
Quellen & mehr
END OF BRIEFING
MAIL:
robert.jeutter@wieerwill.dev
MASTODON:
https://chaos.social/@wieerwill
LINKEDIN:
https://www.linkedin.com/in/wieerwill