Last updated: 2026-10-06

U
Undergraduate level

Designing, Prototyping, and Delivering the Artefact

Many projects produce an artefact: a system, a tool, a model, a piece of hardware, or a prototype that demonstrates an idea. The artefact is the part that can be seen working, and it is tempting to put most of the effort into it. The rest of the project depends on it being built in a way that can be tested, explained, and handed over. A project whose artefact cannot be run by someone other than its author has not yet been delivered.handover means anyone can run it

This page covers the stages from a first design through to a handover: designing for the question rather than for features, prototyping to reduce risk early, working in a development workflow that keeps the artefact in a known state, and testing and documenting it. Testing is covered in more depth in the software engineering pages linked below, so this page focuses on how those ideas apply to a project.

Design for the Question

A design is a set of decisions about structure, interfaces, and data, made in service of the question the project asks. It is easy to design for features, which are visible, and forget the question, which is the reason the artefact exists. Before the design is fixed, check it against the success criteria from Scope, Feasibility, and Defining Success. Each criterion should be measurable through a part of the design. If a major part of the design serves no criterion, ask whether it belongs in the project at all.if a criterion lacks a design witness

Architecture is a useful way to think about the big decisions. The main styles and their trade-offs are described in Software Architecture Styles. For a student project, the most useful rule is to choose the simplest structure that lets you test the question. A layered or modular design often does this with less overhead than a distributed one.

Prototype Early to Reduce Risk

A prototype is a rough version built to answer a specific question. It may be a script that loads the data, a screen that a participant can try, or a single algorithm run on a small case. The purpose is to find out whether the approach is feasible before much effort goes into it. A prototype that answers no question has been built for its own sake.

Write the question before the prototype. For example: "Can the parser handle the full set of input formats in under a second?" The prototype is finished when the question is answered, whether the answer is yes or no.

Prototypes feed the risk register. A prototype that fails early is the cheapest way to discover a risk, and the outcome should be recorded as described in Risk Analysis for a Project.log the failure, not just the fix

A Development Workflow You Can Return To

The workflow is the routine that keeps the artefact in a known state: how changes are made, how they are checked, and how the current version is recorded. For most projects it needs four things:link each commit to an issue for traceability

  • version control with commits small enough to describe in a sentence,
  • a way to run the tests with a single command,
  • a record of which versions of the data and the software produced each reported result,
  • and a rule that the main branch always runs.

Continuous integration is one way to enforce the last two, by running the tests on every change. The principle is described in CI/CD. A simpler project may achieve the same effect with a script and a habit of running it before each commit.

Test-driven and behaviour-driven approaches shape this workflow in a more specific way, by writing the expected behaviour before the code. The mechanics are in TDD and BDD, and the way behaviour-driven scenarios can serve as requirements is discussed in BDD as Specification.

Testing

Testing shows whether the artefact behaves as specified. It does not show whether the specification was the right one, which is the question that evaluation addresses. Keep the two apart in the report. A system that passes every test may still fail to answer the project's question.evaluation validates the spec itself

The main kinds of test, and the trade-offs between them, are covered in Types of Testing and Testing Fundamentals. Two practical points for a project. First, test the parts that carry the claims in the report most thoroughly. Second, when a test is hard to write because the code depends on something external, a test double can isolate the part under test; see Test Doubles, Mocks, Stubs, and Fakes.

When a test passes but the result looks wrong, the problem is often in the test. Mutation testing checks whether the tests would detect a deliberate fault, which is a useful way to test the tests; see Mutation Testing.

Documentation

Documentation has three audiences: a future version of you, a marker, and someone who needs to run the artefact. Each needs something different. The future version needs the decisions and their reasons. The marker needs to see how the artefact supports the claims. The person running it needs a setup that works from a clean machine. A single README that covers all three is possible but rarely clear, so a short README for running, and a separate design note for decisions, is usually better.

Write the setup instructions by following them on a clean environment, not from memory. Most projects that cannot be run by anyone else fail at this step.

Handover

A delivered artefact has a version, a set of instructions, a record of the tests that were run, and a list of known limitations. Before handover, run the setup from the instructions, run the test command, and confirm that the reported results can be reproduced from the recorded versions. If any of these fail, the artefact is not yet delivered.