Module Overview

SE5100 covers the principles, methodologies, and tools for rapid application development — approaches that prioritise speed of delivery, iterative development, and stakeholder collaboration over rigid upfront planning.

High-Yield Topic Clusters

Topic Cluster	Key Exam Patterns
Process Model Selection	Waterfall vs Spiral (drivers/flaws), Prototyping (not standalone), Incremental Development, 5 core attributes, exponential cost, safety-critical vs consumer tech scenarios
RAD vs. Agile	7-dimension comparison; RAD timeboxing; Agile umbrella; 4 Pillars; 4 Phases; RAD Design Model; 4 Issues
Scrum	Roles (ScrumMaster vs PO), ceremonies (Review=product vs Retrospective=process), DoD 5 criteria, Burndown Chart, user story format
XP	TDD, Refactoring, Pair Programming — Scrum teaches management, XP teaches code quality
DevOps and CI/CD	CI vs CD; 8-stage lifecycle; 6-stage pipeline + 4 properties; Docker vs Kubernetes; IaC 5 properties; 4 trade-offs; stats: 10x/30%/60%
Observability	Three Pillars: Logs (what?), Metrics (how?), Traces (where?); USE + RED methods; Observability vs Monitoring
Release Strategies	Blue-Green (instant swap, double infra), Canary (gradual %), Feature Flags (decouple deploy/release); comparison table
DDD	Ubiquitous Language (same terminology), Bounded Contexts (prevent model corruption)
Kanban	WIP Limits, Pull System, "Stop Starting Start Finishing", continuous delivery; Kanban vs Scrum 6-dimension comparison
RAD Teams	6 roles; servant leadership; 4 sourcing strategies; T-shaped professional; 4-stage onboarding; 6 knowledge transfer practices; 4 tracking metrics; UCD Cycle; JRP/JAD
CASE Tools	Unified analysis-to-code pipeline; Visual Modeling; 4GL; Component Repositories (84% cost); RepoGuard
Low-Code / No-Code	"Prototype IS the Product"; Quickbase/Caspio; Prototype Fidelity (Lo-fi vs Hi-fi); Ajax; JRP & JAD
Product Management	PM definition; "Fall in love with the problem"; User Persona 6 components; PM vs PM vs PO; PLC 5 stages (Nokia); Product Dev 6 stages; MVP
SE Ethics & Legal	ACM/IEEE Code; ISO 27000 series; Legal attack surface; Geographical compliance; BA case study (£20M)
SOLID	5 principles; Code Viability Matrix; CI/CD Guardrail Funnel; Knight Capital case study ($460M)
Professional Practices	Dynamic Tension Web; Complete Engineer; SRE + SLOs + Error Budgets; Green SE Carbon Stack; Groupthink Decay Curve; Sociotechnical Ecosystem
Lean	Origins (Toyota TPS → Poppendiecks 2003); 7 Principles; 7 Wastes; Kaizen/PDCA; 4 Anti-Patterns; 24→11 day worked example
VSM	VSM definition; 21-day pipeline example (31% value-adding, 69% waste); 6-step workshop; 6 Lean Metrics incl. Little's Law and DORA
GenAI in RAD	GenAI Development Loop (6 stages); Traditional vs GenAI RAD comparison; Role transformations; 4 Risks; Strategic Methodology Mapping
Revenue Models & Licensing	4 revenue models; 5 transaction sub-types; 5 license categories ordered by restrictiveness; Copyleft vs Proprietary distinction

Study Gaps (Not Yet in Notes)

Note: DSDM — named in lectures but not covered in depth. Design Patterns — named only in L1. "4 golden signals" (Latency/Traffic/Errors/Saturation) — mentioned in assignment, not covered in lecture body. No past papers ingested.

1 — Process Model Selection

Method Selection Principles

Principle	Detail
No "Best" Methodology	Every project is different. The best method is the one that fits your context — not the newest or most popular
Context Determines Choice	Requirements clarity, timeline, team size, and risk tolerance all influence the decision
Predictability vs Adaptability	This is the fundamental trade-off. Know which one your project needs most — it drives all other choices

Important: "Success is not about choosing the newest method, but matching the process to specific constraints."

What is Software Engineering?

Perspective	Detail
IEEE Definition	"The systematic application of scientific and technological knowledge to the design, implementation, and testing of software."
Google's Perspective	"Programming integrated over time"
Economic Reality	Software costs > Hardware costs; Maintenance costs > Development costs

Five Core Product Attributes

Attribute	Role
Performance	Speed and responsiveness of the system
Maintainability	Ease of modifying and extending the system over time
Dependability	Reliability, safety, and security
Efficiency	Resource utilisation (CPU, memory, energy)
Usability	Ease of use for end users

Important: Costs rise exponentially when very high levels of a specific attribute are required.

Process Structure

Every process model — regardless of type — must address all four stages:

Stage	Description
Specification	Define what the system should do
Design	Define the system's structure and architecture
Validation	Verify the system meets requirements
Evolution	Adapt the system to changing needs over time

Foundational Process Models

Waterfall Model (Plan-Driven)

Property	Detail
Structure	Sequential: Requirements → Design → Build → Test → Deploy
Driven by	Plan
Best for	Fixed requirements + Low technical risk + Strict compliance
Critical Flaw	Late value delivery; high cost of change; if market changes mid-project, plan becomes obsolete
Metaphor	Waterfall = Orchestra — everyone follows the score exactly; predictable only when the score is perfect

Contrast: Agile = Jazz — a structured framework for improvisation; adapts to what the audience needs; thrives when requirements evolve.

V-Model (Verification & Validation)

Extension of Waterfall that maps each development stage to a corresponding testing stage:

Developer Life Cycle (left)	Tester Life Cycle (right)
Business Requirements Specification	Acceptance Testing
System Requirements Specification	System Integration Testing
High Level Design	Component Testing
Low Level Design	Unit Testing
Coding (bottom)

Important: The V-Model's key differentiator: every design step has a corresponding testing step defined upfront. Use case: Fixed Requirements + Strict Compliance.

Spiral Model (Risk-Driven)

Origin: Barry Boehm. Differentiator: Explicit Risk Analysis phase in every iteration.

Property	Detail
Structure	Repeating cycles through 4 quadrants: Planning → Risk Analysis → Engineering → Customer Evaluation
Driven by	Risk
Best for	Mission-critical, complex systems where failure is not an option
Critical Flaw	Complex management; elusive "Definition of Done"

Waterfall vs V-Model vs Spiral

Dimension	Waterfall	V-Model	Spiral
Approach	Sequential	Sequential + Verification	Iterative
Driver	Plan	Plan + Validation	Risk
Requirements	Fixed upfront	Fixed upfront	Can evolve
Testing	At end	Mapped to each design stage	Per cycle
Management complexity	Low	Medium	High
Best for	Known, stable requirements	Compliance-critical systems	High-stakes, uncertain projects

Prototyping and Incremental Development

Model	Key Property
Prototyping	Creating a "dummy system" to validate requirements. NOT a standalone methodology — always used within another model
Incremental Development	User sees value during development. Requires loosely-coupled architecture. Concurrent Spec/Dev/Val producing Initial → Intermediate → Final versions

The Methodology Spectrum

Zone	Methodologies	Characteristic
Linear Left	Waterfall, V-Model	Maximum predictability; plan-driven; fixed requirements
Hybrid Center	RAD, FDD	Balance speed with structure; prototype-centric
Adaptive Right	Scrum, Kanban, XP, DevOps, Lean	Maximum adaptability; people-driven; changing requirements

Strategic Model Selection

Primary Constraint	Recommended Model
Fixed Requirements + Low Risk + Strict Compliance	Waterfall / V-Model
Evolving Requirements + High Customer Availability	Agile (Scrum / XP)
Need Extreme Speed (<90 days) + Modular System	RAD
High Risk / Stakes — mission-critical	Spiral
Maintenance Mode + Bottleneck Removal	Kanban

2 — RAD and Agile

Rapid Application Development (RAD)

Property	Detail
Definition	Incremental model (IBM, 1980s) compressing analysis, design, build, and test into short, iterative cycles
Philosophy	"Good enough, fast." Time-boxed cycles (60–90 days)
Timeboxing	Features are cut to meet the deadline — the deadline does not move. Scope is flexible
Tool-Centric	Heavy reliance on CASE tools and component reusability
User Design	Heavy prototyping with active user involvement throughout

