Software Engineering Lecture 8 - Waterfall Model PDF

Software Engineering Prof. Rajib Mall Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur Lecture – 08 Waterfall Model W...

Software Engineering Prof. Rajib Mall Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur Lecture – 08 Waterfall Model Welcome to this lecture we will continue from where we ended last time and we will look at the second phase of the classical Waterfall Model which is requirement analysis. (Refer Slide Time: 00:38) Looking at requirement analysis and specification. (Refer Slide Time: 00:41) The main aim of this page is to understand the exact requirements of the customer and then analyze the requirements. If there are any difficulties in the requirements, eliminate all the problems and then document it properly. Every developer will have to do this sometime or the other, it’s an important skill because it will determine whether the project will succeed or fail. So, this is a very important skill to understand how to gather the requirements, analyze the requirements and then document this properly. We will look at some standard ways of documenting. There are basically two main activities: one is the requirement analysis and the other is requirement specification. The first activity is requirements gathering and analysis and the second activity is requirement specification. Let us look into the requirements gathering and analysis and what is involved in requirement specification. (Refer Slide Time: 02:39) In requirements gathering, you need to gather the requirements, collect the data & understand the customer requirements and during the analysis we analyze the collected requirement, identify what sort of problems can be there in a requirement? Basically, there are 3 main types of problems that normally exist in a gathered requirement first is called as inconsistency, second-anomalies and third-incompleteness. Inconsistencies means that one part of the requirement contradicts with some other part of the requirement. Anomaly is ambiguity, some requirements are anomalous or not clear. In incompleteness somehow the requirement has been missed. So, these 3 problems need to be eliminated and then documented in the form of a requirement specification document known as the SRS document or the software requirement specification document. (Refer Slide Time: 04:10) During the requirements gathering, the relevant data is gathered from the end users. Its normally done through interviews and discussions. For a business accounting software you might have to interview, meet all the accountants in the organization who are doing in the manual mode, find out what exactly what they are doing and the requirement from the software. (Refer Slide Time: 04:45) Once the data is gathered then there will be several contradictions and ambiguities. The main reason for the contradictions and ambiguities is that you are gathering requirement from a set of end user and each user has a different view of the software. Sometimes the views may contradict each other and also they might miss out some of their requirements or they may give a ambiguous statement. Each user has partial and incomplete view of the system. Thus, this is the main reason why there are difficulties in the gathered requirements. (Refer Slide Time: 05:51) All these problems in the requirement have to be identified but how will this be resolved? One of the ways is by discussing with the customers that how exactly that problem will be addressed and once all the difficulties are eliminated from the gathered requirements, these are documented in the SRS document. After few lectures we will look at the exact techniques by which requirement gathering analysis is done and then the format it in which the SRS document will be written. Right after the requirements analysis phase is the design phase, the design phase is based on the requirements. Let us briefly look at what exactly is involved in the design activity. (Refer Slide Time: 07:06) The design activity typically uses the requirement specification document. The designers consult the SRS document and then come up with a design which will be easily implemented in some programming language. The two major approaches which are used are 1) traditional approach and 2) object-oriented approach. (Refer Slide Time: 07:35) In the traditional approach, there are two main activities, one is to develop the DFD representation known as the structured analysis and once the DFD representation or the dataflow diagram representation is complete its translated into a structured design. (Refer Slide Time: 08:07) At the end of the structure design, we will have a high-level design in terms of the module structure. Once the module structure is ready then the detailed design is done where the data structure for each module and also the functions algorithms are designed. (Refer Slide Time: 08:47) On the other hand, in the object-oriented design we identify the relations among objects and then based on that we develop the design. For example, the objects in a payroll software may be the employees, managers, payroll register, departments etc. (Refer Slide Time: 09:22) The object structures are refined into the detailed design. The object-oriented design technique has become very popular as it offers several advantages comprising of lower development effort, lower development time and better maintainability. Once the design phase is complete, coding is taken into account. Based on the design document the coding & testing activities are done. (Refer Slide Time: 10:15) During the coding phase, each module of the design is coded typically that its developer is given couple of modules to code and once this passes the unit testing the modules are documented and the phase completes. The next stage is testing where integration and system testing is done. (Refer Slide Time: 11:03) During integration testing the different modules are integrated in a planned manner that is there are number of steps through which the modules are integrated. To integrate these modules the main idea is to check whether they are interacting properly or not. The interface bugs are the main focus in the integration testing. During unit testing, the bugs in the different modules are identified. So, the system is integrated over a number of steps and each time it is tested to check if there are any bugs and the typical focus of the integration testing is to identify the interface bugs. (Refer Slide Time: 12:29) Once all the modules have been integrated and the system testing is carried out, the fully integrated system is checked to see if it meets the requirements that are experienced by the customer. The goal of the system testing is to check if the developed software satisfies all the requirements that have been expressed in the SRS document and once the system testing is done, the software is delivered to the customer and then the maintenance phase begins. (I.e. if there are any bugs reported by the customer then it may get fixed enhancements and etc) as the maintenance phase continues for quite long time. (Refer Slide Time: 13:38) Earlier we said that the maintenance takes the maximum effort much more than the effort required to develop the product itself. As maintenance occurs over a long time, the lifetime of the software is large. The development time is only a small fraction of the lifetime and typically the effort for maintenance is much more and the development effort to maintenance effort is typically 40 to 60 (i.e. 40 percent development effort and 60 percent maintenance effort). (Refer Slide Time: 14:20) Why maintenance is needed? Well there are 3 main reasons; One is that the bugs may be reported and need to correct those that is called as corrective maintenance. It may be necessary to enhance the functionalities that is hard new functionalities which were not visualized earlier or improve the implementation in some way maybe the response time is not satisfactory & try to improve the response time and etc that is called as perfective maintenance and the third type of maintenance is known as the adaptive maintenance. In adaptive maintenance the software may be required to work with a new hardware. May be that the company procured a new server and it has to be installed and needs to work on this or maybe there is new computer and it needs to work with a new operating system and thus the program needs to be changed a little bit. Hence, this kind of maintenance is called as adaptive maintenance. (Refer Slide Time: 16:34) The classical waterfall model is very simple as it matches with the intuition but it cannot be used or it’s very difficult to use in a real-life project. The main difficulty that will be observed when we try to use the classical model in a real project is that it has a waterfall where it can only go from one stage to the other stage. Once a stage is complete no further activity on that stage will occur as it will transit to the next stage. But what if there was a design error which was discovered during testing (Let’s assume). As every programmer makes mistakes and maybe a mistake was discussed much later. Hence, the classical waterfall model is idealistic, assuming that no mistake is done or no mistake has escaped a phase. In practice there are many mistakes which are committed and escaped in that phase. (Refer Slide Time: 18:01) As soon as there is a problem reported, you have to repeat some activities in the phase in which it was done. Correct those and also the subsequent document. For example, if a requirement is faulty as there is a mistake in doing the requirements and consider we discovered the mistake in the requirement during the design phase then we need to rework the requirements and that will have some cost. But consider we had a mistake in the requirements in the design phase and we did not discover nor in the coding phase but discovered the requirements problem in the testing phase, then it will be much more expensive. Now a question arises why the latter the phase the defect gets detected, the more expensive is the removal. The answer is that we need to rework the results of many phases, if we detect the requirement problem during testing then we not only have to take up the requirements document and change all the requirements that are in problem but also need to redesign, change the code and again do the testing. Obviously, that is much more than if we had discovered the problem during the design stage, we might have to just change the requirements and some part of the design. (Refer Slide Time: 20:34) Thus, once a defect is detected in a latter phase, we need feedback paths in the classical waterfall model. (Refer Slide Time: 20:51) A defect of one phase may get detected in any of the later phase and as it is detected, we need to rework the results produced at that phase and thus we need the feedback paths. We should be able to revisit that phase that is basically the representation of the iterative waterfall model where we have added feedback paths to the classical waterfall model. (Refer Slide Time: 21:28) The later the defect is detected the more expensive it will become. That gives us an idea is that if we detect the defect in the same phase itself then it will cost the least. For example, if the design problem is detected in the design phase, then we can just correct it there itself. But if we detect this during coding or unit testing, we not only have to change the design but also have to change the code. As the programmers commit mistakes that is universal but then the main idea here is that we must be able to detect those mistakes as quickly as possible and within the same phase for the cost of the correction to be low. This is called as the phase containment of errors, the errors must be detected within the same phase in which they are introduced and the major reason behind the phased containment of errors is that it will cost the least and this one of the most important principle in the phase of containment of errors. (Refer Slide Time: 23:09) The iterative waterfall model is used very heavily and it is one of the most fundamental models in the sense that all other models are derived from this model. (Refer Slide Time: 23:43) The waterfall models are easy to understand and easy to use. Even the inexperienced staff who never had any project experience if they work in a project using the waterfall model they can easily relate to the model and feel comfortable. As far as the project manager is concerned the milestones here are well understood. The requirements have been collected in the beginning and based on that the development starts. Thus, the requirements and management control do not change during the development in the sense that based on the requirements it can plan how long will the design & coding take and even have a track on the project. (Refer Slide Time: 24:49) But what are the deficiencies of the waterfall model? One of the major deficiencies of the waterfall model is that it requires all the requirements to be gathered and documented and there is no scope to change this later. But it is often the case that all requirements cannot be given, someone might miss out on some requirements, requirements may change and that cannot be accommodated in a pure waterfall model of development. It lacks flexibility because requirement changes & can’t be accommodated. It can give a false impression of progress because we find that requirements complete, design complete, coding complete but during integration problems may occur. (Refer Slide Time: 25:54) Typically, the scenario is such that the project is on time, everything is under control, the project manager is happy, the requirements, design everything is progressing and then the integration begins. From here, the project starts getting delayed. Till now it was under the grasp of one developer who has done the unit testing but then different developers they have made different assumptions and they do not integrate well. The problem start during integration testing and the project starts getting delayed. The project manager announces the new delivery and keeps on changing it. This is a typical problem of the waterfall model (i.e.; late integration). (Refer Slide Time: 27:46) The waterfall model often observed that it gives a false impression of progress. One of the main reasons is that integration is only at the end and many a times, the problem starts once the integration activity start. Also, during the time of development, the customer is entirely under dark. The customer has no clue regarding what has happened to the software, when it will be delivered, what will it be like and etc. (Refer Slide Time: 29:06) The waterfall model is used for projects which are well known and the development team are very familiar with these kinds of projects. The development by the developers are experienced in developing these kinds of projects. Consider an accounting package, let’s say a company develops the accounting solution for different customers. The developers are experienced on accounting software, the technology, requirements and are almost stable. In this case a waterfall model will be a suitable model. We will stop at this point and we will look at the other models, life cycle models and the type of projects for which they are suitable & how they differ from the waterfall model in the next lecture. Thank you.