Auto-commit 2026-09-08 10:23: 3 files changed, 474 insertions(+), 310 deletions(-)

Modulbeschreibung_AISE502_v2_2026.md

@@ -6,8 +6,14 @@
 | **Ausgabestelle** | Institute for Data Analysis, Artificial Intelligence, Visualization, and Simulation (DAViS) |
 | **Geltungsbereich** | Departement |
 | **Klassifizierung** | Nicht klassifiziert |
-| **Version** | 2.0.0 |
-| **Ausgabedatum** | 2026 (Neufassung) |
+| **Version** | 2.1.0 |
+| **Ausgabedatum** | 8. September 2026 (Inhalte an die ausgelieferten Vorlesungen 1–14 angeglichen) |
+
+> **Hinweis:** Dies ist die **Kurzfassung**. Die ausführliche Fassung mit Phasenlogik,
+> Meilenstein-Tabelle und Literaturapparat ist `Modulbeschreibung_AISE502_v3_2026.md`
+> (Version 3.1.0) mit dem zugehörigen Confluence-Export. Beide Fassungen beschreiben denselben
+> Kurs; massgeblich für den Sitzungsplan ist die eingereichte Semesterinformation
+> (`semesterinformation_HS26_AISE502_AIinSE2.xlsx`).
 
 ---
 
@@ -28,32 +34,38 @@ Das Modul "AI in Software Engineering II" stellt das **Software Engineering gros
 Systeme** in den Mittelpunkt und behandelt Künstliche Intelligenz als integralen Bestandteil
 moderner Softwarearchitekturen. Aufbauend auf den Grundlagen aus "AI in Software
 Engineering I" (LLMs, Prompting, RAG, Clean Code, erste Agenten-Konzepte) verschiebt sich
-der Fokus von der *einzelnen AI-Funktion* hin zum *Entwurf vollständiger, verteilter
-Software-Systeme*, in denen AI-Komponenten zur Laufzeit mitarbeiten.
+der Fokus von der *einzelnen AI-Funktion* hin zum *Entwurf vollständiger Software-Systeme*,
+in denen AI-Komponenten zur Laufzeit mitarbeiten.
 