Important: Timeboxing is the defining RAD characteristic: scope is flexible, the deadline is not.

Four Pillars of RAD

Pillar	Description
Rapid Prototyping	Build working models quickly to validate requirements
Iterative Development	Repeated cycles of build-feedback-refine
User Involvement	Active stakeholder participation throughout — not just at start/end
Component Reuse	Leverage existing libraries, frameworks, and CASE tools to accelerate delivery

Estimation in RAD

Principle	Detail
Timeboxed Planning	Deadline is fixed; scope is cut to fit
Scope Flexibility	Features are deprioritised or dropped when time is tight
Feature-Based Estimation	Estimate by feature value, not raw effort
Velocity-Informed Adjustments	Use team velocity from prior iterations to calibrate future estimates

RAD Phases

Note: The final phase is variously called "Rollout" or "Cutover" — both refer to the same phase. "Cutover" is the original IBM RAD terminology.

Phase	Activities
Requirements Planning	Agree on scope, constraints, and business goals; identify stakeholders
User Design	Prototype development; users test, developers refine; real-time feedback
Construction	Rapid coding; feature improvement; component integration
Cutover / Rollout	Testing; data conversion; training; deployment

The User Design ↔ Construction loop iterates until quality is achieved, then Cutover completes the delivery.

RAD Design Model (parallel)

Model	Activity
Business Modelling	Workflow identification; information flow mapping
Data Modelling	Entity definition; relationship mapping
Process Modelling	Logic definition; transformation mapping
Application Generation	Automated tools; visual development environments; framework reuse
Testing	Continuous validation; user acceptance; integration checks
Turnover	Deployment completion; documentation; knowledge transfer

RAD Ingredients for Success

Ingredient	Detail
SWAT Team	Small, multi-disciplinary group of highly skilled experts; experts in tools
Decisive Management	Willingness to cut bureaucracy; quick decision-making
The Toolset	Heavy reliance on CASE tools, automated code generators, reusable component libraries

RAD Success Factors

Factor	Detail
Small Expert Teams	Fewer handoffs, faster decisions. Quality over quantity — 6–10 people max (2–4 in GenAI RAD)
Strong Decision-Making	Someone with authority must be in the room. Delays kill momentum in a timebox
Automation Tools	Manual processes negate RAD's speed advantage. CASE tools, CI/CD, now AI copilots

RAD Pros and Cons

Pros	Cons
~70% reduction in development cycle time	High cost (tools and skilled talent)
High flexibility for changing requirements	High user commitment required — fails without active users
High user satisfaction via active involvement	Scalability issues — system must be modular
Early customer feedback via prototypes	Not suitable for high technical risk
High reusability of components	Role confusion (developers bypass analysts)

Important: RAD is NOT suitable for: safety-critical systems, systems that cannot be modularised, or projects where users cannot commit significant time.

RAD Trade-offs

Important: The considerations below are not flaws — they are precondition failures. RAD works when skilled teams, committed users, and adequate budget are all present. When any of the three is absent, the corresponding disadvantage materialises.

Advantages	Considerations (precondition failures)
Faster time-to-market	Requires highly skilled talent
High user satisfaction	Users must commit significant time
Early and continuous feedback	Can be expensive to sustain
Reduced overall project risk	Scope creep risk is real

RAD Issues

Issue	Impact
Requires skilled teams	RAD collapses without developers experienced in rapid prototyping
High user availability dependency	Continuous user feedback is essential — unavailable users stall iterations
Integration complexity	Component reuse and parallel development create integration risk
Limited suitability for safety-critical systems	Speed and scope-cutting are incompatible with rigorous safety certification

Specialized RAD Architectures

Architecture	Key Metric	Detail
Component-Based Development (CBD)	70% cycle time reduction; 84% cost reduction	Reuse of COTS components rather than building from scratch
Aspect-Oriented Software Development (AOSD)	—	Cross-cutting concerns (security, logging) managed as separate "aspects" woven across all modules

Feature Driven Development (FDD)

Property	Detail
Focus	Client-valued features; building by feature, not by phase
Approach	Highly structured and design-oriented
Spectrum position	Hybrid Center — more structured than pure Agile, faster than Waterfall

Agile Software Development

The Umbrella: Agile is not a single method — it is a philosophy encompassing Scrum, XP, Crystal, and Lean.

Agile Manifesto — Four Core Values

Value (prioritised)	Over
Individuals & Interactions	Processes & Tools
Working Software	Comprehensive Documentation
Customer Collaboration	Contract Negotiation
Responding to Change	Following a Plan

Important: The Manifesto says "the items on the right have value, but we value the items on the left more." It is not a rejection of process or documentation — it is a priority ordering.

RAD vs. Agile: 7-Dimension Comparison

Feature	RAD	Agile
Primary Driver	Speed of Development	Adaptability to Change
Focus	Tools, Components, UI	People, Communication, Feedback
Planning	Pre-planned prototypes	Rolling wave (Sprint by Sprint)
Customer Role	Design workshops	Continuous collaboration (PO role)
Metric	Code delivered / Time	Business value / Sprint
Requirement Type	Known requirements	Rapidly changing
Complexity	Complex to manage	Self-organizing teams

Important: Core distinction: RAD primary driver = Speed; Agile primary driver = Adaptability.

3 — Scrum

Scrum structures work into Sprints — fixed timeboxes of 1–4 weeks — each producing a "Done" increment. Its essence is Empirical Process Control: Plan → Produce → Inspect/Adapt.

Three Roles

Role	Description
Product Owner (PO)	Single person; maximises business value; manages the "What"; owns the Product Backlog
Development Team	All skills needed; recommended size 5–9 people; builds the "How"
ScrumMaster	Facilitates process, removes impediments; is not the team's boss; NOT the project manager

Important: The ScrumMaster facilitates and removes impediments — not a project manager, not the boss. This distinction is commonly tested.

Four Ceremonies

Ceremony	Purpose	Key Detail
Sprint Planning	Define "what" (PO) and "how" (Dev Team); break user stories into tasks	Sets the Sprint Goal
Daily Stand-Up	15-minute pulse check; surface blockers	3 Questions: (1) What did I do yesterday? (2) What will I do today? (3) Am I blocked?
Sprint Review	Showcase completed work to stakeholders; inspect the product	"Celebration of the increment"
Sprint Retrospective	Honest look at the workflow; identify friction; create action plan for next Sprint	Process Improvement + Risk Mitigation

Important: Sprint Review = inspect the product (showcase to stakeholders). Sprint Retrospective = inspect the process (team workflow improvement). A common exam distinction.

Artifacts

Artifact	Description
Product Backlog	Prioritized list of all desired work — owned by the Product Owner
Sprint Backlog	Subset of Product Backlog items selected for execution in the current Sprint
Sprint Goal	The overarching objective for the Sprint, set during Sprint Planning
Burndown Chart	Tracks remaining effort — ideal line slopes from total story points → zero at Sprint end

Definition of Done (DoD)

A "Done" increment must satisfy all five criteria:

Criterion	Meaning
Code Written	Feature is fully implemented
Tests Passed	Automated tests pass
Integrated	Merged into the main codebase without conflicts
Documented	Code and feature are documented
No Defects	No known bugs in the increment

Important: "If it's not 'Done', it doesn't count." Partial work has zero value in Scrum.

User Stories and Estimation

User Story: "As a <type of user>, I want <some goal> so that <some reason>"
Example: "As an Administrator, I want to modify employee personal details so that I can keep information up-to-date."

Sizing Formula: Size = Effort + Complexity + Uncertainty

The "1-2-3-4" Rule: Top backlog items should be small enough that 1–2 people can finish them in 3–4 days.

Agile Culture

Property	Detail
Psychological Safety	People speak up about problems without fear of blame — essential for honest retrospectives
Active Listening	Team members genuinely hear each other; understanding before responding
Collaboration	Work is shared, not siloed — collective ownership of the increment
Clear Communication	Expectations and progress are transparent — visible backlogs, open impediment logs

Important: Psychological Safety is the prerequisite for every other property — without it, retrospectives become performances rather than improvements.

Related Engineering Practices

Scrum provides process management but not technical guidance. These practices fill the gap:

