Unit 10: Critical Evaluation

A lead developer discovers a data validation defect three days before a major release of a healthcare appointment booking system. The defect allows a malformed date input to silently overwrite appointment records. Fixing it requires four hours of development and full regression testing. The product manager says: "We'll fix it in the next sprint — it's not on the critical path."

Who bears ethical responsibility? What should the developer do? What SDLC process failure allowed this situation to arise?

A software engineering team provides a three-month estimate for a client project. The project manager adjusts this to two months in the proposal, believing the team will work faster under pressure and that the client will accept nothing longer. The team is not told their estimate was changed. Midway through the project, it is clear the original estimate was correct.

Which principles does the project manager's action violate? What should individual team members do when they discover the discrepancy? How does this relate to the MSc principle of evidence-based estimation?

A public-sector client asks the development team to deliver the minimum viable product without WCAG 2.2 accessibility compliance, intending to "add it later." The team knows that accessibility retrofitting is 10× more expensive than designing for it upfront, and that a significant proportion of the target users have visual impairments. The client has a legal obligation under the Equality Act 2010.

What is the engineer's obligation when the client's instruction is both legally non-compliant and likely to cause harm? What documentation should be created?

Integration defect (specifically, an interface mismatch or contract violation). This is a classic example of what integration testing is designed to detect. The defect originates in the requirements or design phase — either the interface contract was not specified, or modules were implemented without referencing it. In testing terms, unit tests for each module passed because they tested in isolation; only integration testing reveals the incompatibility.

Ambiguous requirement. "User-friendly" is unmeasurable — there is no test that can verify or falsify it. It should be replaced with a measurable NFR: e.g., "New users shall be able to complete a booking without assistance within 5 minutes, measured by usability testing with a representative sample of 10 users." The original statement may be retained as a stakeholder goal in a use case description, but it cannot serve as a testable requirement.

Technical debt — specifically, deliberate technical debt that became inadvertent legacy debt. The team made an explicit trade-off (deliberate debt), which is defensible if tracked and resolved. The failure to track and prioritise resolution converted it to unmanaged legacy debt. This is the characteristic pattern through which deliberate tactical shortcuts accumulate into systemic architectural problems.

Coverage is necessary but not sufficient. This scenario illustrates that coverage measures which lines are executed by tests, not whether the tests verify correct behaviour. Tests may execute code with assertions that do not check meaningful outcomes, or may not cover edge cases that the code reaches in production. The finding also suggests tests are verifying implementation rather than requirements — a test design failure rather than a coverage failure.

Blameless post-mortem (also: blameless retrospective). This is a core DevOps cultural practice, associated with the Site Reliability Engineering (SRE) discipline developed at Google. The premise is that individuals operate within systems; defects are caused by system design, not individual error. Blame-focused post-mortems produce defensive behaviour and suppress the honest reporting needed to understand and improve the system.

Strangler Fig pattern. Named after the strangler fig vine that gradually envelops and replaces its host tree. A routing layer (often an API gateway or reverse proxy) intercepts all requests and forwards them to either the legacy system or the new services depending on which capabilities have been migrated. The pattern bounds risk at each migration step and avoids the need for a "big bang" migration where all functionality must be replicated before any transition can occur.

Brooks' Law: "Adding manpower to a late software project makes it later." The new developers require onboarding time from existing team members (reducing their output), increase communication overhead (which grows as O(n²) with team size), and lack the tacit knowledge of existing team members. The correct response to schedule pressure is to descope, change methodology, or accept delay — not to add resources.

Wicked problem (Rittel and Webber). The requirements could not be fully specified upfront because the users could not articulate what they needed without seeing attempts to satisfy their needs. This is the deep justification for iterative and user-centred methodologies in enterprise software: requirements are discovered through the process of trying to satisfy them, not enumerated in advance. The correct methodological response is rapid prototyping and iterative validation, not a heavier requirements engineering effort.

Functional requirements describe what the system must do — specific behaviours or functions. Non-functional requirements describe how the system must perform — quality attributes that apply across functions.

FR example: "The system shall allow a GP to view a patient's appointment history for the preceding 12 months." This specifies a behaviour.

NFR example: "The system shall return appointment history queries within 1.5 seconds for 99% of requests under normal load (up to 500 concurrent users)." This specifies a performance constraint on the behaviour.

The distinction matters for architecture: NFRs such as performance, availability, and security often drive architectural decisions more profoundly than any single functional requirement.

Waterfall is a sequential, phase-gated methodology: requirements are fully specified before design begins; design is complete before implementation begins; each phase produces a baseline artefact that constrains the next. It assumes requirements are knowable upfront and stable. Changes after baseline are costly.

Scrum is an iterative Agile framework operating in fixed-length sprints (typically 2 weeks). Requirements (user stories) are maintained in a prioritised backlog; scope and priority are adjusted between sprints. It assumes requirements will evolve and embraces change.