-Der Kurs ist **architektur-zentriert** (verankert in Sommerville, *Modernes Software-Engineering*)
-und folgt der Leitfrage: *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 –
+Der Kurs ist **architektur-zentriert** und folgt einem eigenen, englischsprachigen
+Vorlesungsskript: *"A Theory of Architecture--Application Fit"*. Dieses entwickelt eine
+messbare Entscheidungstheorie der Softwarearchitektur -- Architektur als Menge schwer
+umkehrbarer, qualitätsgetriebener Entscheidungen, getroffen durch den systematischen Abgleich
+von **Anforderungsprofilen** (zehn Anwendungsklassen) und **Fähigkeitsprofilen** (sieben
+Architektur-Patterns) über **zwölf gemeinsame Profildimensionen**, dokumentiert in einem ADR
+und über den Lebenszyklus empirisch überprüft (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 dabei in **zwei gleichwertigen Rollen**, die durchgängig
-miteinander verwoben werden:
+Künstliche Intelligenz erscheint dabei in **zwei gleichwertigen Rollen**:
 
 - **AI als Werkzeug zum Bauen (Achse A):** Studierende setzen moderne agentische
-  Entwicklungswerkzeuge (z.B. Claude Code, Cursor, Agent-SDKs, MCP) produktiv, aber
-  kritisch-reflektiert ein, um Architektur zu entwerfen, Code zu generieren, zu refactoren
-  und zu reviewen.
+  Entwicklungswerkzeuge produktiv, aber kritisch-reflektiert ein -- auf Basis der empirischen
+  Evidenz (randomisierte Studien mit positiven wie negativen Befunden), mit
+  Architektur-Dokumentation als Agenten-Kontext und Fitness Functions als Leitplanken.
 - **AI als Komponente im System (Achse B):** Studierende entwerfen Architekturen, in denen
-  ein oder mehrere AI-Agenten als Laufzeit-Bausteine wirken, und lernen, diese
-  nicht-deterministischen Komponenten *engineering-tauglich* zu machen – also testbar,
-  beobachtbar, robust, skalierbar und bezahlbar.
+  LLM-, ML- und Optimierungskomponenten als Laufzeit-Bausteine wirken, und machen diese
+  nicht-deterministischen Komponenten *engineering-tauglich* -- gekapselt (Gateway, Ports),
+  asynchron integriert, beobachtbar, getestet (Eval-Harness) und abgesichert (Ontologie-Guard).
 
-Den verbindenden roten Faden bildet die Erkenntnis, dass die ingenieurmässige Disziplin, die
-man zum **Bauen mit** AI benötigt, dieselbe ist wie jene, die man zum **Einbetten von** AI
-benötigt. Durch ein durchgehendes Gruppenprojekt – eine verteilte, AI-gestützte
-Portfolio-Analyse-Plattform – wenden die Studierenden den gesamten Architektur- und
-Engineering-Bogen praktisch an und erleben unmittelbar, wo der Umgang mit
-nicht-deterministischer AI das System-Engineering herausfordert.
+Den verbindenden roten Faden bildet die Erkenntnis (Annahme A6 der Theorie), dass die
+ingenieurmässige Disziplin, die man zum **Bauen mit** AI benötigt, dieselbe ist wie jene, die
+man zum **Einbetten von** AI benötigt: AI erweitert den Qualitätsattributraum, ändert aber die
+Methode nicht. Durch ein durchgehendes Gruppenprojekt -- eine modulare, AI-gestützte
+Portfolio-Analyse-Plattform -- wenden die Studierenden den gesamten Architektur- und
+Engineering-Bogen praktisch an.
 
 Das Verhältnis von klassischem Software Engineering zu AI-spezifischen Techniken beträgt
 etwa **60 % zu 40 %**.
@@ -69,65 +81,73 @@ etwa **60 % zu 40 %**.
 
 Nach erfolgreichem Abschluss dieses Moduls sind die Studierenden in der Lage:
 
-1. **Software-Architektur entwerfen und begründen:**
-   - Architektur als Summe schwer umkehrbarer Entscheidungen verstehen und diese
-     dokumentieren (Architecture Decision Records, C4-Sichten).
-   - Qualitätsattribute (Wartbarkeit, Skalierbarkeit, Zuverlässigkeit, Performance,
-     Sicherheit) als Treiber von Architekturentscheidungen einsetzen und Trade-offs
-     analysieren.
-   - Architekturstile (modularer Monolith, Microservices, Event-Driven, Hexagonal/Ports &
-     Adapters) kennen, vergleichen und situationsgerecht auswählen.
+1. **Architektur als Entscheidungsproblem behandeln:**
+   - Architektur als Menge schwer umkehrbarer Entscheidungen verstehen und 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 anwenden.
 
-2. **Verteilte Systeme robust gestalten:**
-   - Schnittstellen und Kontrakte zwischen Services entwerfen, versionieren und absichern.
-   - Synchrone und asynchrone Kommunikationsmuster anwenden.
-   - Resilienz-Patterns (Timeout, Retry, Circuit-Breaker, Bulkhead, Fallback) gegen
-     unzuverlässige externe Abhängigkeiten einsetzen.
+2. **Anforderungsprofile konstruieren:**
+   - Architektur-relevante Anforderungen als sechsteilige Qualitätsszenarien mit Antwortmass
+     formulieren und über einen Utility Tree gewichten.
+   - Anwendungsklassen als Anforderungsprofile R(a) charakterisieren -- Gewichte,
+     Workload-Shape und regulatorische Knock-out-Constraints.
 
-3. **AI als Systemkomponente integrieren:**
-   - AI-Komponenten hinter stabilen Schnittstellen kapseln (Anti-Corruption-Layer) und
-     deterministische von nicht-deterministischen Systemteilen sauber trennen.
-   - Multi-Agenten-Systeme als Architekturentscheidung konzipieren (Orchestrierungs-
-     Topologien: Chain, Tree, Graph, Multi-Agent) und implementieren.
-   - Domänenwissen (Ontologie) zugleich als Architektur-Vertrag und als Schutzmechanismus
-     gegen Halluzinationen einsetzen.
+3. **Architektur-Patterns beherrschen und ihre Fähigkeitsprofile herleiten:**
+   - Die sieben Patterns (Schichtenarchitektur, modularer Monolith, Hexagonal, Microservices,
+     Event-Driven, Pipes-and-Filters, Serverless) mit Topologie, Ursprungsproblem, Taktiken
+     und Fähigkeitsprofil C(p) erklären und vergleichen.
+   - Open-Source-Referenzsysteme im Quellcode inspizieren und Engineering-Konsequenzen
+     (Build, Test, CI/CD, Betrieb, Teamstruktur) ableiten.
 
-4. **Qualität nicht-deterministischer Software sichern:**
-   - Teststrategien (Testpyramide, TDD, Contract-Tests) für die deterministischen
-     Systemteile anwenden.
-   - Eigene Evaluations-Harnesses für nicht-deterministische AI-Ausgaben aufbauen
-     (LLM-as-Judge, Regression gegen Domänen-Axiome, gelabelte Referenzdaten).
+4. **Die Passung berechnen, begründen und verteidigen:**
+   - Das dreistufige, nicht-kompensatorische Matching-Verfahren anwenden (Knock-out und
+     Workload-Shape-Gate, Veto mit dokumentierten Mitigationen, ordinale Rangbildung mit
+     Sensitivitätsanalyse) und die 7×10-Matrix als Explikationsmodell nutzen.
+   - Hybride als Normalfall erkennen und Evolutionspfade planen (Strangler Fig).
 
-5. **AI-gestützte Software professionell bauen (Achse A):**
-   - Moderne agentische Entwicklungswerkzeuge produktiv einsetzen und deren Ausgaben
-     kritisch bewerten und verantworten.
+5. **Verteilte Ränder robust gestalten:**
+   - Schnittstellen und Kontrakte entwerfen und versionieren; synchrone und asynchrone
+     Kommunikationsmuster situationsgerecht einsetzen.
+   - Resilienz-Patterns (Timeout, Retry, Circuit-Breaker, Bulkhead, Fallback, Dead-Letter
+     Queue, idempotenter Consumer) gegen unzuverlässige externe Abhängigkeiten einsetzen.
 
-6. **Betreiben, skalieren und absichern:**
-   - CI/CD, Deployment-Strategien und Observability (Logging, Metriken, Tracing) anwenden.
-   - Token-Kosten, Latenz und Ressourcennutzung von AI-Komponenten messen und optimieren
-     (Caching, Batching, Model-Routing).
-   - Sicherheitsaspekte berücksichtigen, insbesondere Threat-Modeling und neue
-     Bedrohungsklassen wie Prompt-Injection.
+6. **AI als Systemkomponente integrieren (Achse B):**
+   - AI-Komponenten hinter stabilen Schnittstellen kapseln (Port, LLM-Gateway,
+     Anti-Corruption-Layer) und deterministische von nicht-deterministischen Systemteilen
+     strikt trennen.
+   - Multi-Agenten-Systeme als Komposition klassischer Topologien konzipieren und ihre
+     Ökonomie bewerten; Domänenwissen (Ontologie) zugleich als Architektur-Vertrag und als
+     Halluzinations-Guard einsetzen.
+   - Eigene Eval-Harnesses aufbauen (Golden Sets, LLM-as-Judge, Domänen-Axiome) und als
+     CI-Gate betreiben.
 
-7. **Evolution und Wartbarkeit gewährleisten:**
-   - Strategien zur Weiterentwicklung und Migration (z.B. Strangler-Fig) sowie evolutionäre
-     Architektur mit Fitness Functions anwenden.
+7. **Entscheidungen messbar machen, betreiben und weiterentwickeln:**
+   - Jede Architekturentscheidung mit einem Messvertrag abschliessen: Fitness Functions in
+     CI/CD (Modulgrenzen-Checks, Performance- und Token-Budgets), DORA-Metriken und
+     Observability (Logging, Metriken, Tracing).
+   - Token-Kosten und Latenz messen und optimieren (Caching, Batching, Model-Routing);
+     Conway's Law und Team Topologies als dritte Passungsdimension berücksichtigen.
 
-8. **Ethik und Verantwortung reflektieren:**
-   - Gesellschaftliche und ethische Implikationen AI-gestützter Systeme im sensiblen
-     Anwendungskontext (z.B. Finanzdaten) bewerten und verantwortungsbewusste Lösungen
-     entwickeln.
+8. **AI als Werkzeug professionell einsetzen sowie Ethik und Verantwortung reflektieren
+   (Achse A):**
+   - Die empirische Evidenz zu AI-Coding-Werkzeugen differenziert bewerten und agentische
+     Werkzeuge mit ADRs als Kontext und Tests als Leitplanken einsetzen; Ausgaben kritisch
+     prüfen und verantworten.
+   - Gesellschaftliche, regulatorische (EU AI Act) und ethische Implikationen im sensiblen
+     Anwendungskontext Finanzdaten bewerten; neue Bedrohungsklassen (Prompt Injection,
+     OWASP LLM Top 10) im Threat-Modeling berücksichtigen.
 
 ### Leistungsnachweis
 
 | Anteil | Komponente |
 |---|---|
-| 50 % | Praxisprojekt (verteilte AI-gestützte Plattform, Gruppenarbeit) |
-| 50 % | Schriftliche Prüfung (Schwerpunkt: Architektur-Reasoning und Trade-off-Analyse, keine reine Faktenabfrage) |
+| 50 % | Praxisprojekt (modulare AI-gestützte Plattform, Gruppenarbeit) -- Requirements-Dossier (A1, Woche 3), Architektur-Dossier mit ADR und Messvertrag (A2, Woche 7), Implementierung, 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, keine reine Faktenabfrage |
 
 ### Unterrichtssprache
 
-Deutsch mit englischen Unterlagen und Papern.
+Deutsch mit englischen Unterlagen und Papern (Skript, Folien, Übungen und Prüfung in Englisch).
 
 ### Eingangskompetenzen
 
@@ -139,129 +159,178 @@ Grundlagen in Statistik und maschinellem Lernen.
 
 ## Inhalte
 
-Der Kurs umfasst 14 Sitzungen. Das klassische, architektur-zentrierte Software Engineering
-bildet die Substanz (~60 %). AI wird in zwei Rollen eingewoben: als kurze **AI-Linse** an jedem
-SE-Thema (AI illustriert das jeweilige SE-Konzept) sowie in zwei **eigenen Fokus-Einheiten** für
-genuin neue Themen (Agenten-Architektur, Evaluation). Ein durchgehendes Projekt verschränkt
-beide Achsen.
+Der Kurs umfasst **14 Sitzungen zu je 4 Lektionen**, dem Vorlesungsskript (Teile I--V) folgend.
+Das klassische, architektur-zentrierte Software Engineering bildet die Substanz (~60 %); AI
+erscheint als kurze **AI-Linse** an den einzelnen Themen sowie in zwei eigenen Sitzungen zur
+AI-Dimension (Sitzungen 12 und 13). Ein durchgehendes Projekt verschränkt beide Achsen.
+**Wochen 1--7** sind Designphase (2 L Vorlesung + 2 L Übung), **Wochen 8--13**
+Implementierungsphase (3 L Vorlesung + 1 L Standup/Coaching), **Woche 14** Synthese und
+Präsentationen (1 L + 3 L).
 
-**1. Was ist Software-Architektur?**
-- Inhalte: Architektur vs. Design vs. Implementierung; Architektur als begründete
-  Entscheidungen; Architecture Decision Records (ADR); C4-Sichten; Stakeholder.
-- AI-Linse (A): Ein Agent erstellt ADR-Entwürfe – der Mensch verantwortet die Entscheidung.
-- Projekt: Domäne und Vision; Setup der Entwicklungswerkzeuge.
+**1. Das Entscheidungsproblem und das Framework** *(Teil I)*
+- Inhalte: Vier Produktionssysteme, zwei Fakten (Stack Overflow, Monzo, Segment, Prime Video);
+  Architektur als schwer umkehrbare Entscheidungen; die fünf Framework-Elemente (R(a), C(p),
+  fit, ADR, Messvertrag); die Annahmen A1--A6; ADR/MADR und C4.
+- AI-Linse (A): Ein Agent erstellt ADR-Entwürfe -- der Mensch verantwortet die Entscheidung.
+- Projekt: Kickoff -- Teams, Repository und Werkzeug-Setup, Domänenverständnis,
+  Ontologie-Skizze, rohe Stakeholder-Wünsche.
 
-**2. Qualitätsattribute als Architektur-Treiber**
-- Inhalte: Funktionale vs. nicht-funktionale Anforderungen; Wartbarkeit, Skalierbarkeit,
-  Zuverlässigkeit, Performance, Sicherheit; NFRs messbar machen (Szenarien, Fitness Functions).
-- AI-Linse (B): Nicht-Determinismus, Latenz und Kosten als neue Qualitätsattribute von
-  AI-Komponenten.
-- Projekt: Qualitätsszenarien definieren.
+**2. Das Koordinatensystem: zwölf Profildimensionen** *(Teil I)*
+- Inhalte: Die zwölf Dimensionen mit Antwortmass und Messinstrument; ISO/IEC 25010:2023 als
+  Vokabular; ASR und Quality Attribute Workshop; sechsteilige Qualitätsszenarien; Utility Tree
+  → Gewichte; R(a) aus Gewichten, Workload-Shape und Constraints.
+- AI-Linse (B): Nicht-Determinismus, Latenz und Kosten als Dimension D12 der AI-Integrierbarkeit.
+- Projekt: Requirements-Workshop I -- Qualitätsszenarien mit Antwortmass, Utility Tree beginnen.
 
-**3. Strukturieren im Kleinen: Kopplung & Kohäsion**
-- Inhalte: Kopplung und Kohäsion als zentrale Metriken; Modularität; Richtung von
-  Abhängigkeiten.
-- AI-Linse (B): Adapter/Facade um ein LLM als Anti-Corruption-Layer.
-- Projekt: Domänenmodell (Vertiefung des Stoffs aus AISE501).
+**3. Nachfrage, Angebot, Passung: das formale Modell** *(Teil I)*
+- Inhalte: C(p) über Taktiken; das dreistufige, nicht-kompensatorische Matching-Verfahren am
+  Mini-Match des Kursprojekts (C10 gegen L, MM, MS); warum keine gewichtete Summe;
+  ADR/MADR mit Messvertrag als Abschluss.
+- AI-Linse (A/B): Der LLM-Provider hinter einem Port; ein Agent entwirft den MADR, ein Mensch
+  zeichnet ihn.
+- Projekt: Requirements-Workshop II -- R(Plattform) finalisieren, Ontologie als Vertrag.
+  **Abgabe A1 (Ende Woche 3).**
 
-**4. Design Patterns als Architektur-Vokabular**
-- Inhalte: Relevante GoF-Patterns (Strategy, Adapter, Observer, Factory, Facade) im
-  Architekturkontext; Abgrenzung Prinzip vs. Struktur.
-- AI-Linse (A): Ein Agent schlägt Patterns/Refactorings vor; Studierende prüfen die
-  resultierende Kopplung.
-- Projekt: Ontologie als Vertrag formalisieren.
+**4. Patterns I: ein Deployable** *(Teil II)*
+- Inhalte: Schichtenarchitektur, modularer Monolith, Hexagonal/Ports-and-Adapters -- je
+  Ursprungsproblem, Topologie, Architecture Quantum, Fähigkeitsprofil, Anti-Patterns;
+  Modulgrenzen als CI-Gegenstand (Spring Modulith, import-linter, ArchUnit, Packwerk).
+- AI-Linse (B): Der Port als Anti-Corruption-Layer, der die LLM-Komponente austauschbar macht.
+- Projekt: Architekturstudium I -- healthchecks (Django), Apache Fineract und Cosmic Python im
+  Code; C4-Kontext- und Container-Entwurf.
 
-**5. Architekturstile**
-- Inhalte: Modularer Monolith, Microservices, Event-Driven Architecture, Hexagonal/Ports &
-  Adapters; Auswahlkriterien; Conway's Law und Team-Topologien.
-- AI-Linse (B): Welcher Stil eignet sich, wenn eine Komponente ein Agent ist?
-- Projekt: Architektur aus der Ontologie ableiten (Bounded Contexts → Services).
+**5. Patterns II: verteilte Topologien** *(Teil II)*
+- Inhalte: Microservices und Event-Driven Architecture; Sagas vs. ACID; der verteilte Monolith;
+  Broker- vs. Mediator-Topologie; die sieben Resilienz-Grundmuster; Fallstudien (Netflix,
+  Uber DOMA, Monzo, Segment-Rückbau).
+- AI-Linse (B): Ein LLM-Aufruf als unzuverlässiger Remote-Call; Queues absorbieren Latenz,
+  Rate-Limits und Ausfälle.
+- Projekt: Architekturstudium II -- Ränder entwerfen (Ingestion-Queue, Resilienz gegen
+  API-Ausfall), Service-Kontrakte skizzieren, Matrix-Vorfilter.
 
-**6. Verteilte Systeme I: Schnittstellen und Kontrakte**
-- Inhalte: API-Design, Kontrakte, Versionierung; synchrone vs. asynchrone Kommunikation.
-- AI-Linse (B): Ein LLM-Aufruf als unzuverlässiger Remote-Call.
-- Projekt: Walking Skeleton – Services und ein minimaler Agent laufen.
+**6. Patterns III: Batch und Serverless, Verallgemeinerung -- und die eigene Klasse C10**
+*(Teil II; Teil III)*
+- Inhalte: Pipes-and-Filters/Batch und Serverless/FaaS; Stepping Back -- Architecture Quantum,
+  "Partitioning beats distribution", konsolidierte Fähigkeitstabelle, Ausblick
+  Agenten-Orchestrierung; danach C10, die AI-native Advisory-Plattform (Klasse des Projekts)
+  mit dem Spiegelpaar C1/C2 als Vorschau.
+- AI-Linse (B): Serverless und Pipelines als natürliche Heimat von Ingestion und Evaluation.
+- Projekt: **Der Match** -- drei Stufen für die eigene Plattform, Architekturentscheid,
+  ADR-Entwurf.
 
-**7. Verteilte Systeme II: Resilienz**
-- Inhalte: Resilienz-Patterns (Timeout, Retry, Circuit-Breaker, Bulkhead, Fallback);
-  asynchrone Architektur, Queues, Backpressure.
-- AI-Linse (B): Guards und Fallbacks gegen Halluzination und API-Ausfälle.
-- Projekt: Resilienz gegen Ausfall externer Datenquellen einbauen.
+**7. Die Passung: drei Fälle, das Verfahren, die Matrix** *(Teil IV)*
+- Inhalte: Drei durchgerechnete Matches (C6 Shape-Gate, C1 Veto und Mitigationen, C2 ordinale
+  Lesung mit Sensitivitätsanalyse); das Verfahren im Allgemeinen; die 7×10-Matrix lesen;
+  Einführung des Messvertrags (Fitness Functions, DORA).
+- AI-Linse (A/B): Der Messvertrag als Betriebslizenz auch für agentisch erzeugten Code.
+- Projekt: Lösungsdesign finalisieren (Service-Schnitt, Kontrakte, Walking-Skeleton-Plan,
+  Messvertrag mit Zahlen); **Design-Review-Gate**, **Abgabe A2 (Ende Woche 7)**.
 
-**8. Fokus-Einheit: AI-Agenten als Architektur-Baustein**
-- Inhalte: Agent = Loop + Tools + State; Orchestrierungs-Topologien (Chain, Tree, Graph,
-  Multi-Agent) als Architekturentscheidung; Tool-Use; Inter-Service-Kommunikation der Agenten.
-- Projekt: Orchestrierter Multi-Agent (2–3 Sub-Agenten über klare Kontrakte) – Pflichtteil.
+**8. Anwendungsklassen I: C1--C5** *(Teil III)*
+- Inhalte: Anwendungsklassen als ASR-Bündel; C1 Kernbanking, C2 Social/Content, C3 Back-Office,
+  C4 ERP, C5 E-Commerce -- Herausforderungen mit Zahlen und Regulatorik, Anforderungsprofile
+  und die reale Architekturwahl (LMAX vs. Monzo, Instagram, Shopify, Fineract).
+- AI-Linse (B): Die Latenzklasse, nicht die Genauigkeit, entscheidet über die Platzierung einer
+  AI-Komponente; Agenten schlagen vor, deterministische Services entscheiden und buchen.
+- Projekt: Sprint 1 -- Walking Skeleton beginnen (MarketDataService, minimaler ResearchAgent,
+  stabile API).
 
-**9. Qualität & Test I**
-- Inhalte: Teststrategie, Testpyramide, TDD, Contract-Tests; technische Schuld; Code Reviews.
-- AI-Linse (A): Ein Agent generiert Tests; Studierende bewerten Abdeckung und Qualität.
-- Projekt: Testabdeckung der deterministischen Services.
+**9. Anwendungsklassen II: C6--C9 und zehn Profile nebeneinander** *(Teil III)*
+- Inhalte: C6 Simulation/Batch, C7 DSS/BI, C8 IoT-Streaming, C9 Collaboration/Messaging;
+  die dritte Konsistenzsemantik (Reproduzierbarkeit, Freshness-Kontrakt); zehn Profile
+  nebeneinander mit fünf klassenübergreifenden Beobachtungen.
+- AI-Linse (B): Text-to-SQL nur auf der governierten semantischen Schicht; keine LLM-Aufrufe
+  pro Event im Stream.
+- Projekt: Coaching; Walking Skeleton fertigstellen -- **Meilenstein: läuft End-to-End**.
 
-**10. Fokus-Einheit: Evaluation nicht-deterministischer Ausgaben**
-- Inhalte: Testen nicht-deterministischer Software; LLM-as-Judge; Regression gegen
-  Domänen-Axiome und gelabelte Referenzdaten; Eval-Harness als Software-Engineering-Artefakt.
-- Projekt: Eval-Harness gegen Domänenregeln aufbauen.
+**10. Hybride, Evolution und das achtstufige Entscheidungsverfahren** *(Teil IV)*
+- Inhalte: Hybride als Normalfall; Fit als Funktion der Zeit; Migrationsstrategien
+  (MonolithFirst, Strangler Fig, Sacrificial Architecture; Segment, Prime Video, Shopify);
+  das achtstufige Verfahren an ADR-007; Matrix-Zeilenbegründungen.
+- AI-Linse (B): Die AI-Schicht als bewusst ersetzbare Sacrificial Architecture hinter einem Port.
+- Projekt: Coaching; deterministische Services (Performance, Risk, Optimization) mit exakten
+  Tests gegen die Referenzvektoren.
 
-**11. DevOps und Betrieb**
-- Inhalte: CI/CD, Build-Reproduzierbarkeit, Deployment-Strategien (Blue/Green, Canary);
-  Observability (Logging, Metriken, Tracing); Grundgedanke SRE.
-- AI-Linse (B): Token-Kosten und Latenz im Monitoring; Versionierung von Prompts und Modellen.
-- Projekt: CI/CD-Pipeline und Observability.
+**11. Der Messvertrag, Conway's Law und die Grenzen der Theorie** *(Teil IV)*
+- Inhalte: Fitness Functions in CI/CD (Taxonomie, drei Instrumentenfamilien); die vier
+  DORA-Metriken und der Kopplungs-Befund; Kostenverlauf von Änderungen (Boehm vs. Menzies);
+  Conway's Law und Team Topologies; sechs Grenzen der Theorie.
+- AI-Linse (A/B): Eval-Harness-Pass-Rate und Token-Budget als neue Fitness-Function-Typen mit
+  alter Mechanik.
+- Projekt: Coaching; Resilienz auf allen externen Aufrufen, verifizierte Graceful Degradation
+  -- **Meilenstein: deterministischer Kern vollständig getestet und resilient**.
 
-**12. Skalierung und Evolution**
-- Inhalte: Caching, Lasttests, Skalierungs-Patterns; Strangler-Fig-Migration; evolutionäre
-  Architektur und Fitness Functions.
-- AI-Linse (B): Model-Routing, Caching und Batching als Skalierungs-Patterns.
-- Projekt: Lasttest und Optimierung; Kür: autonome Agenten / Self-Repair-Loops.
+**12. AI-Dimension I: Achse A -- Evidenz und Konsequenzen; Achse B -- Grundlagen** *(Teil V)*
+- Inhalte: Zwei widersprüchliche RCTs (Copilot +55.8 % vs. METR −19 % samt Wahrnehmungslücke)
+  und ihre Auflösung; der Verifikations-Engpass; ADRs und Agenten-Instruktionsdateien als
+  Kontrollschnittstelle; Achse B: der Sentiment-Call falsch und richtig verdrahtet, drei
+  Komponententypen, LLM-Gateway-Referenzarchitektur, Eval-Harness-Grundlagen.
+- Projekt: Coaching; AdvisorAgent mit 2--3 Sub-Agenten hinter dem Gateway (Pflichtteil),
+  Ontologie-Guard auf allen Insights aktiv.
 
-**13. Sicherheit**
-- Inhalte: Threat-Modeling, Secure-by-Design, Least Privilege, Defense in Depth.
-- AI-Linse (A/B): Prompt-Injection als neue Bedrohungsklasse; Security-Review mit AI-Unterstützung.
-- Projekt: Hardening des Systems.
+**13. AI-Dimension II: Bedrohungen, verschobene Matrix, Orchestrierung -- und Synthese** *(Teil V)*
+- Inhalte: OWASP LLM Top 10 und Prompt Injection als Architekturproblem; EU AI Act als
+  Knock-out-Constraint; die fünf Zellverschiebungen der Matrix; Agenten-Orchestrierung als
+  achtes, emergentes Kompositionsmuster und die Ökonomie der Autonomie; Synthese und
+  Prüfungsorientierung.
+- Projekt: Coaching; Eval-Harness als CI-Gate, Kosten- und Latenz-Dashboard, Threat-Model,
+  Hardening, Topologie-ADR; Kür: autonomes Planning, Self-Repair, Model-Routing --
+  **Meilenstein: Eval-Harness im CI, Guard aktiv, Kosten-Observability**.
 
-**14. Synthese, Präsentation und Architektur-Kritik**
-- Inhalte: Trade-offs verteidigen; kritische Bewertung der Architektur; Feedback.
-- Reflexion: Wo half und wo schadete die AI – im Bauen (A) und im System (B)?
-- Projekt: Präsentationen und Peer-Reviews der Abschlussprojekte.
+**14. Synthese, Präsentation und Architektur-Verteidigung**
+- Inhalte (1 L): Die Theorie-Pipeline in einem Satz; eine Disziplin an zwei Bindungsstellen;
+  Prüfungsorientierung und Q&A -- kein neuer Stoff.
+- Reflexion: Wo half und wo schadete die AI -- im Bauen (A) und im System (B)?
+- Projekt (3 L): Präsentationen, Architektur-Verteidigung und Peer-Reviews -- **Abgabe A3**.
 
 ---
 
 ## Praxisprojekt: AI-Augmented Portfolio Intelligence Platform
 
-Als durchgehendes Gruppenprojekt entwickeln die Studierenden eine verteilte Analyse- und
-Advisory-Plattform für Aktienportfolios (**kein Trading, kein echtes Geld** – ausschliesslich
-Analyse und Empfehlung). Die Plattform:
+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; ob ihre Services als ein Deployable oder als mehrere ausgeliefert werden, ist
+die Architekturentscheidung der Teams in Woche 6, die in Woche 14 verteidigt wird. Die
+Plattform:
 
-- bezieht **strukturierte externe Daten** (Börsenkurse / Preisdaten, z.B. via Yahoo Finance) –
-  mit Live-API und verpflichtendem Cache-/Snapshot-Fallback;
+- 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, Web-Berichte) und wandelt sie über
-  eine AI-Komponente in strukturierte Insights um;
-- berechnet **Risikomanagement-, Performance- und Portfolio-Optimierungs-Kennzahlen**
-  (Formeln und Testvektoren werden vorgegeben; die Lernleistung ist das Engineering darum
-  herum, nicht die Herleitung der Finanzmathematik);
-- stellt die Funktionalität **API-first** bereit, mit einem dünnen Dashboard (z.B. Streamlit)
+  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 einem dünnen Dashboard (z. B. Streamlit)
   nur zur Demonstration.
 
