Capstone & Resources · Study deck
Capstone Projects: Planning and Evidence
A strong capstone begins with one testable decision, not a pile of devices.
Test Tessa is your guide for this deck.
After studying this chapter
Learning objectives
A capstone connects a bounded user decision with evidence another person can review.
- A capstone needs a measurable question before extra sensors or services.The smart plant pot can start with whether the soil needs water, giving the team a decision that its first build must support.
- A complete path connects the physical event to a visible result.The reviewer must be able to follow sensing, firmware, network delivery, storage, display, and the resulting response.
- Requirements need acceptance tests, owners, and supporting artifacts.A calibration note, payload sample, query, or screenshot can show how a particular requirement was tested.
- Failures and later changes can require fresh evidence.A sensor library, modem firmware, dashboard query, or enclosure change can invalidate the earlier demonstration of the same project claim.
Major section
In 60 Seconds
The first build should prove one useful decision across the complete system.
- The plant-pot project can start with a soil-watering decision.The team’s proposed sensors, app, and pump need to support one useful choice rather than remain separate demonstrations.
- The plan must state constraints and the safe pump state.User, allowed error, response time, budget, and date are part of the bounded claim that the first build needs to prove.
- Each handoff needs an owner and observable evidence.The path from sense to read, send, store, show, and respond must remain traceable through the components.
- Optional features must wait for the core path’s failure tests.Loose wiring, weak power, lost contact, full storage, a wrong user, a stuck pump, and restart are concrete tests in the chapter.
Major section
Start With One Useful Decision
This opening scene puts the operator’s decision before the unopened hardware; start with the written choice.
- The written decision gives each proposed feature a purpose.A room monitor can support ventilation, while an irrigation prototype can support watering; the user outcome helps define the project boundary.
- Parts selection must follow the intended user outcome.The unopened boxes in the chapter’s story show why choosing sensors or cloud services should wait until the useful decision is clear.
- Ventilation, watering, and route decisions are bounded claims to test.The team can choose the observation and measurable result needed for its particular user instead of treating every feature as equally important.
- The next milestone needs a complete evidence path.A reviewer must be able to follow the physical event to the screen and understand one relevant failure response.
Major section
Project Briefs Become Reviewable Claims
Each project family needs a claim that can be tested through concrete artifacts.
- An environment monitor must make indoor conditions visible to its user.Facility staff need evidence that can support a ventilation decision rather than a dashboard disconnected from the physical observation.
- An agriculture system must connect soil evidence to watering.The project needs the observation, actuator decision, safety interlock, and watering record to establish its useful loop.
- A tracker must preserve useful location evidence across system constraints.Power, cellular delivery, and backend behaviour can affect whether the operator sees a current route or a stale location.
- Each requirement needs an owner, test, and stated limit.An acceptance criterion can make readiness reviewable and keep the team from optimizing features without proving the intended behaviour.
Major section
The user decision gives features a purpose
The user’s decision determines which evidence deserves priority.
- Facility staff need evidence for deciding when to ventilate.Indoor observations are useful when the monitor makes the relevant conditions visible for the room’s operational decision.
- A grower needs soil evidence for deciding when a zone needs water.The agriculture claim must connect the physical reading with the watering decision and a safe response.
- A fleet operator needs location and freshness evidence.A geofence or route decision can be misleading when a displayed location is stale or rests on a different coordinate assumption.
- Features need to support the chosen decision within project constraints.Budget, hardware, schedule, team size, and experience can limit which additions are justified in the final build.
Major section
Parts, delivery, and build constraints
Component and service choices affect the proof as well as the parts list.
- The board choice changes firmware, power, and integration work.ESP32 and Raspberry Pi Pico W can reduce cost, but the chapter still requires careful firmware and power decisions.
- Sensor and modem choices change wiring and field risk.BME280, SCD40, GPS, LoRa, and cellular modules can differ in interfaces, library maturity, current draw, and installation demands.
- Delivery and storage choices need their own recovery evidence.MQTT QoS 1, local buffering, InfluxDB, or Supabase choices must be tested as behaviour rather than decorative architecture labels.
- A bill of materials needs substitutes and lead times.The build can stall when an unavailable or incompatible part has no alternative that fits the project schedule and budget.
Major section
Keep The Thin Slice Alive
A thin vertical slice proves the whole route with the smallest useful set of components.
- An environment monitor needs one complete sensor-to-alert path.One reading, firmware loop, transport, stored row, dashboard value, and alert rule are the chapter’s protected first milestone.
- An agriculture prototype needs a watering record and safety interlock.The soil reading and actuator decision must form a useful local loop, with a defined safe response when the normal path fails.
- A tracker needs a complete GPS-to-route-state path.The fix, cellular publish, backend insert, and geofence calculation must connect to the operator’s visible result.
- The complete path makes integration problems visible early.Optional features can wait while the team repairs disagreements that only appear when the separate components are connected.
Activity 1 · Draw it
✎ Prove one watering decision
I want you to show the complete proof before you add another feature.
Sketch the smallest agriculture path on paper: soil reading, actuator decision, safety interlock, and watering record. Mark a local safe state for the pump. Choose one failure from the chapter and show where its evidence would appear.
4 minutes · Pen and paper · Answer: Activity 1
Major section
The project ledger and measured claims
The project ledger preserves evidence during the build instead of reconstructing it at the end.
- Each requirement needs a component, version, test, and artifact record.The project ledger can link a firmware commit to a serial log, broker trace, database query, or dashboard screenshot.
- A recorded result supports a decision and a retest trigger.Another team member must be able to identify which later change could invalidate the evidence behind the accepted claim.
- A reliability target needs run conditions and a definition of success.The chapter’s > 99% transmission target needs a run length, environment, and retry policy before the number is meaningful evidence.
- The report must distinguish measured, designed, and out-of-scope behaviour.A test log or screenshot can support an unshown feature, but the report cannot turn an unmeasured intention into an observed result.
Major section
Integration Evidence Has Interfaces
Working components can still disagree at the boundaries between them.
- A correct reading can become misleading through wrong payload units.Sensor accuracy is insufficient when the data contract changes the meaning of the physical observation during transmission.
- A successful publish can be absent from the dashboard query.The broker topic must agree with the query, otherwise a working firmware publish cannot establish a visible result.
- A stored row can use the wrong time basis.Device-local time instead of UTC can make later interpretation unreliable even though the database successfully stored the record.
- An alert demonstration still needs a defined stale-data response.A successful alarm during the happy path cannot establish what happens when the dashboard stops receiving fresh observations.
Major section
The device-to-firmware contract
The device-to-firmware contract preserves the meaning and timing of the physical observation.
- Pinout and bus speed define how firmware reaches the sensor.The device-to-firmware contract needs the physical interface to match the code before the returned observation can be trusted.
- Calibration and units determine the reading’s meaning.A sensor can produce a value while the downstream application misinterprets its scale or uses the wrong unit.
- Timing and warm-up behaviour determine when a reading is usable.Error codes also need interpretation so startup or failed measurements cannot silently become normal application data.
- Fault injection can test the next component’s handling of invalid readings.Unplugging a sensor makes the interface failure observable and gives the reviewer evidence for the prototype’s actual response.
Major section
Contracts from firmware to dashboard
Transport and application contracts carry the evidence beyond the device.
- The firmware-to-network contract needs names, schemas, retries, and buffer limits.QoS and duplicate handling must also be explicit so the receiving system can interpret repeated or delayed messages correctly.
- The network-to-cloud boundary needs identity, authorization, and retention rules.Transport protection, idempotency, and schema version are part of the evidence that the cloud keeps the intended message meaning.
- The dashboard contract needs freshness labels and alert ownership.Missing-data states and permissions must be visible so a stored row cannot appear to support an unsupported operational decision.
- Every boundary needs evidence beyond successful delivery.A publish or stored row can succeed while units, timestamps, permissions, or application interpretation are still wrong.
Major section
Measurement units, faults, and retest triggers
A measurement needs a stated unit of observation and an honest failure boundary.
- Latency evidence must identify what event was measured.A packet, batch, geofence event, watering cycle, or dashboard refresh is a different unit of observation for the reported result.
- Power evidence must separate warm-up, processing, radio, sleep, and recovery.An attractive battery estimate can change when sensor warm-up, receive activity, or fault recovery is included in the budget.
- Different injected faults test different interface contracts.A duplicate message, denied dashboard permission, broker restart, or unplugged sensor can expose a different unsupported assumption.
- A retest trigger identifies changes that can invalidate the result.New libraries, modem firmware, antenna placement, dashboard queries, retention policies, or enclosures may require another acceptance run.
Activity 2 · Predict
✎ The dashboard stops getting fresh data
I want you to name the broken boundary and the proof of its response.
The sensor still reads correctly, but the broker restarts and the dashboard value stops updating. On paper, predict which evidence you would inspect across firmware, network, storage, and dashboard. State how stale data should remain distinguishable from fresh data.
3 minutes · Pen and paper · Answer: Activity 2
Major section
The sensor-to-dashboard evidence journey
This journey shows the sensor-to-dashboard path; follow the raw reading through formatting, delivery, and display.
- The sensor supplies the raw observation at the journey’s start.The diagram begins with the physical reading, which must remain traceable through every later interface to the reviewer’s screen.
- MCU formatting must preserve units and time before radio delivery.The next arrows carry the formatted observation through radio and gateway, where retries or identity changes can alter its evidence.
- The cloud path must preserve identity and meaning during storage.The same observation needs to survive retries and backend handling so the stored row can support the original project claim.
- The dashboard update needs freshness that matches the underlying observation.A visible number cannot complete the proof when its timestamp or meaning no longer agrees with the sensor evidence.
Major section
Installation and recovery are integration work
Integration time covers physical installation as well as software connections.
- Real hardware behaviour can depend on wiring and installation details.Pull-ups, level shifting, enclosure airflow, and sensor warm-up are integration work rather than cleanup after the software demonstration.
- Firmware may need watchdog recovery and persistent configuration.A restart can expose missing recovery behaviour even when the sensor loop worked during the initial bench test.
- Dashboards need distinct missing, stale, out-of-range, and permission-suppressed states.Those conditions can look like ordinary values unless the application makes each relevant limitation visible to the user.
- The demonstration must identify real values and unresolved limitations.The reviewer needs to distinguish measured behaviour from planned behaviour and claims that remain outside the project scope.
Major section
One observation across the whole system
The acceptance run must connect the sensor observation to the exact stored and displayed result.
- The timestamp, topic, schema, row, and freshness label must agree.A BME280 or SCD40 bench reading is not an integrated result until the complete stored and displayed observation is consistent.
- The networked event includes behaviour beyond the local reading.Headers, retries, brokers, storage, and rendering can make a small sensor value larger, delayed, and vulnerable to additional failures.
- Network tests can reveal coverage, certificate, session, or duplicate-message problems.A Wi-Fi node that publishes in the lab may still fail in its installed room when radio conditions are weak.
- OTA rollback and watchdog recovery need evidence when the project relies on them.A named mechanism in the architecture cannot establish its actual failure response without an observed test or supporting artifact.
Major section
The repeatable acceptance packet
A repeatable final packet preserves both the tested build and the limits of its evidence.
- The acceptance record needs the requirement, build, calibration, and result.Hardware revision and firmware version are necessary so another reviewer can identify the exact configuration that produced the evidence.
- Payloads, topics, queries, and screenshots let a reviewer follow one case.The acceptance packet must connect the raw observation to the exact stored row, displayed value, and pass/fail decision.
- Power measurements must include warm-up and retransmissions.Regulator quiescent current and recovery states can weaken a battery estimate that looked convincing when only normal activity was counted.
- The engineering handoff needs recovery plans, risks, and retest triggers.Credential rotation and factory-reset behaviour need evidence when the design depends on them for a usable recovery path.
Deck summary
Key takeaways
A completed capstone leaves a repeatable engineering claim and the evidence supporting it.
- The user decision gives the project a cut line for features.Optional additions can be removed without breaking the core demonstration when the team has protected the required sensor-to-decision path.
- One complete path reveals interface problems while repairs are still possible.The team can discover mismatched units, timestamps, topics, or queries before optional features consume the remaining integration schedule.
- Failure tests show what happens when normal assumptions break.Loose wiring, lost contact, low power, wrong users, and a stuck pump are concrete ways to test the plant-pot evidence path.
- A maintained ledger connects the report to artifacts and remaining limits.The final handoff needs the measured result, unresolved risks, and changes that would require fresh evidence before the system is trusted again.
Retrieval practice
Recall check 1 of 2
Test Tessa says: answer from memory, then check your reasoning.
Q1A capstone environment monitor promises useful room-condition alerts. What should accompany that requirement?
Show answer
Answer: C The brief calls for calibration, payload, stored state, alerts, and other review evidence.
Retrieval practice
Recall check 2 of 2
Test Tessa says: answer from memory, then check your reasoning.
Q2A fleet-tracker capstone is growing in scope before its first route works. What should the team preserve?
Show answer
Answer: B The chapter protects a small complete vertical slice before expanding.
Print reference
Answers
Answer key.
- C · The brief calls for calibration, payload, stored state, alerts, and other review evidence.
- B · The chapter protects a small complete vertical slice before expanding.
Print reference
Activity 1 answer
Model answer.
Draw it: The sketch connects soil evidence to the watering decision, passes action through a local safety interlock, and records the watering result. The pump has a local safe state. An empty-tank flag or stuck-pump test should expose the failed boundary and its observed response.
Print reference
Activity 2 answer
Model answer.
Predict: Inspect publish and retry logs, local buffering, broker delivery, stored timestamps, and dashboard freshness labels. The old displayed value must be identifiable as stale. Record the observed reconnect and recovery result without claiming unmeasured delivery or timing guarantees.