AISE502/Modulbeschreibung_AISE502_v3_2026.md

# Modulbeschreibung: AISE502 – AI in SE II

| Feld | Wert |
|---|---|
| **Autor/in** | Herzog Florian |
| **Ausgabestelle** | Institute for Data Analysis, Artificial Intelligence, Visualization, and Simulation (DAViS) |
| **Geltungsbereich** | Departement |
| **Klassifizierung** | Nicht klassifiziert |
| **Version** | 3.1.0 |
| **Ausgabedatum** | 8. September 2026 (Sitzungsplan an die ausgelieferten Vorlesungen 1–14 angeglichen) |

---

## Modul

| Feld | Wert |
|---|---|
| **Name** | AI in Software Engineering II |
| **Kürzel** | AISE502 |
| **ECTS-Punkte** | 4 |
| **Typ** | Pflichtmodul |
| **Verantwortliche/r** | Herzog Florian |
| **Semester** | 5. Semester |

### Leitidee

Das Modul "AI in Software Engineering II" stellt das **Software Engineering grosser, langlebiger
Systeme** in den Mittelpunkt. Sein roter Faden ist das englischsprachige Vorlesungsskript
*"A Theory of Architecture--Application Fit"*, das eine durchgängige, messbare
Entscheidungstheorie der Softwarearchitektur entwickelt: Architektur wird verstanden als die
Menge der signifikanten, schwer umkehrbaren Entscheidungen, die durch **messbare
Qualitätsattribute** getrieben, durch systematischen Abgleich von **Anforderungsprofilen**
(zehn Anwendungsklassen) und **Fähigkeitsprofilen** (sieben Architektur-Patterns) über
**zwölf gemeinsame Profildimensionen** getroffen und über den gesamten Lebenszyklus
empirisch überprüft werden (Fitness Functions, DORA-Metriken).

Die Leitfrage lautet: *Wie entwerfe, begründe und betreibe ich die Struktur eines
Software-Systems so, dass es seine Qualitätsattribute erfüllt und über Jahre wartbar bleibt --
auch dann, wenn einzelne Komponenten nicht-deterministisch, fehlbar und kostenintensiv sind?*

Künstliche Intelligenz erscheint in **zwei gleichwertigen, strikt getrennten Achsen**:

- **Achse A -- AI als Werkzeug zum Bauen:** Studierende setzen agentische
  Entwicklungswerkzeuge produktiv, aber kritisch-reflektiert ein -- auf Basis der empirischen
  Evidenz (randomisierte Studien mit positiven wie negativen Befunden) und mit
  Architektur-Dokumentation und Fitness Functions als Leitplanken.

- **Achse B -- AI als Komponente im System:** Studierende entwerfen Architekturen, in denen
  LLM-, ML- und Optimierungskomponenten als Laufzeit-Bausteine wirken, und machen diese
  nicht-deterministischen Komponenten *engineering-tauglich*: gekapselt (Gateway, Ports),
  asynchron integriert, beobachtbar (Kosten, Latenz), getestet (Eval-Harness) und abgesichert
  (Ontologie-Guard, Prompt-Injection-Abwehr).

Die zentrale Erkenntnis des Moduls (Annahme A6 der Theorie): **AI erweitert den
Qualitätsattributraum, ändert aber die Methode nicht.** Die Disziplin, die man zum Bauen
*mit* AI braucht, ist dieselbe wie jene zum Einbetten *von* AI.

**Didaktisches Prinzip:** Das Modul arbeitet durchgängig **induktiv** -- Fallstudien und
Beispiele zuerst, Verallgemeinerung danach. Jedes Pattern wird aus dem realen Problem
entwickelt, das es hervorbrachte; jede Anwendungsklasse aus ihren realen Herausforderungen;
das Matching-Verfahren aus drei durchgerechneten Fällen. Zu jedem Pattern gehören
Open-Source-Frameworks zum Bauen und klonbare Open-Source-Referenzsysteme zum Inspizieren
("Build it and study it"). Ein durchgehendes Gruppenprojekt -- eine modulare, AI-gestützte
Portfolio-Analyse-Plattform -- wendet den gesamten Bogen praktisch an.

Das Verhältnis von klassischem Software Engineering zu AI-spezifischen Techniken beträgt
etwa **60 % zu 40 %**.