-**Zentrale Architekturregel:** Die AI-Agenten dürfen quantitative Werte ausschliesslich über
-die deterministischen Services beziehen und interpretieren – niemals selbst berechnen. Diese
-Trennung von deterministischen und nicht-deterministischen Systemteilen ist die prüfbare
-Manifestation von "AI engineering-tauglich machen".
+**Zentrale Architekturregel:** *Agents propose; deterministic services decide and book.* Die
+AI-Agenten dürfen quantitative Werte ausschliesslich über die deterministischen Services
+beziehen und interpretieren -- niemals selbst berechnen. Diese Trennung von deterministischen
+und nicht-deterministischen Systemteilen ist die prüfbare Manifestation von "AI
+engineering-tauglich machen" und wird bewertet.
 
 **Beispielhafte Service-Landschaft (Bounded Contexts):** MarketData-Service, News-Ingestion,
 Risk-Service, Performance-Service, Optimization-Service, Portfolio-Service sowie ein
 orchestrierender Advisor-Agent mit spezialisierten Sub-Agenten (Research-, Risk-,
-Optimization-Agent). Eine Ontologie der Anlagedomäne (Asset-Klassen, Sektoren, Regeln) dient
-als Architektur-Vertrag und als Halluzinations-Guard.
+Optimization-Agent) hinter einem einzigen LLM-Gateway. Eine Ontologie der Anlagedomäne
+(Asset-Klassen, Sektoren, Regeln) dient als Architektur-Vertrag und als Halluzinations-Guard.
+
+**Meilensteine:** M1 Requirements und Ontologie (Wochen 1--3, Abgabe A1) · M2
+Architekturentscheid und Lösungsdesign (4--7, Abgabe A2 mit Design-Review-Gate) · M3 Walking
+Skeleton (8--9) · M4 deterministischer Kern und Resilienz (10--11) · M5
+Multi-Agent-Orchestrierung, Evaluation und Hardening (12--13) · M6 Präsentation und
+Architektur-Verteidigung (14, Abgabe A3).
 
 **Abstufung Pflicht / Kür:**
 