Concern	Framework	Key Practices
How to write code well	Extreme Programming (XP)	TDD, Refactoring, Pair Programming, Coding Standards
How to ship continuously	DevOps and CI/CD	CI, CD, Infrastructure as Code
How to align code with business	Domain Driven Design (DDD)	Ubiquitous Language, Bounded Contexts

4 — Extreme Programming (XP)

Scrum teaches management — how to organise and track work. It does not teach how to write code. XP fills this gap by adding technical engineering discipline inside each Sprint.

Five Core XP Values

Value	Meaning
Communication	Keep information flowing between all team members and stakeholders
Simplicity	Do the simplest thing that could possibly work — avoid over-engineering
Feedback	Short cycles expose problems early; use feedback from tests, customers, and team
Courage	Refactor fearlessly, raise problems honestly, discard code that doesn't work
Respect	Team members respect each other's effort and contributions

Four XP Practices

Practice	Description
Test Driven Development (TDD)	Write the test before writing the code. Forces clear requirement thinking and produces a comprehensive test suite by default
Refactoring	Improve the internal structure of existing code without changing its external behaviour. Keeps the codebase clean and maintainable over time
Pair Programming	Two developers at one machine — Driver writes code (focused on immediate); Navigator reviews in real time (big picture, guides, catches bugs). Roles switch every 25–30 min. Benefits: fewer defects, knowledge spread, better design, mentorship
Coding Standards	Uniform style and conventions across the team. Ensures any team member can read, understand, and modify any part of the codebase

Important: TDD = test first, code second; Refactoring = structure changes, behaviour does not. Know these definitions precisely.

Relationship to Scrum

Scrum provides	XP provides
Process management (roles, ceremonies, artifacts)	Engineering practices (how to write production-quality code)
Sprint cadence and transparency	TDD, Refactoring, Pair Programming, Coding Standards
"What to build and when"	"How to build it well"

RAD vs XP

Aspect	RAD	XP
Primary Focus	Delivery speed	Engineering discipline
Development Approach	Prototype-centric	Test-driven practices
Objective	Accelerate time-to-market	Improve code quality and reliability
Typical Techniques	Rapid prototyping, iteration	TDD, Pair programming

Important: RAD and XP are not mutually exclusive — RAD defines how fast to build; XP defines how to build it well. A team can apply XP practices within a RAD timebox.

5 — DevOps and CI/CD

The Gap: Agile speeds up development, but manual deployment creates a bottleneck. Fast sprints mean nothing if releasing to production takes weeks.

DevOps bridges Development (building software) and Operations (running software).

DevOps Stats

Stat	What it means
10× faster deployment	Speed of release vs non-DevOps teams
30% reduction in change failure rate	Fewer broken releases reaching production
60% less time on unplanned work	Fewer incidents, faster recovery

The 8-Stage DevOps Lifecycle

Stage	Activities
Plan	Backlog, sprints, user stories
Code	Feature branches, peer reviews
Build	Compile, package, artifact store
Test	Unit, integration, regression
Release	Versioning, changelogs
Deploy	Blue/green, canary rollouts
Operate	Config management, scaling
Monitor	Metrics, logs, alerts, traces

CI vs CD

Important: CI = automated build+test on every commit; CD Delivery = human gate before prod; CD Deployment = fully automatic. These are commonly confused in exam questions.

	Continuous Integration (CI)	Continuous Delivery	Continuous Deployment
What	Automated build + test on every push	Code always ready to deploy	Every passing build auto-deploys to prod
Gate	Fast test suite; broken builds block team	Human approval gate before prod	No human gate
Goal	Always have a shippable codebase	Reduce time from commit to customer value	Continuous release
Tools	Git, Jenkins, GitHub Actions, CircleCI	Argo CD, Spinnaker, Flux	AWS CodePipeline

Typical DevOps Pipeline

Stages: Code Push → Code Review → Build & Test → Stage Deploy → Integration Tests → Prod Deploy

Pipeline Property	Detail
Repeatable	Same pipeline runs every time — no "works on my machine"
Auditable	Every deploy logged with who, what, and when
Fast Feedback	Bugs caught within minutes of the commit, not weeks
Safe Rollback	Previous build artifacts allow instant rollback if needed

Containers & Orchestration

Concern	Docker	Kubernetes (K8s)
Scope	Single container packaging and running	Multi-container orchestration at scale
Problem solved	Environment consistency; "works on my machine"	Scaling, self-healing, service discovery
Key capabilities	Portable images; Dockerfile defines env declaratively; Container ≠ VM	Auto-scaling; self-healing restarts; rolling updates; zero-downtime deploys; load balancing
When you need it	Every deployment	When running many containers in production

Infrastructure as Code (IaC)

Property	Detail
Reproducible	Spin up identical environments in minutes
Version controlled	Every change tracked in Git
Auditable	Who changed what, when, and why
Cost-controlled	Destroy dev environments overnight
Self-documenting	Code IS the documentation

Tools: Terraform · Pulumi · Ansible · AWS CDK · Helm

DevOps Trade-offs

Trade-off	Resolution
Speed vs Stability	Deploying 10× daily increases incident risk — invest in automated testing and observability
Automation vs Control	Fully automated pipelines reduce human error but reduce oversight — define clear approval gates for production
Cost vs Scalability	Kubernetes, multi-region, and redundancy cost money — size for P99 usage, use auto-scaling and spot instances
Monolith vs Microservices	Monoliths simpler to develop; microservices scale independently but add complexity — start monolith, split when needed

RAD 5-Stage Delivery Pipeline

Stage	Subtitle	What happens
1. Develop	Incremental builds	CASE tools, 4GL, and component repositories accelerate output. Each increment adds real value
2. Integrate	Continuous CI	Multiple merges per day. Every merge triggers automated build check. RepoGuard validates and links commits to bug tracking
3. Test	Automated QA	FitNesse, Selenium, V-Model approach run in parallel with development. Failures block the pipeline immediately
4. Deploy	DevOps bridge	Tested code deployed automatically. Rollback mechanisms included. Communication Middleware enables scalable multi-user deployment
5. Monitor	Cloud + feedback	Response times, resource scaling, security tracked. Performance data feeds back into the development backlog — the loop never stops

Testing Tools in RAD

Tool	What it does	RAD role
FitNesse	Business-readable acceptance tests — stakeholders write and verify criteria without touching code	Bridges business and technical; acceptance criteria become executable tests
Selenium	Automated browser testing for web apps — every UI interaction verified on every build	Catches regression in the UI layer before users do

Relationship to Agile and RAD

Agile (Scrum)	DevOps
Speeds up the development cycle	Speeds up the delivery and deployment cycle
Produces working software every Sprint	Ensures that software can be released continuously
Sprint Review shows working software	CD pipeline actually ships working software

CI/CD as a Code Quality Guardrail

Gate	Tool Examples	What it catches
Linting	ES Lint, TS Lint	Syntax errors, style violations, potential runtime errors before execution
Static Code Analysis	SonarQube	Code complexity, duplication, test coverage gaps, security hotspots
Automated Unit Tests	Jest, JUnit, PyTest	Regression — verifies existing behaviour is not broken by new changes

6 — Observability

Observability is how you maintain quality as you move fast. The Monitor stage of the DevOps lifecycle feeds back into the next Plan cycle — observability makes that feedback actionable.

Important: Three Pillars: Logs (what happened?), Metrics (how is it performing?), Traces (where is it slow?). Know all three definitions and their tools.

The Three Pillars

Pillar	Question Answered	Data Type	Key Practices	Tools
Logs	What happened?	Timestamped event records	Structured JSON preferred; centralise in ELK/Loki; add correlation IDs for cross-service tracing	ELK Stack, Loki, Papertrail
Metrics	How is it performing?	Numeric time series	USE method: Utilisation, Saturation, Errors (for infrastructure); RED method: Rate, Errors, Duration (for services). Alert on anomalies, not fixed thresholds	Prometheus, Grafana, Datadog
Traces	Where is it slow?	Distributed request journeys	Trace ID follows a request across all services; sample 1–10% of requests (cost vs coverage trade-off)	Jaeger, Zipkin, AWS X-Ray

Important: Traces are critical for microservices architectures — a single user request may touch 10+ services. Without traces you cannot pinpoint where latency is introduced.

Observability vs Monitoring

Monitoring	Observability
Tells you when something is wrong	Tells you why something is wrong
Tracks known failure modes	Explores unknown failure modes
Dashboards and alerts	Logs + metrics + traces combined

7 — Release Strategies