### Voraussetzungen

1. AI in Software Engineering I (AISE501)
2. Software Technik I und II
3. Maschinelles Lernen, Deep Learning
4. Mathematik-Grundlagen, Informatik-Grundlagen

### Lernergebnisse

Nach erfolgreichem Abschluss dieses Moduls sind die Studierenden in der Lage:

1. **Architektur als Entscheidungsproblem behandeln (Skript Teil I):**
   - Architektur als Menge schwer umkehrbarer, qualitätsgetriebener Entscheidungen verstehen
     (tragende Annahmen A1--A6) und Entscheidungen mit Rationale dokumentieren
     (Architecture Decision Records, C4-Sichten, ISO/IEC/IEEE 42010).
   - Die zwölf Profildimensionen (ISO/IEC 25010:2023-verankert, je mit Antwortmass und
     Messinstrument) als gemeinsames Koordinatensystem von Anforderung und Fähigkeit
     anwenden.

2. **Anforderungsprofile konstruieren (Teil I und III):**
   - Architektur-relevante Anforderungen elizitieren und als sechsteilige
     Qualitätsszenarien mit Antwortmass formulieren; Gewichte über Utility Trees ableiten.
   - Anwendungsklassen als Anforderungsprofile R(a) charakterisieren: Gewichte,
     Workload-Shape und regulatorische Knock-out-Constraints (u. a. BCBS 239, FINMA 2023/1,
     PCI DSS, EU AI Act).

3. **Fähigkeitsprofile herleiten und Architektur-Patterns beherrschen (Teil II):**
   - Die sieben Patterns (Schichtenarchitektur, modularer Monolith, Hexagonal,
     Microservices, Event-Driven, Pipes-and-Filters, Serverless) mit Topologie, realem
     Ursprungsproblem, Taktiken und dimensionsweisem Fähigkeitsprofil C(p) erklären.
   - Pro Pattern Open-Source-Frameworks einsetzen und Referenzsysteme im Quellcode
     inspizieren; Engineering-Konsequenzen (Build, Test, CI/CD, Deployment, Betrieb,
     Teamstruktur) ableiten.

4. **Passung berechnen, begründen und verteidigen (Teil IV):**
   - Das dreistufige, nicht-kompensatorische Matching-Verfahren anwenden (Knock-out und
     Workload-Shape-Gate, Veto auf hochgewichteten Dimensionen mit dokumentierten
     Mitigationen, ordinale Rangbildung mit Sensitivitätsanalyse) und die 7×10-Matrix als
     Explikations- statt Rechenmodell nutzen.
   - Hybride als Normalfall erkennen (z. B. ACID-Kern mit Event-getriebenen Rändern) und
     Evolutionspfade planen (Strangler Fig, dokumentierte Rückbau-Fallstudien).

5. **Entscheidungen messbar machen und betreiben (Teil IV):**
   - Jede Architekturentscheidung mit einem Messvertrag abschliessen: Fitness Functions in
     CI/CD (z. B. Modulgrenzen-Checks, Performance- und Token-Budgets), DORA-Metriken und
     Observability (Logging, Metriken, Tracing) im Betrieb.

6. **AI als Werkzeug professionell und kritisch einsetzen (Achse A, Teil V):**
   - Die empirische Evidenz zu AI-Coding-Werkzeugen differenziert bewerten (u. a.
     Copilot-RCT, METR-Studie, DORA-Reports) und daraus Konsequenzen für Spezifikation,
     Verifikation und Architektur ziehen.
   - Agentische Werkzeuge mit Architektur-Dokumentation als Kontext und Tests/Fitness
     Functions als Leitplanken einsetzen; Ausgaben kritisch bewerten und verantworten.

7. **AI als Systemkomponente engineering-tauglich machen (Achse B, Teil V):**
   - LLM-, ML- und Optimierungskomponenten hinter stabilen Schnittstellen kapseln
     (Gateway, Anti-Corruption-Layer), asynchron integrieren, deterministische von
     nicht-deterministischen Systemteilen strikt trennen.
   - Eigene Eval-Harnesses aufbauen (Golden Sets, LLM-as-Judge mit Kalibrierung,
     Domänen-Axiome) und als CI-Gate betreiben; Token-Kosten und Latenz messen und
     optimieren (Caching, Batching, Model-Routing).
   - Multi-Agenten-Systeme als Komposition klassischer Topologien konzipieren
     (Chain/Router/Orchestrator/Multi-Agent) und deren Ökonomie bewerten.

