Since 1991, when it formally appeared on the market through a publication, Rapid Application Development ( RAD ) has been a real watershed between developers on the one hand, defend the process architecture and secondly, those who see in it the solution for saving time and money.
Initially based RIPP (Rapid Iterative Production Prototyping) of the 80, the RAD also adds values in many other processes to emphasize the reuse of components already tested or creating new reusable, facilitating software construction. Criticized for a supposed excess informal, is especially advantageous in some situations since the system can be divided into five or six independent modules.
short development cycle is the biggest advantage
Used primarily for information, one of the biggest advantages of using systems applications, the RAD is the extremely short development cycle strong>, from 60 to 90 days. It offers more flexibility to developers who can design and redesign several times since the use of the techniques of Fourth Generation, automating the generation of code and creating reusable code, means that there is no need for manual coding.
In addition to using the pre-existing classes, APIs (which also help provide a more consistent and standardized the appearance design), you can distribute each major function to a given team, only integrating the modules at the end of the project to form a whole. – unlike what occurs in cascade module, which is sequential
This reduces the construction time, allowing, among other advantages, the creation of prototypes that allow early visibility.
Modular construction streamlines the process
The system is especially suitable when the requirements are well understood, there is the possibility of modular construction design and this enables reuse of APIs. In addition, the technique also provides better results when performance is not the most important aspect when the scope of the project is relatively small and when the distribution is small. This is because for large projects more human resources for the formation of several teams, which already spends too endear the project are needed.
For small projects that require quick results with deadlines and streamlined processes, it is ideal, but one must keep in mind that all involved need to be in perfect harmony, as if one can put deadlines is broken risk in the whole model.
The system is also especially advantageous when the project involves technology that already has over a year of existence and whose technical risk has been reset. Thus modularization and commitment to deadlines for each phase are optimized.
But beware, it is not always the ideal
Despite offering a good range of benefits or there are some cases where it should not be the model employee, such as when technical risks are too high, when the degree of compromise between developers and customers is questionable when system can not be fully modularized interfaces or when system components are to be adjusted.