nasa Skill: F Prime Component Development Process
The flight development process for F Prime components follows a strict sequential lifecycle. Each phase produces artifacts that feed the next. Never skip a phase or guess at requirements/design decisions — always ask the user.
For the canonical process description, see the F´ Development Process.
Process Overview
1. Requirements → 2. Design (FPP) → 3. Implementation (C++) → 4. Unit Test → 5. Integration Test
Each phase has a dedicated skill with detailed guidance:
| Phase | Skill | Key Output |
|---|---|---|
| 1. Requirements | fprime-component-requirements |
Written requirements list |
| 2. Design | fprime-component-design-fpp |
.fpp model file |
| 3. Implementation | fprime-component-implementation |
.cpp / .hpp files |
| 4. Unit Test | fprime-component-unit-test |
test/ut/ test suite |
| 5. Integration Test | fprime-component-integration-test |
test/int/ pytest suite |
Cardinal Rules
Ask, don't guess. If you are unsure about a requirement, interface, behavior, naming convention, or deployment context — stop and ask the user. Wrong assumptions in flight software are costly.
Each phase gates the next — with explicit user approval. Present the requirements to the user and obtain approval before starting design. Present the design (FPP model, port layout, behavior, and any configuration) to the user and obtain explicit confirmation before writing any implementation or unit-test code. This applies even to trivial or pass-through components; simplicity does not waive the gate. Once the model is confirmed, you may write tests against it following the test-driven development pattern (see
docs/how-to/test-driven-development.md).Reference the C++ design skill. All implementation must comply with
fprime-cpp-design(CPP-1 through CPP-35). Consult it before writing any C++ code.Follow Test-Driven Development when possible. The recommended F Prime workflow is: design in FPP → write tests → implement to pass tests. See the TDD guide.
Document as you go. Each component should have an SDD (
docs/sdd.md) that records requirements coverage, port descriptions, and design rationale.
When to Use This Skill
- Creating a new component from scratch
- Adding significant new functionality to an existing component (new ports, commands, telemetry, state machines)
- Migrating or refactoring a component where the interface changes
For small bug fixes or implementation-only changes that don't alter the component's interface, you may skip directly to the implementation and unit test phases — but confirm with the user first.
Quick Reference: Key Commands
| Action | Command |
|---|---|
| Create new component | fprime-util new --component |
| Create new port | fprime-util new --port |
| Generate impl stubs | fprime-util impl |
| Generate UT stubs | fprime-util impl --ut |
| Build component | fprime-util build |
| Run unit tests | fprime-util check |
| Run with coverage | fprime-util check --coverage |
| Generate UT build | fprime-util generate --ut |
| Scaffold rule-based tests | fprime-util new --rule-based-test |