Development plan¶
Info
This document is still a draft and is missing sections.
The development plan is provided as a guidance on how the project is developed. It's guiding, not prescriptive.
Change management¶
Changes are categorized into which type of change it concerns:
- A change request changes how the system is intended to function. This can be adding or changing a requirement such that previous implementations are no longer fulfilling specifications, changing the architecture of the system, etc.
- A defect correction adjust documenation, source code or other configuration item such that it is correct. Correct in this case can be adhering to specification, fixing typo, clarifications or other changes that does not change the intention of the system.
- An engineering change is a change to the system that does not correct a defect or changes the functionality of the system. This can be adding tests, updating dependencies, etc.
- A release request is a special kind of change request, where the system is relased for use. See Release process and versioning.
Changes are registerd in Gitlab by creating a new issue and using the appopriate template.
Implementation is done by opening a MR to main
and fill out the appropriate template.
Configuration management¶
All items placed in Gitlab is configuration items. These cannot be changed without following change management. (See above)
Documentation of the project is published at Gitlab pages.
For valid configuration items, see Release process and versioning below.
File organization¶
The project uses a mono-repo structure, meaning everything is put in one repository. The structure is as follows:
- aqla-fw: Source code for firmware
- aqla-hw: KiCAD projects for hardware
- docs: Project documentation not part of the design files
Software file organization¶
cargo
is used to build the software.
To enable running unit tests without compiling to specific hardware, there are two workspaces;
outer
, located ataqla-fw
contains generic code that can build on any host. Any non-hardware specific code should be placed in an approriate crate at the outer workspace.inner
, located ataqla-fw/cross
contains code that needs to be cross-compiled to target. Cross-compiling is controlled byaqla-fw/cross/.cargo/config.toml
.
(Note that there is nothing that define the names; they are just Cargo.toml
files located at these directories)
Verification¶
Info
This section is still a draft. It should include details regarding:
- Unit testing
- HIL testing
- System testing
Release process and versioning¶
The release process is as follows:
- Create a Release request. See Change management
- Open a MR to the
relase
branch. - Fill out the release template, performing activites as necessary.
- Add the release notes to source control.
- If all activities have been performed adequately,
merge the changes to
release
.
Info
This section is still a draft. It should detail:
- What actions are needed for release, and how to track them?
- Versioning scheme used.