-- *Pflicht (bestehensrelevant):* orchestrierter Advisor-Agent mit 2–3 Sub-Agenten über klare
-  Service-Kontrakte; Ontologie-Guard; Sentiment-Evaluation der News; vollständig getestete
-  deterministische Services; Resilienz gegen Ausfall externer Datenquellen; Observability für
-  Kosten und Latenz.
-- *Kür (für Spitzennoten):* autonomes Planning (der Agent entscheidet selbst über
-  Tool-/Sub-Agent-Aufrufe), Self-Repair-Loops, Model-Routing.
+- *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 über klare Service-Kontrakte; Ontologie-Guard;
+  Resilienz gegen Ausfall externer Datenquellen; Eval-Harness für die AI-Komponente;
+  Observability für Kosten und Latenz ü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 Tool- und
+  Sub-Agent-Aufrufe), Self-Repair-Loops, Model-Routing, Deployment mit CI/CD und Tracing.
 
 ---
 
@@ -269,8 +338,9 @@ als Architektur-Vertrag und als Halluzinations-Guard.
 
 **Lehrtechniken:** Vorlesungen, Übungen, Gruppenarbeit, Online-Lehre, Workshops.
 
-**Lernaktivitäten:** Studium von Literatur, Übungsaufgaben, Bearbeiten von Problemen und deren
-Lösungsfindung, Zusammenarbeit mit anderen Studierenden, projektbegleitendes Selbststudium.
+**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.
 
