The Anatomy-Centric Approach Towards Managing Complex Projects

From Waterfall To Increments

During the late 1980s and early 1990s many software producing organizations were trying to find alternatives to the then prevalent “waterfall” model for software development (e.g. Brooks, 1995). Examples of such alternatives are evolutionary delivery models, spiral models, iterative development, etc. The traditional waterfall model consisted of phases performed in sequence: analysis, implementation, and integration & test. In the analysis phase, the total functionality of the system was distributed to subsystems and modules, which were developed and tested in the implementation phase. In the integration phase, modules were gradually integrated and system tested until the entire system functionality was achieved.

However, the waterfall model had several intrinsic problems (ERI-1996-04-04; Karlsson, 2002):

• •

  The time span between specification of the system and feed-back to customers was wide. After providing the requirements at the beginning of the project, the customer had to wait for a long time before seeing any results.

• •

  Requirement changes were hard and expensive to accommodate for. Changes in functionality might lead to the re-opening and re-design of already completed modules.

• •

  The delayed integration of modules (called “Big Bang” integration) meant that potential interface problems between the modules were discovered late in the project. Moreover, the concentration on testing and integration towards the end of the project put a heavy burden on test personnel and system test equipments.

• •

  The early distribution of the total functionality on modules brought about a focus on module quality rather than system quality. There was a tendency for designers to concentrate on their specific module, and paying less attention to interactions between modules.

• •

  The focus on modules resulted in an impaired project control. Since the progress of the project was measured from how many modules were ready, problems caused by potential integration problems and/or lack of customer focus appeared late in the project, which might have cause unforeseen delays.

• •

  Since the project participants executed each phase only once, the potential for learning was low. Good and bad experiences collected in one phase were hard to apply anew as the first opportunity to do so did not come until a new project was started. By that time, most lessons learnt had been forgotten.

These and other problems stimulated Ericsson to look for alternative development models. Various more or less isolated initiatives were taken at different development units during the early 1990s. All these initiatives had in common some kind of incremental developmentapproach, where the total functionality of the system was built in several steps in such a way that each step provided a testable part of the overall system. This is illustrated in Figure 1:

Figure 1.

The difference between the waterfall and the incremental model

Several advantages were anticipated from the transition from the waterfall to the incremental model: