Introduction
In a previous post we proposed our RTOS engineering process: a lean and iterative process, which cycles between project management and development (see Figure). In this post we describe our development approach that can mitigate the risks and uncertainties of developing a new product in a new domain. But before we come to that, we introduce the two essential approaches: “top-down” and “bottom-up“.
Top-down versus bottom-up development
Top-down
The top-down approach manages the complexity of a system (i.e. the problem) by decomposing it into sub-systems (i.e. sub-problems). The sub-systems are again decomposed (and so on). This approach requires a clear system view and also a good domain knowledge (e.g. in the form of clear and correct requirements) in order to be successful. It would fail if this would be the only approach in our niche of creating a new product in new domain because of the lack of technical insight in the beginning of the project. A prevalent example of a top-down approach is the OSI (Open Systems Interconnection) model in which the complex problem of (remotely) communicating applications is decomposed into 7 layers.
Top-down development requires analytic thinking in order to be able to decompose a system into sub-systems.
The people involved are architects, analysts, designers etc. They must be able to regard sub-systems or components as black boxes and thus abstract the (implementation) details.
It’s quite easy to make a planning on a decomposed system. Alas, that planning schedule also easily fails because of unexpected difficulties and under-estimated risks.
Because of the rigid work-flow, top-down tends to have more documentation, but keeping this documentation on par (and synchronized) with development is a tremendous task.
Traditional development methodologies (e.g. waterfall model, ‘traditional’ V-model) follow the top-down approach.
Bottom-up
The bottom-up approach tries to build the system by combining well-known smaller solutions into bigger components. Those slightly bigger components are again combined until the system is built. Bottom-up requires good intuition of how the final system should behave and where the development is going to. In our project we do not want to rely on intuition, but we want risk management, budget control and adhere to our development track schedule.
Bottom-up development requires synthetic thinking: how to combine existing (smaller) solutions in order to realize a final goal (i.e. the end product).
Bottom-up allows for early testing and risk assessment which is great because it removes these uncertainties and risks.
Code hackers typically follow a bottom-up approach. But how does the rest of the team know what they’re doing? How to make sure they’re building the right thing? Do they maintain a set of documentation?
We can only conclude:
Good engineering teams take the best of both top-down and bottom-up approaches.
Our development methodology
We prefer to mix top-down and bottom-up approaches.
Top-down provides us with a structured and logical architecture given the – at that moment – attained domain knowledge. The domain knowledge is captured in the requirements. The requirements and a decent set of architectural views document the system. This enables each team member to understand it.
Bottom-up allows us to mitigate the risks and uncertainties by early experiments. Early test setups can prove or disprove possible solutions to low-level problems. The feasibility of these solutions as well as the attained domain knowledge (via low-level requirements) are fed back into the ‘top-down’ analysis.
The development approach is requirements-driven:
- high-level system requirements are the result of the analysis of the stakeholder requirements as well as system top-down analysis, while
- low-level requirements (e.g. hardware specifications) are delivered by bottom-up experimenting.
The Figure gives an overview of the process.
Of course, as the system evolves ‘top-down’ and ‘bottom-up’ grow towards each other (see Figure).
About rtos.be
Speak Your Mind