@@ -281,14 +351,24 @@ Lösungsfindung, Zusammenarbeit mit anderen Studierenden, projektbegleitendes Se
 | | |
 |---|---|
 | Online-, Hybrid- oder Präsenzunterricht | 42 h |
-| Selbststudium (Lektüre und Projekt) | 78 h |
+| Selbststudium (Skript, Lektüre und Projekt) | 78 h |
 | **Total** | **120 h (4 ECTS)** |
 
 ## Literatur
 
-- *Modernes Software-Engineering: Entwurf und Entwicklung von Softwareprodukten* – Ian
-  Sommerville (Hauptanker).
-- Ergänzend: *Fundamentals of Software Architecture* (Richards & Ford), *Building
-  Microservices* (Newman), *Refactoring* (Fowler) – nach Bedarf als Reader.
-- Aktuelle wissenschaftliche Artikel und Branchenforschung im Bereich AI-Agenten,
-  agentische Entwicklungswerkzeuge und Evaluation von AI-Systemen.
+**Leitmedium:**
+- *AISE502 Lecture Notes -- A Theory of Architecture--Application Fit*, F. Herzog,
+  Fachhochschule Graubünden, 2026 (englisch; wird abgegeben).
+
+**Methodische Hauptquellen der Theorie:**
+- L. Bass, P. Clements, R. Kazman: *Software Architecture in Practice*, 4. Aufl., 2021.
+- M. Richards, N. Ford: *Fundamentals of Software Architecture*, 2. Aufl., O'Reilly, 2025.
+- N. Ford, R. Parsons, P. Kua, P. Sadalage: *Building Evolutionary Architectures*, 2. Aufl.,
+  O'Reilly, 2022.
+- N. Forsgren, J. Humble, G. Kim: *Accelerate*, IT Revolution, 2018.
+
+**Begleitend:**
+- I. Sommerville: *Modernes Software-Engineering*, Pearson, 2020 (deutschsprachiger Anker).
+- S. Newman: *Building Microservices*, 2. Aufl., O'Reilly, 2021 (nach Bedarf als Reader).
+- Aktuelle wissenschaftliche Artikel und Branchenforschung zu AI-Agenten, agentischen
+  Entwicklungswerkzeugen und Evaluation von AI-Systemen (u. a. DORA-Reports, METR).