8. **Ethik und Verantwortung reflektieren:**
   - Gesellschaftliche, regulatorische (EU AI Act) und ethische Implikationen AI-gestützter
     Systeme im sensiblen Anwendungskontext (Finanzdaten) bewerten; neue Bedrohungsklassen
     (Prompt Injection, OWASP LLM Top 10) im Threat-Modeling berücksichtigen.

### Leistungsnachweis

| Anteil | Komponente |
|---|---|
| 50 % | Praxisprojekt (modulare AI-gestützte Plattform, Gruppenarbeit) -- inklusive Requirements-Dossier (A1, Ende Woche 3), Architektur-Dossier mit ADR und Messvertrag (A2, Ende Woche 7), Implementierung sowie Abschlusspräsentation mit Architektur-Verteidigung (A3, Woche 14) |
| 50 % | Schriftliche Modulschlussprüfung, 60 Minuten, open book (Skript und eigene Unterlagen in Papierform), closed internet -- Schwerpunkt: Architektur-Reasoning und Trade-off-Analyse entlang der Passungstheorie, keine reine Faktenabfrage |

### Nachprüfung

Gemäss Rahmenprüfungsordnung.

### Unterrichtssprache

Deutsch. Sämtliche Unterlagen (Vorlesungsskript, Folien, Übungen, Paper) in Englisch.

### Eingangskompetenzen

Sicherer Umgang mit Python, Versionsverwaltung (Git) und grundlegenden Software-Engineering-
Prinzipien (Clean Code, SOLID). Grundverständnis von LLMs, Prompting und RAG aus AISE501.
Grundlagen in Statistik und maschinellem Lernen.

---

## Aufbau des Semesters

Der Kurs umfasst **14 Sitzungen zu je 4 Lektionen**. Der rote Faden ist das Vorlesungsskript
*"A Theory of Architecture--Application Fit"* (Teile I--V); jede Sitzung verbindet einen
Skript-Abschnitt mit einer AI-Linse und einem Projektschritt. Der Semesterplan folgt einer
**Zwei-Phasen-Logik**, die Vorlesung und Projekt eng koppelt:

| Phase | Wochen | Aufteilung | Logik |
|---|---|---|---|
| **Designphase** | 1--7 | 2 L Vorlesung + 2 L Übung | Die Übung erarbeitet Requirements → Architekturstudium → Architekturentscheid → Lösungsdesign. Die Vorlesung liefert just-in-time genau das Handwerkszeug, das die Übung in derselben oder der Folgewoche braucht. |
| **Implementierungsphase** | 8--13 | 3 L Vorlesung + 1 L Übung (Standup/Coaching) | Die Implementierung läuft primär im Selbststudium. Die Vorlesung holt die nicht design-blockierenden Inhalte nach (Anwendungsklassen-Katalog, Messvertrag-Vertiefung, AI-Dimension) -- jeweils in der Woche, in der das Projekt sie braucht. |
| **Abschluss** | 14 | 1 L Synthese + 3 L Präsentationen | Synthese, Grenzen der Theorie und Prüfungsorientierung; danach Abschlusspräsentationen, Architektur-Verteidigung und Peer-Reviews. |

**Kernprinzip der Abstimmung:** Alles, was die Übung zum Entwerfen braucht -- die
R(a)-Methode, die sieben Patterns, das dreistufige Matching-Verfahren --, ist bis Ende Woche 7
gelesen. Alles, was nicht design-blockierend ist (die Klassen C1--C9, Hybride und
Evolutionspfade, die AI-Dimension), liegt in der Implementierungsphase, wo es inhaltlich passt:
die Gateway- und Eval-Harness-Vorlesung genau dann, wenn Gateway und Agenten gebaut werden.

### Meilensteine und Abgaben

