Stage 5 – Implementation / Construction

Capstone Design

Imron Rosyadi

Stage 5 – Implementation / Construction

Capstone Design Course – From Needs to Validated Systems using the V‑Model & ISO/IEC/IEEE 29148

Focus of this session: Stage 5 – Implementation / Construction

DCP‑400 – Implementation Package

This deck is for a dedicated session on Stage 5 of the capstone. Students have already seen the overall course framework and V‑Model; here we zoom in on Implementation / Construction and the role of 29148/15288 and configuration management (CM).

Key goals for you as the instructor: - Connect “hands‑on building” to the formal lifecycle: implementation is not “just coding and soldering”; it is a controlled transformation of design into verified build artifacts, governed by 15288 processes and by the requirements from 29148. - Emphasize configuration management as the glue that keeps the project coherent while reality forces changes. - Use concrete ECE examples (embedded system, FPGA, mixed‑signal board, IoT lab network) so students see themselves in the scenarios.

Session Learning Objectives

By the end of this session, you will be able to:

1. Explain how ISO/IEC/IEEE 15288 and 29148 define and constrain the Implementation process.
2. Describe what configuration management (CM) means in a capstone project and why it matters during implementation.
3. Identify the main activities of Stage 5 (Implementation / Construction) and relate them to the V‑Model and earlier stages.
4. List the key deliverables of Stage 5, including what goes into DCP‑400 Implementation and how IMP-* items appear in the RTM.
5. Apply these ideas to typical ECE capstone projects (e.g., embedded controller, RF or mixed‑signal board, FPGA/DSP design, IoT system).

You can use these as checkpoints: - After coverage of standards: ask students to restate in their own words what implementation is (per 15288) vs “just coding”. - After CM discussion: ask for recent personal horror stories where they “lost work”, broke a build, or forgot which version worked.

Where Are We in the V‑Model?

Note

Stage 5 is the bottom of the V: You turn design descriptions into working hardware, firmware, and software.

Remind students how we got here: - Stages 1–3: defined the right problem and specified the system (StRS, SyRS). - Stage 4: decided how we will realize it (architecture, components, interfaces). Now Stage 5: we build those components, but still within the discipline of the lifecycle.

Stress that Implementation is not isolated: everything we build must trace back up to CMP-*, REQ-*, and STR-*, and forward into TST-*, VER-*, VAL-*.

Standards View: 15288 & 29148 at Stage 5

ISO/IEC/IEEE 15288 – System Life Cycle Processes

Relevant processes for Stage 5:

• Implementation Process
  • Transform system element specifications into realized system elements (code, boards, FPGA bitstreams, etc.).
  • Confirm that each implementation corresponds to its design description.
• Configuration Management Process
  • Establish and control configuration items (CIs).
  • Manage baselines, versions, and changes.
  • Ensure the correct items are used in integration, test, and deployment.

ISO/IEC/IEEE 29148 – Requirements Engineering

• Still relevant in Stage 5 because:
  • Requirements guide what to implement.
  • Requirement changes must be controlled (change requests, impact analysis).
  • Implementation status is recorded in the RTM as REQ-* → CMP-* → IMP-*.

Explain that 15288 gives the process scaffolding (Implementation & CM), while 29148 keeps us honest about why we’re building each thing (requirements).

You don’t need students to recite clause numbers; instead, keep it conceptual: - Implementation is a disciplined transformation from specs to reality. - Configuration management makes that transformation reproducible and controllable.

Stage 5 in the Course Framework

Course Stage:

• Stage 5 – Implementation / Construction

V‑Model Level:

• Bottom: HW/SW Build

Inputs from earlier stages:

• Approved StRS and SyRS/SRS (STR-*, REQ-*).
• Approved Design (DCP‑300) with CMP-* components and interface specs.
• Initial Test Plan (TST-* planned).

Outputs to later stages:

• Realized implementations (IMP-*):
  • Source code, HDL, schematics, PCBs, 3D models, configs, scripts.
• Build & configuration documentation.
• Updated RTM:
  • CMP-* → IMP-* links.
• DCP‑400 – Implementation package.

