857 lines
42 KiB
TeX
857 lines
42 KiB
TeX
% !TEX encoding = UTF-8 Unicode
|
|
% ============================================================================
|
|
% AISE502 -- AI in Software Engineering II
|
|
% Lecture 2 slides, typeset with the official FHGR beamer theme
|
|
% (beamerthemeFHGR.sty, University of Applied Sciences of the Grisons).
|
|
% Slide content is unchanged; only the presentation layer is the FHGR template.
|
|
% ============================================================================
|
|
\documentclass[aspectratio=169]{beamer}
|
|
|
|
\usetheme[showsection, titlebg=pics/theme_pics/titlepage.png]{FHGR}
|
|
|
|
% ============================================
|
|
% PACKAGES
|
|
% The theme already loads tikz, graphicx, xcolor, tabularx, colortbl,
|
|
% listings, hyperref, environ and xparse -- only the extras are needed here.
|
|
% ============================================
|
|
\usepackage[british]{babel}
|
|
\usepackage{booktabs}
|
|
\usepackage{amsmath}
|
|
\usepackage{amssymb}
|
|
\usepackage{tcolorbox}
|
|
\usetikzlibrary{shapes.geometric, arrows.meta, positioning, fit, backgrounds, calc}
|
|
|
|
% ============================================
|
|
% SEMANTIC COLOURS, MAPPED ONTO THE FHGR PALETTE
|
|
% The names used throughout the slides are kept, so no slide text changes;
|
|
% they now resolve to the FHGR brand colours defined by the theme.
|
|
% ============================================
|
|
\colorlet{bankblue}{blue} % FHGR blue (4B92A4)
|
|
\colorlet{bankgreen}{green} % FHGR green (817E65)
|
|
\colorlet{bankred}{red} % FHGR red (C60219)
|
|
\colorlet{codegray}{gray} % FHGR gray (595959)
|
|
\colorlet{backcolour}{linen} % FHGR linen (E1D3B5)
|
|
\definecolor{aiviolet}{HTML}{6B4E71} % muted plum, kept distinct for the AI lens
|
|
|
|
% Attribution labels in English (theme default is German)
|
|
\renewcommand{\source}[1]{\par\hfill {\tiny\color{FHGRDeco} Source:\,\itshape #1}}
|
|
\renewcommand{\imagesource}[1]{\par\hfill {\tiny\color{FHGRDeco} Image source:\,\itshape #1}}
|
|
|
|
% ============================================
|
|
% CUSTOM TCOLORBOXES (same semantics as the script, FHGR colours)
|
|
% ============================================
|
|
\newtcolorbox{keypoint}{
|
|
colback=bankblue!7!white,
|
|
colframe=bankblue,
|
|
title=Key Concept,
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{examplebox}[1][]{
|
|
colback=bankgreen!10!white,
|
|
colframe=bankgreen,
|
|
title={Example: #1},
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{definitionbox}[1][]{
|
|
colback=linen!40!white,
|
|
colframe=camel!85!black,
|
|
title={Definition: #1},
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{thinkbox}{
|
|
colback=lightGray!35!white,
|
|
colframe=darkGray,
|
|
title=Discussion,
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{hinweisbox}{
|
|
colback=bankred!5!white,
|
|
colframe=bankred,
|
|
title=Important Note,
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{ailinse}[1][]{
|
|
colback=aiviolet!7!white,
|
|
colframe=aiviolet,
|
|
title={AI Lens: #1},
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{projektbox}{
|
|
colback=bankblue!4!white,
|
|
colframe=bankblue!70!black,
|
|
title=Project Link: Portfolio Intelligence Platform,
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
% Measurement line used on every dimension slide
|
|
\newcommand{\measured}[2]{%
|
|
\vspace{0.12cm}
|
|
\begin{tcolorbox}[colback=gray!8!white, colframe=gray!70!black, boxrule=0.6pt, arc=2pt, top=1pt, bottom=1pt, left=4pt, right=4pt]
|
|
\footnotesize \textbf{Measured:} #1\\ \textbf{Instrument:} #2
|
|
\end{tcolorbox}}
|
|
|
|
% ============================================
|
|
% TITLE METADATA
|
|
% ============================================
|
|
\title[AI in Software Engineering II]{AISE502: AI in Software Engineering II}
|
|
\subtitle{Lecture 2: The Twelve Dimensions -- and How Requirements Become Measurable\\[0.4ex]{\small Script: Part I, Sections 2--3}}
|
|
\author{Dr.\ Florian Herzog}
|
|
\shortname{AISE502}
|
|
\fullname{Fachhochschule Graub\"unden, Chur -- Autumn Semester 2026}
|
|
|
|
\begin{document}
|
|
|
|
% ============================================
|
|
% TITLE SLIDE
|
|
% ============================================
|
|
\FHGRTitlePage
|
|
|
|
% ============================================
|
|
% AGENDA
|
|
% ============================================
|
|
\begin{frame}{Agenda}
|
|
\small
|
|
\begin{enumerate}\setlength\itemsep{1pt}
|
|
\item Recap: the framework and the nine questions
|
|
\item Load and speed: D1--D3
|
|
\item Correctness and trust: D4--D6
|
|
\item Change and delivery: D7--D9
|
|
\item Economics and organisation: D10--D11
|
|
\item The new dimension: D12 (AI integrability)
|
|
\item Why exactly these twelve -- ISO/IEC 25010:2023
|
|
\item From wishes to scenarios: ASR, QAW, the six-part form
|
|
\item The utility tree: from scenarios to weights
|
|
\item Workload shape, hard constraints -- $R(a)$ assembled
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% RECAP
|
|
% ============================================
|
|
\section{Recap}
|
|
|
|
\begin{frame}{Recap: where we are}
|
|
\footnotesize
|
|
\textbf{Last week:}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item Maxim 1: patterns are neither good nor bad -- only the \textbf{fit} is
|
|
\item the framework: $R(a) \to C(p) \to \mathrm{fit}(a,p) \to$ ADR $\to$ measurement contract
|
|
\item six assumptions A1--A6; the chain \emph{demand $\to$ supply $\to$ match $\to$ record $\to$ test}
|
|
\item nine recurring on-call questions $\to$ five groups of dimensions
|
|
\end{itemize}
|
|
|
|
\vspace{0.2cm}
|
|
\textbf{Today} we build the coordinate system and the demand side:
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item the twelve dimensions \textbf{D1--D12}, one by one -- each with vocabulary and \textbf{instrument}
|
|
\item then the method that turns stakeholder wishes into \textbf{weights}: scenarios, QAW, utility tree
|
|
\end{itemize}
|
|
|
|
\vspace{0.2cm}
|
|
\begin{keypoint}
|
|
Rule of the day (A4, applied to the theory itself): \textbf{no instrument, no dimension.}
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% D1-D3 LOAD AND SPEED
|
|
% ============================================
|
|
\section{Load and Speed: D1--D3}
|
|
|
|
\begin{frame}{D1 -- Read scalability \hfill \normalsize\textcolor{gray}{group: load and speed}}
|
|
\emph{\textcolor{bankblue}{What happens at 08:00 on grade-release day, when the whole semester refreshes at once?}}
|
|
|
|
\vspace{0.2cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item the ability to serve a growing volume of \textbf{read} requests -- requests that look at data without changing it
|
|
\item most interactive systems are \textbf{read-dominated by orders of magnitude}: thousands check a result for every one who appeals it
|
|
\item reads are friendly: they can be served from \textbf{copies} -- replicas and \emph{caches} (fast stores holding ready-made answers)
|
|
\item Stack Overflow: $\sim 1.3$ billion page views/month from a handful of servers; Instagram: a monolith -- \textbf{the single write path is the hard part}
|
|
\end{itemize}
|
|
|
|
\measured{throughput at $k\times$ replication (does doubling servers double throughput?); cache hit ratio; p95 read latency}{step-profile load tests; production RED metrics (Rate, Errors, Duration)}
|
|
\end{frame}
|
|
|
|
\begin{frame}{D2 -- Write scalability and elasticity}
|
|
\emph{\textcolor{bankblue}{Black Friday: checkout traffic jumps to dozens of times the baseline for one weekend -- and is gone on Monday.}}
|
|
|
|
\vspace{0.2cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item the D1 question for requests that \textbf{change} state -- the harder half: a write cannot be served from a copy; every order must reach the \emph{one authoritative record}, durably and in order
|
|
\item \textbf{elasticity} adds the time axis: how quickly capacity follows load -- up \emph{and back down}
|
|
\item reference point: Shopify's BFCM weekend, peaks $\sim 280$ million requests/minute, carried by replicated ``pods'' of a monolith
|
|
\item the opposite end: \textbf{scale-to-zero} -- costing nothing while unused (the serverless promise)
|
|
\end{itemize}
|
|
|
|
\measured{sustained ingest rate (durably absorbed writes/s); time-to-capacity after a load step; cost of idling at zero}{load tests with load steps; elasticity-lag measurement}
|
|
\end{frame}
|
|
|
|
\begin{frame}{D3 -- Latency and predictability}
|
|
\emph{\textcolor{bankblue}{How long does one click take -- and how long does it take on a bad day?}}
|
|
|
|
\vspace{0.1cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \textbf{latency}: time between request and response; \textbf{predictability}: the distribution matters, not the average
|
|
\item \textbf{averages lie}: a system can average $120$\,ms while every twentieth request takes four seconds -- and the most active users hit those most often
|
|
\item vocabulary: \textbf{p50/p95/p99} percentiles; \textbf{tail-latency ratio} p99/p50; \textbf{cold start} $=$ extra delay when the serving component must first wake up
|
|
\item stakes: Amazon $\sim 1\,\%$ of sales lost per additional $100$\,ms; Akamai: up to $7\,\%$ of conversions
|
|
\end{itemize}
|
|
|
|
\measured{p50/p95/p99 response times; cold-start frequency; tail-latency ratio}{distributed tracing (OpenTelemetry) -- following one request across every component; latency budgets as CI gates}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% D4-D6 CORRECTNESS AND TRUST
|
|
% ============================================
|
|
\section{Correctness and Trust: D4--D6}
|
|
|
|
\begin{frame}{D4 -- Consistency and transactional integrity}
|
|
\emph{\textcolor{bankblue}{An e-banking transfer: can the same payment ever be booked twice -- or vanish halfway?}}
|
|
|
|
\vspace{0.1cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item can concurrency and partial failure \textbf{corrupt the data} -- can the numbers silently stop being true?
|
|
\item classic failure, the \textbf{lost update}: two processes read the same balance, both write -- the second silently overwrites the first
|
|
\item vocabulary: \textbf{invariant} (must always hold: debit $=$ credit); \textbf{transactional integrity} (all or nothing); \textbf{staleness} (seconds a copy may lag)
|
|
\item a single database hands you transactions \emph{for free}; every distribution boundary takes part of that away
|
|
\end{itemize}
|
|
|
|
\measured{anomaly rate under concurrent load; invariant-violation count (\textbf{target 0} for ledgers); staleness bound}{Jepsen-style tests (concurrent ops $+$ injected failures); reconciliation jobs}
|
|
\end{frame}
|
|
|
|
\begin{frame}{D5 -- Availability and fault isolation}
|
|
\emph{\textcolor{bankblue}{One component crashes at noon: does the whole app go dark, or does one widget show a spinner?}}
|
|
|
|
\vspace{0.2cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item availability: share of time the system does its job; fault isolation: \textbf{how much of the product dies when one part dies}
|
|
\item \textbf{blast radius}: \% of functionality lost per component failure -- in a single process it is $100\,\%$ \emph{by construction}; \textbf{MTTR}: mean time to recovery
|
|
\item operations vocabulary: \textbf{SLO} (``$99.9\,\%$ of requests succeed this month''), \textbf{error budget} (the tolerated $0.1\,\%$), \textbf{burn rate}
|
|
\item run continuously in the pipeline, such an automated check of an architectural property is a \textbf{fitness function} -- a term we will use constantly
|
|
\end{itemize}
|
|
|
|
\measured{SLO attainment; error-budget burn; blast radius; MTTR}{chaos experiments -- deliberately kill components under load and measure what users lose}
|
|
\end{frame}
|
|
|
|
\begin{frame}{D6 -- Security and auditability}
|
|
\emph{\textcolor{bankblue}{The regulator asks: prove what happened to this one transaction, end to end.}}
|
|
|
|
\vspace{0.1cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item keeping attackers out is necessary \emph{everywhere}; what discriminates between \textbf{structures} is \textbf{auditability} -- the ability to reconstruct history
|
|
\item \textbf{audit trail}: complete, tamper-evident record of who changed what, when, on whose authority -- a \emph{legal duty} in supervised industries (FINMA, PCI DSS)
|
|
\item \textbf{audit scope}: the portion of the system auditors must examine -- confining sensitive flows to a small region shrinks the scope, and the bill
|
|
\item some structures record every change as an event \emph{as their normal mode}; others reassemble history from scattered log files
|
|
\end{itemize}
|
|
|
|
\measured{time to reconstruct a complete audit trail for one transaction; \% of state changes journaled (append-only)}{audit drills -- run like fire drills; immutable logs; PCI/FINMA scope reviews}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% D7-D9 CHANGE AND DELIVERY
|
|
% ============================================
|
|
\section{Change and Delivery: D7--D9}
|
|
|
|
\begin{frame}{D7 -- Evolvability and maintainability}
|
|
\emph{\textcolor{bankblue}{A feature request arrives: how many places in the code must change?}}
|
|
|
|
\vspace{0.1cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item prices the \textbf{next} change -- which, over a lifetime dominated by evolution (A5), dominates most others
|
|
\item central measure, worth memorising: \textbf{change dispersion} $=$ modules touched by an average feature -- \emph{one is excellent, seventeen is an architecture problem}
|
|
\item underlying variable: \textbf{coupling} -- metrics: CBO (coupling between objects), Martin's \emph{instability}
|
|
\item \textbf{declared-boundary violations} (code bypassing declared module boundaries): target 0, enforceable in CI with ArchUnit / Spring Modulith
|
|
\end{itemize}
|
|
|
|
\measured{change dispersion over the version history; coupling metrics (CBO, instability); boundary violations (target 0)}{ArchUnit / Spring Modulith verification as CI gates; CK metric suite}
|
|
\end{frame}
|
|
|
|
\begin{frame}{D8 -- Simplicity and time-to-market}
|
|
\emph{\textcolor{bankblue}{Two students must ship a working MVP in one semester. Does the structure let them?}}
|
|
|
|
\vspace{0.2cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item how much machinery must \emph{exist, be understood, and be kept alive} before the first unit of value reaches a user
|
|
\item a structure that requires a container orchestrator, a message broker, and a dozen repositories before ``hello, world'' has \textbf{failed this dimension for that team} -- however well it would carry Shopify's Black Friday
|
|
\item this is where A2 bites hardest: the structures that win D8 tend to concede D2 or D11 -- a small team's rational choice \emph{differs} from a platform company's
|
|
\end{itemize}
|
|
|
|
\measured{time from empty repository to first production release; onboarding time to first merged contribution; count of distinct runtime technologies}{delivery calendar; team surveys; tech-radar count}
|
|
\end{frame}
|
|
|
|
\begin{frame}{D9 -- Testability and deployability}
|
|
\emph{\textcolor{bankblue}{Can a developer know within seconds that a change is safe -- and release it this afternoon without coordinating with three teams?}}
|
|
|
|
\vspace{0.1cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item two abilities, \textbf{deliberately fused}: fast, trustworthy verification \emph{and} independent, low-risk release
|
|
\item vocabulary: \textbf{hermetic test} (fully self-contained -- no shared staging, no live external service); \textbf{deployment frequency}; \textbf{change failure rate} (share of releases that break something)
|
|
\item why fused: DORA 2017 found precisely this pair -- test without an integrated environment, deploy independently -- predicted delivery performance \emph{more strongly than automation itself}; both are surface expressions of \textbf{coupling}
|
|
\end{itemize}
|
|
|
|
\measured{test feedback time; \% hermetic tests; deployment frequency; change failure rate}{pipeline telemetry; DORA capability items}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% D10-D11 ECONOMICS AND ORGANISATION
|
|
% ============================================
|
|
\section{Economics and Organisation: D10--D11}
|
|
|
|
\begin{frame}{D10 -- Operating cost efficiency}
|
|
\emph{\textcolor{bankblue}{The cloud bill tripled. Which part of the structure spends the money -- and what was it doing at 03:00?}}
|
|
|
|
\vspace{0.2cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item prices the running system -- \textbf{machines and people}
|
|
\item vocabulary: \textbf{cost per request}; \textbf{idle cost} (capacity doing nothing -- the 03:00 question); \textbf{TCO}; \textbf{FTE}
|
|
\item the hidden term matters most: a self-managed container platform is dominated not by compute prices but by \textbf{platform-team FTEs} -- the ``microservice premium'' materialises as staffing
|
|
\item Prime Video's $> 90\,\%$ cost cut: the same dimension, seen from the infrastructure side
|
|
\end{itemize}
|
|
|
|
\measured{TCO split build/platform/run; cost per request; idle cost; platform-team FTEs}{FinOps reporting -- making cloud spend visible and attributable per team and feature}
|
|
\end{frame}
|
|
|
|
\begin{frame}{D11 -- Team scaling (Conway fit)}
|
|
\emph{\textcolor{bankblue}{The team grows from three to thirty. Do releases speed up -- or does everyone wait on everyone?}}
|
|
|
|
\vspace{0.2cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \textbf{Conway's law}, in one sentence: a system's structure ends up mirroring the communication structure of the organisation that builds it
|
|
\item consequence: \emph{every architecture decision is a team-structure decision} -- whether the architect intends it or not
|
|
\item operational core: how many teams can design, build, and \textbf{release without waiting for each other}?
|
|
\item DORA: \emph{deployments per developer per day} \textbf{rises} with team count in loosely coupled organisations -- and \textbf{falls} in tightly coupled ones
|
|
\end{itemize}
|
|
|
|
\measured{deployments per developer per day as the team count grows; number of teams releasing without cross-team coordination}{DORA scaling analysis; Team Topologies review}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% D12 THE NEW DIMENSION
|
|
% ============================================
|
|
\section{The New Dimension: D12}
|
|
|
|
\begin{frame}{D12 -- AI integrability}
|
|
\emph{\textcolor{bankblue}{The new feature's core is an LLM call: eight seconds, paid per request, sometimes confidently wrong. How hard does the structure fight it?}}
|
|
|
|
\vspace{0.1cm}
|
|
\footnotesize
|
|
How cheaply can the structure host a component that is \textbf{slow, fallible, priced per call}? It needs three things:
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item a \textbf{queue}: a waiting line, so an eight-second call -- or a provider outage -- does not block everything behind it
|
|
\item a \textbf{port}: a narrow, contract-shaped interface isolating the non-determinism, so deterministic tests can substitute a \emph{fake}
|
|
\item a \textbf{measurement point}: cost and quality of \emph{every single call} observable -- providers price per \textbf{token}, so cost accrues \emph{per request}
|
|
\end{itemize}
|
|
|
|
\measured{seconds-scale latency tolerance; isolability of non-determinism behind contracts; token-cost observability per request}{\textbf{eval harness}: versioned test inputs with expected qualities; pass rate $\geq$ threshold as a CI gate -- the AI counterpart of a regression suite}
|
|
\end{frame}
|
|
|
|
\begin{frame}{One system, one profile}
|
|
\begin{examplebox}[a retail e-banking application, walked through the five groups]
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \textbf{Load and speed:} payday-morning peaks; reads $\gg$ writes; two seconds tolerated, not ten $\to$ D1, D3 matter; D2 modest
|
|
\item \textbf{Correctness and trust:} a double-booked transfer is existential; the audit trail is a legal duty $\to$ D4, D6 \emph{as high as they go}; D5 high
|
|
\item \textbf{Change and delivery:} monthly, formally reviewed releases -- but decades of regulatory change $\to$ D7 high, D9 moderate
|
|
\item \textbf{Economics and organisation:} platform organisation exists anyway; dozens of teams $\to$ D10 medium, D11 high
|
|
\item \textbf{AI:} a chat assistant is attractive -- but a confidently wrong answer about a balance is a \emph{safety} problem $\to$ D12 medium, hard guardrails
|
|
\end{itemize}
|
|
\end{examplebox}
|
|
|
|
\vspace{0.05cm}
|
|
\footnotesize The judgements are debatable; the point is not: \textbf{a real system has a \emph{profile}} -- demanding on a few dimensions, relaxed on others. Writing it down rigorously is the second half of today.
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% WHY EXACTLY THESE TWELVE
|
|
% ============================================
|
|
\section{Why Exactly These Twelve}
|
|
|
|
\begin{frame}{Quality attributes, not functions}
|
|
\footnotesize
|
|
\begin{columns}[T]
|
|
\begin{column}{0.48\textwidth}
|
|
\textcolor{bankblue}{\textbf{Functional requirement}}
|
|
\begin{itemize}
|
|
\item \emph{what} the system shall do
|
|
\item compute interest, post a booking, render a feed
|
|
\item largely \textbf{structure-neutral} (A3)
|
|
\end{itemize}
|
|
\end{column}
|
|
\begin{column}{0.48\textwidth}
|
|
\textcolor{bankblue}{\textbf{Quality attribute requirement}}
|
|
\begin{itemize}
|
|
\item \emph{how well}, under which conditions, at what cost
|
|
\item the misleading classic term: ``non-functional''
|
|
\item this is what \textbf{structure determines}
|
|
\end{itemize}
|
|
\end{column}
|
|
\end{columns}
|
|
|
|
\vspace{0.3cm}
|
|
\begin{examplebox}[the same function, three structures]
|
|
``Post a booking'' can run inside a layered monolith, as a \emph{saga} across microservices, or as an event-sourced log. The \textbf{function is identical} -- the consistency guarantee, the latency distribution, the audit trail, and the cost of the next change are \textbf{radically different}.
|
|
\end{examplebox}
|
|
|
|
\vspace{0.15cm}
|
|
All twelve dimensions are quality attributes or workload/constraint characteristics -- \textbf{never features}.
|
|
\end{frame}
|
|
|
|
\begin{frame}{The names: ISO/IEC 25010:2023}
|
|
\footnotesize
|
|
The naming standard for quality attributes -- nine characteristics, each with sub-characteristics:
|
|
|
|
\vspace{0.15cm}
|
|
\begin{center}
|
|
\footnotesize
|
|
functional suitability $\cdot$ performance efficiency $\cdot$ compatibility $\cdot$ interaction capability $\cdot$ reliability $\cdot$ \textbf{security} $\cdot$ maintainability $\cdot$ \textbf{flexibility} $\cdot$ \textbf{safety}
|
|
\end{center}
|
|
|
|
\vspace{0.15cm}
|
|
Three 2023 changes matter directly for this module:
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \textbf{Safety} became a new top-level characteristic (fail safe, hazard warning) -- exactly what a confidently-wrong AI component requires
|
|
\item \emph{portability} became \textbf{Flexibility}, with an explicit new \emph{scalability} sub-characteristic
|
|
\item \textbf{Security} gained \emph{resistance} -- sustaining operation under attack: the normative hook for prompt-injection robustness
|
|
\end{itemize}
|
|
|
|
\vspace{0.15cm}
|
|
\begin{keypoint}
|
|
The 2023 vocabulary covers AI-bearing systems \textbf{without private extensions} -- A6 starts with the quality model itself.
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Three admission conditions}
|
|
\small
|
|
A candidate became one of the twelve only if it passed all three:
|
|
|
|
\vspace{0.15cm}
|
|
\begin{enumerate}\setlength\itemsep{2pt}
|
|
\item \textbf{Standard anchoring} -- maps to ISO/IEC 25010:2023 vocabulary (reaching beyond it -- cost, organisation -- is stated explicitly)
|
|
\item \textbf{Discrimination} -- must distinguish at least two of the seven patterns; a dimension on which all patterns score alike carries no matching information
|
|
\item \textbf{Instrumentation} -- must have a defined \textbf{response measure and measurement instrument}: every rating is a testable prediction, not an adjective
|
|
\end{enumerate}
|
|
|
|
\vspace{0.15cm}
|
|
\begin{hinweisbox}
|
|
\footnotesize \textbf{No instrument, no dimension} -- this excludes ``elegance'' and ``future-proofness''. And ISO 25010 is a \emph{taxonomy}, not a \emph{metric}: do not argue about the box a concern belongs to -- write it as a \textbf{scenario with a response measure} and the question dissolves.
|
|
\end{hinweisbox}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The reference card (1/2): D1--D6}
|
|
\begin{center}
|
|
\scriptsize
|
|
\begin{tabular}{@{}p{0.6cm}p{2.9cm}p{4.6cm}p{4.4cm}@{}}
|
|
\toprule
|
|
\textbf{\#} & \textbf{Dimension} & \textbf{Response measure (examples)} & \textbf{Instrument} \\
|
|
\midrule
|
|
D1 & Read scalability & throughput at $k\times$ replication; cache hit ratio & load tests; RED metrics \\
|
|
D2 & Write scalability \& elasticity & sustained ingest rate; time-to-capacity; scale-to-zero cost & load steps; elasticity lag \\
|
|
D3 & Latency \& predictability & p50/p95/p99; cold starts; tail ratio p99/p50 & distributed tracing; latency budgets in CI \\
|
|
D4 & Consistency \& integrity & anomaly rate; invariant violations ($0$ for ledgers); staleness bound & Jepsen-style tests; reconciliation jobs \\
|
|
D5 & Availability \& fault isolation & SLO attainment; error-budget burn; blast radius; MTTR & SLOs; chaos experiments \\
|
|
D6 & Security \& auditability & time to reconstruct an audit trail; \% changes journaled & audit drills; immutable logs; scope reviews \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.1cm}
|
|
\footnotesize\textcolor{codegray}{Full version with ISO anchors: the script's canonical reference card (Table 3).}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The reference card (2/2): D7--D12}
|
|
\begin{center}
|
|
\scriptsize
|
|
\begin{tabular}{@{}p{0.6cm}p{2.9cm}p{4.6cm}p{4.4cm}@{}}
|
|
\toprule
|
|
\textbf{\#} & \textbf{Dimension} & \textbf{Response measure (examples)} & \textbf{Instrument} \\
|
|
\midrule
|
|
D7 & Evolvability \& maintainability & change dispersion; coupling (CBO, instability); boundary violations ($0$) & ArchUnit / Spring Modulith in CI \\
|
|
D8 & Simplicity \& time-to-market & empty repo $\to$ first release; onboarding time; technology count & delivery calendar; surveys \\
|
|
D9 & Testability \& deployability & test feedback time; \% hermetic tests; deployment frequency; change failure rate & pipeline telemetry; DORA items \\
|
|
D10 & Operating cost efficiency & TCO build/platform/run; cost per request; idle cost; platform FTEs & FinOps reporting \\
|
|
D11 & Team scaling (Conway) & deployments per developer per day; teams releasing without coordination & DORA scaling; Team Topologies \\
|
|
D12 & AI integrability & seconds-scale latency tolerance; isolable non-determinism; token-cost observability & eval-harness pass rate in CI; cost budgets \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% DEMAND SIDE: ASR, QAW, SCENARIOS
|
|
% ============================================
|
|
\section{From Wishes to Scenarios}
|
|
|
|
\begin{frame}{The demand side: what we are building}
|
|
\begin{center}
|
|
\Large
|
|
$R(a) \;=\; \bigl(\underbrace{w_1, \dots, w_{12}}_{\text{priority weights}};\;\; \underbrace{S(a)}_{\text{workload shape}};\;\; \underbrace{K(a)}_{\text{hard constraints}}\bigr)$
|
|
\end{center}
|
|
|
|
\vspace{0.4cm}
|
|
None of these is written down by intuition -- each is \textbf{produced} by a defined method:
|
|
|
|
\vspace{0.2cm}
|
|
\begin{center}
|
|
\small
|
|
\begin{tabular}{@{}lll@{}}
|
|
\toprule
|
|
\textbf{Step} & \textbf{Method} & \textbf{Produces} \\
|
|
\midrule
|
|
1 & elicitation (QAW) & a prioritised pool of candidate \textbf{ASRs} \\
|
|
2 & six-part scenarios & the candidates in \textbf{falsifiable form} \\
|
|
3 & utility tree & the twelve \textbf{weights} $w_1, \dots, w_{12}$ \\
|
|
4 & inventory & workload shape $S(a)$, constraints $K(a)$ \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Architecturally significant requirements (ASR)}
|
|
\begin{definitionbox}[Architecturally significant requirement]
|
|
A requirement with a \textbf{profound effect on the architecture} -- one whose late accommodation would be disproportionately expensive -- and typically \textbf{difficult to achieve}.
|
|
\end{definitionbox}
|
|
|
|
\vspace{0.3cm}
|
|
\small
|
|
Empirical finding (Chen et al.\ 2013; 90 practitioners, $> 500$ organisations):
|
|
\begin{itemize}
|
|
\item ASRs are typically \textbf{poorly specified, vague, and implicit}
|
|
\item they hide inside business goals: \emph{``we plan to enter three new markets next year''} $\;\to\;$ a scalability ASR \emph{and} a compliance ASR
|
|
\item they cannot be read off a requirements document -- they must be \textbf{elicited}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Eliciting ASRs: the Quality Attribute Workshop (QAW)}
|
|
\small
|
|
The SEI's established format -- its essence is two design choices:
|
|
|
|
\vspace{0.2cm}
|
|
\begin{columns}[T]
|
|
\begin{column}{0.44\textwidth}
|
|
\textcolor{bankblue}{\textbf{1. Who is in the room}}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \emph{not} the development team alone
|
|
\item the stakeholders whose concerns the architecture must balance:
|
|
\item users, operators, auditors, regulators, product owners
|
|
\end{itemize}
|
|
\end{column}
|
|
\begin{column}{0.52\textwidth}
|
|
\textcolor{bankblue}{\textbf{2. The sequence}}
|
|
\begin{enumerate}\setlength\itemsep{1pt}
|
|
\item business and mission drivers first
|
|
\item identify architectural drivers
|
|
\item scenario \textbf{brainstorming}
|
|
\item consolidation
|
|
\item \textbf{prioritisation by stakeholder vote}
|
|
\item refinement of the top candidates into the measurable six-part form
|
|
\end{enumerate}
|
|
\end{column}
|
|
\end{columns}
|
|
|
|
\vspace{0.3cm}
|
|
\emph{Produced:} the raw material of $R(a)$ -- prioritised candidate ASRs, \textbf{not yet measurable}.
|
|
\end{frame}
|
|
|
|
\begin{frame}{The measurable form: the six-part scenario}
|
|
\begin{definitionbox}[Quality attribute scenario]
|
|
\footnotesize
|
|
\begin{enumerate}\setlength\itemsep{0pt}
|
|
\item \textbf{Source of stimulus} -- who or what triggers it: a user, another system, an attacker
|
|
\item \textbf{Stimulus} -- the arriving event: a request, a failure, a load spike
|
|
\item \textbf{Environment} -- the operating condition: normal, overload, degraded
|
|
\item \textbf{Artifact} -- the part of the system stimulated
|
|
\item \textbf{Response} -- the desired observable reaction
|
|
\item \textbf{Response measure} -- the quantity, \textbf{with number and unit}, by which success is judged
|
|
\end{enumerate}
|
|
\end{definitionbox}
|
|
|
|
\vspace{0.05cm}
|
|
\begin{hinweisbox}
|
|
\small The \textbf{response measure} is the non-negotiable part: ``the system shall be scalable'' names an \emph{aspiration}; a scenario with a response measure names a \emph{test}.
|
|
\end{hinweisbox}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Worked scenario 1: availability in a payment service}
|
|
\begin{examplebox}[banking]
|
|
\footnotesize
|
|
\emph{Source:} a heartbeat monitor. \emph{Stimulus:} reports the failure of one application server. \emph{Environment:} normal operation, mid-day load. \emph{Artifact:} the payment service. \emph{Response:} requests are redirected to replicas; operations staff notified; in-flight transactions complete or roll back atomically. \emph{\textbf{Response measure:}} failover $< 30$\,s; \textbf{zero} transactions lost or double-posted.
|
|
\end{examplebox}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize
|
|
``The payment service shall be highly available'' hides \textbf{three architectural decisions} the scenario exposes:
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item replicas (redundancy tactic) \quad $\cdot$ \quad failure detection (heartbeat tactic)
|
|
\item transactional atomicity \emph{across} the failover -- a guarantee some patterns provide structurally, others do not
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
The response measure is \textbf{directly executable} as a chaos experiment: kill an instance under load, measure.\\
|
|
\textbf{One artefact, three roles:} requirement, design driver, test specification.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Worked scenario 2: safety in an AI advisory platform}
|
|
\begin{examplebox}[Axis B]
|
|
\footnotesize
|
|
\emph{Source:} a customer. \emph{Stimulus:} submits a request for which the LLM generates a \textbf{factually wrong} recommendation. \emph{Environment:} normal operation. \emph{Artifact:} the advisory platform. \emph{Response:} the deterministic validation layer detects and blocks the answer and escalates to a human advisor. \emph{\textbf{Response measure:}} detection rate $\geq 99\,\%$ on the \emph{versioned evaluation set}, $< 2$\,s added latency.
|
|
\end{examplebox}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize Two things are notable:
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item the six-part form needed \textbf{no extension} for a non-deterministic component -- \textbf{A6 at work}: the stimulus is probabilistic (the model \emph{will} sometimes hallucinate), and the requirement is placed \textbf{on the system around the model}, not on the model
|
|
\item the response measure \emph{presupposes an artefact}: a versioned evaluation set -- the \textbf{eval harness} (D12)
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
\textcolor{codegray}{In ISO/IEC 25010:2023 terms: a \emph{Safety} scenario (fail safe, hazard warning).}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% UTILITY TREE
|
|
% ============================================
|
|
\section{The Utility Tree}
|
|
|
|
\begin{frame}{The utility tree: prioritising scenarios}
|
|
\small A workshop produces more scenarios than any analysis can carry. The \textbf{utility tree} (ATAM) prioritises them top-down; every leaf is rated H/M/L on \textbf{business importance} (what does failure cost us?) and \textbf{achievement difficulty} (how hard, architecturally?).
|
|
|
|
\vspace{0.15cm}
|
|
\begin{center}
|
|
\resizebox{0.72\textwidth}{!}{%
|
|
\begin{tikzpicture}[
|
|
sysbox/.style={rectangle, draw, rounded corners=4pt, align=center, font=\scriptsize\sffamily, line width=0.8pt, inner sep=4pt},
|
|
root/.style={sysbox, fill=bankblue!20, draw=bankblue, font=\small\sffamily\bfseries, minimum height=1.1cm, minimum width=1.9cm},
|
|
attr/.style={sysbox, fill=bankgreen!15, draw=bankgreen, minimum width=2.6cm, minimum height=0.85cm},
|
|
leafhh/.style={sysbox, fill=bankred!15, draw=bankred, text width=6.6cm},
|
|
leaf/.style={sysbox, fill=gray!12, draw=gray!60!black, text width=6.6cm},
|
|
arr/.style={-{Stealth[length=2.2mm]}, thick, gray!60!black}
|
|
]
|
|
\node[root] (util) at (0,0) {Utility};
|
|
\node[attr] (cons) at (3.6,2.7) {Consistency \&\\integrity};
|
|
\node[attr] (avail) at (3.6,0.9) {Availability};
|
|
\node[attr] (perf) at (3.6,-0.9) {Performance};
|
|
\node[attr] (mod) at (3.6,-2.7) {Modifiability};
|
|
\node[leafhh] (l1) at (9.2,2.7) {\textbf{(H,\,H)} No booking lost or double-posted under concurrent node failure; invariant violations $= 0$};
|
|
\node[leafhh] (l2) at (9.2,0.9) {\textbf{(H,\,H)} Failover of the payment service $< 30$\,s with zero transaction loss};
|
|
\node[leaf] (l3) at (9.2,-0.9) {(H,\,M) Card authorisation p95 $< 2$\,s at $3\times$ baseline load};
|
|
\node[leaf] (l4) at (9.2,-2.7) {(M,\,H) New regulatory report integrated in $\leq 10$ person-days, touching $\leq 2$ modules};
|
|
\draw[arr] (util) -- (cons);
|
|
\draw[arr] (util) -- (avail);
|
|
\draw[arr] (util) -- (perf);
|
|
\draw[arr] (util) -- (mod);
|
|
\draw[arr] (cons) -- (l1);
|
|
\draw[arr] (avail) -- (l2);
|
|
\draw[arr] (perf) -- (l3);
|
|
\draw[arr] (mod) -- (l4);
|
|
\end{tikzpicture}%
|
|
}
|
|
\end{center}
|
|
|
|
\centering\small The \textcolor{bankred}{\textbf{(H,\,H) leaves}} -- important \emph{and} hard -- are the architecturally critical points.
|
|
\end{frame}
|
|
|
|
\begin{frame}{From leaves to weights}
|
|
\small The utility tree is the \textbf{methodical derivation of the weights}:
|
|
|
|
\vspace{0.15cm}
|
|
\begin{keypoint}
|
|
\small Dimension $D_i$ receives $w_i(a) = \textbf{High}$ exactly when the class's characteristic utility tree has \textbf{(H,\,H) leaves} under the corresponding attribute. Medium and Low follow from the remaining leaf ratings.
|
|
\end{keypoint}
|
|
|
|
\vspace{0.2cm}
|
|
\footnotesize What a weight \emph{asserts}:
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \textbf{High} is not enthusiasm -- it is a claim with teeth: binding scenarios exist whose failure is \emph{existential}. High weights carry \textbf{veto power} in the match (week 3).
|
|
\item Every High must survive the question: \emph{``show me the (H,\,H) leaf.''}
|
|
\item \textbf{Low} is equally deliberate: not ``we do not care'' but \emph{``we will not pay structure for this''}
|
|
\item \textbf{Medium} is the tradeable middle.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{What High and Low look like (selection)}
|
|
\scriptsize
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{2.6cm}p{5.3cm}p{5.2cm}@{}}
|
|
\toprule
|
|
\textbf{Dimension} & \textbf{High: example} & \textbf{Low: example} \\
|
|
\midrule
|
|
D1 Read scalability & a public social/content feed: thousands of reads per write & an ERP used by clerks: load bounded by headcount \\
|
|
D2 Write scal.\ \& elasticity & Black Friday checkout: $10$--$50\times$ seasonal write peaks & a BI warehouse loaded once, nightly \\
|
|
D4 Consistency & a payments ledger: one double booking is existential & a social feed: a stale like-count harms nobody \\
|
|
D8 Simplicity \& TTM & an internal back-office tool: its value is shipping this quarter & a core ledger: care beats speed \\
|
|
D11 Team scaling & a platform built by thirty teams & a two-person project: nothing to mirror \\
|
|
D12 AI integrability & the AI-native advisory platform: hosting fallible components \emph{is} the product & a classical accounting module \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize Note the \textbf{D4 row}: ledger and feed are near-perfect \emph{mirror images} -- a structure optimised for one is close to pessimal for the other. Part III uses exactly this pair as its anchor.
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% SHAPE, CONSTRAINTS, R(a) ASSEMBLED
|
|
% ============================================
|
|
\section{Workload Shape, Constraints, and $R(a)$}
|
|
|
|
\begin{frame}{The last two components: shape and constraints}
|
|
\footnotesize
|
|
\textbf{Workload shape $S(a)$} -- how load arrives:
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \emph{interactive} $\cdot$ \emph{continuous stream} $\cdot$ \emph{scheduled batch} $\cdot$ explicitly \emph{hybrid} -- with its signature: read/write ratio, load pattern, latency budget, data volume, change rate
|
|
\item \textbf{measured, not guessed}: ratios from access logs, patterns from telemetry
|
|
\item patterns have native shapes too -- the match enforces this as a \emph{gate}: a batch pipeline cannot carry an interactive core
|
|
\end{itemize}
|
|
|
|
\vspace{0.15cm}
|
|
\textbf{Hard constraints $K(a)$} -- an explicit inventory:
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item regulatory obligations (BCBS 239, PCI DSS, EU AI Act), team size and skills, budget, mandated platforms
|
|
\end{itemize}
|
|
|
|
\vspace{0.15cm}
|
|
\begin{hinweisbox}
|
|
\textbf{Constraints are knock-out filters, never weights.} A violating pattern is excluded \emph{before} any scoring -- never averaged away: an architecture that cannot produce the legally required audit trail is \textbf{not a candidate}.
|
|
\end{hinweisbox}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Worked construction: $R(\text{C10})$ -- the advisory platform (your project!)}
|
|
\footnotesize
|
|
\begin{center}
|
|
\footnotesize
|
|
\begin{tabular}{@{}lp{9.6cm}@{}}
|
|
\toprule
|
|
\textbf{High} & D6 auditability (provenance) $\cdot$ D7 evolvability (model/prompt churn) $\cdot$ D9 testability (evals) $\cdot$ D10 cost \emph{per request} $\cdot$ D12 AI \\
|
|
\textbf{Medium} & D1, D3, D4, D5, D8 \\
|
|
\textbf{Low} & D2, D11 \\
|
|
\textbf{Shape} & \emph{hybrid}: interactive advisory dialogue $+$ batch pipelines (indexing, eval runs) \\
|
|
\textbf{Constraints} & EU AI Act (logging, documentation, human oversight); GDPR \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.2cm}
|
|
Two Mediums surprise students:
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \textbf{D3}: users accept seconds for an advisory answer -- the concern is \emph{cost per request}, not speed
|
|
\item \textbf{D4}: a hybrid -- knowledge index eventually consistent, transaction and audit path strictly ACID
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
Every High traces to (H,\,H) scenarios; the constraints are knock-out conditions for the match.
|
|
\end{frame}
|
|
|
|
\begin{frame}{This week's exercise: your QAW}
|
|
\begin{projektbox}
|
|
\footnotesize Run a \textbf{compressed QAW} in stakeholder roles (retail customer, compliance officer, operations engineer, product owner):
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item brainstorm, consolidate, prioritise scenarios; refine the top candidates into the \textbf{six-part form} -- each with a \emph{numeric} response measure
|
|
\item assemble a \textbf{utility tree}; identify the \textbf{(H,\,H) leaves}
|
|
\end{itemize}
|
|
\textbf{Deliverable:} $\geq 8$ scenarios, $\geq 3$ addressing the AI components (answer correctness, token cost per request, provider migration).
|
|
\end{projektbox}
|
|
|
|
\vspace{0.15cm}
|
|
\begin{hinweisbox}
|
|
\small Not a warm-up: the (H,\,H) leaves become the \textbf{weights of your requirements profile} (A1, next week) -- matched in your week-6 ADR, defended in week 14.
|
|
\end{hinweisbox}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% SUMMARY
|
|
% ============================================
|
|
\section{Summary}
|
|
|
|
\begin{frame}{Summary}
|
|
\footnotesize
|
|
\begin{enumerate}\setlength\itemsep{2pt}
|
|
\item Twelve dimensions in five groups -- each a recurring question, \textbf{named and instrumented}: \emph{no instrument, no dimension}
|
|
\item ISO/IEC 25010:2023 supplies the names -- and since 2023 covers AI systems without private extensions
|
|
\item ASRs are vague and implicit $\to$ \textbf{elicited} in a QAW; they discriminate only as \textbf{six-part scenarios} -- the response measure (number $+$ unit) is non-negotiable
|
|
\item The \textbf{utility tree} derives the weights: (H,\,H) leaves $\to$ High; \textbf{High $=$ veto claim}
|
|
\item $R(a) = (w_1, \dots, w_{12};\, S(a);\, K(a))$ -- weights, measured shape, knock-out constraints
|
|
\end{enumerate}
|
|
|
|
\vspace{0.2cm}
|
|
\begin{keypoint}
|
|
\textbf{Maxim 6.} An architecture decision without a response measure is an \emph{opinion}; with a response measure and a fitness function it is a \emph{testable hypothesis}.
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Next week}
|
|
\begin{columns}[T]
|
|
\begin{column}{0.55\textwidth}
|
|
\textcolor{bankblue}{\textbf{Lecture 3 -- the supply side and the match}}
|
|
\begin{itemize}
|
|
\item the seven candidate patterns, previewed
|
|
\item capability profiles $C(p)$ via \textbf{tactics}
|
|
\item the three-stage, non-compensatory \textbf{fit} procedure
|
|
\item worked mini-match: the advisory platform (C10!) against three candidates
|
|
\item recording decisions: \textbf{ADR / MADR}
|
|
\end{itemize}
|
|
\end{column}
|
|
\begin{column}{0.42\textwidth}
|
|
\textcolor{bankblue}{\textbf{Reading}}
|
|
\begin{itemize}
|
|
\item this week: script Part I, Sections 2--3
|
|
\item ahead: Part I, Sections 4--6
|
|
\end{itemize}
|
|
|
|
\vspace{0.3cm}
|
|
\textcolor{bankblue}{\textbf{Exercise}}
|
|
\begin{itemize}
|
|
\item Requirements workshop I: QAW $+$ utility tree
|
|
\item \textbf{A1 due end of week 3}
|
|
\end{itemize}
|
|
\end{column}
|
|
\end{columns}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% END
|
|
% ============================================
|
|
\FHGRClosingPage[][{\color{white}\parbox{0.9\paperwidth}{\centering Thank you!\\[3ex]
|
|
{\normalsize\mdseries Dr.\ Florian Herzog\\[0.9ex]
|
|
Fachhochschule Graub\"unden, Chur\\[2.4ex]
|
|
{\small AISE502 -- AI in Software Engineering II}}}}]
|
|
|
|
\end{document}
|