The evaluation stage is the final stage of the Software Development Life Cycle. Having built and tested a system, developers and clients assess how well it meets the original goals. Evaluation answers the question: how good is the solution?
A thorough evaluation considers four key criteria:
Does the system do what it was designed to do? Does it meet all functional requirements? Would users and clients consider it suitable for its intended use?
How well does the system use resources — time (speed of execution) and memory (RAM and storage)? An efficient solution minimises resource usage without sacrificing correctness.
How easy is it to understand, modify, and update the code in future? Is it well-structured, documented, and modular? Poor maintainability leads to technical debt.
What features or optimisations could be added in later versions? What limitations were identified? Evaluation drives the next iteration of development.
A system is fit for purpose if it correctly meets all the requirements gathered during the analysis stage. During evaluation, developers compare the completed system against the original specification:
| Requirement | Specification | Status | Notes |
|---|---|---|---|
| Login system | Users can log in with username and password | MET | Works correctly for all test cases |
| Response time | Pages must load in under 2 seconds | PARTIAL | Average 1.8s but peaks at 4s under load |
| Report generation | Export reports as PDF | MET | All report types export successfully |
| Mobile support | Must work on mobile devices | NOT MET | Layout breaks on screens under 480px wide |
If a requirement is not met, the evaluation must identify this clearly. The client decides whether to accept the system as-is, request rework, or defer the unmet requirement to a future version.
Feedback from end users is a key source of evidence for evaluating fitness for purpose. User testing, surveys, and interviews after delivery can reveal issues not identified during development.
An efficient program achieves correct results while minimising the resources it consumes. Two key dimensions:
| Dimension | What it measures | Why it matters |
|---|---|---|
| Time efficiency | How fast the algorithm runs — how execution time scales with input size | Slow programs frustrate users and may be unusable at scale (e.g. a search that takes 10 seconds) |
| Space efficiency | How much memory (RAM or storage) the program uses | Programs using excessive memory may crash on limited-resource devices or be undeployable |
Evaluation may include performance testing results: measuring how the program performs under expected and peak loads. Inefficiencies discovered at this stage are candidates for future improvements.
Maintainability describes how easily the code can be understood, modified, and extended in the future. Software is maintained throughout its lifetime: bugs are fixed, features added, security patches applied. Code that is difficult to maintain leads to technical debt — accumulated shortcuts that make future changes increasingly costly and risky.
Factors that improve maintainability:
| Factor | Good practice | Poor practice (low maintainability) |
|---|---|---|
| Naming | calculateMonthlyInterest() | calc1(), x, tmp |
| Comments | Explaining why — "// Check for leap year before calculating February days" | No comments, or comments restating obvious code |
| Modular structure | Small, single-purpose functions; low coupling between modules | Long monolithic functions that do everything |
| Indentation | Consistent indentation showing code structure clearly | Inconsistent or missing indentation |
| Documentation | External documentation explaining how modules work and how to extend them | No documentation; only the original developer understands the code |
In practice, the four evaluation criteria sometimes conflict. Developers must make informed trade-offs:
Can be very fast but uses complex techniques (e.g. bitwise operations, manual memory management) that are hard to understand and modify.
Easier to maintain and extend, but may run slightly slower. Often the better choice unless performance is critical.
A fully specified system with every feature implemented — but it takes longer to build, costing more time and money.
A working system with the most important features delivered quickly. Less-critical features deferred to future versions.
No software is perfect. Evaluation identifies what was not fully achieved and what users wish was different. A good evaluation explicitly lists potential future improvements — features to add, performance optimisations, usability enhancements, or security hardening. These become the starting requirements for the next iteration of development, closing the SDLC loop.
8 questions · 21 marks
def c(x, y): return x * y / 100. Describe two ways this code could be made more maintainable.[2]calculateDiscountAmount(price, discountPercent) makes the purpose immediately clear [1]; Use meaningful parameter names — replace x and y with price and discountPercent so future developers know what values to pass [1]; Add a comment explaining what the function does, what its parameters represent, and what it returns [1].| Term | Definition |
|---|
Timed exam conditions.