348 lines
19 KiB
Markdown
348 lines
19 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** | 3.0.0 |
|
||
| **Ausgabedatum** | 2026 (Neufassung entlang des Vorlesungsskripts) |
|
||
|
||
---
|
||
|
||
## Modul
|
||
|
||
| Feld | Wert |
|
||
|---|---|
|
||
| **Name** | AI in Software Engineering II |
|
||
| **Kürzel** | AISE502 |
|
||
| **ECTS-Punkte** | 4 |
|
||
| **Typ** | Pflichtmodul |
|
||
| **Verantwortliche/r** | Herzog Florian |
|
||
| **Semester** | 5. Semester |
|
||
|
||
### Leitidee
|
||
|
||
Das Modul "AI in Software Engineering II" stellt das **Software Engineering grosser, langlebiger
|
||
Systeme** in den Mittelpunkt. Sein roter Faden ist das englischsprachige Vorlesungsskript
|
||
*"A Theory of Architecture--Application Fit"*, das eine durchgängige, messbare
|
||
Entscheidungstheorie der Softwarearchitektur entwickelt: Architektur wird verstanden als die
|
||
Menge der signifikanten, schwer umkehrbaren Entscheidungen, die durch **messbare
|
||
Qualitätsattribute** getrieben, durch systematischen Abgleich von **Anforderungsprofilen**
|
||
(zehn Anwendungsklassen) und **Fähigkeitsprofilen** (sieben Architektur-Patterns) über
|
||
**zwölf gemeinsame Profildimensionen** getroffen und über den gesamten Lebenszyklus
|
||
empirisch überprüft werden (Fitness Functions, DORA-Metriken).
|
||
|
||
Die Leitfrage lautet: *Wie entwerfe, begründe und betreibe ich die Struktur eines
|
||
Software-Systems so, dass es seine Qualitätsattribute erfüllt und über Jahre wartbar bleibt --
|
||
auch dann, wenn einzelne Komponenten nicht-deterministisch, fehlbar und kostenintensiv sind?*
|
||
|
||
Künstliche Intelligenz erscheint in **zwei gleichwertigen, strikt getrennten Achsen**:
|
||
|
||
- **Achse A -- AI als Werkzeug zum Bauen:** Studierende setzen agentische
|
||
Entwicklungswerkzeuge produktiv, aber kritisch-reflektiert ein -- auf Basis der empirischen
|
||
Evidenz (randomisierte Studien mit positiven wie negativen Befunden) und mit
|
||
Architektur-Dokumentation und Fitness Functions als Leitplanken.
|
||
- **Achse B -- AI als Komponente im System:** Studierende entwerfen Architekturen, in denen
|
||
LLM-, ML- und Optimierungskomponenten als Laufzeit-Bausteine wirken, und machen diese
|
||
nicht-deterministischen Komponenten *engineering-tauglich*: gekapselt (Gateway, Ports),
|
||
asynchron integriert, beobachtbar (Kosten, Latenz), getestet (Eval-Harness) und abgesichert
|
||
(Ontologie-Guard, Prompt-Injection-Abwehr).
|
||
|
||
Die zentrale Erkenntnis des Moduls (Annahme A6 der Theorie): **AI erweitert den
|
||
Qualitätsattributraum, ändert aber die Methode nicht.** Die Disziplin, die man zum Bauen
|
||
*mit* AI braucht, ist dieselbe wie jene zum Einbetten *von* AI.
|
||
|
||
**Didaktisches Prinzip:** Das Modul arbeitet durchgängig **induktiv** -- Fallstudien und
|
||
Beispiele zuerst, Verallgemeinerung danach. Jedes Pattern wird aus dem realen Problem
|
||
entwickelt, das es hervorbrachte; jede Anwendungsklasse aus ihren realen Herausforderungen;
|
||
das Matching-Verfahren aus drei durchgerechneten Fällen. Zu jedem Pattern gehören
|
||
Open-Source-Frameworks zum Bauen und klonbare Open-Source-Referenzsysteme zum Inspizieren
|
||
("Build it and study it"). Ein durchgehendes Gruppenprojekt -- eine 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 %**.
|
||
|
||
### Voraussetzungen
|
||
|
||
1. AI in Software Engineering I (AISE501)
|
||
2. Software Technik I und II
|
||
3. Maschinelles Lernen, Deep Learning
|
||
4. Mathematik-Grundlagen, Informatik-Grundlagen
|
||
|
||
### Lernergebnisse
|
||
|
||
Nach erfolgreichem Abschluss dieses Moduls sind die Studierenden in der Lage:
|
||
|
||
1. **Architektur als Entscheidungsproblem behandeln (Skript Teil I):**
|
||
- Architektur als Menge schwer umkehrbarer, qualitätsgetriebener Entscheidungen verstehen
|
||
(tragende Annahmen A1--A6) und Entscheidungen mit Rationale dokumentieren
|
||
(Architecture Decision Records, C4-Sichten, ISO/IEC/IEEE 42010).
|
||
- Die zwölf Profildimensionen (ISO/IEC 25010:2023-verankert, je mit Antwortmass und
|
||
Messinstrument) als gemeinsames Koordinatensystem von Anforderung und Fähigkeit
|
||
anwenden.
|
||
|
||
2. **Anforderungsprofile konstruieren (Teil I und III):**
|
||
- Architektur-relevante Anforderungen elizitieren und als sechsteilige
|
||
Qualitätsszenarien mit Antwortmass formulieren; Gewichte über Utility Trees ableiten.
|
||
- Anwendungsklassen als Anforderungsprofile R(a) charakterisieren: Gewichte,
|
||
Workload-Shape und regulatorische Knock-out-Constraints (u. a. BCBS 239, FINMA 2023/1,
|
||
PCI DSS, EU AI Act).
|
||
|
||
3. **Fähigkeitsprofile herleiten und Architektur-Patterns beherrschen (Teil II):**
|
||
- Die sieben Patterns (Schichtenarchitektur, modularer Monolith, Hexagonal,
|
||
Microservices, Event-Driven, Pipes-and-Filters, Serverless) mit Topologie, realem
|
||
Ursprungsproblem, Taktiken und dimensionsweisem Fähigkeitsprofil C(p) erklären.
|
||
- Pro Pattern Open-Source-Frameworks einsetzen und Referenzsysteme im Quellcode
|
||
inspizieren; Engineering-Konsequenzen (Build, Test, CI/CD, Deployment, Betrieb,
|
||
Teamstruktur) ableiten.
|
||
|
||
4. **Passung berechnen, begründen und verteidigen (Teil IV):**
|
||
- Das dreistufige, nicht-kompensatorische Matching-Verfahren anwenden (Knock-out und
|
||
Workload-Shape-Gate, Veto auf hochgewichteten Dimensionen mit dokumentierten
|
||
Mitigationen, ordinale Rangbildung mit Sensitivitätsanalyse) und die 7×10-Matrix als
|
||
Explikations- statt Rechenmodell nutzen.
|
||
- Hybride als Normalfall erkennen (z. B. ACID-Kern mit Event-getriebenen Rändern) und
|
||
Evolutionspfade planen (Strangler Fig, dokumentierte Rückbau-Fallstudien).
|
||
|
||
5. **Entscheidungen messbar machen und betreiben (Teil IV):**
|
||
- Jede Architekturentscheidung mit einem Messvertrag abschliessen: Fitness Functions in
|
||
CI/CD (z. B. Modulgrenzen-Checks, Performance- und Token-Budgets), DORA-Metriken und
|
||
Observability (Logging, Metriken, Tracing) im Betrieb.
|
||
|
||
6. **AI als Werkzeug professionell und kritisch einsetzen (Achse A, Teil V):**
|
||
- Die empirische Evidenz zu AI-Coding-Werkzeugen differenziert bewerten (u. a.
|
||
Copilot-RCT, METR-Studie, DORA-Reports) und daraus Konsequenzen für Spezifikation,
|
||
Verifikation und Architektur ziehen.
|
||
- Agentische Werkzeuge mit Architektur-Dokumentation als Kontext und Tests/Fitness
|
||
Functions als Leitplanken einsetzen; Ausgaben kritisch bewerten und verantworten.
|
||
|
||
7. **AI als Systemkomponente engineering-tauglich machen (Achse B, Teil V):**
|
||
- LLM-, ML- und Optimierungskomponenten hinter stabilen Schnittstellen kapseln
|
||
(Gateway, Anti-Corruption-Layer), asynchron integrieren, deterministische von
|
||
nicht-deterministischen Systemteilen strikt trennen.
|
||
- Eigene Eval-Harnesses aufbauen (Golden Sets, LLM-as-Judge mit Kalibrierung,
|
||
Domänen-Axiome) und als CI-Gate betreiben; Token-Kosten und Latenz messen und
|
||
optimieren (Caching, Batching, Model-Routing).
|
||
- Multi-Agenten-Systeme als Komposition klassischer Topologien konzipieren
|
||
(Chain/Router/Orchestrator/Multi-Agent) und deren Ökonomie bewerten.
|
||
|
||
8. **Ethik und Verantwortung reflektieren:**
|
||
- Gesellschaftliche, regulatorische (EU AI Act) und ethische Implikationen AI-gestützter
|
||
Systeme im sensiblen Anwendungskontext (Finanzdaten) bewerten; neue Bedrohungsklassen
|
||
(Prompt Injection, OWASP LLM Top 10) im Threat-Modeling berücksichtigen.
|
||
|
||
### Leistungsnachweis
|
||
|
||
| Anteil | Komponente |
|
||
|---|---|
|
||
| 50 % | Praxisprojekt (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 |
|
||
|
||
### Nachprüfung
|
||
|
||
Gemäss Rahmenprüfungsordnung.
|
||
|
||
### Unterrichtssprache
|
||
|
||
Deutsch. Sämtliche Unterlagen (Vorlesungsskript, Übungen, Paper) in Englisch.
|
||
|
||
### Eingangskompetenzen
|
||
|
||
Sicherer Umgang mit Python, Versionsverwaltung (Git) und grundlegenden Software-Engineering-
|
||
Prinzipien (Clean Code, SOLID). Grundverständnis von LLMs, Prompting und RAG aus AISE501.
|
||
Grundlagen in Statistik und maschinellem Lernen.
|
||
|
||
---
|
||
|
||
## 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)*
|
||
- 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** *(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. 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)*
|
||
- 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.
|
||
|
||
**5. 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.
|
||
|
||
**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).
|
||
|
||
**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.
|
||
|
||
**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.
|
||
|
||
**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).
|
||
|
||
**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.
|
||
|
||
**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.
|
||
|
||
**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.
|
||
|
||
**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.
|
||
|
||
**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.
|
||
|
||
---
|
||
|
||
## 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.
|
||
|
||
---
|
||
|
||
## Lehr- und Lernmethoden
|
||
|
||
**Lehrtechniken:** Vorlesungen, Übungen, Gruppenarbeit, Online-Lehre, Workshops.
|
||
|
||
**Lernaktivitäten:** Studium des Skripts und der Literatur, Inspektion realer
|
||
Open-Source-Systeme, Übungsaufgaben, Bearbeiten von Problemen und deren Lösungsfindung,
|
||
Zusammenarbeit mit anderen Studierenden, projektbegleitendes Selbststudium.
|
||
|
||
**Lehrmethode:** Präsentation; Einzel-, Partner- und Gruppenarbeit; E-Learning.
|
||
|
||
---
|
||
|
||
## Struktur
|
||
|
||
| | |
|
||
|---|---|
|
||
| Online-, Hybrid- oder Präsenzunterricht | 42 h |
|
||
| Selbststudium (Skript, Lektüre und Projekt) | 78 h |
|
||
| **Total** | **120 h (4 ECTS)** |
|
||
|
||
## Literatur
|
||
|
||
**Leitmedium (roter Faden):**
|
||
- *AISE502 Lecture Notes -- A Theory of Architecture--Application Fit*, F. Herzog,
|
||
Fachhochschule Graubünden, 2026 (englisch; wird abgegeben).
|
||
|
||
**Die vier methodischen Hauptquellen der Theorie (im Skript gewürdigt):**
|
||
- L. Bass, P. Clements, R. Kazman: *Software Architecture in Practice*, 4. Aufl.,
|
||
Addison-Wesley/SEI, 2021 (Qualitätsszenarien, Taktiken, Utility Tree/ATAM).
|
||
- M. Richards, N. Ford: *Fundamentals of Software Architecture -- A Modern Engineering
|
||
Approach*, 2. Aufl., O'Reilly, 2025 (Architecture Characteristics, Trade-off-Gesetze).
|
||
- N. Ford, R. Parsons, P. Kua, P. Sadalage: *Building Evolutionary Architectures*, 2. Aufl.,
|
||
O'Reilly, 2022 (Fitness Functions, Messvertrag).
|
||
- N. Forsgren, J. Humble, G. Kim: *Accelerate -- The Science of Lean Software and DevOps*,
|
||
IT Revolution, 2018 (DORA-Metriken, Kopplungs-Befund).
|
||
|
||
**Begleitend:**
|
||
- I. Sommerville: *Modernes Software-Engineering*, Pearson, 2020 (deutschsprachiger Anker).
|
||
- S. Newman: *Building Microservices*, 2. Aufl., O'Reilly, 2021 (nach Bedarf als Reader).
|
||
- Aktuelle wissenschaftliche Artikel und Branchenforschung zu AI-Agenten, agentischen
|
||
Entwicklungswerkzeugen und Evaluation von AI-Systemen (u. a. DORA-Reports, METR,
|
||
Anthropic Engineering).
|