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.
- 1 Genutchen, Michiel Van, "Why is Software Late? An Empirical Study of Reasons For Delay in Software Development," IEEE Transactions On Software Engineering, Vol. 17, # 6 (June, 1991), pp. 582-590. Google ScholarDigital Library
- 2 Henderson - Sellers, B. & Edwards Julian M., "The Fountain Model For Object-oriented System Development," Object Magazine, (July-August 1993), pp. 71-79.Google Scholar
- 3 Henderson - Sellers, B. & Edwards Julian M., "The Object-Oriented Systems Life Cycle," Communications of The ACM, (September 1990), Vol. 33, # 9, pp. 143-159. Google ScholarDigital Library
- 4 Ishii Hiroshi; Minoru Kobayashi, and Kazuho Arita. "Iterative Design of Seamless collaboration Media" Communications of the ACM, Vol. 37, Number 8, August 1994, pp. 83-97. Google ScholarDigital Library
- 5 Northrop Linda M., "Object Oriented Software Engineering," Software Engineering Institute. Marciniak, John J., Editor-In-Chief, "Encyclopedia Of Software Engineering," Wiley Interscience, Vol. 2 (1994 by John Wiley & Sons, Inc.); pp. 729- 737. ISBN 0-471-54002-1.Google Scholar
- 6 Putnam L. H., "A general Empirical Solution to The Macro Software Sizing And Estimating Problem," IEEE Transactions on Software Engineering, Vol. SE-4, NO. 4, 1978, pp. 345-361.Google ScholarDigital Library
- 7 U.S. Department of Commerce/National Bureau of Standards., "Guideline for Lifecycle Validation, Verification, and Testing of Computer Software," Federal Information Standards Publication, FIPS PUB 101 (June, 1983).Google Scholar
- 8 Warburton, Roger D.H. "Managing and Predicting the costs of Real-time Software" IEEE Transactions on Software Engineering, Vol. SE-9, No. 5, September 1983, pp. 562-569.Google ScholarDigital Library
- 9 Weinberg, Gerald M., "Quality Software Management - Volume 1: Systems Thinking" Dorset House Publishing, 1992. ISBN: 0- 932633-22-6. Google ScholarDigital Library
- 10 Wiest, Jerome D. and Levy, Ferdinand K., "A Management Guide to PERT/CPM" (1977), Prentice-Hall, Inc., Englewood Cliffs, New Jersey 07632. Second Edition. ISBN: 0-13-549105-3.Google Scholar
- 11 Wirfs-Brock, Wilkerson and Weiner L. "Designing Object Oriented Software" (1990), Englewood Cliffs, N.J.: Prentice Hall. ISBN: 0136298257. Google ScholarDigital Library
Index Terms
- The fountain model and its impact on project schedule
Recommendations
Feature-Oriented Project Line Engineering
Product line software engineering is an emerging paradigm that guides organizations toward developing products from core assets instead of developing them one by one from scratch. Requirements are essential inputs to PL asset development, but they aren'...
The agile practices impact model: idea, concept, and application scenario
ICSSP 2015: Proceedings of the 2015 International Conference on Software and System ProcessBecause agile development has become more important in software engineering in recent years, many companies want to become agile. One way to do so is context-specific improvement, preferably performed by selecting the right agile practices and ...
Comments