 students in this module, I will talk about the disadvantages of the rapid application development or RAD methodology. And I will also compare the RAD with agile. Okay, in the previous module it was intro to RAD and the advantages over here disadvantages and the comparison. So let's deep more. So the disadvantages of the RAD approach, scalability of team. Now it is easier to have a small team working together as in the traditional RAD approach. But when there is a large team, okay, then it becomes difficult to manage and for that large team to work together. How and why? Because of the inter team communication. Inter team communication. You can have a close knit team working in a RAD environment. But when the scope of the project increases, right, the team size increases, then the communication between the team members becomes a problem. Now it is easy to stay focused with a small team of all the team members. But when the story is changing every day, which is part of the RAD, then it is difficult for all the team members to stay on the same page. So that's a big disadvantage of the RAD approach. Then is the continued commitment of the clients. Now the clients have their own major tasks to do and deliver, right? And of course they are having that application developed. Now in the waterfall approach, client is away, is gone after providing the specifications. And they are attending to their main tasks, main job, main duties, right? And they work and the primary focus on their work. Now for the client, this frequent prototyping, frequent meeting with the developers, frequent evaluations, they appear to be consuming their time, their cycles, in the short term, which appears to be a loss of resources, loss of time and not attending to their major task. Okay. And of course, but that is not in the long run. And it is interface focused. Quality is judged by the inspection. Okay. And backend is foregone for the front end, right? So at the end, what may happen is that the developers just patch the things together and make them work. And yet that not be a excellent approach or result. Now RAID versus agile, they are not the same. Okay. Nature of the project. If it is an internal project, if the main focus is interfacing with the customers, the portal with the customer at the front end, then RAID is fine. But if it's mission critical application, such as flight control, such as the pace, the hard pace maker of a client or a patient, then RAID is not the right approach. Because if the application crashes, unfortunately, the plane may crash. The patient may not be available to give the feedback. Use the client. So it doesn't work for mission critical applications. Now remember one thing that RAID is a methodology. Agile is a philosophy. So you cannot, you cannot compare both of them. Okay. There are, of course, certain similarities, but they're not the same. So in the next set of slides, I'll briefly go over some of the similarities, but mostly they are the diss similarities. So let's move ahead to the next slide. So in the agile philosophy, we can see that the customer satisfaction, okay, is important. And it's continuous. Over here, it is also the same thing. So there's a similarity over here between the RAID and the agile methodology. Changes are welcome. Unlike waterfall changes are welcome. Okay. Changes are also welcome in the RAID approach. So you see on those two criterias, they are similar. RAID versus the agile. But if you see that you are setting a deadline weeks rather than months, okay, there are no specific timeframes in the context of RAID. There are no, there nothing is recommended. They are not recommended. Okay. And close daily cooperation between business people and the developers. Okay. Feedback is required. Okay. But it is not critical that you say it should be daily. It should be hourly. All right. So these are the differences. Projects are built around motivated individuals. Okay. Now we say it's a team. It doesn't have to be what type of team members, what should be their approach that is not covered in the RAID explanation. Face to face conversation is the best way. But there is no opinion regarding the locality of team members. Can they meet over a web chat over online but in agile, it's face to face. Working software is the primary measure of progress. You have something which is working and which is delivered, delivered working software. Both cases. So this is a similarity. Sustainable development able to maintain a constant pace. Constant is the keyword over here. But there is no opinion about the pace of the development. It should be fast. It should be variable. It should be constant. It should be of course, it should not be slow. Continuous attention to technical excellence. Functionality. It is it is not the excellence over here. So there the difference over here. You can see that they are different. And finally, simplicity, maximizing the amount of work done. Okay, there is nothing about reducing the work, no about reduction. Best architectures, requirements, designs emerge. Okay, but over here it is not about team structure. And finally, the team reflects on how to become more effective. Regularly. Okay. This is not inherent to the red practice. Right. Now, of course, how do you achieve all of these things, which are the objectives of the red, you achieve them using the red tools. And these red tools, these are the names of some of the tools over here. And you can see that they are for the mobile, they are for the variable devices, and for the web mobile also. So there is a lot of diversity in terms of the operating system also, windows and macOS. And then we have these more of the user testing and feedback tools. So the point over here is that the red environment is a rich ecosystem. There are many tools for development for testing for feedback. And of course, the list goes on. So that's all I have for this module for you. And I hope that it has helped me wonderful and useful module for you. Thanks for your time.