Waterfall is more appropriate for: safety-critical embedded systems with stable, formally verified requirements (e.g., flight control software); contractually fixed-scope projects with clear acceptance criteria; systems where iterations would be prohibitively expensive (nuclear plant control systems).

Scrum is more appropriate for: enterprise software with evolving user requirements; products where user feedback drives development direction; teams with direct access to stakeholders; digital services expected to evolve post-launch.

Both are use case relationships in UML, but they represent different dependency structures.

«include» represents mandatory shared behaviour: the base use case always invokes the included use case. Arrow points from base to included. Use when behaviour must be reused across multiple use cases to avoid duplication. Example: "Book Appointment" and "Cancel Appointment" both «include» "Authenticate User."

«extend» represents optional or conditional behaviour: the extending use case adds to the base under specific conditions, at a defined extension point. Arrow points from extending to base. Use when behaviour only occurs in certain scenarios. Example: "Add to Waiting List" «extends» "Book Appointment" when no slots are available.

A common mistake: reversing the «extend» arrow. The arrow runs from the optional behaviour to the core behaviour (the extending use case depends on the base, not the other way around).

SAST (Static Application Security Testing) analyses source code or compiled binaries without executing them. It detects vulnerability patterns (SQL injection sinks, unsafe deserialization, hardcoded credentials) by inspecting code structure. It runs early in the pipeline — on commit or pull request. It cannot detect vulnerabilities that only appear in a running system.

DAST (Dynamic Application Security Testing) sends attack probes (malformed inputs, injection attempts, authentication bypass requests) to a running application and analyses responses. It detects runtime vulnerabilities that SAST misses (race conditions, authentication logic flaws, server configuration issues). It requires a deployed test environment.

SAST finds how the code is written; DAST finds how the running system behaves. Both are needed: SAST fails to catch environment-dependent vulnerabilities; DAST cannot analyse code paths that are not triggered by its probes.

Corrective maintenance is reactive: it fixes defects discovered in a production system. It is triggered by failure and carries urgency.

Preventive maintenance is proactive: it improves the system before problems occur — refactoring, updating dependencies, improving tests, resolving technical debt. It is triggered by professional judgement, not immediate failure.

Why preventive maintenance is underprioritised: it has no visible immediate cost of neglect. A failing system demands attention; a healthy system with accumulating technical debt does not. Product stakeholders who control the backlog prioritise user-visible features (perfective maintenance) and urgent defects (corrective maintenance) over improvements whose benefit is the absence of future problems. The cost of this prioritisation is paid later, in accelerating maintenance effort and eventual legacy system crises. Organisations that budget sprint capacity explicitly for preventive maintenance — treating it as a first-class cost category — consistently avoid the crisis pattern.

Monitoring is the practice of watching known, predefined signals: dashboards of specific metrics (CPU, error rate), alerts triggered by threshold breaches. It answers the question: "Is this specific thing wrong?"

Observability is a system property: the degree to which the internal state of a system can be inferred from its external outputs (logs, metrics, traces). An observable system allows engineers to answer questions they did not anticipate when they set up monitoring: "Why is this specific user's request slow?" or "What was the state of the database connection pool at the moment this error occurred?"

Monitoring is necessary but not sufficient for production operations. A system can be heavily monitored but poorly observable — you know something is wrong (alert fires) but cannot determine what or why (no traces, unstructured logs). Observability supports diagnosis; monitoring supports alerting. Both are required.

Coupling measures the degree of interdependence between modules. High coupling means changes to one module require changes to others; the system is fragile. Low coupling means modules can change independently; the system is maintainable.

Cohesion measures how strongly related the responsibilities within a single module are. High cohesion means a module does one thing well; it is understandable and testable. Low cohesion (a "God class" or utility module) means a module has unrelated responsibilities; it is difficult to test in isolation and attracts further unrelated additions.

The design goal is high cohesion and low coupling. These properties are related: modules with high cohesion have clear, bounded interfaces, which naturally reduces coupling to other modules. Both are measurable — coupling through dependency analysis tools, cohesion through LCOM (Lack of Cohesion in Methods) metrics.

A security requirement specifies what the system must do (or not do) with respect to security, at a level that is technology-independent and testable: "All data in transit between client and server shall be encrypted using TLS 1.3 or later." It belongs in the requirements specification and RTM.

A security control is the implementation mechanism that satisfies the requirement: TLS certificate configuration, enforced HTTPS redirects, HSTS headers. It belongs in the design and implementation documentation.

The distinction matters because: (1) requirements must be defined before controls are selected — choosing a control before the requirement is understood risks solving the wrong problem; (2) multiple controls may satisfy the same requirement — the requirement creates the test, and the control must pass it; (3) security audits test compliance with requirements, not the presence of specific controls.