Important

You should not be inventing major new requirements or architecture in Stage 5. If you must, it goes through change control.

Use the “no surprise architecture” rule: if someone opens DCP‑300 and DCP‑400, they should recognize that DCP‑400 is just the realization of what DCP‑300 promised, modulo logged changes.

You can ask: > If you discover a better sensor or new algorithm at Stage 5, what do you do? Answer: evaluate impact, propose a change, update requirements/design formally, then implement—not just silently swap.

What Is “Implementation” in 15288 Terms?

ISO/IEC/IEEE 15288 – Implementation Process (informal summary):

1. Prepare for Implementation
   • Confirm design is implementable with available tools, parts, skills.
   • Set up repositories, build environments, toolchains, labs.
2. Perform Implementation
   • Develop and assemble system elements per design.
   • Follow coding standards, EDA rules, lab safety procedures.
3. Confirm Implementation
   • Check each built element against its design description.
   • Ensure the implementation is ready for verification (Stage 6).

Note

In capstone terms: Implementation is “build what you designed, in a reproducible way, and prove you’re ready to test.”

Make a distinction: - Unit tests and bring‑up in Stage 5 might be informal quick checks. - Formal Verification activities belong to Stages 6 and 7.

15288 expects that by the end of Implementation, you have: - Buildable configurations. - Baselines. - Items that can be passed to Verification with a clear bill of materials and build procedures.

What Is Configuration Management (CM)?

Configuration Management (from 15288 CM process):

• Identify the configuration items (CIs) that make up your system.
• Define baselines: snapshots of CIs at key milestones (e.g., end of Stage 4, Stage 5 TRR).
• Control changes:
  • Propose → evaluate → approve/reject → implement → record.
• Maintain status accounting: who changed what, when, and why.
• Audit: verify that delivered items match the documented configuration.

Warning

Without CM, you get: - “It works on my laptop.” - “Which version are we demoing?” - “We lost the only working firmware.”

Relate to students’ experience: - Broken group project because one teammate overwrote someone else’s code. - PCB rev that worked, followed by a “fixed” rev that doesn’t, because no one recorded the exact component values that worked.

Explicitly mention: - In industry, CM is central for safety, certification, and maintainability (e.g., in medical devices, aerospace, automotive).

CM in the Capstone Context

Typical Configuration Items (CIs) in ECE capstone:

• Software artifacts:
  • Source code, libraries, build scripts, Dockerfiles.
• Hardware artifacts:
  • Schematics, PCB layouts, BOM, mechanical CAD.
• Programmable logic:
  • HDL, constraint files, synthesis/project files, bitstreams.
• Configuration data:
  • Calibration tables, config files, lookup tables, FPGA register maps.
• Documentation:
  • DCP documents, test procedures, user manuals.

CM mechanisms you will use:

• Git repository (or equivalent):
  • Branches, tags, pull requests, commit history.
• Versioning schemes:
  • e.g., v0.9-proto, v1.0-TRR, PCB rev A/B/C.
• Change log / issue tracker:
  • Link issues to REQ-*, CMP-*, IMP-*.
• RTM updates:
  • Track which requirements are implemented by which IMP-* items.

Clarify expectations: - Every team should have one or more repos that collectively define the full system. - They should use branching and pull requests rather than committing to main blindly. - They should use tags for baselines (e.g., stage5-trr-baseline).

You can show a sample repo structure on the board or in a live demo.

Stage 5 Activities – Big Picture

Key activities in Stage 5:

1. Set up the implementation environment
   • Toolchains, IDEs, simulators, synthesis tools, PCB vendors, lab benches.
2. Implement components (IMP-*)
   • Coding firmware/applications/FPGA logic.
   • Building and assembling PCBs and hardware prototypes.
3. Perform internal checks
   • Smoke tests, static analysis, code review, bench bring‑up.
4. Manage configurations and changes
   • Use Git, track issues, maintain change logs.
   • Keep RTM synchronized with evolving implementation.
5. Prepare for Unit/System Verification
   • Ensure build is repeatable and documented.
   • Ensure component implementations match design (CMP-*).

