 Hello, welcome to the session on the reason for moving to the agile model because of the problems of traditional software development methods such as waterfall model, the v-model and rational unified process model. In businesses today, these traditional methods are being replaced more and more by a modern process that is agile method. We look at the reasons as to why traditional methods may no longer be applicable in modern businesses. Let us see the learning outcome. At the end of this session, students will be able to explain reasons for moving to agile software development. Let me explain in brief the traditional software development models that is waterfall model. The most popular one which is being followed currently by many companies is called the waterfall model or the modified v-model. In this traditional waterfall model software is developed in a sequential manner. We start with requirement analysis where we collect the requirements from the clients. Once the complete set of requirements are collected, we move on design phase where the complete set of requirements have been completely designed and after the design is over, we move on to the coding where that design is converted into various codes using different programming language. After the coding is completed, we go to the testing where the entire programs are tested to check whether the programs are in line with the requirements. When it is delivered to the client, there could be some issues or hitches at the customer place. If that happens, then the software enters into the maintenance phase. So the software developer will fix those problems which are being faced by the client and then subsequently the software is getting maintained. So this is a typical software, a sequential lifecycle model and most of the software companies are following currently. And this is called a waterfall model because primarily all these requirements are completed and frozen. We don't allow any changes to the requirements when we enter into the design. In the same way, when you complete the design and move into the coding, there cannot be any changes to the design. So primarily the water only flows down, you cannot make the water flow up. So it has to follow down. So that's why it is called waterfall model. Consider a scenario how the IT project really works. The figure one indicates how the customer explained the requirements to the people. The figure two indicates what the project manager really understood from the customer. The figure three indicates how the analyst designed it. Figure four indicates what the developer or programmer wrote. Then figure five, what the business consultant presented. Then figure six indicates how the project was documented. Then figure seven indicates what operations are installed. Then figure eight indicates how the customer was built. Then figure nine indicates how the solution was supported. Then figure 10 indicates what the customer really needed. So here you can see the figure one and figure 10 is completely different. What the customer explained and what the customer really needed is different. It is all because of the lack of communication in the team and lack of proper team management. Now pause the video for a while and list down the major issues or problems of traditional software development from your perspective. Let me go through the list of issues. The most popular in traditional software development is unclear requirements or ambiguous requirements. Almost everybody complained about this. And the second one is requirement change. Customer changed their mind halfway through the development lifecycle. You are already in the coding phase and customer comes up with its completely new requirements. So the requirements change during the development lifecycle after the requirement phase. Project takes too long. If any changes in the requirement phase or design phase, as per the survey, only 32% of the projects are delivered successfully. Developers implement few requirements out of which only few requirements are used. As per survey, 64% of functionality are rarely used. The lack of involvement of the customer. Traditionally in this lifecycle, customers are involved in the initial requirement phase and may or may not be involved during the design and coding phase. Finally, they come back and get involved in the final testing phase. Usually the user acceptance testing phase in between there is a big gap between the development community and the customers. And the customers keep on waiting to see the product for a long time. So lack of involvement of the customers. The accuracy of estimation probably because of the unclear requirements, when you start with unclear requirements, then your estimation cannot be very accurate. Unfortunately, so estimation is an issue. The in uneven loading of resources, say for example, during requirement phase, they involved business analyst during design phase. We need architects during code. We need programmers or developers. And during design phase, during testing phase, we need testers. So these people are not leveled throughout the development lifecycle. They come and perform their role in different phases of lifecycle. So the resources are not leveled properly. And then the last minute correction is very difficult, primarily because of this sequential way of developing software. If at all customer wants some changes, in last minute, it is really very difficult to measure the changes so that what another problem mentioned by another developer and not much time is available for testing. Unfortunately, the design may get delayed and coding also may delayed, but you have to still maintain the end delivery dates. So unfortunately, you may not get much time for testing. And because you don't have the much time for testing, and you may not have much time for fixing the defects, obviously lack of collaboration within a team. If there is no proper communication between the team members, then difficult to complete the task within time and budget. Then poor progress or tracking of phases of the development is one more issue. Another issue faced by the people are a lot of documentation, requirement specification documents, you need design documents, you need various program document, you need test plans, test cases, and you need configure management documents. So many different documents need to be prepared for this traditional development method. And most of the people complain there is a schedule at cost over the probably because of ambiguous requirements, probably because of requirement change, but schedule and cost overrun to happen. And lot of midnight work before the final delivery. Customers are not happy or not satisfied. So most of these issues are overcome in agile model. This is one of new method. And most of industries adopted agile model for development of quality projects within a time and budget. We will discuss in detail about agile model in subsequent video sessions. These are the references I refer. Thank you.