Elements of a Robust Product Development Process
What are the major elements of a robust product development process? Perhaps, like for most products, the process involved in developing a project based on an embedded microcontroller. This process not only involves the creation of schematics and code, but perhaps more importantly, a holistic thought process about what you are trying to accomplish from an architectural perspective. Things like design targets, power budgets, packaging, etc.
One unique characteristic of an embedded system is the close interaction between hardware and software. Because of this interaction, the software and hardware should never be designed in isolation from each other. If we are taking about a project where the hardware designer and the software designer are not the same person, these two people or teams must communicate such that the hardware designers understand the software and the programmers understand the hardware. One way to tackle collaborative projects is to break the project into sub-systems where a single person is responsible for the overall system and the sub-systems interoperability, and other members of the team or teams tackle the hardware and software aspects of that sub-systems. However, this requires people that can do both hardware and software. This may be a better way to break up the tasks, but it requires careful coordination of the system-wide software integration and hardware constraints.
Concept/Problem Definition: The first step in any project development is to define the problem to be solved by the product. The outcome should be a simple problem definition from the user’s point of view. It should describe the problem, not address the solution.
Requirements/Specifications: This is the process of developing a solution to the problem on paper in the form of a requirements document or specifications. Depending on the project, this could be a simple block diagram. Requirements define what the design will do to solve the problem, but they do not address the methods used to implement the solution. The requirements document is also used to create the test plan. When the project is complete, it must be tested to verify that it meets the requirements. The requirements document defines what needs to be tested.
Architectural Design: Architectural design, also called system design, is the top layer of the design process in which the design is partitioned into functional blocks and appropriate technologies. For embedded systems the following are some of the architectural design decisions that must be made: What will be done in hardware versus software, major hardware and software blocks, etc.
Detailed Design and Construction: The detailed design and construction phase of the project is where most of the time is spent. This is where you actually design, construct, and test the system. For software this means detailed design, writing, and debugging the code. For hardware this means detailed design, prototyping, and testing circuits, and these tasks will go much more smoothly if careful forethought has been given to the entire project.