Key vocabulary

Evaluating a finished program

Why evaluation is its own separate stage

A program that has passed every test in its test plan (SDD16) and has had its bugs found and fixed through debugging (SDD17) is working — but "working" and "good" are not automatically the same thing. Evaluation is the final stage of the analysis→design→implementation→testing→evaluation cycle, and asks a broader question than testing does: not just "does this specific test case pass," but "is this a genuinely well-built program overall?" Higher recognises five distinct, named criteria for answering that question.

Fitness for purpose

Fitness for purpose asks whether the program actually does what it was designed to do, judged directly against the functional requirements identified back in SDD2's analysis stage. This is the most fundamental criterion — a program can be efficient, easy to use, and robust, and still fail this criterion entirely if it simply doesn't do what was originally asked of it.

Efficient use of coding constructs

This criterion asks whether the program uses appropriate, economical language features to solve its problem, rather than unnecessarily wasteful or convoluted alternatives. Using a fully appropriate standard algorithm (SDD13–15) where one exists, rather than reinventing something more complicated, is a direct example of this criterion in practice.

Usability

Usability asks whether the program is easy for its intended end-user — not the programmer — to actually use: clear prompts, sensible input handling, and understandable output and feedback all contribute to this. A program can be perfectly correct internally and still score poorly here if a real user would find it confusing or unclear to interact with.

Maintainability

Maintainability asks whether the code itself is easy for a programmer — possibly not the original author, and possibly the same programmer returning to it much later — to read, understand, and safely change. Meaningful variable and function names, sensible use of comments, and a clear modular structure (SDD7's functions and procedures) all directly support this criterion.

Robustness

Robustness asks whether the program continues to behave sensibly when faced with unexpected, invalid, or edge-case situations, rather than crashing outright. This connects directly back to SDD16's erroneous test data and SDD15's edge-case discussion (an empty array, a boundary value) — a robust program anticipates these situations rather than being caught out by them.

Worked examples

def findMinimum(array):
    smallest = array[0]
    for i in range(1, len(array)):
        if array[i] < smallest:
            smallest = array[i]
    return smallest

def findMinimumInefficient(array):
    sortedArray = sorted(array)
    return sortedArray[0]

def f(r):
    print(r.n)
    print(r.p)
    print(r.s)

# Prints a tuck shop item's
# details clearly for the end-user
def printItemDetails(item):
    print("Name:", item.name)
    print("Price:", item.price, "p")
    print("Stock:", item.stock)

Task Set A — Core questions

Task Set B — Extension