| Meilenstein | Wochen | Abgabe / Check |
|---|---|---|
| **M1** Requirements und Ontologie | 1--3 | **A1 Requirements-Dossier** (Ende Woche 3): Qualitätsszenarien mit Antwortmass, Utility Tree, R(Plattform) |
| **M2** Architekturentscheid und Lösungsdesign | 4--7 | **A2 Architektur-Dossier** (Ende Woche 7): ADR mit Rationale, C4-Sichten, Messvertrag -- plus **Design-Review-Gate**; Produktivcode beginnt erst nach dem Gate |
| **M3** Walking Skeleton | 8--9 | Check Woche 9: dünner End-to-End-Schnitt läuft |
| **M4** Deterministischer Kern und Resilienz | 10--11 | Check Ende Woche 11: Kern vollständig gegen Referenzvektoren getestet, Resilienz auf allen externen Aufrufen |
| **M5** Multi-Agent-Orchestrierung, Evaluation, Hardening | 12--13 | Check Ende Woche 13: Eval-Harness als CI-Gate, Ontologie-Guard aktiv, Kosten-Observability |
| **M6** Präsentation und Architektur-Verteidigung | 14 | **A3 Abschlusspräsentation** mit Architektur-Verteidigung und Peer-Reviews |

---

## Inhalte

**1. Das Entscheidungsproblem und das Framework** *(Skript Teil I, §1--2)*

- Inhalte: Vier Produktionssysteme, zwei Fakten (Stack Overflow, Monzo, Segment, Prime Video);
  Architektur als schwer umkehrbare, qualitätsgetriebene Entscheidungen; die fünf
  Framework-Elemente (R(a), C(p), fit, ADR, Messvertrag); die tragenden Annahmen A1--A6;
  von Alltagsfragen zu den zwölf Dimensionen (Überblick der fünf Gruppen).

- Praktische Anwendung: Projekt-Kickoff (Teams, Repository und Werkzeug-Setup inkl. agentischer
  Entwicklungswerkzeuge, Domänenverständnis, erste Ontologie-Skizze, rohe Stakeholder-Wünsche);
  ein Agent erstellt ADR-Entwürfe -- der Mensch entscheidet und verantwortet (Achse A).

**2. Das Koordinatensystem: zwölf Profildimensionen und messbare Anforderungen** *(Teil I, §2--3)*

- Inhalte: Die zwölf Dimensionen einzeln motiviert, je mit Antwortmass und Messinstrument
  (Last, Korrektheit/Vertrauen, Wandel/Delivery, Ökonomie/Organisation, AI-Integrierbarkeit);
  ISO/IEC 25010:2023 als Vokabular; architektur-relevante Anforderungen (ASR), Quality
  Attribute Workshop, sechsteilige Qualitätsszenarien, Utility Tree → Gewichte; R(a) aus
  Gewichten, Workload-Shape und Knock-out-Constraints.

- Praktische Anwendung: Requirements-Workshop I -- Qualitätsszenarien mit Antwortmass für die
  Projektplattform (mindestens acht, davon drei für die AI-Komponenten), Utility Tree beginnen.

**3. Nachfrage, Angebot, Passung: das formale Modell** *(Teil I, §4--6)*

- Inhalte: Herleitung von C(p) über Taktiken (Pattern vs. Taktik, Evidenzbasis); das
  dreistufige, nicht-kompensatorische Matching-Verfahren am Mini-Match des Kursprojekts
  (C10 gegen L, MM und MS); warum keine gewichtete Summe (MCDM-Kritik); ADR/MADR und der
  Messvertrag als Abschluss jeder Entscheidung.

- Praktische Anwendung: Requirements-Workshop II -- R(Plattform) finalisieren (Gewichte,
  Workload-Shape, Knock-out-Constraints), Ontologie als Vertrag fixieren.
  **Abgabe A1: Requirements-Dossier (Ende Woche 3).**

**4. Patterns I: ein Deployable** *(Teil II, §8--10)*

- Inhalte: Schichtenarchitektur, modularer Monolith, Hexagonal/Ports-and-Adapters -- je:
  reales Ursprungsproblem, Topologie, Architecture Quantum, dimensionsweises Fähigkeitsprofil,
  Engineering-Konsequenzen, Anti-Patterns; Modulgrenzen als CI-Gegenstand (Spring Modulith,
  import-linter, ArchUnit, Packwerk).

