297 lines
14 KiB
Markdown
297 lines
14 KiB
Markdown
# 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** | 2.0.0 |
|
||
| **Ausgabedatum** | 2026 (Neufassung) |
|
||
|
||
---
|
||
|
||
## Modul
|
||
|
||
| Feld | Wert |
|
||
|---|---|
|
||
| **Name** | AI in Software Engineering II |
|
||
| **Kürzel** | AISE502 |
|
||
| **ECTS-Punkte** | 4 |
|
||
| **Typ** | Pflichtmodul |
|
||
| **Verantwortliche/r** | Herzog Florian |
|
||
| **Semester** | 5. Semester |
|
||
|
||
### Leitidee
|
||
|
||
Das Modul "AI in Software Engineering II" stellt das **Software Engineering grosser, langlebiger
|
||
Systeme** in den Mittelpunkt 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 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 –
|
||
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:
|
||
|
||
- **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.
|
||
- **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.
|
||
|
||
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.
|
||
|
||
Das Verhältnis von klassischem Software Engineering zu AI-spezifischen Techniken beträgt
|
||
etwa **60 % zu 40 %**.
|
||
|
||
### Voraussetzungen
|
||
|
||
1. AI in Software Engineering I (AISE501)
|
||
2. Software Technik I und II
|
||
3. Maschinelles Lernen, Deep Learning
|
||
4. Mathematik-Grundlagen, Informatik-Grundlagen
|
||
|
||
### Lernergebnisse
|
||
|
||
Nach erfolgreichem Abschluss dieses Moduls sind die Studierenden in der Lage:
|
||
|
||
1. **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.
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
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).
|
||
|
||
5. **AI-gestützte Software professionell bauen (Achse A):**
|
||
- Moderne agentische Entwicklungswerkzeuge produktiv einsetzen und deren Ausgaben
|
||
kritisch bewerten und verantworten.
|
||
|
||
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.
|
||
|
||
7. **Evolution und Wartbarkeit gewährleisten:**
|
||
- Strategien zur Weiterentwicklung und Migration (z.B. Strangler-Fig) sowie evolutionäre
|
||
Architektur mit Fitness Functions anwenden.
|
||
|
||
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.
|
||
|
||
### Leistungsnachweis
|
||
|
||
| Anteil | Komponente |
|
||
|---|---|
|
||
| 40 % | Praxisprojekt (verteilte AI-gestützte Plattform, Gruppenarbeit) |
|
||
| 20 % | Präsentation und Architektur-Verteidigung des Projekts |
|
||
| 10 % | Assignments (Lese- und Mini-Aufgaben begleitend) |
|
||
| 30 % | Schriftliche Prüfung (Schwerpunkt: Architektur-Reasoning und Trade-off-Analyse, keine reine Faktenabfrage) |
|
||
|
||
### Unterrichtssprache
|
||
|
||
Deutsch mit englischen Unterlagen und Papern.
|
||
|
||
### 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.
|
||
|
||
---
|
||
|
||
## 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.
|
||
|
||
**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.
|
||
|
||
**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.
|
||
|
||
**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).
|
||
|
||
**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.
|
||
|
||
**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).
|
||
|
||
**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.
|
||
|
||
**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.
|
||
|
||
**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.
|
||
|
||
**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.
|
||
|
||
**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.
|
||
|
||
**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.
|
||
|
||
**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.
|
||
|
||
**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.
|
||
|
||
**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.
|
||
|
||
---
|
||
|
||
## 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:
|
||
|
||
- bezieht **strukturierte externe Daten** (Börsenkurse / Preisdaten, 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)
|
||
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".
|
||
|
||
**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.
|
||
|
||
**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.
|
||
|
||
---
|
||
|
||
## Lehr- und Lernmethoden
|
||
|
||
**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.
|
||
|
||
**Lehrmethode:** Präsentation; Einzel-, Partner- und Gruppenarbeit; E-Learning.
|
||
|
||
---
|
||
|
||
## Struktur
|
||
|
||
| | |
|
||
|---|---|
|
||
| Online-, Hybrid- oder Präsenzunterricht | 42 h |
|
||
| Selbststudium (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.
|