Modulbeschreibung_AISE502_v3_2026.md

@@ -6,8 +6,8 @@
 | **Ausgabestelle** | Institute for Data Analysis, Artificial Intelligence, Visualization, and Simulation (DAViS) |
 | **Geltungsbereich** | Departement |
 | **Klassifizierung** | Nicht klassifiziert |
-| **Version** | 3.0.0 |
-| **Ausgabedatum** | 2026 (Neufassung entlang des Vorlesungsskripts) |
+| **Version** | 3.1.0 |
+| **Ausgabedatum** | 8. September 2026 (Sitzungsplan an die ausgelieferten Vorlesungen 1–14 angeglichen) |
 
 ---
 
@@ -59,7 +59,7 @@ Beispiele zuerst, Verallgemeinerung danach. Jedes Pattern wird aus dem realen Pr
 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 verteilte, AI-gestützte
+("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
@@ -138,7 +138,7 @@ Nach erfolgreichem Abschluss dieses Moduls sind die Studierenden in der Lage:
 
 | Anteil | Komponente |
 |---|---|
-| 50 % | Praxisprojekt (verteilte AI-gestützte Plattform, Gruppenarbeit) -- inklusive Requirements-Dossier (A1), Architektur-Dossier mit ADR und Messvertrag (A2), Implementierung sowie Abschlusspräsentation mit Architektur-Verteidigung |
+| 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
@@ -147,7 +147,7 @@ Gemäss Rahmenprüfungsordnung.
 
 ### Unterrichtssprache
 
-Deutsch. Sämtliche Unterlagen (Vorlesungsskript, Übungen, Paper) in Englisch.
+Deutsch. Sämtliche Unterlagen (Vorlesungsskript, Folien, Übungen, Paper) in Englisch.
 
 ### Eingangskompetenzen
 
@@ -157,132 +157,196 @@ 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
 
-Der Kurs umfasst 14 Sitzungen. 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. Didaktik durchgängig induktiv: Fallstudien und
-Beispiele vor der Verallgemeinerung.
+**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).
 
