Software and Security Engineering: Examinable Syllabus

What the exam tests

The Part IA Software and Security Engineering paper (Paper 2) is taught across Easter term. There are 6 lectures plus a security engineering thread running through the course. The exam typically offers 1–2 questions, with a scenario-based multi-part format (a—c), each part building on the last.

The questions reward concrete, well-grounded reasoning over generic textbook definitions. You are expected to invoke named case studies and course frameworks as evidence for your arguments.

Syllabus checklist

1. Engineering Mindset and Cost of Failure

• Programming vs Software Engineering (team size, scale, lifespan, metrics)
• Software Crisis (1968 NATO Conference)
• Brooks’s Law: communication paths $= \frac{n(n-1)}{2}$
• Discrete state and the impossibility of exhaustive testing
• Moore’s Law vs human cognition — the widening gap
• Systems and emergent behaviour (positive and negative)
• Lifecycle cost: 80/20 rule, four types of maintenance
• Bit rot (software entropy)
• Five case studies: Therac-25, Mars Climate Orbiter, London Ambulance Service, Post Office Horizon, Boeing 737 MAX — know the mechanism, not just the headline
• Technical debt: principal, interest, the quadrant (Reckless/Prudent × Deliberate/Inadvertent)
• Iron Triangle: Fast, Good, Cheap — pick two
• Professional responsibility: pushing back, BCS Code of Conduct

2. Requirements and Specifications

• Problem space (Why) vs Solution space (What)
• The Translation Gap
• Elicitation: interviews vs ethnography — strengths and weaknesses
• FR vs NFR: definitions, examples, the “-ilities”
• NFR trade-offs (Security vs Usability, Performance vs Maintainability)
• Fit criteria: every NFR needs a measurable target
• UML: class diagrams (association, inheritance, aggregation, composition), sequence diagrams (lifelines, messages, activation boxes)
• UML as sketch vs blueprint; analysis paralysis
• Roles: PM, EM, TPM — responsibilities and deliverables
• MoSCoW prioritisation
• PRD contents; requirement traceability

3. Engineering Process

• Software process: four fundamental activities
• Waterfall: five phases, management appeal, the fatal flaw (time gap)
• Spiral Model: four quadrants, risk-driven iteration
• Iterative vs Incremental development
• Agile Manifesto: four values, what Agile is NOT
• XP practices: pair programming, TDD, CI, simple design, refactoring
• YAGNI, premature optimisation
• Scrum: three pillars, three artifacts, five events, three roles
• Story Points and Planning Poker
• “Scrum-but” anti-patterns
• Kanban: continuous flow, WIP limits
• Scaling: SAFe, LeSS, Spotify model

4. Quality Assurance and Reliable Delivery

• Centralised vs distributed VCS (SVN vs Git)
• Git fundamentals: commits (SHA-1), staging area, branches, merge conflicts
• Git Flow vs Trunk-Based Development
• PR workflow and code review
• Bug lifecycle; linking commits to issues
• Coding standards and linters
• Manual vs automated testing
• Testing Pyramid: unit, integration, E2E (cost, speed, isolation, confidence)
• Stubs (canned return) vs Mocks (verify interaction)
• Code coverage ≠ correctness (the average([]) trap)
• Mutation testing: killed vs survived mutants
• TDD: Red-Green-Refactor
• CI, CD, CDP — definitions and differences
• Pipeline anatomy: Commit → Build → Unit → Lint → Integration → Staging → Prod
• Quality Gates
• Promotion pipeline: Dev → CI → Staging → Prod
• Google’s xFood: Fishfood → Teamfood → Dogfood
• Blue-Green deployment
• Canary deployment (vs A/B Testing — know the difference)
• Feature Flags; Progressive Delivery
• SLI, SLO, Error Budget; how error budget throttles releases
• DevOps: “you build it, you run it”
• Cloud: IaaS vs PaaS vs SaaS; shared responsibility model
• Containers vs VMs; Docker vs K8s
• Observability: metrics, logs, traces, dashboards
• Monitoring (known unknowns) vs Observability (unknown unknowns)