Emphasize that this is iterative: - You implement a subset of components. - You do some internal tests. - You discover issues → maybe update design or even requirements through formal change control.

But from a process perspective, all this iteration still stays within Stage 5 until the team is formally ready to enter Stage 6 (Unit Verification).

DCP‑400 – Implementation Package (Overview)

Main artifact for Stage 5:

• DCP‑400 – Implementation

Typical contents:

1. Implementation Overview
   • Summary of what was implemented relative to DCP‑300.
2. Implementation Items List
   • Table of IMP-* items and links to CMP-*, REQ-*.
3. Build & Deployment Procedures
   • How to build, load, configure, and run the system.
4. Configuration Management Summary
   • Repository location, branches, tags.
   • List of baselines and CI identifiers.
5. Change Log
   • Approved changes to requirements and design that affected implementation.

Important

If someone gave you DCP‑300 and DCP‑400, you should be able to rebuild the project from scratch.

Make clear that DCP‑400 is not a giant code printout. Instead, it’s the index and explanation of the implementation and CM approach. Actual code, schematics, etc. live in repos and tool projects, referenced by DCP‑400.

Example: IMP-* Entries in the RTM

Traceability extension at Stage 5:

Previously:

• STR-* → REQ-* → CMP-*

Now we add:

• CMP-* → IMP-*

Example rows in RTM:

CMP ID	IMP ID	Description
CMP-SW-010	IMP-SW-010A	UI module (Flutter app)
CMP-SW-020	IMP-SW-020A	Control task (FreeRTOS C module)
CMP-SY-030	IMP-SY-030A	Sensor PCB rev B (KiCad project)
CMP-SY-040	IMP-SY-040A	LoRa gateway firmware (C++)

Tip

