UNIT-2 PROJECT LIFE CYCLE MODELS

1. UNIT-2PROJECT LIFE CYCLE MODELS UNIT STRUCTURE: 2.1 Classical Waterfall Model 2.2 Iterative Waterfall Model 2.3 Prototyping Model 2.4 Evolutionary Model 2.5 Spiral Model

2. INTRODUCTION TO THE UNIT: This chapter basically describes the various project life cycle models and its applicability. The main contents of the project life cycle models are classical waterfall model, iterative waterfall model, prototyping model, evolutionary model, spiral model. The project life cycle model also describes the advantages, disadvantages, applications suitability and limitations. UNIT LEARNING OBJECTIVES: After reading this chapter the learner may find the usefulness of the project life cycle model for software industry. Explanation of Classical and Iterative waterfall model. Prototyping model and its application Evolutionary model and its usefulness Spiral model and its variants.

3. 2.1 CLASSICAL WATERFALL MODEL The classical waterfall model divides the life cycle into the phases shown in below figure. This model breaks down the life cycle into an intuitive set of phases. The different phases of this model are: feasibility study, requirements analysis and specification, design, coding and unit testing, integration and system testing, and maintenance. The different phases starting from the feasibility study to the integration and system testing phase are known as the development phases. The part of the life cycle model between the feasibility study and product testing and delivery is known as the development part. At the end of the development part of the life cycle, the product becomes ready to be delivered to the customer. The maintenance phase commences after completion of the development phase.

5. 2.1.1Feasibility Study The main aim of the feasibility study activity is to determine whether it would be financially and technically feasible to develop the product. The feasibility study activity involves the analysis of the problem and collection of all relevant information relating to the product such as the different data items which would be input to the system, the processing required to be carried out on these data, the output data required to be produced by the system, as well as various constraints on the behavior of the system. The collected data are analyzed to arrive at the following: An abstract problem definition. An abstract problem definition is a rough description of the problem which considers only the important requirements and ignores the rest. Formulation of the different solution strategies. Analysis of alternative solution strategies to compare the benefits and shortcomings. 2.1.2 Requirements Analysis and Specification The aim of the requirements analysis and specification phase is to understand the exact requirements of the customer and to document them properly. This phase consists of two distinct activities, namely requirements gathering and analysis, and requirements specification.

6. 2.1.3 Requirements gathering and analysis The goal of the requirements gathering activity is to collect all relevant information from the customer regarding the product to be developed with a view to clearly understanding the customer requirements and weeding out the incompleteness and inconsistencies in these requirements The requirements analysis activity is begun by collecting all relevant data regarding the product to be developed from the users of the product and from the customer through interviews and discussions. For example, to perform the requirements analysis of a business accounting software required by on organization, the analyst might interview all the accountants of the organization to ascertain their requirements. The data collected from such a group of users usually contain several contradictions and ambiguities, since each user typically has only a partial and incomplete view of the system. Therefore, it is necessary to identify all ambiguities and contradictions in the requirements and resolved them through further discussions with the customer. After all ambiguities, inconsistencies, and incompleteness have been resolved and all the requirements properly understood, the requirements specification activity can start. During this activity, the user requirements are systematically organized into a Software Requirements Specification (SRS) document.

7. 2.1.4 Requirements specification The customer requirements identified during the requirements gathering and analysis activity are organized into a SRS document. The important components of this document are the functional requirements, the nonfunctional requirements, and the goal of implementation. Documenting the functional requirements involves the identification of the functions to be supported by the system. Each function can be characterized by the input data, the processing required on the input data, and the output data to be produced. The non-functional requirements identify the performance requirements, the required standards to be followed, etc. The SRS document is written using the end –user terminology. This makes the SRS document understandable by the customer. After all, it is important that the SRS document be reviewed and approved by the customer. The SRS document normally serves as a contract between the development team and the customer. Any future dispute between the customer and the developers can be settled by examining the SRS document. It is therefore an important document which must be thoroughly understood by the developer team, and reviewed jointly with the customer. The SRS documents provides not only the basis for carrying out all the development activities, but also the basis for several other documents such as the design document, the users’ manuals, the system test plan, etc.

9. 2.1.5 Design The goal of the design phase is to transform the requirements specified in the SRS document into a structure that is suitable for implementation in some programming language. In technical terms, during the design phase the soft ware architecture is derived from the SRS document. Two distinctly different design approaches are available: the traditional design approach and the object-oriented design approach. 2.1.6 Traditional design approach The traditional design approach is currently being used by many software development houses. Traditional design consists of two different activities; first a structured analysis of the requirements specification is carried out where the detailed structure of the problem is examined. This is followed by a structure design activity. During structured design, the results of structured analysis are transformed into the software design. Structured analysis involves preparing a detailed analysis of the different functions to be supported by the system and identification of the data flow among the different functions. Data flow diagrams (DFDs) are used to perform structured analysis and to document the results.

