ACKNOWLEDGEMENT

It gives me great pleasure & satisfaction to present seminar report entitled The waterfall model the completion of any task is not only the reward to the person activity involved in accomplishing it , but also the person involved in inspiring & guide lining . I am highly indebted to my seminar guide Mr. Vijay Gulsan Pandey for his invaluable support and guidance throughout the work. I extended my great thanks to my seminar in charge Mr. Vijay Gulsan Pandey for his support without which the work would have never been realized. Last but not the least I would like to thanks all friends who directly or indirectly helped me in completion of work with in this short span of time.

Priya singh B.Tech. 3rd year Roll no:-29106

CONTENTS

1. Introduction to software development life cycle (SDLC)....3 1.1. Planning..3 1.2. implementation, testing and documenting.4 1.3. deployment and maintenance.4 2. Waterfall model6 2.1. History....6 2.2. About the model.7 2.3. Types of waterfall model8 3. Classical waterfall model.8 3.1. Introduction ...8 3.2. Phases of the classical waterfall model..8 3.2.1. Feasibility study...9 3.2.2. Requirement analysis and specification..10 3.2.3. Design.11 3.2.4. Coding and unit testing ..11 3.2.5. System and integration testing12 3.2.6. Maintenance12 3.3. Advantage of classical waterfall model...13 3.4. Disadvantage of classical waterfall model...13 4. Iterative waterfall model.15 4.1. Advantage of iterative waterfall model....16 4.2. Disadvantage of iterative waterfall model...16 5. References..17

1. SOFTWARE DEVELOPMENT LIFE CYCLE MODEL

A software development process, also known as a software development life cycle (SDLC), is a structure imposed on the development of a software product. Similar terms include software life cycle and software process. It is often considered a subset of systems development life cycle. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process. Some people consider a life-cycle model a more general term and a software development process a more specific term. For example, there are many specific software development processes that 'fit' the spiral life-cycle model. ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be the standard that defines all the tasks required for developing and maintaining software. The large and growing body of software development organizations implements process methodologies. Many of them are in the defense industry, which in the U.S. requires a rating based on 'process models' to obtain contracts. The international standard for describing the method of selecting, implementing and monitoring the life cycle for software is ISO/IEC 12207. A decades-long goal has been to find repeatable, predictable processes that improve productivity and quality. Some try to systematize or formalize the seemingly unruly task of writing software. Others apply project management techniques to writing software. Without project management, software projects can easily be delivered late or over budget. With large numbers of software projects not meeting their expectations in terms of functionality, cost, or delivery schedule, effective project management appears to be lacking. Organizations may create a Software Engineering Process Group (SEPG), which is the focal point for process improvement. Composed of line practitioners who have varied skills, the group is at the center of the collaborative effort of everyone in the organization who is involved with software engineering process improvement.

1.1. PLANNING
An important task in creating a software program is extracting the requirements or requirements analysis. Customers typically have an abstract idea of what they want as an end result, but not what software should do. Skilled and experienced software engineers recognize incomplete, ambiguous, or even contradictory requirements at this point. Frequently demonstrating live code may help reduce the risk that the
3

requirements are incorrect. Once the general requirements are gathered from the client, an analysis of the scope of the development should be determined and clearly stated. This is often called a scope document. Certain functionality may be out of scope of the project as a function of cost or as a result of unclear requirements at the start of development. If the development is done externally, this document can be considered a legal document so that if there are ever disputes, any ambiguity of what was promised to the client can be clarified.

1.2. IMPLEMENTATION, TESTING AND DOCUMENTING

Implementation is the part of the process where software engineers actually program the code for the project. Software testing is an integral and important phase of the software development process. This part of the process ensures that defects are recognized as soon as possible. Documenting the internal design of software for the purpose of future maintenance and enhancement is done throughout development. This may also include the writing of an API, be it external or internal. The software engineering process chosen by the developing team will determine how much internal documentation (if any) is necessary. Plan-driven models (e.g., Waterfall) generally produce more documentation than agile models.

1.3. DEPLOYMENT AND MAINTENANCE

