 So students, in this module, I'll be talking about rapid application development. What is the methodology of rapid application development? How it compares with agile? This of course is the part of the next module. What are the advantages of rapid application development, red, what are disadvantages? And how it applies to what we will be doing in the next modules? So without further ado, I will move on. So the basic concept of rapid application development is that it is more focused on the user feedback as compared to following strict deadlines or following strict design or following something strict, strictly. So the concept of red is that it treats the software development project not as steel but as clay, it is malleable, it can be molded, it can be changed. So this is the basic spirit of the rapid application development. So what are the module contents which we'll be covering? So we'll cover the red methodology and the advantages of red, the disadvantages of rapid application development, how red compares with the agile. And then of course the red tools. So we'll cover some of the modules, contents in the current module and the remaining in the next module. So let's go ahead. So what is the red methodology? It defines lose requirements, lose not in the literally meaning of the word. What is the spirit or the concept of lose used over here? The requirements can change unlike the waterfall model or the traditional approach where the requirements are fixed. Over here the requirements can change. So that is why we call it the lose requirements. So what the end user provides to the developers is a vision. And what the developers get from the client or the customer is a gist of their requirements, not the detailed requirements, not the complete requirements, just a gist of the concept of the requirements. So this is the first step. Define lose requirements is the first step. The second step is prototype. Prototype is not the actual system, but something which is a representative of the actual system on a certain level on a certain scale with a certain functionality. So what the developers are aiming at to develop something and to show it to the client and what they develop, it should satisfy all or some of the requirements. Of course it's not the end thing, we'll go to those steps, but it should be reflecting those requirements which were in the gist, which were in the vision. And of course to achieve this prototyping, the developers can cut corners. They can work with the scope or the play with the scope of the work or the functionality to a certain limit and pay the debt later. So what was not covered, that is covered in more detail at a later stage. So get the lose requirements and do the prototyping. Two steps. Let's move ahead. How do this feedback is absorbed by the developers from interface to functionality? So they make this prototype and that prototype is available to the client for review and the client can talk about from interface to functionality covering everything. They provide the feedback to the developers and at the same time, unlike the waterfall model, unlike the traditional models, the client can add or delete certain functionality. Now this deletion is less likely to happen. This is less likely to happen. I will explain to you why. Addition can be there, but the deletion is less likely to happen. Then what will be the result of this absorbing the feedback, either go back to prototyping or go to the next step. Understood. So once we have these lose requirements, we have the prototyping, we have this absorbing the feedback, then of course finalize the product. How do you finalize the product, optimize or reengineer optimize. So optimize means that the client was happy to a certain extent. Now they want to improve it, optimize or reengineer and improve the elite elite is the maintainability, the stability and the other things you can just put them before elite and connect to the database and write that documentation, wonderful documentation. So you are through with it. Okay. So let's go to the next slide and which is the advantages of rad rapid application development is obviously is the speed. So how do you get the speed and how do you happen to finish the projects on time in the in the waterfall model when the project is submitted, the developers cannot go on a vacation. Why because the end user will come up surely with different demands, different requirements, different changes. Okay. But in the red case, since the user is working kind of in sync with the developers, so red will finish on time, finish on time, that is the speed, how it will get the speed in the cost in red, you are building the system as per the exact kind of requirements of the end user. That is how you're building the system. But in the waterfall model, you may build something right and the end user, the client decides it is not worthwhile. So you kind of cut down that zombie stuff. Okay. But over here, there's no gutting. There is no cutting that zombie stuff which was built. So there is no loss of time and the time translates into cost. So there is no loss of time. The cost is reduced. And finally is a developer satisfaction. Waterfall model developers are kind of working in silos because they are detached from the end users or the clients over here. The client is in sync. So there are more satisfied clients in the red approach. And why because the red client is in sync with the developers every step of the way. So these are some of the advantages of rapid application development. In the next module, I'll talk about disadvantage. I'll do the comparison and more interesting stuff. Thank you for your time.