Use IDs in: - Commit messages - Issue tracker - Comments in code (// Implements REQ-SW-015 via CMP-SW-020)

Walk through a specific example: - REQ-SW-015: “System shall log all temperature readings to local storage with timestamp resolution of 1 s.” - Allocated to CMP-SW-020 (Data logger module). - Implementation: IMP-SW-020A (C++ class DataLogger, files logger.cpp/h).

Show how a commit message might look: - Implement IMP-SW-020A (DataLogger) for REQ-SW-015 This is exactly the kind of traceability 29148 and many regulated domains expect.

ECE Example 1 – Embedded Motor Controller

Project Scenario:

A BLDC motor controller for a small robot arm.

Earlier stages defined:

• REQ-SY-010: Motor speed shall be controllable from 0–3000 RPM with ±2% accuracy.
• CMP-SW-020: Motor control firmware module.
• CMP-SY-030: Power stage & gate driver PCB.

Stage 5 Implementation Tasks:

• Write firmware for:
  • PWM generation & current sensing.
  • PID speed controller (or FOC if advanced).
• Assemble power stage PCB, solder drivers and MOSFETs.
• Bring up current sensors and encoders.

Related IMP-* Items:

• IMP-SW-020A: motor_ctrl.c / motor_ctrl.h implementing speed loop.
• IMP-SW-020B: current_sense.c with ADC driver and calibration.
• IMP-SY-030A: Assembled PCB rev B with BOM v1.1.

Configuration Management:

• Git repo for firmware with tags:
  • v0.3-proto-pwm-only
  • v0.5-closed-loop
• PCB project with revision labels:
  • motor_board_revB, BOM file versioned.

You can ask students: - What happens if they re‑tune the PID gains directly on hardware and forget to update the repo or note in DCP‑400? This is a CM failure: the arm that “worked in the demo” is not reproducible.

Point out that even analog tweaks (e.g., adjusting a trimpot) should be documented as part of configuration.

ECE Example 2 – FPGA‑Based DSP Filter

Project Scenario:

FPGA card that performs real‑time FIR filtering on an audio stream.

Earlier stages defined:

• REQ-SY-020: The system shall implement a low‑pass FIR filter with 60 dB stop‑band attenuation at 8 kHz, fs = 48 kHz.
• CMP-HW-010: FPGA top‑level design.
• CMP-SW-030: Coefficients generator / control interface software.

Stage 5 Implementation Tasks:

• Write HDL modules:
  • fir_core, axi_stream_if, clk_gen.
• Generate filter coefficients with Python/MATLAB script.
• Synthesize and place‑and‑route for chosen FPGA.

IMP-* Items & CM:

• IMP-HW-010A: HDL sources in /hdl/fir_core/, Git repo tag fpga-fir-v1.0.
• IMP-SW-030A: gen_coeffs.py script version 1.2, with config file for 8 kHz cutoff.
• IMP-HW-010B: Bitstream file fir_filter_top.bit built from tag fpga-fir-v1.0.

Configuration concerns:

• Store exact tool versions (e.g., Vivado 2023.2).
• Store synthesis options & constraints used for the baseline build.

Highlight a common failure mode in FPGA projects: - “We had a working bitstream, then we re‑synthesized with slightly different options, and timing broke.” Without CM, you may never recover the working configuration.

Tie back to 15288’s idea that you must be able to reproduce a configuration for maintenance and future verification.

ECE Example 3 – IoT Sensor Network (Smart Lab)

This continues the course’s earlier Smart Lab Sensor Network example.

Recall Requirements:

• REQ-SY-010: Each sensor node shall measure temperature 10–40°C with ±0.5°C accuracy.
• REQ-SY-011: Each node shall transmit measurements at least once every 60 s.

Stage 5 Tasks:

• Implement sensor node firmware (temp/humidity readout, LoRaWAN stack).
• Implement gateway service and database.
• Implement dashboard UI.

Implementation & CM:

• IMP-SW-040A: Node firmware repo with modules sensor.c, radio.c, main.c.
• IMP-SW-050A: Server backend repo (api.py, db_models.py).
• IMP-SW-060A: Web dashboard (dashboard.vue).
• IMP-SY-070A: Node PCB rev C (KiCad project).

Use Git tags: - stage5-demo-node-fw-v0.9 - stage5-demo-backend-v0.7

DCP‑400 references all of these as CIs and explains how to deploy a full test network.

You can discuss typical IoT pitfalls: - Changing data format or protocol without updating both ends → integration breakage. CM and traceability help: - A change request might say “Update payload format to include battery voltage (REQ-SY-0xx)”; this would cause updates in design and implementation, all referenced from DCP‑400.

Implementation Workflow – From Design to Code/Boards

Stress that the plan step is real: - Map components to tasks, assign owners. - Decide which branches and repos will host each IMP-*.

Also emphasize internal checks: - These are not the same as formal Stage 6 tests; they are developer tests to ensure the implementation is stable and ready to enter formal verification.

Implementation Planning – Breaking Down the Work

From components to tasks:

Example (Smart Lab project):

• CMP-SW-010 UI module → tasks:
  • Design page layout.
  • Implement dashboard front‑end.
• CMP-SW-020 control logic → tasks:
  • Implement alert rules engine.
• CMP-SY-030 sensor board → tasks:
  • Layout rev B, order PCBs, assemble 3 prototypes.

Best practices:

• Define clear task boundaries aligned with CMP-*.
• Assign owners for each IMP-* implementation.
• Use issues/tickets that reference component IDs.

Example Task Table:

Task ID	CMP ID	Short Description	Assignee
T‑501	CMP-SY-030	Layout sensor PCB rev B	Alice
T‑502	CMP-SW-020	Implement alert engine	Bob
T‑503	CMP-SW-010	Dashboard UI first version	Chen
T‑504	CMP-SY-030	Assemble 3 sensor boards	Dana

Later, each task produces corresponding IMP-* entries linked back to CMP-*.

Point out that this is also project management: breaking work down into implementable chunks that match your architecture.

Encourage teams to map tasks into whatever tracking tool they use (GitHub Issues, Jira, Trello), always referencing CMP-* and (when relevant) REQ-*.

Coding and HDL Practices at Stage 5

Software / Firmware / HDL implementation guidelines:

• Follow style guides (consistent naming, comments, formatting).
• Embed traceability hints:
  • Comments like // Implements REQ-SW-011, CMP-SW-020.
• Modularize code according to components (CMP-*).
• Use unit‑test‑friendly design (dependency injection, test benches).
• For HDL: use clean module boundaries that match architecture diagrams.

Tip

Think of each IMP-* as a product someone else might reuse. Make it readable, testable, and traceable.

While this lecture is not a full software engineering class, remind them: - Poorly structured code makes Stage 6 and Stage 7 much harder. - Traceability in code makes debugging and compliance easier.

If you have departmental coding standards, reference them here.

Hardware Build Practices at Stage 5

Hardware implementation guidelines:

• Keep versioned schematics and layouts; never edit without version control.
• Label board revisions clearly (e.g., silkscreen “Rev B.1”).
• Maintain a versioned BOM:
  • Include part numbers, manufacturers, tolerances, and any acceptable alternates.
• Document assembly process:
  • Which parts are hand‑soldered vs reflowed.
  • Rework steps (e.g., “Cut trace X, add 10 kΩ pull‑up”).

Note

Your PCB rev that works “after some bodges” is still a configuration that must be documented.

In many ECE projects, the “working board” in the lab is not identical to the design file baseline due to hand mods.

Stress that these must become explicit IMP-* changes: - E.g., IMP-SY-030B: “Sensor PCB rev B with blue‑wire fix F1 and F2 applied.” Later, Stage 4 design files may be updated to rev C reflecting those fixes.

Configuration Baselines in Stage 5

What is a baseline?

A baseline is a formally agreed snapshot of your configuration items (CIs) at a specific time, used as a reference going forward.

Typical baselines at Stage 5:

• Implementation Baseline for TRR (Test Readiness Review):
  • Tagged Git commits for firmware, backend, and UI.
  • PCB revision and BOM version.
  • Documented calibration/config files.

Important

At the Stage 5 Gate (TRR), you must be able to say: > “We are using these exact versions of code, boards, and configs for verification.”

Relate this to DCP‑400: - DCP‑400 should state which tags/branches form the TRR baseline. - This allows Stage 6/7 to report test results against a known configuration.

Change Control During Implementation

Reality: you will discover issues during Stage 5.

Examples:

• A sensor is noisier than the datasheet claimed → requirement or design may need adjustment.
• MCU flash is too small → firmware must be refactored or hardware changed.

Change control steps (adapted from 15288):

1. Raise a change request (CR)
   • Describe the problem and proposed change.
2. Impact analysis
   • Which REQ-*, CMP-*, TST-* are affected?
3. Decision
   • Advisor / team approves, rejects, or defers.
4. Implement change
   • Update requirements/design/implementation.
5. Update traceability & DCPs
   • RTM, DCP‑200/300/400 updated accordingly.

Warning

Do not silently change functionality. If it affects requirements or design, it must go through change control.

In smaller student projects, this can be lightweight: - A shared “Change Log” section in DCP‑400. - A label in GitHub issues (“Change Request”), referencing IDs.

But the discipline is the same as 15288: changes are evaluated and recorded, not hidden.

Example Change Request – Smart Lab Project

Problem:

• Prototype nodes last only 12 hours on battery instead of the 72 hours implied by REQ-SY-0xx (battery life requirement).

Proposed Changes:

• Change reporting interval from 60 s to 5 min.
• Add deep‑sleep mode in firmware.

Change Control Actions:

1. CR‑005 logged referencing REQ-SY-0xx and CMP-SW-020.
2. Impact analysis:
   • Data latency may affect stakeholder expectations (STR-SY-001).
3. Stakeholders consulted; they accept 5 min updates.
4. Approve CR‑005.
5. Update:
   • REQ-SY-011 text to new 5 min period in DCP‑200.
   • Design (DCP‑300) to include deep‑sleep mode.
   • Firmware implementation (IMP-SW-020B) to include sleep logic.
6. Update RTM and DCP‑400.

This shows 29148 and 15288 principles in practice: requirements are living but controlled, and implementation changes must be consistent with updated requirements and stakeholder needs.

Use this to underscore: > “It’s fine to discover problems. It’s not fine to hide them or ‘hack around’ them without updating the formal artifacts.”

Internal Testing vs Formal Verification

During Stage 5, you will:

• Run quick checks to see if your implementation basically works:
  • Power‑on tests.
  • Simple functional tests (e.g., “LED blinks”, “UART prints messages”).
  • HDL simulations to see waveforms look reasonable.
• Fix defects discovered during bring‑up.

These are sometimes called developer tests or smoke tests.

Formal Verification (Stages 6 & 7):

• Uses planned test cases (TST-*, VER-*) traceable to REQ-*.
• Follows documented procedures.
• Has clearly recorded pass/fail criteria.

Note

Stage 5 ends when you have implementations stable enough to enter planned verification.

Explain that students should do a lot of testing in Stage 5, but those tests may not be fully documented or traceable yet.

Formality and traceability of tests increase as you move into Stages 6 and 7.

Documenting Implementation in DCP‑400

Suggested sections (template):

1. Introduction
   • Scope of this implementation phase.
2. Implementation Items (IMP-*)
   • Table mapping CMP-* → IMP-* → repository paths / file sets.
3. Configuration Identification
   • Repos, branches, tags, PCB revs, BOM versions, toolchain versions.
4. Build & Deployment Procedures
   • Step‑by‑step instructions to build firmware/HDL/software and deploy to hardware.
5. Change Log & Known Issues
   • List of change requests and their status.
   • Known limitations of this implementation (for Stage 6/7 awareness).
6. Readiness for Verification
   • Statement of which REQ-* are now implemented and ready for testing.

Encourage teams to think of DCP‑400 as something a new engineer could pick up to reproduce the system.

During grading, DCP‑400 gives you a way to see: - Whether the team has coherent CM. - Whether they understand what has actually been implemented versus what was merely designed.

In‑Class Exercise – Map Your Project to IMP-*

Activity (5–10 minutes):

1. Pick your current or planned capstone project.
2. Identify 3–5 components (CMP-*) from your Stage 4 architecture.
3. For each component, propose:
   • A plausible implementation artifact (IMP-*).
   • The repository or file where it will live.
   • Who on the team is likely to own it.

Example answer snippet:

• CMP-SW-015 – Data acquisition service
  • IMP-SW-015A – daq_service.py in labdaq/backend/ (owned by Sam).
• CMP-SY-025 – Sensor shield board
  • IMP-SY-025A – sensor_shield_revA KiCad project (owned by Alex).

Tip

Use this to plan your repos and tasks early, rather than improvising halfway through implementation.

Walk around and spot‑check a few teams. Ask questions: - “Is every major block in your architecture getting at least one IMP-*?” - “Who’s responsible for PCB vs firmware vs server side—do you have coverage?”

This exercise makes the abstract IMP-* concept tangible and also helps identify scope issues early.

Summary – Key Takeaways for Stage 5

1. Stage 5 (Implementation / Construction) is the bottom of the V‑Model, where designs become real HW/SW systems.
2. ISO/IEC/IEEE 15288 defines the Implementation and Configuration Management processes that guide how you build and control your system elements.
3. ISO/IEC/IEEE 29148 remains active: implementation must continue to respect and trace back to requirements, and any requirement changes must be controlled.
4. Your main Stage‑5 deliverable is DCP‑400 Implementation, which documents:
   • Implementation items (IMP-*) and their traceability to CMP-* / REQ-*.
   • Configuration baselines, repos, versions, build procedures, and change log.
5. Solid configuration management (Git, tags, PCB revs, BOM versions, change control) is essential for:
   • Reproducibility.
   • Reliable verification and validation later.
   • Professional practice aligned with real ECE industries.

Important

Stage 5 is not “just hacking until it works.” It is disciplined construction under configuration control, preparing you for rigorous verification and validation.

Close by connecting forward: - Next sessions will focus on how your Stage 5 implementation feeds into Stage 6 (Unit / Component Verification) and Stage 7 (System / Integration Verification).

Invite questions: - About Git workflows, PCB versioning, or how detailed DCP‑400 needs to be. Encourage teams to start setting up repos and CM practices immediately, not halfway through the build.