Deployment starts after the code is appropriately tested, approved for release, and sold or otherwise distributed into a production environment. This may involve installation, customization (e.g. by setting parameters to the customer's values), testing, and possibly an extended period of evaluation. Software training and support is important, as software is only effective if it is used correctly. Maintaining and enhancing software to cope with newly discovered faults or requirements can take substantial time and effort, as missed requirements may force redesign of the software. Software Development Life Cycle or SDLC is a model of a detailed plan on how to create, develop, implement and eventually fold the software. Its a complete plan
4

outlining how the software will be born, raised and eventually be retired from its function. Although some of the models dont explicitly say how the program will be folded, its already common knowledge that software will eventually have its ending in a never ending world of change web, software and programming technology. Software development life cycle model is a descriptive and diagrammatic representation of the software life cycle. A software lifecycle model is a standardized format for planning organizing, and running a new development project. Hundreds of different kinds of models are known and used. There are so many kinds of different lifecycle models some of them are listed below: Waterfall model. Code-and-fix model Spiral model Prototyping model Incremental or evolutionary model By changing the lifecycle model, we can improve: Development speed (time to market) Product quality Project visibility Administrative overhead Risk exposure Customer relations etc.

2. WATERFALL MODEL

2.1. HISTORY
In 1970 Royce proposed what is presently referred to as the waterfall model as an initial concept, a model which he argued was flawed (Royce 1970). His paper explored how the initial model could be developed into an iterative model, with feedback from each phase influencing subsequent phases. It is only the initial model that received notice his own criticism of this initial model has been largely ignored. The phrase "waterfall model" quickly came to refer not to Royce's final, iterative design, but rather to his purely sequentially ordered model. This article uses the popular meaning of the phrase "waterfall model". For an iterative model similar to Royce's final vision, see the spiral model. Despite Royce's intentions for the waterfall model to be modified into an iterative model, use of the waterfall model as a purely sequential process is still popular, and, for some, the phrase "waterfall model" has since come to refer to any approach to software creation which is seen as inflexible and non-iterative. Those who use the phrase "waterfall model" pejoratively for non-iterative models that they dislike usually see the waterfall model itself as naive and unsuitable for an iterative process. The unmodified "waterfall model" Progress flows from the top to the bottom, like a waterfall. In Royce's original waterfall model, the following phases are followed in order: Requirements specification Design Construction (implementation or coding) Integration Testing and debugging (validation) Installation Maintenance

To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. For example, one first completes requirements specification which is set in stone. When the requirements are fully completed, one proceeds to design. The software in question is designed and a blueprint is drawn for implementers (coders) to follow this design should be a plan for implementing the requirements given. When the design is fully completed, an implementation of
6

that design is made by coders. Towards the later stages of this implementation phase, disparate software components produced by different teams are integrated. After the implementation and integration phases are complete, the software product is tested and debugged; any faults introduced in earlier phases are removed here. Then the software product is installed, and later maintained to introduce new functionality and remove bugs. Thus the waterfall model maintains that one should move to a phase only when it preceding phase is completed and perfected. Phases of development in the waterfall model are discrete, and there is no jumping back and forth or overlap between them. However, there are various modified waterfall models (including Royce's final model) that may include slight or major variations upon this process.

2.2. ABOUT THE MODEL

The waterfall model is a popular version of the systems development life cycle model for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is linear and sequential. Waterfall approach was first Process Model to be introduced and followed widely in Software Engineering to ensure success of the project. In "The Waterfall" approach, the whole process of software development is divided into separate process phases. The purpose of this model is to introduce modus operandi into the system design process; as a skeleton for system development it advances consecutively through a succession of phases, preliminarily with system feasibility analysis and concluding up to system release and maintenance. The name "waterfall" portrays system progress flows from the top to the bottom, like water falling down steps in a waterfall panorama, one phase at a time towards the bottom in a cascading effect. In comparison to iterative models, the Waterfall model is seen as inflexible and linear though it's preferred by many who feel iterative software development methodologies lack discipline. Although there are variations, in the true Waterfall model, the project only moves from one phase to the next when a phase is completed in its entirety. Therefore, no work will begin on the design phase until requirements analysis is complete. Also, there is no room for backtracking, so when a phase is complete it has to be right. The phases in Waterfall model are: Requirement Specifications phase, Software Design, Implementation and Testing & Maintenance.

2.3. TYPES OF WATERFALL MODEL

There are basically two types of waterfall model: Classical waterfall model. Iterative waterfall model.

3. CLASSICAL WATERFALL MODEL 3.1. INTRODUCTION

The classical waterfall model is intuitively the most obvious way to develop software. Though the classical waterfall model is elegant and intuitively obvious, it is not a practical model in the sense that it cannot be used in actual software development projects. Thus, this model can be considered to be a theoretical way of developing software. But all other life cycle models are essentially derived from the classical waterfall model. So, in order to be able to appreciate other life cycle models it is necessary to learn the classical waterfall model.

3.2. PHASES OF THE CLASSICAL WATERFALL MODEL

Classical waterfall model divides the life cycle into the following phases as shown in fig.1 Feasibility Study Requirements Analysis and Specification Design Coding and Unit Testing Integration and System Testing Maintenance

Fig 1 different phases of waterfall model

3.2.1 FEASIBILITY STUDY

The main aim of the feasibility study activity is to determine whether it would be financially & technically feasible to develop the product. It involves analysis of the problem & collection of all relevant information relating to the product. The collected data are analyzed for The important requirements of the customer are captured & the details of the requirements are ignored. Formulation of the different strategies for solving the problem: The different ways in which the problem can be solved are identified. Evaluation of different solution strategies: The different solution strategy are analyzed to their benefits and shortcomings and includes making approximate estimates of the resources required, cost of development, & development time required for each alternate solutions. Best so The main aim of feasibility study is to determine whether it would be financially and technically feasible to develop the product. At first project managers or team leaders try to have a rough understanding of what is required to be done by visiting the client side. They study different input data to the system and output data to be produced by the system. They study what kind of processing is needed to be done on these data and they look at the various constraints on the behavior of the system.
9

 After they have an overall understanding of the problem they investigate the
different solutions that are possible. Then they examine each of the solutions in terms of what kind of resources required, what would be the cost of development and what would be the development time for each solution. Based on this analysis they pick the best solution and determine whether the solution is feasible financially and technically. They check whether the customer budget would meet the cost of the product and whether they have sufficient technical expertise in the area of development.

3.2.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 The goal of the requirements gathering activity is to collect all relevant information from the customer regarding the product to be developed. This is done to clearly understand the customer requirements so that incompleteness and inconsistencies are removed. 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 an 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 resolve 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. The customer requirements identified during the requirements gathering and analysis activity are organized into a SRS document. The important components of
10

this document are functional requirements, the nonfunctional requirements, and the goals of implementation.

3.2.3 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 software architecture is derived from the SRS document. Two distinctly different approaches are available: the traditional design approach and the object-oriented design approach. Traditional design approach 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 structured design activity. During structured design, the results of structured analysis are transformed into the software design. Structured analysis involves specified in the SRS document into sub decomposition of the functional requirements functions & the data flow among these sub functions is analyzed. Structured design transforms the structured analysis into software design. Two main activities involved are: architectural design & detailed design. Object-oriented design approach 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

3.2.4 CODING AND UNIT TESTING

The purpose of the coding and unit testing phase (sometimes called the implementation 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. During this 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

The purpose of this section of software development is to translate the software design into source code. Design is implemented into a workable solution. Each component of the design is implemented as a program module. For a good quality programs every software development organization formulates its own coding standards that suits itself. Coding standard addresses different issues. After coding is complete each module is unit tested. It involves various testing each module in isolation from other modules. The main aim of this testing is to determine the correct working of the individual modules

3.2.5 INTEGRATION AND SYSTEM TESTING

Integration of different modules is undertaken once they have been coded and unit tested. 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. The goal of system testing is to ensure that the developed system conforms to its requirements laid out in the SRS document. System testing usually consists of three different kinds of testing activities: testing: It is the system testing performed by the development team. 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. System testing is normally carried out in a planned manner according to the system test plan document. The system test plan identifies all testing related activities that must be performed, specifies the schedule of testing, and allocates resources. It also lists all the test cases and the expected outputs for each test case.

3.2.6 MAINTENANCE
Maintenance of a typical software product requires much more than the effort necessary to develop the product itself. Many studies carried out in the past confirm this and indicate that the relative effort of development of a typical software product to its maintenance effort is roughly in the 40:60 ratios. Maintenance involves performing any one or more of the following three kinds of activities:

12

 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 customers 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.

3.3 ADVANTAGE OF CLASSICAL WATERFALL MODEL

The project requires the fulfillment of one phase, before proceeding to the next. Therefore if there is a fault in this software it will be detected during one of the initial phases and will be sealed off for correction. A lot of emphasis is laid on paperwork in this method as compared to the newer methods. When new workers enter the project, it is easier for them to carry on the work from where it had been left. The newer methods dont document their developmental process which makes it difficult for a newer member of the team to understand what step is going to follow next. The Waterfall Model is a straight forward method and lets one know easily what stage is in progress. The Waterfall method is also well known amongst the software developers therefore it is easy to use. It is easier to develop various software through this method in short span of time.

3.4 DISADVANTAGE OF CLASSICAL WATERFALL MODEL

The classical waterfall model is an idealistic one since it assumes that no development error is ever committed by the engineers during any of the lifecycle phases. However, in practical development environments, the engineers do commit a large number of errors in almost every phase of the life cycle. The source of the defects can be many: oversight, wrong assumptions, use of inappropriate technology, communication gap among the project engineers, etc. These defects usually get detected much later in the life cycle. For example, a design defect might go unnoticed till we reach the coding or testing phase. Once a defect is detected, the engineers need to go back to the phase where the defect had occurred
13

and redo some of the work done during that phase and the subsequent phases to correct the defect and its effect on the later phases. Therefore, in any practical software development work, it is not possible to strictly follow the classical waterfall model. There are many disadvantages to the model as well. Lets have a look at those, Many software projects are dependent upon external factors; out of which the client for which the software is being designed is the biggest factor. It happens a lot of times, that the client changes the requirement of the project, thereby influencing an alteration in the normal plan of construction and hence the functionality as well. The Waterfall Model doesnt work well in a situation like this as it assumes no alteration to occur once the process has started according to plan. If, for instance, this happens in a Waterfall Model, then a number of steps would go to waste, and there would arise a need to start everything all over again. Of course this also brings about the aspect of time and money which will all go to waste. Therefore this method will not at all prove to be cost effective. It is not even easy to take out the cost estimate of each step, as each of the phases is quite big. There are many other software developmental models which include many of the same aspects of the Waterfall model. But unlike the Waterfall model, these methods are not largely affected by the outside sources. In the waterfall model, there are many different people working in the different phases of the project like the designers and builders and each carries his own opinion regarding his area of expertise. The design, therefore, is bound to be influenced; however in the Waterfall model, there is no room for that. The other negative aspect of this model is that a huge amount of time is also wasted. For example if we study any software development process, we know that Phase II cannot be executed until Phase I has been successfully completed; so while the designers are still designing the software, time of the builders is completely wasted. Another disadvantage of this method is that the testing period comes quite late in the developmental process; whereas in various other developmental programs the designs would be tested a lot sooner to find the flaw at a time when a lot of time and money has not been wasted.

14

 Elaborate documentation during the Waterfall method has its advantages, but it is not without the disadvantages as well. It takes a lot of effort and time, which is why it is not suitable for smaller projects.

4. ITERATIVE WATERFALL MODEL

Iterative waterfall model is similar to classical waterfall model. The iterative model can be viewed by making necessary changes to the classical model to make it applicable for practical software development projects. The main change is done by providing feedback paths from every phase to its preceding phase. An iterative lifecycle model does not attempt to start with a full specification of requirements. Instead, development begins by specifying and implementing just part of the software, which can then be reviewed in order to identify further requirements. This process is then repeated, producing a new version of the software for each cycle of the model. For each cycle of the model, a decision has to be made as to whether the software produced by the cycle will be discarded, or kept as a starting point for the next cycle. Eventually a point will be reached where the requirements are complete and the software can be delivered, or it becomes impossible to enhance the software as required, and a fresh start has to be made. The iterative lifecycle model can be likened to producing software by successive approximation. Drawing an analogy with mathematical methods that use successive approximation to arrive at a final solution, the benefit of such methods depends on how rapidly they converge on a solution. The key to successful use of an iterative software development lifecycle is rigorous validation of requirements, and verification (including testing) of each version of the software against those requirements within each cycle of the model. The first three phases of the example iterative model is in fact an abbreviated form of a sequential waterfall lifecycle model. Each cycle of the model produces software that requires testing at the unit level, for software integration, for system integration and for acceptance. As the software evolves through successive cycles, tests have to be repeated and extended to verify each version of the software.

15

Fig 2 iterative waterfall model

4.1. ADVANTAGE OF ITERATIVE WATERFALL MODEL

It is much better model of the software process in practice. It allows feedback to proceeding stages and hence is not very rigid. It can be used for project in which requirements are not well understood.

4.2. DISADVANTAGE OF ITERATIVE WATERFALL MODEL

It is harder to manage this model No clear milestone in the development process. No stage is really finished (until the system is no longer in use)
16

5. REFERENCES
Information is taken in whole, or in part, from Wikipedia, The Free Encyclopedia www.google.com R. S. Pressman, Software Engineering: A Practitioners Approach, McGraw Hill Rajib Mall, Fundamentals of Software Engineering, PHI Publication. K. K. Aggarwal and Yogesh Singh, Software Engineering, New Age International Publishers.

17