197 lines
19 KiB
Plaintext
197 lines
19 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.0.0|
|
||
|*Ausgabedatum*|2026 (Neufassung entlang des Vorlesungsskripts)|
|
||
|
||
----
|
||
|
||
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 verteilte, 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 (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 %|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, Ü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. 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.
|
||
|
||
# *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).
|
||
# *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.
|
||
# *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.
|
||
# *Patterns I: Ein Deployable* _(Teil II)_
|
||
#* Inhalte: Schichtenarchitektur, modularer Monolith, Hexagonal/Ports-and-Adapters – je: reales Ursprungsproblem, Topologie, 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.
|
||
# *Patterns II: Verteilte Topologien* _(Teil II)_
|
||
#* 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.
|
||
# *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).
|
||
# *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.
|
||
# *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.
|
||
# *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).
|
||
# *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.
|
||
# *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.
|
||
# *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.
|
||
# *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.
|
||
# *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.
|
||
|
||
----
|
||
|
||
h2. 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 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.*
|
||
|
||
* 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;
|
||
* 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".
|
||
|
||
*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.
|
||
|
||
----
|
||
|
||
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).
|
||
* Aktuelle wissenschaftliche Artikel und Branchenforschung zu AI-Agenten, agentischen Entwicklungswerkzeugen und Evaluation von AI-Systemen (u. a. DORA-Reports, METR, Anthropic Engineering).
|