146 lines
12 KiB
TypeScript
146 lines
12 KiB
TypeScript
|
||
import { Exercise } from '../types';
|
||
|
||
export const swaExercises5: Exercise[] = [
|
||
{
|
||
id: 'swa-4-1-doku',
|
||
title: '4.1 - SWA – Architekturdokumentation',
|
||
parts: [
|
||
{
|
||
id: '4-1-a',
|
||
prompt: 'Warum sollte man Architektur dokumentieren? Was sind die Herausforderungen?',
|
||
solution: 'Gründe für Dokumentation:\n- Kommunikation: Gemeinsames Verständnis für alle Stakeholder schaffen.\n- Wissensbewahrung: Architekturwissen langfristig sichern.\n- Nachvollziehbarkeit: Die Rationale hinter Designentscheidungen festhalten.\n\nHerausforderungen:\n- Veraltete Dokumentation: Die Doku wird nicht synchron mit dem Code gehalten.\n- Falscher Detailgrad: Entweder zu viel oder zu wenig Information.\n- Hoher Aufwand: Dokumentation wird als Belastung empfunden.',
|
||
points: 6,
|
||
type: 'text',
|
||
},
|
||
{
|
||
id: '4-1-b',
|
||
prompt: 'Beschreiben Sie vier wichtige Kapitel des arc42-Templates.',
|
||
solution: '1. Einführung und Ziele: Definiert die Aufgabenstellung, Qualitätsziele und Stakeholder.\n2. Kontextabgrenzung: Zeigt die Grenzen des Systems und seine Schnittstellen zu Nachbarsystemen.\n3. Bausteinsicht: Beschreibt die statische Struktur des Systems in Form von Komponenten und deren Beziehungen.\n4. Architekturentscheidungen: Hält wichtige Designentscheidungen und deren Begründungen fest (z.B. als ADRs).',
|
||
points: 6,
|
||
type: 'text',
|
||
},
|
||
{
|
||
id: '4-1-c',
|
||
prompt: 'Was ist ein ADR? Was sind die Vorteile?',
|
||
solution: 'Ein ADR (Architecture Decision Record) ist ein Dokument, das eine einzelne, wichtige Architekturentscheidung, ihren Kontext und ihre Konsequenzen festhält.\n\nVorteile:\n1. Transparenz: Macht die Gründe für Entscheidungen nachvollziehbar ("Was haben wir uns dabei gedacht?").\n2. Wissensbewahrung: Erleichtert das Onboarding neuer Teammitglieder und verhindert, dass Wissen verloren geht.',
|
||
points: 5,
|
||
type: 'text',
|
||
},
|
||
{
|
||
id: '4-1-d',
|
||
prompt: 'Nach welchen Kriterien kann man einen ADR bewerten?',
|
||
solution: '1. Vollständigkeit: Enthält der ADR alle wichtigen Abschnitte (Kontext, Entscheidung, Konsequenzen)?\n2. Klarheit des Problems: Wird das zugrundeliegende Problem klar beschrieben?\n3. Alternativen: Wurden vernünftige Alternativen betrachtet und analysiert?\n4. Begründung: Ist die Begründung für die gewählte Lösung nachvollziehbar?\n5. Konsequenzen: Werden sowohl positive als auch negative Konsequenzen dargestellt?',
|
||
points: 6,
|
||
type: 'text',
|
||
}
|
||
],
|
||
explanation: '### Lösungserklärung\n\n**Architekturdokumentation** ist kein Selbstzweck, sondern dient der **Kommunikation**, **Wissensbewahrung** und **Nachvollziehbarkeit**. Die größte **Herausforderung** ist, sie aktuell, relevant und mit angemessenem Aufwand zu pflegen.\n\n**arc42** ist eine praxiserprobte Vorlage, die eine Standardstruktur für Architekturdokumentation bietet und sicherstellt, dass alle wichtigen Aspekte (Ziele, Kontext, Bausteine, Entscheidungen etc.) abgedeckt werden.\n\n**ADRs (Architecture Decision Records)** sind leichtgewichtige Dokumente, die jeweils eine wichtige Architekturentscheidung festhalten. Sie dokumentieren nicht nur das *Was*, sondern vor allem das *Warum*. Eine Sammlung von ADRs bildet ein wertvolles Protokoll der Architektur-Evolution.\n\n### Quellen\n*Folien 4.1, Seite 5-26*'
|
||
},
|
||
{
|
||
id: 'swa-4-3-wissen',
|
||
title: '4.3 - SWA – Wissenstransfer',
|
||
parts: [
|
||
{
|
||
id: '4-3-a',
|
||
prompt: 'Warum ist expliziter Wissenstransfer in Softwareprojekten wichtig?',
|
||
solution: 'Reine Dokumentation reicht nicht aus. Expliziter Wissenstransfer (z.B. in Architektur-Sessions) ist wichtig, um:\n- Die Motivation hinter Regeln und Entscheidungen zu erklären ("Beraten statt vorschreiben").\n- Ein gemeinsames Verständnis zu schaffen und Diskussionen zu ermöglichen.\n- Architekturerosion zu vermeiden, indem das Team die Architektur versteht und mitträgt.\n- Neue Teammitglieder effektiv einzuarbeiten.',
|
||
points: 6,
|
||
type: 'text',
|
||
},
|
||
{
|
||
id: '4-3-b',
|
||
prompt: 'Was ist ein Architecture Communication Canvas? Erläutern Sie zwei Felder daraus.',
|
||
solution: 'Der Architecture Communication Canvas ist ein Werkzeug, um Softwarearchitektur klar und strukturiert zu kommunizieren.\n\nBeispiel-Felder:\n1. System Purpose & Key Features: Beschreibt den Hauptzweck und die wichtigsten Funktionen des Systems.\n2. Key Challenges & Solutions: Listet die wichtigsten Herausforderungen und deren architektonische Lösungsansätze auf.',
|
||
points: 6,
|
||
type: 'text',
|
||
},
|
||
{
|
||
id: '4-3-c',
|
||
prompt: 'Wie kann man den Architecture Communication Canvas in einen agilen Entwicklungsprozess integrieren?',
|
||
solution: 'Der Canvas kann in agilen Ritualen genutzt werden:\n- Im Sprint Planning: Zur Kommunikation architekturrelevanter User Stories und deren Abhängigkeiten.\n- Im Sprint Review: Zur Visualisierung der umgesetzten Architekturaspekte für Stakeholder.\n- In Retrospektiven: Zur Bewertung und Verbesserung von Architekturentscheidungen.',
|
||
points: 6,
|
||
type: 'text',
|
||
},
|
||
{
|
||
id: '4-3-d',
|
||
prompt: 'Welche spezifischen Herausforderungen sehen Sie beim Wissenstransfer in agilen Teams und wie begegnen Sie diesen?',
|
||
solution: 'Herausforderungen in agilen Teams:\n- Zeitdruck: Schnelle Sprints lassen wenig Zeit für formelle Dokumentation.\n- Sich ändernde Anforderungen: Architektur und Wissen müssen sich kontinuierlich anpassen.\n\nLösungsansätze:\n- Leichtgewichtige Formate wie ADRs und Canvases verwenden.\n- Wissenstransfer in agile Rituale integrieren (z.B. Sprint-Reviews, Dailies).\n- "Living Documentation", die sich teils automatisch generiert.',
|
||
points: 7,
|
||
type: 'text',
|
||
}
|
||
],
|
||
explanation: '### Lösungserklärung\n\n**Wissenstransfer**: Dokumentation allein ist passiv. Aktiver **Wissenstransfer** in Sessions und Meetings ist entscheidend, um die "Warum"-Fragen zu klären und sicherzustellen, dass die Architektur vom Team verstanden und gelebt wird. Nur so lässt sich Architekturerosion wirksam bekämpfen.\n\n**Architecture Communication Canvas**: Ein Werkzeug, das hilft, das "Big Picture" einer Architektur auf einer Seite zu visualisieren. Es ist ideal für die Kommunikation mit verschiedenen Stakeholdern und lässt sich gut in **agile Prozesse** integrieren.\n\n**Agiler Wissenstransfer**: In **agilen Teams** ist der formale Dokumentationsaufwand oft geringer. Umso wichtiger sind kontinuierliche Kommunikation und leichtgewichtige Werkzeuge. Wissen muss fließen. Statt großer Dokumente werden oft kleine, fokussierte Artefakte (ADRs) und regelmäßige Austauschformate bevorzugt, um mit der hohen Änderungsgeschwindigkeit Schritt zu halten.\n\n### Quellen\n*Folien 4.3, Seite 2-5*'
|
||
},
|
||
{
|
||
id: 'swa-4-5-bewertung-a',
|
||
title: '4.5 - SWA - Architekturbewertung mit LASR (Teil 1)',
|
||
parts: [
|
||
{
|
||
id: '4-5-a',
|
||
prompt: 'Warum sind Architektur-Reviews wichtig?',
|
||
solution: 'Architektur-Reviews sind wichtig, weil sie:\n- Risiken frühzeitig identifizieren, bevor sie teuer zu beheben sind.\n- Die Architektur gegen die definierten Qualitätsziele validieren.\n- Den Wissenstransfer und ein gemeinsames Verständnis im Team fördern.\n- Helfen, technische Schulden zu erkennen und zu vermeiden.',
|
||
points: 5,
|
||
type: 'text',
|
||
},
|
||
{
|
||
id: '4-5-b',
|
||
prompt: 'Erläutern Sie den Unterschied zwischen quantitativer und qualitativer Analyse bei Architektur-Reviews.',
|
||
solution: 'Quantitative Analyse ist Tool-basiert und liefert messbare, objektive Metriken (z.B. Kopplungsmetriken, Code Coverage). Qualitative Analyse ist Workshop-basiert (z.B. LASR, ATAM) und basiert auf der subjektiven Bewertung und Diskussion durch Experten. Sie erfasst komplexe Zusammenhänge, die Metriken nicht sehen.',
|
||
points: 6,
|
||
type: 'text',
|
||
},
|
||
{
|
||
id: '4-5-c',
|
||
prompt: 'Nennen Sie ein Beispiel für eine Architekturmetrik.',
|
||
solution: 'Ein Beispiel ist die ACD/NCCD Metrik (Average Component Dependency). Sie misst die durchschnittliche Anzahl direkter und indirekter Abhängigkeiten einer Komponente. Ein hoher Wert kann auf eine zu starke Kopplung oder zyklische Abhängigkeiten im System hinweisen.',
|
||
points: 4,
|
||
type: 'text',
|
||
},
|
||
{
|
||
id: '4-5-d',
|
||
prompt: 'Erläutern Sie den Begriff „Pre-Mortem" im Rahmen der Architekturbewertung.',
|
||
solution: 'Pre-Mortem ist eine Bewertungstechnik, bei der man sich vorstellt, das Projekt sei in der Zukunft gescheitert. Das Team analysiert dann rückblickend die möglichen Gründe für dieses Scheitern. Dies hilft, proaktiv Risiken zu identifizieren und Gegenmaßnahmen einzuleiten, bevor die Probleme tatsächlich eintreten.',
|
||
points: 5,
|
||
type: 'text',
|
||
}
|
||
],
|
||
explanation: '### Lösungserklärung\n\n**Architektur-Reviews** sind ein entscheidendes Werkzeug zur Qualitätssicherung. Sie helfen, Risiken frühzeitig zu finden und die Architektur zu validieren.\n\nMan unterscheidet **quantitative** (Tool-basierte Metriken) und **qualitative** (Workshop-basierte Diskussion) Analysen. Beide Ansätze ergänzen sich gut.\n\n**Pre-Mortem** ist eine proaktive Risikoanalysetechnik, bei der man ein Scheitern des Projekts annimmt, um dessen mögliche Ursachen zu ergründen.\n\n### Quellen\n*Folien 4.5, Seite 2-24*'
|
||
},
|
||
{
|
||
id: 'swa-4-5-bewertung-b',
|
||
title: '4.5 - SWA - Architekturbewertung mit LASR (Teil 2)',
|
||
parts: [
|
||
{
|
||
id: '4-5-e',
|
||
prompt: 'Beschreiben Sie die vier Hauptschritte der LASR-Methodik.',
|
||
solution: '1. Mission Statement: Ein gemeinsames Verständnis des Systemzwecks schaffen.\n2. Bewertungsmaßstab: Die Top 3-5 Qualitätsziele definieren und als Spinnennetz-Diagramm visualisieren.\n3. Basis-Review: Mit einem strukturierten Pre-Mortem (Risikokarten) Schwächen und Risiken identifizieren, die das Erreichen der Ziele gefährden.\n4. Zielorientierte Analyse: Die Ergebnisse validieren und durch gezielte Diskussionen schärfen.',
|
||
points: 8,
|
||
type: 'text',
|
||
},
|
||
{
|
||
id: '4-5-f',
|
||
prompt: 'Erklären Sie, wie das Spinnennetz-Diagramm in LASR verwendet wird.',
|
||
solution: 'Das Spinnennetz-Diagramm ist das zentrale Visualisierungselement in LASR. Jede seiner Achsen repräsentiert ein priorisiertes Qualitätsziel. Zuerst wird die Ziellinie (grün) eingetragen, die die angestrebten Werte darstellt. Nach der Risikoanalyse wird die Ergebnislinie eingetragen, die die geschätzte tatsächliche Erreichung zeigt. Die Lücken zwischen den Linien machen Problembereiche sofort sichtbar.',
|
||
points: 6,
|
||
type: 'text',
|
||
},
|
||
{
|
||
id: '4-5-g',
|
||
prompt: 'Nennen Sie zwei Vorteile von LASR gegenüber ATAM.',
|
||
solution: '1. Geringerer Aufwand: LASR ist schlanker und kann mit dem eigenen Team in kürzerer Zeit durchgeführt werden.\n2. Selbstdurchführbarkeit: LASR kann ohne externe, speziell geschulte Moderatoren durchgeführt werden.',
|
||
points: 4,
|
||
type: 'text',
|
||
},
|
||
{
|
||
id: '4-5-h',
|
||
prompt: 'Diskutieren Sie Vor- und Nachteile der LASR-Methodik gegenüber rein quantitativen Ansätzen.',
|
||
solution: 'Vorteile von LASR (qualitativ): Erfasst ganzheitlich qualitative Aspekte und Risiken, die Metriken nicht sehen. Fördert das gemeinsame Verständnis im Team.\nNachteile von LASR: Ergebnisse sind subjektiv und hängen von den Teilnehmern ab. Der Aufwand ist höher als bei automatisierten Messungen.\n\nEin idealer Ansatz kombiniert oft beide Methoden.',
|
||
points: 6,
|
||
type: 'text',
|
||
}
|
||
],
|
||
explanation: '### Lösungserklärung\n\n**LASR (Lean Architecture-System-Review)** ist eine schlanke, qualitative Review-Methode. Die vier Schritte bauen aufeinander auf:\n1. **Mission Statement**: Klärt das "Warum" des Systems.\n2. **Bewertungsmaßstab**: Definiert die wichtigsten Qualitätsziele als messbare Achsen im **Spinnennetz-Diagramm**.\n3. **Basis-Review**: Findet mittels eines strukturierten **Pre-Mortems** Risiken, die diese Ziele gefährden.\n4. **Zielorientierte Analyse**: Vertieft die Diskussion zu den kritischsten Risiken.\n\nIm Vergleich zu umfassenderen Methoden wie **ATAM** ist **LASR** deutlich leichtgewichtiger und schneller durchführbar.\n\n### Quellen\n*Folien 4.5, Seite 2-24*'
|
||
}
|
||
];
|