$28.2 CONCURRENT ENGINEERING 925 But the Waterfall Model also suffers (among other deficiencies)from the rigidity of its approach:taken literally,it would mean that no design can proceed until all the specification is complete,no implementation until all design is complete.This is a certain recipe for disaster:one grain of sand in the machine,and the whole project comes to a halt. Various proposals such as the Spiral model have attempted to reduce this risk by providing a more iterative approach,But they retain the one-thread approach of the Waterfall,which hardly reflects the nature of today's software development,especially for large"virtual"teams that may be distributed over many sites,communicating through the Intemet and other "electronic collocation"mechanisms. Successful object-oriented development needs to support a concurrent engineering scheme,offering decentralization and flexibility,without losing the benefits of the waterfall's orderliness.We will in particular have to retain a sequential component,with well-defined activities.Object-oriented development does not mean that we can or should get rid of sound engineering practices.If anything,the added power of the method requires us to be more organized than before. With a division into clusters we can achieve the right balance between sequentiality and concurrent engineering.We will have a sequential process,but subject to backward adjustments(this is the concept of reversibility,discussed in more detail at the end of this chapter),and applied to clusters rather than to the entire system. The mini-lifecycle governing the development of a cluster may pictured as this: Individual cluster Specification lifecycle Design Implemen tation V&V Generali- zation TIME The shape of the activity representations suggests the seamless nature of the development.Instead of separate steps as in the waterfall model,we see an accretion process-think of the figure as depicting a stalactite-in which every step takes over from the previous one and adds its own contribution.§28.2 CONCURRENT ENGINEERING 925 But the Waterfall Model also suffers (among other deficiencies) from the rigidity of its approach: taken literally, it would mean that no design can proceed until all the specification is complete, no implementation until all design is complete. This is a certain recipe for disaster: one grain of sand in the machine, and the whole project comes to a halt. Various proposals such as the Spiral model have attempted to reduce this risk by providing a more iterative approach, But they retain the one-thread approach of the Waterfall, which hardly reflects the nature of today’s software development, especially for large “virtual” teams that may be distributed over many sites, communicating through the Internet and other “electronic collocation” mechanisms. Successful object-oriented development needs to support a concurrent engineering scheme, offering decentralization and flexibility, without losing the benefits of the waterfall’s orderliness. We will in particular have to retain a sequential component, with well-defined activities. Object-oriented development does not mean that we can or should get rid of sound engineering practices. If anything, the added power of the method requires us to be more organized than before. With a division into clusters we can achieve the right balance between sequentiality and concurrent engineering. We will have a sequential process, but subject to backward adjustments (this is the concept of reversibility, discussed in more detail at the end of this chapter), and applied to clusters rather than to the entire system. The mini-lifecycle governing the development of a cluster may pictured as this: The shape of the activity representations suggests the seamless nature of the development. Instead of separate steps as in the waterfall model, we see an accretion process — think of the figure as depicting a stalactite — in which every step takes over from the previous one and adds its own contribution. Individual cluster lifecycle Generali￾zation Implemen tation Design Specification V & V TIME