- Praktische Anwendung: "Build it and study it" -- healthchecks (Django), Apache Fineract und
  das Cosmic-Python-Repo klonen und die Architektur im Code nachweisen; Architekturstudium I
  für die Plattform, C4-Kontext- und Container-Entwurf; AI-Linse: der LLM-Provider hinter
  einem Port.

**5. Patterns II: verteilte Topologien** *(Teil II, §11--12)*

- Inhalte: Microservices und Event-Driven Architecture -- Ursprungsprobleme (Release-Zug,
  Ingest), Fähigkeitsprofile, Sagas vs. ACID, der verteilte Monolith als häufigster
  Fehlausgang, Broker- vs. Mediator-Topologie, Schema-Governance, die sieben
  Resilienz-Grundmuster (Timeout, Retry, Circuit-Breaker, Bulkhead, Fallback, Dead-Letter
  Queue, idempotenter Consumer); Fallstudien (Netflix, Uber DOMA, Monzo, Segment-Rückbau).

- Praktische Anwendung: Online Boutique und der Home-Assistant-EventBus im Quellcode;
  Architekturstudium II -- Ränder entwerfen (Ingestion-Queue, Resilienz gegen API-Ausfall),
  Service-Kontrakte skizzieren, Matrix-Vorfilter der Kandidaten; AI-Linse: ein LLM-Aufruf als
  unzuverlässiger Remote-Call, Queues als Puffer (D12).

**6. Patterns III: Batch und Serverless, die Verallgemeinerung -- und die eigene Klasse C10**
*(Teil II, §13--17; Teil III, §28)*

- Inhalte: Pipes-and-Filters/Batch und Serverless/FaaS; die Verallgemeinerung: Architecture
  Quantum, "Partitioning beats distribution", Evidenzbasis und die konsolidierte
  Fähigkeitstabelle als Vergleichssicht; Agenten-Orchestrierung als emergentes
  Kompositionsmuster (Ausblick); danach **C10 -- AI-native Advisory-Plattformen**, die Klasse
  des Kursprojekts, mit dem Spiegelpaar C1/C2 als Kurzvorschau.

- Praktische Anwendung: dbt-Pipeline (jaffle_shop_duckdb) lokal bauen und den
  Knative-Bookstore inspizieren; **der Match**: das dreistufige Verfahren für die eigene
  Plattform durchführen (Knock-out → Veto → ordinale Lesung), Entscheid fällen, ADR beginnen.

**7. Die Passung, formal: drei Fälle, das Verfahren, die Matrix** *(Teil IV, §30--32, 34; §37 Einführung)*

- Inhalte: Drei durchgerechnete Matches (C6: das Shape-Gate leert sechs von sieben Zellen;
  C1: Veto und dokumentierte Mitigationen; C2: ordinale Lesung mit Sensitivitätsanalyse und
  Tradeoff-Point); das Verfahren im Allgemeinen und was eine gewichtete Summe zerstört hätte;
  Zellsemantik und Lesart der 7×10-Matrix (Spalten, Zeilen, fünf Stützpunkte); Einführung des
  Messvertrags (Fitness Functions, vier DORA-Metriken).

- Praktische Anwendung: Lösungsdesign finalisieren -- Service-Schnitt und Kontrakte,
  Walking-Skeleton-Plan, Messvertrag mit Zahlen (Token-Budget, Eval-Schwelle ≥ 95 %,
  p95-Latenz ≤ 20 s, null Modulgrenzen-Verletzungen); **Design-Review-Gate** mit Verteidigung
  des ADR. **Abgabe A2: Architektur-Dossier (Ende Woche 7).**

**8. Anforderungsprofile I: Anwendungsklassen C1--C5** *(Teil III, §18--23)*

- Inhalte: Anwendungsklassen als ASR-Bündel, nicht als Branchenlabel; C1 Kernbanking,
  C2 Social/Content, C3 Back-Office, C4 ERP, C5 E-Commerce -- je: reale Herausforderungen mit
  Zahlen und Regulatorik, Anforderungsprofil über die zwölf Dimensionen, und *welche
  Architektur reale Systeme wählten und warum* (LMAX vs. Monzo, Instagram, Shopify, Fineract).