Release strategies decouple deployment frequency from deployment risk — the goal is to ship to production safely and often.

Important: Blue-green = instant all-or-nothing swap; Canary = gradual shift; Feature Flags = decouple code deploy from feature activation.

Blue-Green Deployment

Element	Detail
BLUE	v1 — currently live, receives 100% of traffic
GREEN	v2 — new version deployed and tested in parallel
Switch	Traffic redirected Blue → Green when Green is ready
Rollback	Instant — switch traffic back to Blue
Cost	Requires double the infrastructure during transition

Canary Release

Element	Detail
Traffic split	Start small — e.g., v1: 90%, v2: 10%
Progression	Gradually shift more traffic to v2 as confidence grows
Auto-rollback	Triggered automatically on error rate threshold breach
Risk	Only a small percentage of users see potential issues

Feature Flags (Feature Toggles)

Property	Detail
Core idea	Ship "dark" features in deployed code, enable for specific users via config
A/B testing	Test new features on subsets of users, measure impact before full rollout
Kill switch	Disable a feature instantly without a new deployment
Tools	LaunchDarkly · Unleash · Flagsmith · AWS AppConfig

Comparison

Strategy	Traffic Control	Rollback Speed	Infrastructure Cost	Best For
Blue-Green	Instant all-or-nothing switch	Instant	High (2× environments)	Guaranteed rollback in seconds
Canary	Gradual percentage shift	Fast (reduce %)	Low (same infrastructure)	Validating with real traffic
Feature Flags	Per-user / per-segment	Instant (toggle off)	None	Decoupling deploy from release

8 — Domain Driven Design (DDD)

Complex software fails when code drifts away from the business reality it is meant to model. DDD keeps code aligned with the business domain throughout development.

Core Concepts

Concept	Definition
Ubiquitous Language	Developers and Domain Experts must use the same terminology throughout code, documentation, and conversation. Eliminates translation errors between business intent and technical implementation
Bounded Contexts	Clear boundaries around each part of the domain model prevent model corruption — the risk that terms mean different things in different parts of the system

Architecture

Business / Domain Layer
        ↕
  Ubiquitous Language   ← the shared vocabulary
        ↕
Infrastructure / Code Layer

Important: Know the two key terms: Ubiquitous Language (same terminology across business and code) and Bounded Contexts (clear domain boundaries to avoid model corruption).

In fast-moving Agile environments, without explicit domain boundaries and shared language, the codebase rapidly diverges from business intent. DDD provides the architectural discipline to prevent this even under rapid development cycles.

9 — Kanban

Kanban is positioned in the Adaptive Right of the methodology spectrum. Core focus: Continuous Flow and Bottleneck Identification through visualising work and limiting WIP.

Core Concept: "Stop starting, start finishing."

The Kanban Board

| To Do          | Doing (WIP: 3) | Done           |
|----------------|----------------|----------------|
| [task]         | [task]         | [task ✓]       |
| [task]         | [task]         | [task ✓]       |
| [task]         | [task]         |                |
| [task]         |                |                |

When the "Doing" column is full, no new work can be pulled — teams must finish before they start.

Push vs Pull

System	How work enters	Effect
Push	Work is assigned and scheduled from upstream — team receives work whether ready or not	Bottlenecks are hidden; WIP accumulates silently; team appears busy but throughput stalls
Pull	Work is taken by the team when capacity exists — nothing starts until a slot opens	Bottlenecks become immediately visible as columns fill to their WIP limit

Important: "Pull systems reveal bottlenecks; push systems hide them." This is why WIP limits are the primary Lean/Kanban mechanism.

Core Principles

Principle	Detail
WIP Limits	Cap on how many items can be in progress simultaneously — highlights bottlenecks and improves flow velocity
Continuous Delivery	Items flow to Done as they are completed, not at Sprint end — no fixed cadence
Pull System	Work is pulled by capacity, not pushed by schedule
Visualise Work	The board makes blocked items, bottlenecks, and team capacity immediately visible

Kanban vs Scrum

Dimension	Kanban	Scrum
Cadence	Continuous flow; no fixed iterations	Fixed Sprints (2–4 weeks)
Changes	Can happen anytime	Locked during a Sprint
Roles	No prescribed roles	PO, ScrumMaster, Dev Team
Ceremonies	None required	Sprint Planning, Daily Scrum, Review, Retrospective
WIP	Explicitly limited via WIP limit	Implicitly limited by Sprint scope
Output metric	Lead time / Throughput	Velocity (story points/Sprint)

When to Use Kanban

Maintenance Mode — ongoing support where requests arrive continuously
Focus on Flow — minimising lead time is more important than delivering planned features
Continuous Delivery — need to ship items as they complete rather than waiting for a Sprint end
Bottleneck visibility — team wants to identify and fix process constraints

Important: Strategic Selection: Kanban → Primary Constraint = Bottleneck Removal. (Waterfall → Fixed Requirements; Agile/Scrum → Evolving Requirements; RAD → Extreme Speed; Spiral → High Risk)

10 — RAD Teams

Cross-Functional Teams

Property	Detail
Diverse Skills	Mix of dev, design, QA, and business expertise
Shared Goals	Team owns delivery end-to-end, not by phase
Flat Hierarchy	Direct communication, minimal approval chains
Autonomous	Empowered to make decisions within scope

RAD Team Structure — Six Roles

Role	Responsibility
Product Owner	Owns the vision; prioritises backlog; accepts deliverables. Bridge between business and team
RAD Facilitator	Manages timelines; removes blockers; protects team from scope creep and external distractions
Developers	Full-stack or specialised; build rapidly using reusable components and modern frameworks
UX/UI Designers	Create prototypes; conduct user research; translate user feedback into design iterations
QA Engineers	Embedded testers who validate continuously (not just at end); write acceptance criteria with PO
Business Analyst	Translates business requirements into user stories; maintains alignment between stakeholders and team

Important: RAD Facilitator ≠ Project Manager. The RAD Facilitator protects the timebox and removes blockers — they do not direct tasks. This parallels the ScrumMaster role.

Management Principles

Traditional	RAD
Top-down directives	Servant leadership — managers remove obstacles, not direct tasks
Phase-gate reviews	Continuous feedback
Fixed scope	Flexible scope; time-box discipline protects boundaries
Milestone tracking	Velocity tracking; transparent communication via daily standups + visible backlogs

Sourcing Strategies

Strategy	Pro	Con
Internal Secondment	Low cost, high context	Availability conflicts
External Contracting	On-demand expertise	Higher cost, onboarding time
Hybrid Sourcing (most common)	Flexible, cost-effective	Coordination overhead
Outsourced Teams	Fast ramp-up	Alignment risks, IP concerns

T-Shaped Professional — Skill Requirements

Skill Type	Detail
Technical Skills	Coding, testing, DevOps, prototyping tools, version control
Domain Knowledge	Understanding of the business domain, user workflows, and system constraints
Communication	Active listening, stakeholder management, technical writing, presentation
Adaptability	Comfort with ambiguity, rapid context switching, learning on-the-fly

Training & Onboarding (4 Stages)

Stage	Timing	Activities
Orientation	Day 1–3	Team charter, tooling setup, codebase walkthrough, stakeholder intros
Immersion	Week 1	Shadow existing team members, attend user sessions, review prototypes and backlog
Contribution	Week 2	Pair with senior members on live tasks, take ownership of small features with mentorship
Full Integration	Week 3+	Independent task ownership, participate in design sessions and retrospectives

Knowledge Transfer Practices

Practice	How It Transfers Knowledge
Pair Programming	Code written in pairs — both developers understand the implementation
Code Reviews	Every PR reviewed by at least one other; review comments are knowledge transfer artifacts
Wiki / Living Docs	Lightweight docs in sprint — focus on decisions made and why, not just what was built
Demo Sessions	Weekly demos open to entire team — everyone explains what they built
Retrospectives	Structured exchange of what worked, what didn't, what to carry forward
Rotation Policy	Regularly rotate team members across features and modules to distribute knowledge

Work Tracking Metrics

RAD Kanban boards use four columns: Backlog → In Progress → Review → Done.

Metric	Definition	Purpose
Velocity	Story points completed per sprint	Forecast future capacity
Cycle Time	Time from task start to completion	Identify bottlenecks
Defect Density	Bugs per feature	Track quality trends across sprints
Prototype Iterations	Number of feedback-driven cycles	Measure responsiveness to user input

