The life cycle of an embedded project

Modern development frameworks, such as agile software development methodologies, recommend, among other best practices, splitting the work into smaller action points, and marking milestones through the project development, producing intermediate working deliverables. Each deliverable focuses on giving a prototype of the entire system, with the missing features temporarily replaced using dummy code.

These recommendations seem particularly effective on embedded projects. In an environment where every error could be fatal to the entire system, working on small action points, one at a time, is an efficient way to promptly identify defects and regressions while working on the code base, provided that a CI mechanism is in place from the early stages of the development. Intermediate milestones should be as frequent as possible, and for this reason, it is advisable to create a prototype of the final system as soon as possible in the development phase. This has to be taken into account when actions are identified, prioritized, and distributed to the team.

Once the steps to reach the goal are defined, we need to find the optimal sequence to produce working prototypes for the intermediate milestones. The dependencies among the development actions are taken into account to sort the priorities for the assignments of the work.

Facing unexpected issues along the path, a progressive understanding of the system behavior and hardware constraints may change the view on the architecture of the system while it is under development. Changing specifications as a reaction to measurements and evaluations performed on the intermediate prototype may require a major code rework. Throwing away consistent parts of the project to replace them with a new, improved design is often definitely beneficial for the quality of the project and may result in improved productivity in the later stages. This process, known as refactoring, must not be seen as development overhead whenever it is aimed to improve the design and behavior of the system.

Finally, the process of creating system software includes the necessity of defining a clear API for the applications to be able to interact with the system in the desired way. Embedded system provide specific APIs to access system resources most of the time, however, some operating systems and libraries may provide POSIX-like interfaces to access functionalities. In any case, the API is the entry point for the system interfaces, and must be designed for usability and well documented.