3.3.1 - Formative project skills: iterative development evidence

An iteration connects a goal, evidence and a decision

Iterative development builds and refines a solution through repeated cycles. Appropriate agile principles include manageable increments, frequent checks and feedback that can change the next priority. They do not require a particular commercial meeting schedule, and they do not remove planning or documentation.

Begin a cycle with a requirement or uncertainty: what behaviour should this version establish? Design the relevant change before writing it, implement a bounded part, check it and review the evidence. Then justify the next decision. A development journal preserves this sequence while it happens: version/date, intended behaviour, design choice, implemented change, actual results and the next action. Design evidence can recur at the start of each iteration rather than appearing only once before the whole project.

For a formative lending prototype, the rule is “an item is overdue only after its due day”. An early comparison using today >= due_day makes an item due today overdue. A due-today test reveals the discrepancy. A justified next decision is to use a strict comparison and retain the due-today check, then investigate whether the normal before/after cases still work. “Changed a symbol” describes the edit; linking it to the inclusive-boundary failure explains why it was needed.

Development is not always a defect fix. A user may find that an error message does not tell them which field needs correction, leading to a revised message. Record the actual feedback, the need it reveals, the alternatives considered and why the chosen change fits. A pleasing screen does not establish that the underlying rule or saved data is correct.

A prototype investigates a defined part of the solution

A prototype is an early version built to investigate behaviour, interaction or feasibility. State what it includes and excludes. A prototype checking one overdue rule is not a finished lending system, and success on that rule cannot show that a GUI, persistence or notification delivery works.

The original practice prototype below uses non-negative integer day numbers. Due today is not overdue. It deliberately covers only that rule and invalid day-number rejection; no GUI, storage or message sending is implemented.

def is_overdue(due_day, today):
    """Due today is not overdue; use non-negative integer day numbers."""
    if type(due_day) is not int or type(today) is not int:
        raise ValueError("Day numbers must be non-negative integers")
    if due_day < 0 or today < 0:
        raise ValueError("Day numbers must be non-negative integers")
    return today > due_day

This is a static teaching example. It can be practised in a suitable local Python environment; it is not an assessed source-writing task. The type checks deliberately reject strings, fractional values and Booleans as day numbers. These input choices belong to this miniature contract, not every possible date-handling design.

The reference versions were checked on the following inputs. Version 1 had the same validation but used today >= due_day; version 2 uses the strict comparison shown above.

An annotated evidence item identifies the version, starting/input values, observed result and its meaning for the requirement. For the middle row, “Version 1 returned True for due 8/today 8, contradicting the due-today rule; version 2 returned False after the strict-comparison change” is useful annotation. A screenshot without input/version information may be impossible to interpret. Preserve the failed version and result; an attractive final screenshot cannot reconstruct earlier development.

Screenshots, selected source excerpts, test output and genuine feedback serve different purposes. A code excerpt shows an implemented change; observed output shows the checked behaviour. Neither alone proves a complete project. Keep the relevant evidence together through references rather than adding many unexplained pictures.