10. 2.1.7 Object-oriented design approach Object-oriented design (OOD) is a relatively new technique. In this technique, various objects that occur in the problem domain and the solution domain are first identified and the different relationships that exist among these objects are identified. The object structure is further refined to obtain the detailed design. The OOD approach has several benefits such as lower development time and effort, and better maintainability of the product. 2.1.8 Coding and Unit Testing The purpose of the coding and unit testing phase of software development is to translate the software design into source code. Each component of the design is implemented as a program module. The end- product of this phase is a set of program modules that have been individually tested. A coding standard addresses issues such as the standard ways of laying out of the program codes, the template for laying out the function and module headers, commenting guidelines, variable and function naming conventions, the maximum number of source lines permitted in each module, and so forth. During the phase, each module is unit tested to determine the correct working of all the individual modules. It involves testing each module in isolation as this is the most efficient way to debug the errors identified at this stage.

11. 2.1.9 Integration and System Testing During the integration and system testing phase, the modules are integrated in a planned manner. The different modules making up a software product are almost never integrated in one shot. Integration is normally carried out incrementally over a number of steps. During each integration step, the partially integrated system is tested and a set of previously planned modules are added to it. Finally, when all the modules have been successfully integrated and tested, system testing is carried out. System testing usually consists of three different kinds of testing activities: Alpha-testing: It is the system testing performed by the development team; Beta-testing: It is the system testing performed by a friendly set of customers. Acceptance testing: It is the system testing performed by the customer himself after the product delivery to determine whether to accept or reject the delivered product. 2.1.10 Maintenance Maintenance of a typical software product requires much more effort than the effort necessary to develop the product itself. Maintenance involves performing any one or more of the following three kinds of activities: Correcting errors that were not discovered during the product development phase. This is called corrective maintenance. Improving the implementation of the system, and enhancing the functionalities of the system according to the customer’s requirements. This is called perfective maintenance. Porting the software to work in a new environment. For example, porting may be required to get the software to work on a new computer platform or with a new operating system. This is called adaptive maintenance.

12. 2.2 ITERATIVE WATERFALL MODEL Feedback paths are needed in the classical waterfall model from every phase to its preceding phases as shown in figure to allow for the correction of the errors committed during a phase that are detected in later phases. Some of the glaring shortcomings of the waterfall model are the following: The waterfall model cannot satisfactorily handle the different types of risks that a real-life software project is subjected to. For example, the waterfall model assumes that the requirements be completely specified before the rest of the development activity can start. Therefore, it cannot accommodate the uncertainties that exist at the beginning of most of the projects. As a result, it cannot be satisfactorily used in projects where only rough requirements are available at the beginning of the project. To achieve better efficiency and higher productivity, most real-life projects cannot follow the rigid phase sequence imposed by the waterfall model. A rigid adherence to the waterfall model creates “blocking states” in the system. That is, some team members would have to wait for a phase to be complete before they can start their next activity. This is clearly a wastage of resources and such wastages are rarely tolerated in real projects. For example, if an engineer works fast and completes the design of the parts assigned to him early, he should not idle, waiting for the others to complete their designs. Instead, he should proceed to the next phase.

15. Some of the glaring shortcomings of the waterfall model are the following: The waterfall model cannot satisfactorily handle the different types of risks that a real-life software project is subjected to. For example, the waterfall model assumes that the requirements be completely specified before the rest of the development activity can start. Therefore, it cannot accommodate the uncertainties that exist at the beginning of most of the projects. As a result, it cannot be satisfactorily used in projects where only rough requirements are available at the beginning of the project. To achieve better efficiency and higher productivity, most real-life projects cannot follow the rigid phase sequence imposed by the waterfall model. A rigid adherence to the waterfall model creates “blocking states” in the system. That is, some team members would have to wait for a phase to be complete before they can start their next activity. This is clearly a wastage of resources and such wastages are rarely tolerated in real projects. For example, if an engineer works fast and completes the design of the parts assigned to him early, he should not idle, waiting for the others to complete their designs. Instead, he should proceed to the next phase.