-**1. Das Entscheidungsproblem und das Framework** *(Skript Teil I)*
-- Inhalte: Vier Produktionssysteme, eine Lektion (LMAX, Monzo, Stack Overflow, Prime Video);
-  Architektur als schwer umkehrbare Entscheidungen; die fünf Framework-Elemente (R(a), C(p),
-  fit, ADR, Messvertrag); die tragenden Annahmen A1--A6; ADR/MADR und C4.
-- Praktische Anwendung: Projektstart (Domäne, Vision, Werkzeug-Setup); 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.
 
-**2. Das Koordinatensystem: zwölf Profildimensionen** *(Teil I)*
-- Inhalte: Von Alltagsfragen zu messbaren Dimensionen; die zwölf Dimensionen einzeln
-  motiviert (Last, Korrektheit/Vertrauen, Wandel/Delivery, Ökonomie/Organisation, AI);
-  ISO/IEC 25010:2023 als Vokabular; Antwortmasse und Messinstrumente.
-- Praktische Anwendung: Dimensionsprofil einer täglich genutzten App erstellen und
-  diskutieren; erste Qualitätsszenarien für die Projektplattform formulieren.
+**3. Angebot, Passung und Entscheidungsprotokoll** *(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).**
 
-**3. Nachfrage, Angebot, Passung: das formale Modell** *(Teil I)*
-- Inhalte: Konstruktion von R(a) (ASR → Szenarien → Utility Tree → Gewichte; Workload-Shape;
-  Knock-out-Constraints); Herleitung von C(p) über Taktiken; das dreistufige
-  Matching-Verfahren am Mini-Match des Kursprojekts (C10 gegen drei Kandidaten); warum keine
-  gewichtete Summe (MCDM-Kritik).
-- Praktische Anwendung: R(Projektplattform) im Team konstruieren und als Utility Tree
-  begründen; Qualitätsszenarien mit Antwortmass fixieren.
-
-**4. Patterns I: Ein Deployable** *(Teil II)* 
+**4. Patterns I: ein Deployable** *(Teil II, §8--10)*
 - Inhalte: Schichtenarchitektur, modularer Monolith, Hexagonal/Ports-and-Adapters -- je:
