EC-15.3 Capstone II: Build, Test and Evidence

What this is and why it exists

The second stage is where the method of the design module is either applied or regretted.

Most of what a reader needs here has already been said in the laboratory and design topics. This stage is about doing it under time pressure, which is a different skill.

The most valuable section is the one on cutting scope. Every real project reaches that point, and students are rarely told that doing it deliberately is normal engineering rather than a failure.

The vocabulary

• Incremental build — assembling and testing one subsystem at a time.
• Verification plan — the table of requirements, tests and evidence from the first stage.
• Version control — a record of every state a project has been in, that can be returned to.
• Minimum demonstrable result — the smallest outcome that would still be a success.
• Feature freeze — a date after which nothing new is started.

The mental model

Build in the order the first stage planned, riskiest first, subsystem by subsystem, testing as each arrives.

That order exists to keep faults separable, and abandoning it under pressure is exactly what makes a final fortnight chaotic. When everything is connected at once, every fault masks the others. That is the argument the integration topic made, and a close deadline does not suspend it.

Testing runs against the verification plan rather than against hope. Each requirement has a test and each test has a result.

Running them as the build progresses spreads the work over weeks. More importantly, a fundamental failure is discovered in week five rather than week eleven. A project that defers all its testing has also deferred all of its bad news.

Evidence is collected while it is in front of you. Captures, measurements, photographs, and the settings that produced them.

Reconstructing evidence afterwards costs more time than collecting it did, and produces something weaker. The setup has been dismantled and the conditions are a reconstruction. Ten minutes a session is the whole cost.

Version control covers everything, not only code. Schematics, board files, firmware, test scripts and the report itself.

Being able to return to last week's working state is worth more in the final month than any other single practice. The characteristic disaster of a capstone's last fortnight is a change that broke something, made on top of four other changes, with no way back.

Now the part that matters most. Decide what the minimum demonstrable result is, and decide the date after which nothing new will be started.

Both decisions should be made early, when they are calm, rather than in the final week when they are made badly. A planned reduction demonstrated fully beats an ambitious plan demonstrated partly, on every assessment criterion and in every professional setting.

Cutting scope on purpose is a normal engineering act. Cutting it by accident, by running out of time with three things half finished, is the failure.

Finally, reserve the last fortnight for integration, the report and rehearsal. No new work.

Projects still adding features in the last week are the ones that demonstrate badly. Nothing has been tested together and nobody has practised showing it. The report also takes longer than everyone expects, and writing it while the equipment is still assembled is far easier than writing it afterwards.

What you should now be able to explain or do

• Build and integrate in the planned order, and say why pressure is not a reason to abandon it.
• Run the verification plan continuously rather than at the end.
• Collect evidence during the work rather than reconstructing it later.
• Keep everything under version control and explain what that protects.
• Decide a minimum demonstrable result and a feature freeze date in advance.
• Reserve the final fortnight for integration, the report and rehearsal.

Check yourself