5. Software Evolution

• Lehman’s Laws: Continuing Change, Increasing Complexity, Self-Regulation
• Maintenance split: Perfective 50%, Adaptive 25%, Corrective 20%, Preventive 5%
• Legacy code: definition, COBOL pandemic case study
• Software archaeology: git blame, git log -S, issue-tracker links, characterisation tests
• APIs as contracts
• SemVer: MAJOR.MINOR.PATCH — know what counts as breaking
• Zero-Ver problem
• Exact, tilde (~), caret (^) constraints; lockfiles
• Postel’s Law: conservative sender, liberal receiver
• Backward vs forward compatibility
• Hyrum’s Law; SimCity / Windows 95 hack
• Deprecation path: Announce → Deprecate → Wait → Remove
• Code smells: Long Method, God Object, Feature Envy, Data Clumps
• Characterisation (Golden Master) tests
• Strangler Fig pattern; Netscape Big Bang rewrite failure
• Y2K: technical debt at global scale
• SRE: 50% toil rule; MTBF vs MTTR; SLI/SLO
• Four Golden Signals: Latency, Traffic, Errors, Saturation
• Chaos engineering: steady state → hypothesis → experiment → verify
• Chaos Monkey, Chaos Gorilla, Chaos Kong
• Supply chain: transitive dependencies, Left-Pad, Log4Shell, SBOM, CVE

6. Software Engineering in the AI Era

• AI coding capabilities: autocomplete, boilerplate, prototyping, translation, testing, fuzzing, self-healing CI/CD, debugging, refactoring
• AI coding risks: hallucinations, technical debt of ignorance, model variance, bias
• Generator/Verifier (Critic) architecture
• AI throughout the workflow: design, coordination, code review, documentation
• AI agents: tool use, agency
• Building WITH AI vs Building FOR AI
• Reliability Paradox: deterministic code vs probabilistic AI
• Why AI coding advances faster: ground truth (compiler/tests)
• Architectural challenges of Building FOR AI: latency, cost, provider lock-in
• Junior Developer Gap; Jevons Paradox
• Reasoning Ceiling: what AI cannot (yet) do
• Enduring engineering questions

7. Security Engineering

• Access matrix: ACLs (column-centric) vs Capabilities (row-centric)
• Characteristics: checking access, “what can user X do?”, revocation, delegation, auditing
• STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
• Applying STRIDE to a specific system’s data flows
• One-way information flow: confidentiality (low → high), integrity (high → low)
• Password authentication: salt, hash, session token
• Public-key authentication: key pair, challenge-response, signed posts
• Password vs public-key: secret transmission, server breach, usability, cross-server trust, revocation, key loss
• Testing a decentralised system: unit, integration, protocol conformance, fuzzing, load, security testing

Key formulae and rules

Formula / Rule	Use
$\text{Comm paths} = \frac{n(n-1)}{2}$	Brooks’s Law — quantify communication overhead
Error Budget $= 100\% - \text{SLO}$	Determine remaining “risk budget” for new feature releases
$\text{MAJOR}.\text{MINOR}.\text{PATCH}$	SemVer — determine correct version bump for a described change

Exam technique summary

1. Ground every principle in a named case study. “Never rely on a single sensor” → “Never rely on a single sensor (cf. Boeing 737 MAX’s single AoA sensor).”
2. Answer scenario questions in the scenario’s terms. Apply STRIDE to this system’s flows, not generic ones.
3. Use quantitative reasoning where possible — communication paths, error budgets, version numbers.
4. Give a balanced, labelled pros/cons discussion with a justified conclusion for high-mark parts.
5. Distinguish lookalike concepts: FR/NFR, Mock/Stub, Monitoring/Observability, Blue-Green/Canary, A/B Testing/Canary.