Participatory Design (PD) — 3 Techniques

Technique	Description
Co-Design Workshops	Users sketch interfaces, create paper prototypes, and prioritise features alongside the design team. Held at sprint start
Contextual Inquiry	Developers and designers observe users in their actual work environment — reveals tacit needs no interview would surface
Prototype Walkthroughs	Users walk through clickable prototypes while thinking aloud; team observes silently and notes friction points

User-Centered Design (UCD)

UCD Cycle: Understand Context → Specify Requirements → Produce Design → Evaluate Design → (Meets Requirements? → done or back to Understand)

UCD Role	Responsibility
UX Researcher	Plans and conducts user research; interprets findings; feeds insights into backlog
Interaction Designer	Owns wireframes, information architecture, and interaction flows
Usability Tester	Runs usability sessions; documents friction; tracks UX debt sprint-over-sprint
Accessibility Specialist	Ensures all outputs meet WCAG standards
Product Manager	Translates UX findings into prioritised features; champions user needs in backlog

Project Management Tools

JRP & JAD Workshops

	JRP (Requirements)	JAD (Design)
Focus	Requirements gathering	Application design
Goal	Agree on scope and what the system must do	Agree on how the system will work
Who attends	Business stakeholders + analysts	Business + developers + designers
Output	Requirements document / user stories	Wireframes, data models, workflow designs
RAD value	Replaces weeks of back-and-forth with a 1–3 day workshop	Gets design decisions made with all parties in the room

Important: JRP and JAD are time-compression techniques — they collapse requirements and design cycles from weeks of email chains into structured days of facilitated workshop.

11 — CASE Tools and Development Environments

Computer-Aided Software Engineering (CASE) tools automate the backbone of development — compressing the time from analysis to working code by replacing manual tasks with automated pipelines. In RAD, CASE tooling is what makes "60–90 day" delivery cycles achievable.

Important: CASE tools = unified analysis-to-code pipeline. RAD relies on them to eliminate the gap between design and implementation.

Integrated CASE Toolsets

Feature	Detail
Drag-and-drop code generation	Produce code directly from process/data models with minimal hand-coding
Consistent code base	New generation integrates with previously generated code — no manual stitching
Analysis-to-code pipeline	The entire lifecycle from requirements model to executable artifact is a single workflow

Visual Modeling Tools

Tool Class	Capability
ERD-to-code	Entity-Relationship Diagrams become working database schemas and data-access code (e.g., Totem)
Diagram-to-code	UML, process models, and flow diagrams generate application skeletons
Round-trip engineering	Code changes reflect back in the diagram; diagram changes generate code — always in sync

4th Generation Languages (4GL) vs 3GL

Aspect	3GL	4GL
Abstraction level	Procedure-oriented — you write every step	Result-oriented — you declare the outcome
Code volume	High — hundreds of lines for a form	Low — a few declarations
Source	Written manually	Generated from process/data models
Examples	Java, C++, COBOL	SQL, RPG, PowerBuilder, Oracle Forms

Component Repositories

Property	Detail
Reuse over rebuild	Components verified across prior projects — no reinventing the wheel
Cost impact	Up to 84% reduction in project costs through component reuse
Quality assurance	Reused components carry prior test results; fewer defects per feature
Repository governance	Components tracked, versioned, and retired — monitored for performance over time

Version Control

Capability	Why it matters in RAD
Parallel feature branches	Multiple developers build features simultaneously — no stepping on each other
Clean merge	Branches merge back to trunk; conflicts surfaced and resolved automatically
Full audit trail	Every change attributed to a person, timestamp, and commit message
Reversibility	Any bad change can be reverted instantly — essential in fast, iterative RAD cycles

RepoGuard Framework

Feature	Detail
Pre-storage validation	Before any resource is permanently committed, RepoGuard checks it against defined rules
Bug tracker linkage	Every commit links to a bug/ticket — nothing slips through unreviewed or untracked
Policy enforcement	Code style, test coverage thresholds, and security rules applied at commit time

The Automation Compound Effect

Tool Class	RAD Acceleration
Integrated CASE Toolsets	Eliminates analysis→code translation gap
Visual Modeling (ERDs→code)	Turns architecture sessions into working schemas
4GL	10× fewer lines of code for UI/DB work
Component Repositories	84% cost reduction through reuse
Version Control + RepoGuard	Parallel teams without chaos

12 — Low-Code / No-Code Prototyping

Important: "The Prototype IS the Product" — platforms like Quickbase and Caspio ship with built-in databases, reporting engines, and admin tools, making the prototype-to-production transition seamless.

Low-Code / No-Code Platforms

Feature	Detail
Built-in database	No schema design or ORM wiring — storage is instant
Reporting engine	Charts, dashboards, and exports generated from data out of the box
Admin tools	User management, permissions, and configuration without custom code
Prototype-to-production	The prototype built in the platform is the production system — no throw-away work

Platform	Category	Strength
Quickbase	No-code	Business application builder; DB + reporting + admin built in
Caspio	Low-code	Web database apps; built-in workflows and API connections
Bubble	No-code	Full-stack web app builder; logic, DB, and UI in one
Webflow	No-code	Front-end/CMS; design-to-production web publishing

User-Driven Prototyping

Principle	Detail
Iterative with client	Show early → get feedback → refine → repeat
Requirements emerge	Users discover what they want by interacting with a working model, not by reading specs
Reduces rework	Misunderstandings caught at prototype stage cost far less than at system-test stage

Prototype Fidelity

	Low-Fidelity	High-Fidelity
What it is	Sketches, paper prototypes, rough wireframes	Interactive, near-production mockup
Purpose	Early concept validation — test the idea cheaply	Stakeholder sign-off — validate look, feel, and flow
When used	Sprint start / discovery phase	Pre-production / UAT stage
Cost to change	Very cheap — sketches are disposable	Higher — polished prototypes take time to rebuild
Tools	Paper, Balsamiq, Figma Lo-Fi	Figma Hi-Fi, Webflow, Framer, low-code platforms

Important: Low-fi first, high-fi later. The mistake is building high-fi prototypes before the concept is validated — wasted effort if the idea changes.

Ajax for Web Prototyping

Aspect	Detail
Mechanism	Browser sends small data requests in the background; only relevant parts of the page update
User experience	Feels like a native app — instant feedback, no "white flash" between actions
Examples	Search-as-you-type, live form validation, dynamic dashboards

13 — Product Management

Software Product Management governs a product from its inception to the market or customer delivery, in order to maximise revenue. Product management sits at the intersection of Customer, Technology, and Business.

Important: "Fall in love with the problem — not the product." The PM's job is to understand what customers need, not to advocate for a particular solution.

The Product Manager Role

Responsibility	Detail
Reach product-market fit	Helps the product achieve and grow product-market fit by focusing on business needs
Manage the roadmap	Communicates with stakeholders to align the product roadmap with company goals
Cross-functional knowledge	Must know business models, product design, product marketing, and product development
Wears different hats	Acts as UX designer, product marketer, Business Analyst, and Data scientist as needed

Understanding the Customer

Job Story format: "When [Situation] I want to [Motivation] so I can [Expected Outcome]"

Step	Activity
Understand	Interviews, surveys, observations of customer behaviour
Model	Create end user personas
Document	Record customer feedback
Analyse	Understand jobs to be done; know competitor solutions; identify market fit; find what's missing

User Persona — 6 Components

Component	Content
Demographic Information	Age, gender, occupation, education, income
Behaviours	How the user interacts with products, purchasing habits, online behaviour
Goals	What the user hopes to achieve by using the product/service
Needs	The user's requirements and expectations from the product/service
Challenges	Obstacles or pain points in achieving their goals
Preferences	Preferred features, design, communication channels

PM vs Project Manager vs Product Owner

Important: Three roles commonly confused in exams — know the distinctions precisely.

Dimension	Product Manager	Project Manager	Product Owner
Focus	Strategic — product vision, business objectives, market	Tactical — organisation and resourcing for each initiative	Tactical — converts PM strategy into actionable tasks
Responsibilities	Researching, setting product vision, maintaining product roadmap	Breaking down initiatives, planning timelines, allocating resources	Working with cross-functional teams; sprint backlog management
Time horizon	Long-term product success	Project duration	Sprint-by-sprint delivery

Product Life Cycle (5 Stages)

