Middle-out approaches concurrently combine the best aspects of the traditional top-down and subsystem-level bottom up development methods. But is it enough?
By John Blyler, Affiliate Professor, Portland State Univ.
Systems engineering is taught as a top-down process, but most engineering domains (like EE, ME, etc.) follow a subsystem or component bottom-up approach. Conversely, all but the largest projects in the working world use a middle-out approach, which is a concurrent combination of top-down and bottom-up activities. The benefit of a middle-out approach is that it preserves the top-level requirements and function development with the known requirements and functions from bottom-level system elements.
As a general rule, very few systems are developed from scratch. Typically, most projects add new functionality or upgrades to existing system with legacy components and subsystems. Such activities often require integration with commercial-of-the-shelf (COTS) or IP subsystems. This is the middle-out approach based on the iterative nature of the fundamental systems engineering method.
I’m working on an update to a systems engineering management text and would greatly appreciate your thoughts on the following questions:
- a) Do you agree that most SE projects in the working world use a middle-out approach? Why or why not?
- b) How do you manage projects from the middle out?
- c) Are the current challenges in the software world between the incorporation of Waterfall and Agile an example of middle-out systems engineering? Why or why not?
- d) Do you have any case studies on middle-out SE, i.e., combining Waterfall and Agilent software development or electronic and chip design projects?
Please respond directly to this post of email me at: email@example.com Thanks and cheers — John