Concurrent Engineering |
 |
 |
 |
| Written by Graham Stoney | |||
|
Don't let my use of taxonomy based on ISO 15288 and ISO 12207 confuse you into thinking that either these standards or I advocate a waterfall model of development, because they/we do not. Each of the development activities we describe occurs in parallel. These activities tend to have a staggered start (you begin requirements analysis before you begin validation, for instance), and the level of effort for each one varies during the life of the project; but early activites such as requirements analysis are never fully completed until the end of the project. It should be obvious that if the engineers designing the lowest level components in the system have to wait for all their input requirements to ripple down to them waterfall style, the project will take a long time to complete. Engineering needs to proceed at all levels and in all components simultaneously. This means proceeding on risk sometimes. If the input requirements aren't known when a designer begins their work on a subcomponent, the logical choices are to either begin by doing the system level functional design necessary to derive the input requirements (if nobody is currently working on that), or to talk to the people who are working on it and document the current best guess at what the requirements are most likely to be before proceeding with the subcomponent design. In practice, this isn't very different from what designers do in environments with no formal requirements tracking processes; the difference here is that the engineers' guesses are acknowledged as guesses, documented and reviewed before the bulk of the design work proceeds. Social Bookmark this page:         
|