- Praktische Anwendung: Sprint 1 -- Beginn des Walking Skeleton (MarketDataService, minimaler
  ResearchAgent, stabile API); AI-Linse: die Latenzklasse, nicht die Genauigkeit, entscheidet
  über die Platzierung einer AI-Komponente.

**9. Anforderungsprofile II: C6--C9 und zehn Profile nebeneinander** *(Teil III, §24--27, 29)*

- Inhalte: C6 Simulation/Batch, C7 DSS/BI, C8 IoT-Streaming, C9 Collaboration/Messaging;
  die dritte Konsistenzsemantik (Reproduzierbarkeit, Freshness-Kontrakt); Verallgemeinerung:
  zehn Profile nebeneinander mit ihren Fussnoten und fünf klassenübergreifenden Beobachtungen
  (u. a.: D11 High, nicht Skalierung, erzwingt Microservices).

- Praktische Anwendung: Coaching; Walking Skeleton fertigstellen -- **Check Woche 9: läuft
  End-to-End**; das Projekt erbt C6 (Ingestion- und Eval-Pipelines) und C7 (Analytik).

**10. Hybride, Evolution und das achtstufige Entscheidungsverfahren** *(Teil IV, §35--36, 33)*

- Inhalte: Hybride als Normalfall und die Bewertungseinheit Subsystem; Fit als Funktion der
  Zeit (Lehman, Annahme A5), Migrationsstrategien (MonolithFirst, Strangler Fig in beide
  Richtungen, Sacrificial Architecture; Fallstudien Segment, Prime Video, Shopify); das
  achtstufige Entscheidungsverfahren von den ASRs bis zum Messvertrag, durchgespielt an
  ADR-007; die Zeilen-Begründungen der Matrix im Detail.

- Praktische Anwendung: Coaching; deterministische Services (Performance, Risk, Optimization)
  mit exakten Tests gegen die Referenzvektoren; AI-Linse: die AI-Schicht als bewusst
  ersetzbare Sacrificial Architecture hinter einem Port.

**11. Der Messvertrag, Conway's Law und die Grenzen der Theorie** *(Teil IV, §37--39)*

- Inhalte: Fitness Functions (atomar/holistisch, triggered/continual/temporal) in CI/CD und
  ihre drei Instrumentenfamilien; die vier DORA-Metriken und der Kopplungs-Befund; die
  vierstufige Kaskade und der C10-Referenzvertrag; Kostenverlauf von Änderungen (Boehm vs.
  Menzies); Conway's Law und Team Topologies als dritte Passungsdimension; sechs Grenzen der
  Theorie, auf sich selbst angewandt.

- Praktische Anwendung: Coaching; Resilienz auf allen externen Aufrufen (Timeout, Retry,
  Circuit-Breaker, Fallback) und verifizierte Graceful Degradation -- **Check Ende Woche 11**;
  der Messvertrag der eigenen Abgabe wird in CI verdrahtet.

**12. Die AI-Dimension I: Achse A -- Evidenz und Konsequenzen; Achse B -- Grundlagen**
*(Teil V, §40--41, §42.1--42.5)*

- Inhalte: Zwei widersprüchliche randomisierte Experimente (Copilot-RCT +55.8 % vs. METR
  −19 % inklusive Wahrnehmungslücke) und ihre Auflösung über fünf Moderatorvariablen; der
  Verifikations-Engpass; ADRs und Agenten-Instruktionsdateien als Kontrollschnittstelle,
  Fitness Functions als Betriebslizenz für Agenten; danach Achse B: der Sentiment-Call falsch
  und richtig verdrahtet, drei Komponententypen (LLM, ML, Solver), die
  LLM-Gateway-Referenzarchitektur (Port, Routing, Caching, Budgets, Fallbacks, Ontologie-Guard)
  und die Grundlagen des Eval-Harness.

- Praktische Anwendung: Coaching; AdvisorAgent mit 2--3 Sub-Agenten hinter dem Gateway
  (Pflichtteil), Ontologie-Guard auf allen Insights aktiv; Achse-A-Arbeitsregeln im Team
  (Agenten-Instruktionsdatei, signierte ADRs, CI-Gate, AI-Policy).

**13. Die AI-Dimension II: Bedrohungen, verschobene Matrix, Orchestrierung -- und Synthese**
*(Teil V, §42.6--42.7, 43--45)*