Stage	Key Activity
Conception and Creation	Idea to initial build
Introduction	Launch — Early validation critical here
Growth	Rapid sales increase
Maturity	Peak sales — Sustaining innovation required to maintain position
Decline	Sales fall — product is retired or repositioned

Important: "Sustaining innovation" at Maturity extends the lifecycle — failing to innovate here leads to Nokia-style decline (Nokia was largest cell phone maker in 1998 but collapsed due to hardware focus, resistance to Android, and overconfidence in brand value).

Product Development (6 Stages)

Stage	Activity
01 Idea Generation	Brainstorming; SWOT analysis; target market analysis; customer needs, pricing, and market research
02 Product Definition	Scoping and refining the product concept; define value propositions, marketing strategies, success metrics
03 Prototyping	Constructing a visual representation — from drawings to computer-rendered high-level prototypes
04 Initial Design	Producing an initial mockup; stakeholders collaborate; designed for target audience; may take several iterations
05 Validation and Testing	Validating and testing the development strategy; testing required across dev, marketing, and every product part
06 Commercialisation	Developing and implementing the product; launching with planned commercialisation strategies

Minimum Viable Product (MVP)

Property	Detail
Definition	A version of a product with just enough features to be usable by early customers who can then provide feedback for future development
MVP ≠ Prototype	Prototype = internal sample used to explain a concept. MVP = fully functioning version released publicly
MVP ≠ Draft	MVP is not a plan or draft — it is ready to go to market

Company	Their MVP
Amazon	Online bookstore only (early 1990s)
Facebook	"Thefacebook" — launched across 4 universities to connect campus friends
Airbnb	Simple room-exchanging platform

Important: MVPs are released publicly to receive market feedback and pivot in the right direction — unlike prototypes which are used internally.

14 — SE Ethics and Legal Compliance

"Ethics is not philosophy; it is a structural requirement for system viability."

Professional Ethics

Layer	Body	Scope
ACM/IEEE 1999 Code of Ethics	International professional standard	Committing to public health, safety, and welfare as the primary obligation — above client or employer interests when they conflict
IEEE	Institute of Electrical and Electronics Engineers	Defines, advances, and regulates professional engineering standards globally
SLASSCOM	Sri Lanka Association for Software & Services Companies	Local professional body — same mandate at national level

Standardisation: ISO 27000 Series

Standard	Name	Purpose
ISO 27001	ISMS Requirements	Core — the certifiable standard; defines requirements for establishing, implementing, maintaining, and improving an ISMS
ISO 27002	Guidelines	Implementation guidance for ISO 27001 controls
ISO 27701	PIMS Requirements	Privacy Information Management System — extends 27001 for personal data
ISO 27011	Telco	Sector-specific guidelines for telecommunications
ISO 27017	Cloud	Sector-specific guidelines for cloud services
ISO 27019	Energy	Sector-specific guidelines for energy industry
ISO 27034	AppSec	Application security guidance
ISO 27799	Health	Sector-specific guidelines for healthcare

The Legal Attack Surface

Legal Area	What it covers	Key Risks
Contracts	NDAs, Intellectual Property (IP) protection	Disclosing customer data = immediate legal conflict; IP leakage through code sharing
Licensing & Copyright	Open-source constraints vs. commercial requirements	Confusing open-source licences with commercial freedom; Patent infringement and royalty fees
Cybercrime Liability	Fraud, unauthorised access, spam, theft of sensitive data	Engineers can be held liable for systems they build if security is negligent

Important: Compliance is geographical. Shariah law in the Middle East vs GDPR in Europe alters fundamental data processing architecture — not just policies. Building for a global market means designing for the most restrictive jurisdiction.

Case Study: British Airways — Failure of Privacy by Design

Stage	Detail
Context	BA operates a massive, legacy web booking system handling highly sensitive global customer data
Systemic Vulnerability	Poor architectural isolation; lack of third-party script auditing; failure to implement "Privacy by Design"
Catalyst	Magecart cyber-attackers inject 22 lines of malicious JavaScript into the payment page to scrape credit card data
Fallout	£20M GDPR fine. A technical oversight translates directly into a massive legal and financial liability

Critical Takeaway: Code readability, strict linting, and dependency auditing are legal risk mitigation strategies — not just engineering hygiene. Unaudited third-party scripts are a legal attack surface.

Privacy by Design — the architectural principle BA violated: privacy protections must be built into the system architecture from the start, not added as a post-hoc layer.

15 — SOLID Principles

"Architectural integrity requires principles that prevent technical debt from compounding."

The Five SOLID Principles

SOLID principles and Code Viability Matrix

Letter	Principle	Definition
S	Single Responsibility	A class should have one, and only one, reason to change. It should perform only one function.
O	Open/Closed	Software objects should be open for extension, but closed for modification. Add behaviour by extending, not by changing existing code.
L	Liskov Substitution	Objects of the same type should be replaceable with others from the same category without altering the function of the program. Subclasses must honour the contract of their parent class.
I	Interface Segregation	No client should be forced to depend on methods it does not use. Interfaces should be kept small and separate — many specific interfaces are better than one general-purpose interface.
D	Dependency Inversion	High-level modules should not depend on low-level modules — both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions.

The Code Viability Matrix

80–90% of a developer's time is spent reading code, not writing it. Hyper-optimised code is frequently unreadable, creating a long-term maintenance liability.

Zone	Readability	Execution Speed	Result
Viability Zone	High	High	Sustainable production code
Fast but Fragile	Low	High	Unreadable, unmaintainable — technical debt accumulates
Readable but Slow	High	Low	Cannot scale — performance becomes a bottleneck
Danger Zone	Low	Low	Both unmaintainable and slow — replace immediately

Reaching the Viability Zone requires: Comprehensive logs · Linting tools (SonarQube) · Clear comments where intent is non-obvious · Balancing performance with long-term maintainability

The CI/CD Guardrail Funnel

Automated gate sequence — only verified, secure code reaches production:

ES Lint / TS Lint — Syntax and style enforcement; catches errors before execution
Static Code Analysers (SonarQube) — Code metrics: complexity, duplication, coverage, security hotspots
Automated Unit Tests — Regression protection; every commit verified against the test suite

Case Study: Knight Capital Group — $460M Code Regression

Stage	Detail
Context	High-frequency trading firm executing millions of stock trades per minute
Systemic Vulnerability	'Dead code' — an obsolete testing function called "Power Peg" left in the active codebase for years. Zero automated CI/CD deployment guardrails
Catalyst	Manual deployment error: new software correctly installed on 7 servers, but the 8th server missed — triggering the obsolete Power Peg function
Fallout	System buys high and sells low continuously. $460 million loss in exactly 45 minutes, leading to bankruptcy

Critical Takeaway: Robust version control and automated deployments are not optional — they are corporate survival mechanisms. Dead code + manual deployments + zero CI/CD guardrails = existential risk.

SOLID violations present: Single Responsibility violated — Power Peg testing code lived in the production module. No automated gate to catch stale code before deployment.

16 — Professional Engineering Practices

The Dynamic Tension Web

Force	Measured by	The constraint
Cost	Resource optimisation, compute spend	Reducing cost increases strain on time and quality
Quality	Defect density, performance, reliability	High quality requires time and money
Time	Throughput, latency, delivery speed	Speed pressure degrades quality and raises cost

Important: "System complexity dictates that 'Done Quickly' and 'Low Cost' mathematically guarantee 'Low Quality.'" — The triangle cannot be optimised in all three corners simultaneously.

The Complete Engineer

Domain	Components
Knowledge	Domains, legal scope, lifecycle processes — knowing what applies where
Skills	Debugging, communication, technical execution — being able to apply that knowledge
Attitudes	Loyalty, ethics, doing the right things the right way — choosing to apply it correctly

Site Reliability Engineering (SRE)

Dimension	Legacy Maintenance	SRE Paradigm
Approach	Reactive, manual patching	Proactive, automated scaling
Team structure	Siloed development vs. operations	Software engineers designing operations
Reliability target	Mathematical illusion of "100% uptime"	Designing for acceptable failure
MTTR	>24 hours	Target: <30 minutes

SLOs and Error Budgets

Service Level Objectives (SLOs): The agreed reliability target (e.g., 99.99% uptime). SLOs define acceptable reliability rather than pretending failure can be eliminated.
Error Budget: The allowed failure margin (100% minus the SLO). If SLO = 99.99%, error budget = 0.01% downtime per period.
When the budget is full: deploy freely. When the budget is exhausted: freeze deployments and focus on stability.

