AISE502/moodle/week_08.html

<!-- ==========================================================================
     AISE502 · Moodle course page · Week 8
     Section title (Edit section → Section name): Week 8: Requirements Profiles I – Application Classes C1–C5
     Three blocks follow, matching the FHGR section template. Paste each block into the
     corresponding 'Text and media area' (editor → source code view), or all three into one.
     The slide set of lecture 8 is added by the lecturer as a file resource below block 2.
     Generated by src/build_moodle.py from src/content/week_08.json – edit the JSON, not this file.
     ========================================================================== -->

<!-- BLOCK 1 · Learning objectives -->
<h4>🎯 Learning objectives</h4>
<ul>
  <li>I can define an application class as an ASR bundle and write it as R(a) = (w; S(a); K(a)).</li>
  <li>I can derive a class's High weights from documented challenges and binding scenarios, each H a veto trigger.</li>
  <li>I can place C1–C5 on the map of ten classes by workload shape and consistency semantics.</li>
  <li>I know the binding scenarios, High weights, shape S(a) and constraints K(a) of classes C1 to C5.</li>
  <li>I can explain, with LMAX and Monzo, why R(a) defines a feasible set rather than one pattern.</li>
  <li>I can explain why C2 scales reads from a monolith yet moves to EDA+MS at measured organisational scale.</li>
  <li>I can explain why D8 = H and D10 = H jointly veto premium-priced structures in C3.</li>
  <li>I can explain why cross-module ACID binds C4 to one transactional quantum and makes MS the strongest anti-fit.</li>
  <li>I can explain C5's hybrid consistency as a designed boundary that belongs in an ADR.</li>
  <li>I can judge where an AI component may live in a topology by its latency class, not its accuracy.</li>
</ul>

<!-- BLOCK 2 · Theory -->
<h4>🧑‍🏫 Theory</h4>
<p><strong>Lecture 8: Requirements Profiles I – Application Classes C1–C5</strong> · 3 lessons lecture + 1 lesson standup/coaching<br>
Part III turns to the demand side: the requirements profiles of application classes C1–C5, derived from documented challenges and binding scenarios – every closing verdict a preview for Part IV.</p>
<ul>
  <li>An application class is an ASR bundle, not an industry label: R(a) = (w; S(a); K(a)) – weights from the (H,H) leaves, S(a) gates the core, K(a) knocks out before scoring.</li>
  <li>A weight is a compressed empirical claim, made auditable per class: documented challenges → binding scenarios with response measures → High weights; an H is a veto trigger, not a coefficient.</li>
  <li>Regulation translates directly into structure (immutable journals, scope zoning); one organisation runs several classes, so the matrix is read per subsystem; classifying a system is a hypothesis, never a verdict.</li>
  <li>The map of ten classes: workload shape × consistency semantics; C1–C5 all interactive – C1/C4 strict ACID, C3 ACID-leaning, C5 split by subsystem, C2 eventual; C1 and C2 form the mirror pair.</li>
  <li>C1 core banking: D4/D5/D6/D7/D9 High, densest K(a); LMAX vs. Monzo – R(a) defines the feasible set, constraints decide within it; AI at the edge: agents propose, deterministic services decide and book.</li>
  <li>C2 social media: 50:1 and the fan-out; D1/D3/D5/D7/D9/D11 High, D4 Low; Instagram scales reads from a monolith at 100 deployments/day – a monolith is an organisational problem, not a read-scaling problem.</li>
  <li>C3 back-office, the modal case: ca. 60 % of life-cycle cost is evolution (D7 = H); D8 = H and D10 = H jointly veto premium-priced structures; verdict MM, workflow engine behind a port.</li>
  <li>C4 ERP: integration is the product – cross-module ACID postings bind the class to one transactional quantum; MM the strongest alignment in the matrix, MS's −− on D4 the strongest anti-fit.</li>
  <li>C5 e-commerce: quality attributes with price tags, 10–50× peaks, hybrid consistency as a designed boundary, PCI DSS v4.0 scope minimisation as structure; Shopify vs. Amazon – team size, not traffic, decides.</li>
  <li>Side by side: D7 High in all five, D8/D10 High only in C3; verdict previews C1 MM+HX, C2 EDA+MS at measured organisational scale, C3/C4/C5 MM – Part IV recomputes every verdict.</li>
</ul>
<p>📎 <strong>Materials:</strong> Slide set of Lecture 8 <em>(added below by the lecturer)</em> · Script: Part III – Sections 18 (Application Classes as Requirements Profiles), 19 (C1 – Core Banking / Transaction Systems), 20 (C2 – Social Media / Content Platforms), 21 (C3 – Back-Office / Workflow Applications), 22 (C4 – ERP / Enterprise Core Systems) and 23 (C5 – E-Commerce Platforms).</p>

<!-- BLOCK 3 · Self-study and assignments -->
<h4>🧑‍💻 Self-study and assignments</h4>
<p><strong>📖 Reading before the lecture:</strong> Part III – Sections 18 (Application Classes as Requirements Profiles), 19 (C1 – Core Banking / Transaction Systems), 20 (C2 – Social Media / Content Platforms), 21 (C3 – Back-Office / Workflow Applications), 22 (C4 – ERP / Enterprise Core Systems) and 23 (C5 – E-Commerce Platforms).</p>
<p><strong>Also before the lecture:</strong></p>
<ul>
  <li>Sprint 1 / M3 starts this week: bring the walking-skeleton plan from your A2 dossier (MarketDataService + minimal ResearchAgent + stable API).</li>
  <li>Make sure Deliverable A2 and the design-review gate are complete – production code starts only after the gate (exploratory spikes are allowed).</li>
  <li>Have the 7 × 10 matching matrix from Lecture 7 at hand: this week derives its rows C1–C5 from the demand side.</li>
</ul>
<p><strong>🧩 Exercise session:</strong> The exercise slot becomes a one-lesson standup/coaching session as the implementation phase begins with Sprint 1 of the walking skeleton (M3); implementation happens mainly in self-study time.</p>
<p><strong>🛠️ Project work this week</strong> · Milestone M3 – Walking Skeleton (weeks 8–9)</p>
<ul>
  <li>Start the walking skeleton (Sprint 1, M3) first thing in the implementation phase: MarketDataService delivers prices, a minimal ResearchAgent produces one validated Insight, plus a stable API and a placeholder UI that calls it.</li>
  <li>Keep the deterministic core free of LLM calls – agents propose, deterministic services decide and book; this is the line that is graded. Your deterministic services inherit the C3 verdict: ACID, boring on purpose.</li>
  <li>Use a snapshot of market/news data so that demo and grading are reproducible.</li>
  <li>Commit after each milestone and record architectural decisions as ADRs as you go.</li>
  <li>Work towards the week-9 check: the walking skeleton runs end-to-end (M3).</li>
</ul>
<p><em>No deliverable is due this week.</em></p>