- Inhalte: OWASP LLM Top 10 und Prompt Injection als Architektur-, nicht Modellproblem;
  EU AI Act als Knock-out-Constraint in R(a); wie AI die Matrix verschiebt (D12-Mechanik,
  fünf Zellverschiebungen, MLOps-Reifegrade); Agenten-Orchestrierung als achtes,
  emergentes Kompositionsmuster (sechs Topologien, Task-Signatur-Tabelle, Ökonomie der
  Autonomie); Synthese der Theorie und Prüfungsorientierung.

- Praktische Anwendung: Coaching; Eval-Harness als CI-Gate, Kosten- und Latenz-Dashboard,
  Threat-Model inklusive Prompt Injection über News, Hardening, Topologie-ADR;
  Kür: autonomes Planning, Self-Repair-Loops, Model-Routing. **Check Ende Woche 13.**

**14. Synthese, Präsentation und Architektur-Verteidigung**

- Inhalte (1 Lektion, kein neuer Stoff): das Skript rückwärts als ein Argument gelesen;
  die Theorie-Pipeline in einem Satz; eine Disziplin an zwei Bindungsstellen (Achse A und B);
  Prüfungsorientierung und Q&A.

- Praktische Anwendung (3 Lektionen): Abschlusspräsentationen, **Architektur-Verteidigung**
  der eigenen Trade-offs, Reflexion (wo half und wo schadete AI -- im Bauen und im System)
  sowie Peer-Reviews. **Abgabe A3 / Meilenstein M6.**

---

## Praxisprojekt: AI-Augmented Portfolio Intelligence Platform

Als durchgehendes Gruppenprojekt entwickeln die Studierenden eine modulare Analyse- und
Advisory-Plattform für Aktienportfolios (**kein Trading, kein echtes Geld** -- ausschliesslich
Analyse und Empfehlung). Die Plattform ist im Skript als zehnte Anwendungsklasse (C10)
durchmodelliert; das im Modul berechnete Verdikt lautet **hexagonaler modularer Monolith als
deterministischer Kern, Event-getriebene Ränder, Pipelines für Ingestion und Evaluation,
orchestrierter Advisor-Agent hinter einem LLM-Gateway**. Ob die Services als ein Deployable
oder als mehrere ausgeliefert werden, ist nicht vorgegeben, sondern die Architekturentscheidung,
welche die Teams in Woche 6 mit dem dreistufigen Verfahren treffen und in Woche 14 verteidigen.
Die Plattform:

- bezieht **strukturierte externe Daten** (Börsenkurse, z. B. via Yahoo Finance) -- mit
  Live-API und verpflichtendem Cache-/Snapshot-Fallback;

- bezieht **unstrukturierte externe Daten** (Firmen-News) und wandelt sie über eine
  AI-Komponente in strukturierte, gegen die Ontologie validierte Insights um;

- berechnet **Risiko-, Performance- und Portfolio-Optimierungs-Kennzahlen** (Formeln und
  Testvektoren werden vorgegeben; die Lernleistung ist das Engineering darum herum);

- stellt die Funktionalität **API-first** bereit, mit dünnem Dashboard zur Demonstration.

**Zentrale Architekturregel:** *Agents propose; deterministic services decide and book.*
Die AI-Agenten beziehen und interpretieren quantitative Werte ausschliesslich über die
deterministischen Services -- sie berechnen nie selbst. Diese Trennung ist die prüfbare
Manifestation von "AI engineering-tauglich machen" und wird bewertet.

**Abstufung Pflicht / Kür:**

- *Pflicht (bestehensrelevant):* aus der Ontologie abgeleitete Architektur mit ADRs und
  C4-Sicht; vollständig und exakt getestete deterministische Services; orchestrierter
  Advisor-Agent mit 2--3 Sub-Agenten, die nur über Service-Kontrakte kooperieren;
  Ontologie-Guard auf allen AI-Insights; Resilienz gegen Ausfall externer Datenquellen;
  Eval-Harness für die AI-Komponente; Kosten- und Latenz-Observability über das einzige
  LLM-Gateway; der Messvertrag aus A2 (Modulgrenzen-Check, Eval-Schwelle, Token-Budget) in CI
  verdrahtet.

