79 lines
10 KiB
HTML
79 lines
10 KiB
HTML
<!-- ==========================================================================
|
||
AISE502 · Moodle course page · section "Project exercise"
|
||
Section title (Edit section → Section name): 🛠️ Project exercise
|
||
Paste into one 'Text and media area'. Add the three documents as file resources directly below it
|
||
(project_exercise/project_exercise.pdf, Folien/AISE502_Projekt_Folien.pdf, project_exercise/ui_sketches/),
|
||
or replace the [link] placeholders with their URLs.
|
||
Generated by src/build_moodle.py.
|
||
========================================================================== -->
|
||
|
||
<h4>🛠️ Project exercise: AI-Augmented Portfolio Intelligence Platform</h4>
|
||
<p>Over the whole semester, in teams, you design, build and operate a <strong>modular, AI-augmented analysis
|
||
platform for stock portfolios</strong>. The platform ingests market prices (structured) and company news
|
||
(unstructured), turns news into validated insights with an AI component, computes risk, performance and
|
||
optimisation figures in deterministic services, and exposes everything API-first through an orchestrated
|
||
multi-agent advisor – with a thin dashboard for demonstration only. It is a Software Engineering II project:
|
||
its centre of gravity is <strong>architecture</strong> – how you structure a system so that it meets its quality
|
||
attributes and stays maintainable while one part of it (the news understanding) is non-deterministic, fallible
|
||
and costly. Whether the services ship as one modular monolith or as several deployables is your architecture
|
||
decision (week 6), which you defend in week 14.</p>
|
||
<p>AI appears in two roles: as a <strong>tool</strong> you build the system with (Axis A) and as a
|
||
<strong>component</strong> inside the system (Axis B). Everything the lecture teaches – profiles, matching,
|
||
ADRs, measurement – you apply to this system. The project counts <strong>50 %</strong> of the module grade.</p>
|
||
<div style="border-left:4px solid #c0392b; background:#fdf0ee; padding:8px 12px; margin:10px 0;">❗ <strong>The single most important rule.</strong> The AI agents may only <em>obtain and
|
||
interpret</em> quantitative values through the deterministic services – they must <em>never compute</em> a risk
|
||
number, a return or an allocation themselves. An agent that “estimates” a volatility is an architecture defect.
|
||
This separation of deterministic from non-deterministic system parts is the core engineering lesson of the
|
||
course, and it is graded.</div>
|
||
|
||
<h5>📎 Documents</h5>
|
||
<ul>
|
||
<li><strong>Exercise sheet</strong> – <em>project_exercise.pdf</em> (16 pages): the normative description –
|
||
overview and goals, functional requirements, reference architecture, AI integration rules, mandatory vs.
|
||
distinction, semester plan and milestones, assessment, UI sketches. <strong>Read it in full.</strong> [link]</li>
|
||
<li><strong>Project slides</strong> – <em>AISE502_Projekt_Folien.pdf</em>: the kickoff presentation of the
|
||
project. The slides are the map, the sheet is the territory. [link]</li>
|
||
<li><strong>UI sketches</strong> – low-fidelity sketches of the user journey and the six screens (HTML and
|
||
PNG; also Section 8 of the sheet). [link]</li>
|
||
</ul>
|
||
|
||
<h5>Two phases, six milestones</h5>
|
||
<p><strong>Weeks 1–7 – design phase:</strong> the two-lesson exercise slot produces the requirements, studies
|
||
candidate architectures against the patterns taught in the lecture, and decides and documents your
|
||
architecture. <strong>Weeks 8–13 – implementation phase:</strong> the exercise slot becomes a one-lesson
|
||
standup/coaching session; implementation happens mainly in self-study time. <strong>Week 14:</strong>
|
||
presentations, architecture defence and peer reviews. The project work for each week is listed in the weekly
|
||
sections; the exercise sheet remains the normative source.</p>
|
||
<table style="width:100%; border-collapse:collapse; margin:6px 0 12px 0;">
|
||
<tr><th style="text-align:left; border-bottom:2px solid #999; padding:4px 8px; vertical-align:top;">Milestone</th><th style="text-align:left; border-bottom:2px solid #999; padding:4px 8px; vertical-align:top;">Weeks</th><th style="text-align:left; border-bottom:2px solid #999; padding:4px 8px; vertical-align:top;">Content</th><th style="text-align:left; border-bottom:2px solid #999; padding:4px 8px; vertical-align:top;">Deliverable / check</th></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;"><strong>M1</strong> Requirements and Ontology</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">1–3</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Domain model and ontology; at least eight quality attribute scenarios with response measures (three of them for the AI components); utility tree; R(platform) with weights, workload shape and hard constraints; repository and tooling.</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Deliverable A1 (end of week 3): requirements dossier</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;"><strong>M2</strong> Architecture Decision and Solution Design</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">4–7</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Study the reference systems; run the three-stage match; ADR with rationale and C4-style diagram; bounded contexts → services and contracts; measurement contract with numbers (eval pass rate ≥ 95 %, p95 latency ≤ 20 s, token budget, zero boundary violations); walking-skeleton plan.</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Deliverable A2 (end of week 7): architecture dossier + design-review gate</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;"><strong>M3</strong> Walking Skeleton</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">8–9</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Thin end-to-end slice: MarketDataService delivers prices, a minimal ResearchAgent produces one validated Insight; stable API and a placeholder UI.</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Check (week 9): the skeleton runs end-to-end</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;"><strong>M4</strong> Deterministic Core and Resilience</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">10–11</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Performance, Risk and Optimization services fully tested against the reference vectors; resilience patterns on all external calls; graceful degradation verified.</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Check (end of week 11): core fully tested and resilient</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;"><strong>M5</strong> Multi-Agent Orchestration, Evaluation, and Hardening</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">12–13</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Advisor orchestrates 2–3 sub-agents through contracts, every LLM call through the gateway, ontology guard active; evaluation harness as a CI gate; cost and latency observability; topology ADR; threat model incl. prompt injection; optional distinction work.</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Check (end of week 13): eval harness in CI + guard + cost observability</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;"><strong>M6</strong> Presentation and Architecture Defence</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">14</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Present the system, defend the architectural trade-offs, reflect on where AI helped and hurt (Axis A and B), peer reviews; show one measurement-contract violation caught by CI.</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Deliverable A3 (week 14): final presentation with architecture defence</td></tr>
|
||
</table>
|
||
|
||
<h5>Deliverables and assessment</h5>
|
||
<ul>
|
||
<li><strong>A1 – requirements dossier</strong> (end of week 3): scenarios, utility tree, R(platform).</li>
|
||
<li><strong>A2 – architecture dossier</strong> (end of week 7): ADR, C4 views, measurement contract –
|
||
followed by the design-review gate. Production code starts only after the gate (exploratory spikes are allowed).</li>
|
||
<li><strong>A3 – final presentation with architecture defence</strong> (week 14), plus peer reviews.</li>
|
||
</ul>
|
||
<p>Evaluation of the project emphasises: <strong>architecture & trade-offs</strong> (decomposition, contracts,
|
||
deterministic/non-deterministic separation, ADRs), <strong>robustness</strong> (resilience, guards, graceful
|
||
degradation), <strong>quality</strong> (tests for the deterministic services, eval harness for AI),
|
||
<strong>AI integration</strong> (anti-corruption layering, ontology guarding), <strong>operation</strong>
|
||
(observability of cost and latency), and the distinction criteria for top marks (sheet, Section 5).
|
||
The other 50 % of the module grade is the written examination (60 minutes, open book, closed internet).</p>
|
||
|
||
<h5>Hints from the sheet</h5>
|
||
<ul>
|
||
<li>Build the walking skeleton first thing in the implementation phase – a thin end-to-end slice de-risks everything that follows.</li>
|
||
<li>Use the design phase fully: a decided architecture with contracts and a measurement contract makes the implementation weeks sufficient; an undecided one does not.</li>
|
||
<li>Pin the deterministic services with tests before you trust any agent output; keep the deterministic core free of LLM calls – this is the line that is graded.</li>
|
||
<li>Use a snapshot of market and news data so that demo and grading are reproducible even if the live APIs misbehave.</li>
|
||
<li>Commit after each milestone; record architectural decisions as ADRs as you go.</li>
|
||
</ul>
|