 So, in this module I will talk about a give a brief introduction about rapid application development which is a methodology which will be followed in this course and in addition to read or rapid application development I will also talk about the programming language or the programming language paradigm that will be used in this course which is PHP and I will also very briefly compare and tell you how other programming environments for web based applications for web programming they stack up together how do they compare with each other and with PHP such as cold fusion such as ASP such as Java server pages and the list goes on so without further ado I move on to the details of rapid application development so what is read read is an agile methodology close to the agile development methodology rapid application development and it it is does not strictly follows the development schedule so it does not strictly follows the it doesn't mean it is total chaotic or it is chaos that is not the case it does not strictly follows the development schedule so what is the the read methodology define the requirements the requirements are defined okay and but the stress is more or not the following the requirements very very religiously because the the requirements take shape as we proceed in the red environment say for example so the the requirements are defined and based upon those requirements which are defined a prototyping is done by the programmers and the programmers develop a prototype that could be the final prototype of course towards the end of the application or it could be an intermediate or the first prototype and that prototype is presented to the end users is presented to the client and the client gives their feedback okay so we have this feedback over here is very important and this feedback by the client is noted now this feedback could be about the design this feedback could be about the results its feedback could be about the interface and everything in that feedback is noted is observed and is followed by the red team and then we have this finalized product so in this finalized product the feedback is contained and the prototype is developed into a final thing documentation takes place and optimization of whatever has been developed that takes place and we have this interaction a close interaction between the developers the programmers and the end user which result in an application right so that is the red methodology so now let's look at the advantages of the red methodology now since the developers are routinely meeting with the end users and they are in sync in terms of their requirements in terms of what they need they are reading not each other's mind but they know what the customer wants what the client wants so the development pace is very high then is the cost cost in terms of that it doesn't happen that some complex module or some complex part of the application is developed and that complex part which has taken a lot of resources in terms of man hours is not finally used or is discarded and that money is kind of lost that effort is lost and then is the developer satisfaction now any developer they would like to get their feedback and they would like to know that whatever they have developed they have actually delivered now in the red methodology since the the developers and the end user they are close intact in contact in touch with each other therefore the developer is getting direct feedback from the end user and the end user is happy because whatever the end user wanted that is being developed that is going inside the system so there's the developer satisfaction so these are the three main advantages of the red methodology now if you go on to the red disadvantages now we see that the red team they are meeting together the developers are meeting with the end users and they are meeting on kind of a one-on-one basis now the problem over here is that if the number of people in the team increases then there is the communication gap so the people are meeting over a changing drama over a changing story and it's kind of difficult to keep everyone on board so the point I'm trying to make is that red is fine when the scope or the scale of the project is small but when the scale increases when there is a lot of work to be done in terms of complexity in terms of modules to be developed then that is the weakness of the red then is the commitment a commitment in terms of that people sit together and they develop the requirements the developers and then user and then the developers go and do their work and the end user go and do their work and when they have to meet again they kind of feel that what is the purpose of meeting again and again and again so they kind of lose their commitment but that pays in the long run but in the short term it's not very attractive and finally the interface focus usually the end user is presented with the interface to the application to the end result and they are happy with it but sometimes the developers they lose track of the design methodology and they are just focusing on the interface and in the end they just hot pot do things connect things together and make something work which is doesn't follows the methodologies or the models of software engineering and that's where the problem lies and then what is PHP and comparing PHP with other aspects PHP stands for hypertext processing and it is used why because they are millions of users and websites and it is not very expensive to use also and I'll provide the details.