The fountain model and its impact on project schedule

• Authors: Krish Pillai
• Venue: ACM SIGSOFT Software Engineering Notes
• Year: 1996

pA software life-cycle is defined as "[the activity relatedto the software during] the period of time beginning when thesoftware product is conceived and ending when the resultantsoftware products are no longer available for use [7]." A softwaredevelopment life-cycle can be broadly divided into phases, eachphase being characterized by a well-defined set of activitiesassociated with it. A model to represent such a life-cycle helpsteam members define their tasks more precisely. It helps managerstrack the project schedule and aids verification of requirementsspecification as the product evolves. Traditionally, software development has been based on the"Waterfall" model, shown in figure 1, or its variations. There is anatural tendency among designers to proceed in a highly sequential,linear, and non-iterative manner. Designers tend to adhere to theold adage "Well begun is half done," by trying to make the analysisand design of the product as complete and precise as possible,before even embarking on its implementation. Every iteration, ifany, to refine the design is viewed as an indicator of aninsufficiency in the design. Tampering with the original conceptualdesign is discouraged, and though designers do iterate, they do sowith a feeling of "guilt/incompetence."Conventionally, the different phases in a life-cycle wereclassified as follows:• Requirements Definition and AnalysisPhase--- This phase is characterized by review and analysis of afunctional document that describes the product. Requirements arereviewed and analyzed and requirements based test-cases are alsogenerated at this stage.• Design Phase--- Design drafts are reviewed and finalized. Test cases fordesign integrity are also generated at this stage.• Implementation and TestingPhase--- 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 thisphase. This may involve some minimal final acceptance leveltesting.• Maintenance Phase--- Regression testing, software evaluations and specificationsfor evolving the software are generated during this phase.The waterfall model does not have a well defined method ofprototyping. It should be noted that a methodology such as the oneabove, provides hardly any latitude for iteration either. Thestress is on refining the output of each phase to the highestdegree possible before the commencement of the succeeding phase.Such an approach may however, not prove feasible under certaincircumstances, especially when the product under development ishighly complex, and composed of several agencies responsible fortasks of very high specificity. The sheer complexity of therequirements specification can obscure the underlying details somuch 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 anintegral part of the developmental life-cycle. The problem withdesigning "state-of-the-art" products is that, usually the mostefficient design isn't yet known at the analysis stage. Thisnecessitates an iterative approach to the analysis, design, andimplementation stages discernible in a product's developmentallife-cycle.However, the necessity of an iterative approach to productdevelopment requires basic building blocks that do not undergodrastic mutation over iterations. This is an issue of the choice ofthe "Problem representation domain" in which the model life-cycleis to be represented. The solution to this is to adopt anobject-oriented approach since objects are fairly stable buildingblocks that can be identified at a very early stage in the productlife-cycle. In most cases, the analysis, design, and implementationstages can all be mapped into the object-oriented domain withouthaving to make disjoint mappings into the "Structured AnalysisDomain" [3]. And the "Fountain model," employed with much successin object-oriented projects, is ideally suited [5] for modelingsuch projects.A problem that is seldom addressed in concerned literature isthe tendency for projects employing an iterative paradigm to runbehind schedule. This paper investigates the most common causes ofschedule slippage in a typical project based on the fountain model.Solutions that project team leaders adopt to counter these causesare also mentioned. "Constraint mechanisms" that are indicators ofpossible schedule slippage, are also investigated.