Important: SLOs + Error Budgets resolve the fundamental ops tension: engineering teams want to ship fast; ops teams want stability. The error budget gives both teams a shared objective metric to negotiate against.

Green Software Engineering

The Green Software Carbon Stack has three layers:

Layer	Focus	How to reduce carbon impact
Layer 1: Code Efficiency	CPU cycles	Hyper-bloated code draws more electrical power. Efficient algorithms and clean code directly reduce energy consumption
Layer 2: Network Transit	Data movement	Minimising payload sizes (efficient APIs, compression, caching) reduces the massive energy cost of moving data globally
Layer 3: Hardware & Hosting	Infrastructure	Use carbon footprint tools to schedule high-compute tasks in regions powered by renewable energy grids

Groupthink and Intellectual Honesty

The Groupthink Decay Curve — Compounding System Flaws over the Project Lifecycle:

Curve A (Groupthink Environment): Developers refuse to admit mistakes. Echo chambers suppress dissent. Flaws compound from ~5 → 1000+ by End-of-Life.
Curve B (Controlled Baseline): Achieved through constructive dissent, pair programming, rigorous reviews, shared responsibility, and continuous feedback. Flaws stay flat at ~5–10.

Required input	Why
Intellectual honesty	Admitting lack of knowledge and acknowledging mistakes prevents small issues from compounding
Constructive dissent	Diverse perspectives catch what consensus misses
Psychological safety	Without it, teams default to consensus-seeking at the expense of technical rigour
Direct communication	Indirection (passing info through layers) introduces delay and distortion

Stakeholder Management

Step	Action	Output
1. Requirement Development & Signoff	Establish baseline consensus with stakeholders — document what is agreed and get formal sign-off	Baseline requirements document
2. Scoping via Sprint Backlog	Translate requirements into the sprint backlog — defend the boundary against scope creep	Bounded sprint scope
3. Tracking via JIRA	Make bugs and requirements visible — track progress transparently	Actionable, visible progress

The Modern Sociotechnical Ecosystem

A complete professional practice chains five nodes — each one enabling the next:

Node	Domain	Key Metrics
SOLID Code	Technical Excellence	Clean architecture, low coupling
CI/CD Pipelines	Quality Assurance	Automated tests >95% pass, rapid deployment
SRE Error Budgets	Reliability	SLO target 99.99%, MTTR <30 minutes
GDPR / Legal Compliance	Risk Mitigation	Data minimisation, audit trails
Green SE Metrics	Sustainability	Carbon footprint, energy efficiency

Important: "Pulling any node on this blueprint affects the others. A true professional understands the entire cascading chain of risk and execution."

17 — Lean Software Development

Origins

Milestone	Detail
1950s — TPS	Post-war Japan: Toyota couldn't afford excess inventory, defective parts, or idle workers. Necessity created the Toyota Production System (TPS). Quote: "Build only what is needed, when it is needed, in the amount needed."
1988 — 'Lean' Named	MIT researchers coined "Lean" studying global car manufacturing. Toyota produced cars with half the defects and half the space of Western factories
2003 — Software Adaptation	Mary & Tom Poppendieck published Lean Software Development: An Agile Toolkit — inventory = partially done work, defects = bugs, motion = handoffs

The 7 Lean Principles

#	Principle	Core Idea	In Practice
1	Eliminate Waste	Remove anything that doesn't add value	Identify the 7 waste categories; apply VSM to make waste visible
2	Amplify Learning	Build feedback loops into every process	Frequent stand-ups, retrospectives, pair programming, short iterations
3	Decide as Late as Possible	Keep options open until you have enough information	Avoid premature architectural commitment; defer reversible decisions
4	Deliver as Fast as Possible	Reduce time from concept to customer	Short iterations, CI/CD, small batch sizes
5	Empower the Team	Push decisions to the people with the most information	Self-organising teams; managers as obstacle-removers, not task-assigners
6	Build Integrity In	Quality is built in from the start, not tested at the end	TDD, automated testing, refactoring, code reviews
7	See the Whole	Optimise the entire value stream, not individual parts	Sub-optimising one stage often hurts the whole — a fast developer who creates slow testing is net negative

Important: Principle 7 (See the Whole) is the most commonly violated in practice — and the root cause of the "Local Optimization" anti-pattern. Improvements only count when they reduce end-to-end lead time.

The 7 Wastes in Software

Waste	Toyota Equivalent	Software Example	Lean Fix
Partially Done Work	WIP inventory	Feature 80% coded but not integrated, tested, or deployed — absorbs cost, delivers nothing	WIP limits. Define 'done' as deployed and in use
Extra Processes	Over-processing	Status reports duplicating Jira. Approval steps for low-risk changes	Process audit — keep what adds real value; eliminate the rest
Extra Features	Overproduction	'Gold-plating' — configurable admin dashboard when client asked for a simple read-only view	Validate every feature against real user need before building
Task Switching	Motion waste	Developer on 4 parallel tickets. Each switch requires 20+ minutes to regain deep focus	Strict WIP limits. One thing to completion before starting the next
Waiting	Waiting	Waiting for code review, test environment, approval, a dependency another team is building	Map wait times explicitly. Automate approvals. Share environments
Motion	Transportation	Information through 4 people before reaching who can act — each step = delay and distortion	Direct communication. Developer with client directly where possible
Defects	Defects	A bug found in production costs 10–100× more to fix than during development	Automated testing, TDD, code reviews — catch defects at the source

Important: Defect escape rate target: <5% of defects should reach production. Rising escape rate = quality gates weakening.

Kaizen: Continuous Improvement (PDCA Cycle)

Step	Action	Key Rule
PLAN	Identify one specific problem. Form a measurable hypothesis: "If we change X, we expect Y improvement." Define measurement method before making the change	One problem at a time. Hypothesis must be measurable
DO	Implement the change at small scale first — one sprint or one iteration period	Don't change multiple things at once — you can't measure what you can't isolate
CHECK	Measure the result against your hypothesis. Did the change produce the expected improvement?	Compare against the hypothesis, not against feelings
ACT	If it worked: standardise, document, make it the new baseline, then start again. If not: learn and run a new experiment	Kaizen never stops — the next improvement always exists

Lean Anti-Patterns

