228 lines
26 KiB
Plaintext
228 lines
26 KiB
Plaintext
h1. 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)|
|
||
|
||
----
|
||
|
||
h2. Modul
|
||
|
||
||Feld||Wert||
|
||
|*Name*|AI in Software Engineering II|
|
||
|*Kürzel*|AISE502|
|
||
|*ECTS-Punkte*|4|
|
||
|*Typ*|Pflichtmodul|
|
||
|*Verantwortliche/r*|Herzog Florian|
|
||
|*Semester*|5. Semester|
|
||
|
||
h3. 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 %*.
|
||
|
||
h3. Voraussetzungen
|
||
|
||
# AI in Software Engineering I (AISE501)
|
||
# Software Technik I und II
|
||
# Maschinelles Lernen, Deep Learning
|
||
# Mathematik-Grundlagen, Informatik-Grundlagen
|
||
|
||
h3. Lernergebnisse
|
||
|
||
Nach erfolgreichem Abschluss dieses Moduls sind die Studierenden in der Lage:
|
||
|
||
# *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.
|
||
# *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).
|
||
# *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.
|
||
# *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).
|
||
# *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.
|
||
# *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.
|
||
# *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.
|
||
# *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.
|
||
|
||
h3. 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|
|
||
|
||
h3. Nachprüfung
|
||
|
||
Gemäss Rahmenprüfungsordnung.
|
||
|
||
h3. Unterrichtssprache
|
||
|
||
Deutsch. Sämtliche Unterlagen (Vorlesungsskript, Folien, Übungen, Paper) in Englisch.
|
||
|
||
h3. 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.
|
||
|
||
----
|
||
|
||
h2. 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.
|
||
|
||
h3. 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|
|
||
|
||
----
|
||
|
||
h2. Inhalte
|
||
|
||
# *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).
|
||
# *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.
|
||
# *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).*
|
||
# *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.
|
||
# *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).
|
||
# *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.
|
||
# *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).*
|
||
# *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.
|
||
# *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).
|
||
# *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.
|
||
# *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.
|
||
# *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).
|
||
# *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.*
|
||
# *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.*
|
||
|
||
----
|
||
|
||
h2. 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).
|
||
|
||
----
|
||
|
||
h2. 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.
|
||
|
||
h2. 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.
|
||
|
||
----
|
||
|
||
h2. Struktur
|
||
|
||
||Element||Stunden||
|
||
|Online-, Hybrid- oder Präsenzunterricht|42 h|
|
||
|Selbststudium (Skript, Lektüre und Projekt)|78 h|
|
||
|*Total*|*120 h (4 ECTS)*|
|
||
|
||
h2. 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).
|