-  reales Ursprungsproblem, Topologie, dimensionsweises Fähigkeitsprofil,
+  reales Ursprungsproblem, Topologie, Architecture Quantum, dimensionsweises Fähigkeitsprofil,
   Engineering-Konsequenzen, Anti-Patterns; Modulgrenzen als CI-Gegenstand (Spring Modulith,
-  import-linter, ArchUnit).
-- Praktische Anwendung: "Build it and study it" -- healthchecks (Django), Apache Fineract
-  und das Cosmic-Python-Repo klonen und die Architektur im Code nachweisen; AI-Linse: der
-  LLM-Provider hinter einem Port.
+  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)*
+**5. Patterns II: verteilte Topologien** *(Teil II, §11--12)*
 - Inhalte: Microservices und Event-Driven Architecture -- Ursprungsprobleme (Release-Zug,
-  Ingest), Profile, Sagas vs. ACID, Resilienz-Grundmuster (Timeout, Retry, Circuit-Breaker),
-  Schema-Governance; dokumentierte Fallstudien (Netflix, Uber DOMA, Segment-Rückbau).
-- Praktische Anwendung: Online Boutique (Kubernetes) und der Home-Assistant-EventBus im
-  Quellcode; AI-Linse: ein LLM-Aufruf als unzuverlässiger Remote-Call.
+  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; Verallgemeinerung** *(Teil II)*
-- Inhalte: Pipes-and-Filters/Batch und Serverless/FaaS; danach die Verallgemeinerung:
-  Architecture Quantum, "Partitioning beats distribution", Evidenzbasis (Sterne-Ratings)
-  und die konsolidierte Fähigkeitstabelle als Vergleichssicht.
-- Praktische Anwendung: dbt-Pipeline (jaffle_shop_duckdb) lokal bauen; Knative-Bookstore
-  inspizieren; Projekt: Bounded Contexts aus der Ontologie ableiten (Vertiefung AISE501).
+**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. Anwendungsklassen I: Transaktion, Content, Verwaltung** *(Teil III)*
-- Inhalte: 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, Odoo/Fineract).
-- Praktische Anwendung: Walking Skeleton des Projekts -- deterministische Services und ein
-  minimaler Agent laufen End-to-End.
+**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. Anwendungsklassen II: Daten, Echtzeit, AI-nativ** *(Teil III)*
-- Inhalte: C6 Simulation/Batch, C7 DSS/BI, C8 IoT-Streaming, C9 Collaboration/Messaging,
-  C10 AI-native Advisory-Plattform (das Kursprojekt als zehnte Klasse); Verallgemeinerung:
-  zehn Profile nebeneinander, Spiegelpaare, Übergabe an das Matching.
-- Praktische Anwendung: Anforderungsprofil des Projekts gegen C10 abgleichen; Resilienz
-  gegen Ausfall externer Datenquellen einbauen.
+**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. Die Passung: drei Fälle, drei Stufen, die Matrix** *(Teil IV)*
-- Inhalte: Drei durchgerechnete Matches (C6: Shape-Gate; C1: Veto und Mitigationen; C2:
-  ordinale Rangbildung und Tradeoff-Points); das Verfahren im Allgemeinen; die 7×10-Matrix
-  mit Zeilen-Begründungen.
-- Praktische Anwendung: Matching der eigenen Plattform-Architektur nachvollziehen und als
-  ADR mit Rationale dokumentieren (Pflicht-Artefakt).
+**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)*
-- Inhalte: Hybride als Normalfall; Evolutionspfade und Migrationsstrategien (Strangler Fig;
-  Fallstudien Segment, Prime Video, Shopify); das achtstufige Entscheidungsverfahren von den
-  ASRs bis zum Messvertrag, durchgespielt am Kursprojekt (ADR-007).
-- Praktische Anwendung: Orchestrierter Multi-Agent (2--3 Sub-Agenten über klare Kontrakte)
-  -- Pflichtteil des Projekts.
+**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: Fitness Functions, DORA, Betrieb** *(Teil IV)*
-- Inhalte: Fitness Functions (atomar/holistisch, triggered/continual) in CI/CD; die vier
-  DORA-Metriken und der Kopplungs-Befund; Observability; Kostenverlauf von
-  Architekturänderungen (Boehm vs. Menzies); Conway's Law und Team Topologies als dritte
-  Passungsdimension.
-- Praktische Anwendung: CI/CD-Pipeline mit Architektur-Fitness-Functions (Modulgrenzen,
-  Budgets) und Observability für Kosten und Latenz aufsetzen.
+**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. Achse A: AI als Werkzeug -- Evidenz und Konsequenzen** *(Teil V)*
-- Inhalte: Zwei widersprüchliche Experimente (Copilot-RCT +55.8 % vs. METR −19 % inkl.
-  Wahrnehmungslücke) und ihre Auflösung; der Verifikations-Engpass; Architektur-Dokumente
-  als Agenten-Kontext; Guardrails als Voraussetzung; Werkzeuglandschaft und Risiken.
-- Praktische Anwendung: Ein Agent generiert Tests/Refactorings gegen die eigene Codebasis;
-  Studierende bewerten Abdeckung, Qualität und Review-Last.
+**12. 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. Achse B: AI als Komponente -- Kapselung, Evaluation, Orchestrierung** *(Teil V)*
-- Inhalte: Der Sentiment-Call falsch und richtig verdrahtet; drei Komponententypen (LLM,
-  ML, Solver); LLM-Gateway-Referenzarchitektur (Routing, Caching, Budgets, Fallbacks);
-  Eval-Harness (Golden Sets, LLM-as-Judge, Domänen-Axiome) als CI-Gate; Prompt Injection
-  und EU AI Act; Agenten-Orchestrierung als emergentes Kompositionsmuster und ihre Ökonomie.
-- Praktische Anwendung: Eval-Harness gegen Domänenregeln aufbauen (Pflicht); Ontologie-Guard
-  und Kosten-Dashboard; Kür: autonomes Planning, Self-Repair-Loops, Model-Routing.
+**13. Achse B: Bedrohungen, verschobene Matrix, Agenten-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-Kritik**
-- Inhalte: Die Theorie-Pipeline in einem Satz; Grenzen der Theorie (auf sich selbst
-  angewandt); Trade-offs verteidigen; Reflexion: Wo half und wo schadete AI -- im Bauen
-  (Achse A) und im System (Achse B)?
-- Praktische Anwendung: Präsentationen, Architektur-Verteidigung und Peer-Reviews der
-  Abschlussprojekte.
+**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 verteilte Analyse- und
+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; ihre Architektur folgt dem im Modul berechneten Verdikt: **hexagonaler
-modularer Monolith als deterministischer Kern, Event-getriebene Ränder, Pipelines für
-Ingestion und Evaluation, orchestrierter Advisor-Agent hinter einem LLM-Gateway.**
+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 Insights um;
+  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.
@@ -290,19 +354,38 @@ Ingestion und Evaluation, orchestrierter Advisor-Agent hinter einem LLM-Gateway.
 **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".
+Manifestation von "AI engineering-tauglich machen" und wird bewertet.
 
 **Abstufung Pflicht / Kür:**
 
-- *Pflicht (bestehensrelevant):* orchestrierter Advisor-Agent mit 2--3 Sub-Agenten über
-  klare Service-Kontrakte; LLM-Gateway mit Kosten-Observability; Ontologie-Guard;
-  Eval-Harness als CI-Gate; vollständig getestete deterministische Services; Resilienz
-  gegen Ausfall externer Datenquellen; ein ADR mit Messvertrag (Token-Budget,
-  Eval-Schwelle, Modulgrenzen-Check).
-- *Kür (für Spitzennoten):* autonomes Planning, Self-Repair-Loops, Model-Routing.
+- *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.
@@ -342,6 +425,7 @@ Zusammenarbeit mit anderen Studierenden, projektbegleitendes Selbststudium.
 **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).