The fountain model and its impact on project schedule

Abstract

A software life-cycle is defined as "[the activity related to the software during] the period of time beginning when the software product is conceived and ending when the resultant software products are no longer available for use [7]." A software development life-cycle can be broadly divided into phases, each phase being characterized by a well-defined set of activities associated with it. A model to represent such a life-cycle helps team members define their tasks more precisely. It helps managers track the project schedule and aids verification of requirements specification as the product evolves. Traditionally, software development has been based on the "Waterfall" model, shown in figure 1, or its variations. There is a natural tendency among designers to proceed in a highly sequential, linear, and non-iterative manner. Designers tend to adhere to the old adage "Well begun is half done," by trying to make the analysis and design of the product as complete and precise as possible, before even embarking on its implementation. Every iteration, if any, to refine the design is viewed as an indicator of an insufficiency in the design. Tampering with the original conceptual design is discouraged, and though designers do iterate, they do so with a feeling of "guilt/incompetence." Conventionally, the different phases in a life-cycle were classified as follows: • Requirements Definition and Analysis Phase --- This phase is characterized by review and analysis of a functional document that describes the product. Requirements are reviewed and analyzed and requirements based test-cases are also generated at this stage. • Design Phase --- Design drafts are reviewed and finalized. Test cases for design integrity are also generated at this stage. • Implementation and Testing Phase --- All test cases are finalized. The implementation is tested, first at the unit level, then following integration. • Installation Phase --- The system is accepted for release to customers during this phase. This may involve some minimal final acceptance level testing. • Maintenance Phase --- Regression testing, software evaluations and specifications for evolving the software are generated during this phase. The waterfall model does not have a well defined method of prototyping. It should be noted that a methodology such as the one above, provides hardly any latitude for iteration either. The stress is on refining the output of each phase to the highest degree possible before the commencement of the succeeding phase. Such an approach may however, not prove feasible under certain circumstances, especially when the product under development is highly complex, and composed of several agencies responsible for tasks of very high specificity. The sheer complexity of the requirements specification can obscure the underlying details so much that, a precise and detailed design is rendered impossible. Another instance is the case with products that involve "cutting-edge" technology, where research and development forms an integral part of the developmental life-cycle. The problem with designing "state-of-the-art" products is that, usually the most efficient design isn't yet known at the analysis stage. This necessitates an iterative approach to the analysis, design, and implementation stages discernible in a product's developmental life-cycle. However, the necessity of an iterative approach to product development requires basic building blocks that do not undergo drastic mutation over iterations. This is an issue of the choice of the "Problem representation domain" in which the model life-cycle is to be represented. The solution to this is to adopt an object-oriented approach since objects are fairly stable building blocks that can be identified at a very early stage in the product life-cycle. In most cases, the analysis, design, and implementation stages can all be mapped into the object-oriented domain without having to make disjoint mappings into the "Structured Analysis Domain" [3]. And the "Fountain model," employed with much success in object-oriented projects, is ideally suited [5] for modeling such projects. A problem that is seldom addressed in concerned literature is the tendency for projects employing an iterative paradigm to run behind schedule. This paper investigates the most common causes of schedule slippage in a typical project based on the fountain model. Solutions that project team leaders adopt to counter these causes are also mentioned. "Constraint mechanisms" that are indicators of possible schedule slippage, are also investigated.