- *Kür (für Spitzennoten):* autonomes Planning (der Advisor entscheidet selbst über Sub-Agent-
  und Tool-Aufrufe), Self-Repair-Loops, Model-Routing, Deployment mit CI/CD und Tracing.

**Bewertungsschwerpunkte:** Architektur und Trade-offs (Schnitt, Kontrakte, Trennung
deterministisch/nicht-deterministisch, ADRs), Robustheit (Resilienz, Guards, Graceful
Degradation), Qualität (Tests der deterministischen Services, Eval-Harness), AI-Integration
(Anti-Corruption-Layer, Ontologie-Guard), Betrieb (Observability von Kosten und Latenz).

---

## Unterlagen und Lernumgebung

- **Vorlesungsskript** *A Theory of Architecture--Application Fit* (Teile I--V, 45 Abschnitte)
  -- Leitmedium, Prüfungsgrundlage und Lektüre vor jeder Sitzung; wird während des Semesters
  entlang der Vorlesung korrigiert und ergänzt (die jeweils aktuelle Fassung liegt auf Moodle).

- **Foliensätze der 14 Vorlesungen** sowie ein eigener Foliensatz zur Projekteinführung.
- **Aufgabenblatt zum Praxisprojekt** (normative Quelle für Anforderungen, Meilensteine und
  Bewertung) inklusive UI-Skizzen der sechs Bildschirme.

- **Moodle-Kursraum** mit einem Abschnitt pro Woche (Lernziele, Theorie, Selbststudium und
  Aufgaben), einem Abschnitt zum Skript und einem Abschnitt zum Praxisprojekt.

## Lehr- und Lernmethoden

**Lehrtechniken:** Vorlesungen, Übungen, Gruppenarbeit, Online-Lehre, Workshops.

**Lernaktivitäten:** Studium des Skripts und der Literatur, Inspektion realer
Open-Source-Systeme, Übungsaufgaben, Bearbeiten von Problemen und deren Lösungsfindung,
Zusammenarbeit mit anderen Studierenden, projektbegleitendes Selbststudium.

**Lehrmethode:** Präsentation; Einzel-, Partner- und Gruppenarbeit; E-Learning.

---

## Struktur

| Element | Stunden |
|---|---|
| Online-, Hybrid- oder Präsenzunterricht | 42 h |
| Selbststudium (Skript, Lektüre und Projekt) | 78 h |
| **Total** | **120 h (4 ECTS)** |

## Literatur

**Leitmedium (roter Faden):**

- *AISE502 Lecture Notes -- A Theory of Architecture--Application Fit*, F. Herzog,
  Fachhochschule Graubünden, 2026 (englisch; wird abgegeben).

**Die vier methodischen Hauptquellen der Theorie (im Skript gewürdigt):**

- L. Bass, P. Clements, R. Kazman: *Software Architecture in Practice*, 4. Aufl.,
  Addison-Wesley/SEI, 2021 (Qualitätsszenarien, Taktiken, Utility Tree/ATAM).

- M. Richards, N. Ford: *Fundamentals of Software Architecture -- A Modern Engineering
  Approach*, 2. Aufl., O'Reilly, 2025 (Architecture Characteristics, Trade-off-Gesetze).

- N. Ford, R. Parsons, P. Kua, P. Sadalage: *Building Evolutionary Architectures*, 2. Aufl.,
  O'Reilly, 2022 (Fitness Functions, Messvertrag).

- N. Forsgren, J. Humble, G. Kim: *Accelerate -- The Science of Lean Software and DevOps*,
  IT Revolution, 2018 (DORA-Metriken, Kopplungs-Befund).

**Begleitend:**

- I. Sommerville: *Modernes Software-Engineering*, Pearson, 2020 (deutschsprachiger Anker).
- S. Newman: *Building Microservices*, 2. Aufl., O'Reilly, 2021 (nach Bedarf als Reader).
- ISO/IEC 25010:2023 (Qualitätsvokabular) und ISO/IEC/IEEE 42010:2022 (Architekturbeschreibung).
- Aktuelle wissenschaftliche Artikel und Branchenforschung zu AI-Agenten, agentischen
  Entwicklungswerkzeugen und Evaluation von AI-Systemen (u. a. DORA-Reports, METR,
  Anthropic Engineering).