Anti-Pattern	Symptom	Fix
Cargo Cult Lean	Team adopts ceremonies (standups, boards) but not discipline. WIP limits on paper, routinely violated. Metrics collected, not acted on	Start with one principle applied rigorously. Enforce one WIP limit strictly. Act on one metric consistently
Local Optimization	Dev team improves cycle time, but deployment is monthly and testing takes two weeks. Overall lead time unchanged	VSM the entire process including stages outside your direct control. Improvements only count when they reduce end-to-end lead time
Waste Without a Fix	Team runs VSM, identifies waste, presents to management — nothing changes. Six months later, same waste exists	Pair VSM exercises with explicit authority to change identified processes. Leadership must visibly act on findings
Metric Gaming (Goodhart's Law)	Cycle time improves but throughput drops. Defect escape rate improves but defect count rises	Use multiple metrics together. Simultaneous improvement in one metric and degradation in another = gaming, not real improvement

Lean in Practice — Worked Example (54% Lead Time Reduction)

Step	Action	Result
1. Run a VSM	Map every step request→deployment. Discover: 8 days wait before sprint planning, 4 days code review wait, 3 days test environment wait. Only 9 of 24 days are value-adding (38%)	Baseline: 24 days
2. Apply Pull	Implement continuous-flow backlog; requests enter ready queue immediately; developers pull when ready. WIP limit of 1.5 per developer	18 days
3. Fix the Bottleneck	Code review wait is new biggest waste. Solution: pair reviews (originator + reviewer together), same-day turnaround target, PR notification rules	14 days
4. Kaizen	Monthly VSM re-run. Biggest waste: test environment setup. Solution: containerised environments auto-provisioned via CI/CD trigger	11 days (54% reduction)

18 — Value Stream Mapping (VSM)

A Value Stream Map (VSM) traces every step from customer request to working software — measuring time spent in value-adding work versus time spent waiting. It makes invisible waste visible so you can eliminate it.

"69% of development time is typically non-value-adding. VSM is the diagnostic tool that forces honest measurement of where time actually goes."

The VSM Pipeline — Typical Example

Step	Active Time
Backlog Refinement	1 day
Sprint Planning	0.5 day
Development	3 days
Code Review	0.5 day
Testing	1 day
Deploy to Production	0.5 day

Metric	Value
Total calendar time	21 days
Active value-adding work	6.5 days (31%)
Waiting / non-value time	15 days (69%)
Biggest waste	Sprint wait (7 days) + code review wait (2 days)

Important: The gap between total calendar time and active work time is your waste target. In this example, 69% of time is pure queue. Fix the queue, not the code.

How to Run a VSM Workshop (6 Steps)

Map every step from customer request to production deployment
Record actual time for each step — not estimated, not planned; actual measured time
Record actual wait times between each step (queue time before each stage)
Calculate value-adding % vs. total time — this is your efficiency ratio
Identify the single biggest waste source — the one queue or delay that dominates
Design one intervention; measure the impact — one change at a time so you can attribute the result

The 6 Lean Metrics

Metric	Definition	Key Insight / Formula
Cycle Time	Time from when work starts to when it's delivered	A rising cycle time means work is getting slower. Aim to reduce 20% per quarter
Lead Time	Time from when a request is made to when it's delivered — includes queue time	Lead time = what the customer experiences. Gap between Lead Time and Cycle Time = your biggest waste target
Throughput	Number of features/stories delivered per unit time	Throughput plateaus signal a bottleneck. Little's Law: Throughput = WIP ÷ Cycle Time
WIP Count	Number of items actively in progress at any one time	High WIP correlates with context switching and long cycle times. Starting WIP limit = team size × 1.5
Defect Escape Rate	Percentage of defects discovered in production vs. total defects found	Any escaped defect is a process failure. Target: <5% of defects reach production
Deployment Frequency	How often working software is deployed to production	DORA classification: daily+ = Elite, weekly = High, monthly = Medium. Elite performers: multiple deploys per day

Important: Use metrics as a system, not in isolation. Goodhart's Law: when a measure becomes a target, it ceases to be a good measure. Simultaneous improvement in one metric and degradation in another = gaming.

19 — GenAI in RAD

"Speed is no longer the constraint — judgment is." — GenAI has removed the speed barrier. What matters now is knowing when to use these tools, how to review their output critically, and when to slow down and think.

What GenAI Changes

GenAI Capability	Impact on RAD
Natural language → working code	Specification and initial implementation collapse into one step
AI-assisted across the entire SDLC	Every phase — design, code, test, review, document — has AI acceleration
Prototyping in hours, not days	The RAD 60–90 day cycle compresses further; inner iterations shrink to hours

The GenAI Development Loop (6 Stages)

Stage	What happens
1. Prompt	Developer writes a plain-English description of the feature — no formal spec needed
2. Generate	AI produces a working implementation in seconds, covering the core logic
3. Review	Developer reads the generated code critically — checking correctness, security, and fit
4. Refactor	Developer restructures and adapts the generated code to integrate with the existing codebase
5. Test	Automated tests run immediately; feedback loop closes in minutes, not days
6. Deploy	Tested, reviewed code goes through the deployment pipeline

Important: The GenAI loop is the same as traditional development. The difference is speed: Prompt replaces hours of spec work; Generate replaces days of coding.

Traditional RAD vs GenAI RAD

Attribute	Traditional RAD	GenAI RAD
Primary Tools	CASE tools & IDE	AI copilots & LLMs
Team Size	SWAT teams (6–10)	Small teams (2–4)
Cycle Time	Days to weeks	Hours to days
Prototyping	Manual mockups	AI-generated in minutes
Code Review	Peer review	AI-assisted + human oversight

How Roles Are Shifting

Traditional Role	GenAI Role	What changes
Developer	AI Orchestrator	Directs, validates, and integrates AI-generated code rather than writing everything manually
QA Engineer	Automation Designer	Designs AI-powered test strategies and pipelines rather than writing individual test cases
Business Analyst	Prompt Engineer	Translates requirements into precise AI instructions that generate the right output
Designer	AI UX Specialist	Integrates AI capabilities into user-centered workflows; governs AI-generated UI components

Important: Human oversight is the constant across all role shifts. Roles move up the abstraction ladder — from doing to directing — but remain accountable for the output.

Risks of GenAI in Development

Risk	Description	Mitigation
Hallucinated Code	AI generates plausible-looking code that is logically wrong or subtly broken	Always review — never ship unreviewed generated code
Security Risks	Vulnerabilities slip through when AI output isn't carefully audited	Security audit every generated file; treat AI output as untrusted until reviewed
Over-Reliance	Foundational skills erode when engineers stop thinking critically and delegate too much	Maintain core engineering practice; use AI as accelerator, not replacement
Hard Debugging	When AI-generated code fails, tracing the root cause can be significantly more complex	Review code before merging so you understand it; keep generated functions small

Strategic Methodology Mapping

Methodology	Context	When to use
Waterfall	Fixed Requirements	Stable scope, well-documented, compliance-driven projects
Agile	Changing Requirements	Evolving needs, cross-functional teams, iterative delivery
RAD	Speed is the Priority	Tight deadlines, high user involvement, proven patterns
GenAI RAD	Extreme Acceleration	AI-assisted, small teams (2–4), hours-long cycles, responsible oversight

20 — Revenue Models and Software Licensing

Revenue Model vs Revenue Stream

Term	Definition
Revenue Model	The strategy of managing a company's revenue streams and the resources required for each
Revenue Stream	A company's single source of revenue — a company can have zero or many revenue streams

Four Revenue Models

Model	Description	Examples
Transaction-based	Revenue generated by directly selling an item or service to a customer	Microsoft, Apple, Samsung
Advertisement-based	Revenue from selling ad space; used by high-traffic websites/apps/marketplaces	Google, YouTube, Facebook
Commission-based	A commission charged on transactions between buyers and sellers	Airbnb, Uber, Booking.com
Donation-based / Pay-what-you-want	Product/service is free; revenue generated from voluntary donations	Wikipedia, open-source projects

Transaction-Based Sub-types (5)

Sub-type	Description	Examples
Licensing / One-time purchase	Sell software by license; one payment for perpetual use	Microsoft Windows, Apache Server, video games
Subscription / Recurring payment	User pays monthly or annual fee for continued access	Netflix, Spotify, Adobe products
Pay-per-use	Charge for computing resources, memory, or time actually consumed	Amazon Web Services, Google Cloud Platform
Freemium / Upselling	Main product is free; charge for additional functions, services, or extensions	Skype, Dropbox, Evernote
Hybrid pricing	A mixture of more than one pricing model	Mailchimp, AWS higher tiers, Salesforce

Important: Know the 5 transaction sub-types with examples. Freemium ≠ free: core is free, premium features are paid.

Software Licensing

Definition: A contract between the entity that created and supplied an application (or underlying source code) and its end user. Protects IP, provides legally binding definitions for distribution and use, spells out installation rights, warranties, liabilities, and IP protections.

License Categories — Ordered by Restrictiveness

From least restrictive → most restrictive:

License	Restrictiveness	Description	Examples
Public Domain	None	No legal, copyright, or editing restrictions. Free to use, modify, distribute, or sell without any restrictions	SQLite, ImageJ, SHA-3
LGPL	Very low	Allows linking to open-source libraries within proprietary software. Resulting code can be licensed under any other type	VLC, 7zip
Permissive	Low	Few restrictions on distribution or modifications. Most common open-source license type. Variants: Apache, BSD, MIT	Apache, BSD, MIT licensed projects
Copyleft	Medium	Modified/distributed code must carry the same license (reciprocal). If original is "personal use only", derivative must also be "personal use only"	Linux kernel, OBS, GIMP
Proprietary	Most restrictive	Software ineligible for copying, modifying, or distribution. Protects developer/owner from unauthorized use	Spotify, Windows

Copyleft vs Proprietary (Key Distinction)

	Copyleft	Proprietary
Can modify?	Yes — but derivative must carry same license	No
Can distribute?	Yes — under same license terms	No
Example	Linux kernel (GPL) — can modify but must release as GPL	Windows — cannot copy, modify, or distribute

Important: The restrictiveness spectrum is: Public Domain → LGPL → Permissive → Copyleft → Proprietary. The most common exam confusion is between Copyleft (reciprocal — derivative inherits the license) and Proprietary (no copying/modifying at all).