Hybrid approach to system design
The age-old debate among system designers and their managers is whether to use top-down or bottom-up design techniques. Experience shows that a hybrid approach works best.
To use the top-down method, the designer starts with the big picture and works down to the details. The top level looks generally at what the prospective user wants the system to do and the major specifications. The designer then works down a level at a time, filling in details until, at the very bottom, the design is complete.
Managers, of course, love the top-down approach. With it, they know what they’re going to get, and can estimate overall costs and schedules. It also works well in a project-team environment, as there’s an overall plan of tasks that can be divided up between team members. The top-down method lends itself naturally to standard project management metrics, such as milestones, Gantt charts, bills of materials, and so forth.
The bottom-up approach, on the other hand, starts with one particular feature. After completing a module for that feature, the designer takes up another feature and writes a module for that. He or she then adds “hooks” that connect the modules. The process continues as the designer takes up each feature in turn. Since the work proceeds by adding features, adding new, unanticipated features at any time — even long after the project is complete — is not difficult. The approach is especially efficient when the system needs to be expandable.
Bottom-up projects, however, are hard to manage. With no overall vision, it is hard to measure progress. There are no milestones. The budget is guesswork. Schedules mean nothing. Teamwork is difficult. The resulting design may not be well integrated because intermodule communication standards are ad hoc and tend to drift as the project goes forward.
Both approaches clearly have advantages and disadvantages. The good news is that they are not incompatible. The best approach is a hybrid: plan top-down, and execute bottom-up.
Start with top-down planning to identify required modules and interface standards. That makes possible all of the nice milestones, budgetary estimates, and task definitions that project managers love.
Stop short, however, of specifying how each feature or set of features is to be embodied. That would be what ultimate Taoist master Lau Tsu called “cutting wood for the master carpenter.” The plan should provide enough detail so that everyone on the team knows what is expected of them, but there it should stop.
At that point, hand assignments out to team members. They should work bottom-up to implement the plan. Well-trained and well-disciplined programmers, for example, know how to use structured programming methods to modularize their parts of the project and avoid writing “spaghetti code,” which is difficult or impossible to maintain or extend. Well-trained team members in other engineering disciplines are similarly skilled.
The hybrid approach is easy to apply to any engineering project. Building any structure bigger than a doghouse, for example, is almost impossible to do any other way. How do you build a brick wall without knowing where to put it, and how many bricks to use? That’s the top-down part. When you take trowel and hod in hand, however, you’re going to put one brick on top of another from the bottom up.
Controls projects could be done completely top-down or completely bottom-up. It is important for control engineers, therefore, to understand the two approaches and combine them appropriately in the hybrid approach. Even when an engineer is working alone, the hybrid approach helps keep the project organized and the resulting system usable, maintainable, and extensible.
|C.G. Masi is a senior editor with Control Engineering. Contact him by email at email@example.com .|