16. 2.3 PROTOTYPING MODEL The prototyping model suggests that before carrying out the development of the actual software, a working prototype of the system should be built. A prototype is a toy implementation of the system. A prototype usually exhibits limited functional capabilities, low reliability, and inefficient performance compared to the actual software. An important purpose is to illustrate the input data formats, messages, reports, and the interactive dialogues to the customer. This is a valuable mechanism for gaining better understanding of the customer’s needs. In this regard, the prototype model is very useful in developing the Graphical User Interface (GUI) part of a system. The prototyping model of software development is shown in figure. In this model, product development starts with an initial requirements gathering phase. A quick design is carried out and the prototype is built. The developed prototype is submitted to the customer for his evaluation. Based on the customer feedback, the requirements are refined and the prototype is suitably modified. This cycle of obtaining customer feedback and modifying the prototype continues till the customer approves the prototype. The actual system is developed using the iterative waterfall approach. However, in the prototyping model of development, the requirements analysis and specification phase becomes redundant as the working prototype approved by the customer becomes redundant as the working prototype approved by the customer becomes an animated requirements specification.

18. 2.4 EVOLUTIONARY MODEL This life cycle model is also referred to as the successive versions model and sometimes as the incremental model. In this life cycle model, the software is first broken down into several modules which can be incrementally constructed and delivered. The development team first develops the core modules of the system. This initial product skeleton is refined into increasing levels of capability adding new functionalities in successive versions. Each evolutionary version may be developed using an iterative waterfall model of development. The evolutionary model is shown in figure.

20. 1.5 SPIRAL MODEL The diagrammatic representation of this model appears like a spiral with many loops. The exact number of loops in the spiral is not fixed. Each loop of the spiral represents a phase of the software process. For example, the innermost loop might be concerned with feasibility study. The next loop with requirements specification, the next one with design, and so on. This model is much more flexible compared to the other models, since the exact number of phases through which the product is developed in this model is not fixed. The phases we mentioned are just examples and may vary from one project to another. For instance, it is possible that for some other project the design might be accomplished over three or four consecutive loops and in some other project the design might be over in just one loop.

22. Each phase in this model is split into four sectors as shown in figure. The first quadrant identifies the objectives of the phase and the alternative solutions possible for the phase under consideration. During the second quadrant, the alternative solutions are evaluated to select the best solution possible. For the chosen solution, the potential risks are identified and dealt with by developing an appropriate prototype. A risk is essentially any adverse circumstance that might hamper the successful completion of a software project. Activities during the third quadrant consists of developing and verifying the next level of the product. Activities during the fourth quadrant concern reviewing the results of the stages traversed so far with the customer and planning the next iteration around the spiral. With each iteration around the spiral, progressively a more complete version of the software gets built. After several iterations along the spiral, all risk are resolved and the software is ready for development. At this point, a waterfall model of software development is adopted. The radius of the spiral at any point represents the cost incurred in the project till then, and the angular dimension represents the progress made in the current phase.

23. Summary This chapter discusses various models of software project life cycles and their applicability. It should be noted that in real life situations, the actual life cycle model could be a combination of the features of one or more of the above models. These models are basically to be the guidelines rather than be prescriptive. At the end of the day it is important not to twist the natural and most appropriate way of working on a project to suit the above models. Review questions What is a life cycle model for a project? What are the principles behind the waterfall model? Explain the advantages, disadvantages and applicability of the waterfall model? Describe the waterfall model with suitable examples? What are the main principles adopted in the prototyping model?

24. List out the advantages, disadvantages and the applications of prototyping model? What are the basic moralities of Evolutionary model? Explain the key advantages, disadvantages of Evolutionary model? Explain the various conditions applicable for the Evolutionary model? Describe the features of the Spiral model and its variants? Briefly explain the key advantages, disadvantages of the Spiral model? Is the Waterfall model always incpplicable in the case of projects with a very short life cycle? Give a counter-example if it indeed is applicable. Let us assume that you are developing a general purpose accounting software for use by multiple customers. Which life cycle model would you choose to use? What adaptations would you make to the chosen models? In today’s hosted model of deployment, new versions are hosted on the Internet and customers try out the latest versions from the Internet. Discuss the applicability of the various models (discussed in this chapter) to the present day scenario. Describe at least one scenario where Waterfall model is preferable to all other models?

25. References Swapana Kishore and Rajesh Naik, Software Requirements and Estimation, First (Reprint) Edition, Tata McGraw-Hill Publishing company ltd (2001) Pankaj Jalote, Software Project Management in Practice, First (Reprint) Edition, Pearson Education Inc (2002) Swapana Kishore and Rajesh Naik, ISO 9001:2000 For Software Organizations, First Edition, Tata McGraw-Hill Publishing company ltd (2003) Pankaj Jalote, CMM in Practice, Fourth (Reprint) Edition, Pearson Education Inc (2002) Rajib Mall, Fundamentals of software Engineering, Second Edition, Prentice Hall of India (Pvt) Ltd (2004).