Leaderboard

Rapid application development abbreviated as RAD, is an agile software development methodology popularly followed in software development. This model was originally conceived in the 1980’s. A significant benefit of using this methodology is to get a faster project turnaround which makes it an appealing choice for companies and software developers working in a fast-paced environment. Typically, any software development project that can be divided into small modules, and which can be assigned to different developers from different teams can be developed using the RAD model. At the high level, RAD model contains 4 distinct phases namely; I. Requirements planning: Generically software development starts with a detailed planning phase spending a large amount of time with the users. However, RAD starts by defining a very brief set of requirements, as the methodology allows any change in the requirements during any stage in the development cycle. II. User description / user design: This is the important phase that sets RAD methodology apart from other methods where, the product is built through several prototype iterations. During this phase the developers work very closely with the clients to ensure that their requirements are incorporated into the product being developed and the expectations are met. The developer develops the prototype, the client tests it and both the parties get together to discuss what worked and what did not repeatedly until all or most issues are resolved, and requirements met. III. Construction: In this phase, the prototype or the beta model is converted into a full-scale working model. As a vast majority of the problems and requirements were addressed during the previous phase, the construction of the product can be quicker. Typically, in this phase, construction preparation, application development, coding and integration & testing activities are done. Even at this phase, clients can suggest changes and modifications or even new ideas to resolve problems. IV. Cutover: In this phase, the finished and finalized product is launched which includes data conversion, testing and switching over to the new system. Even during this phase, developers and clients work hand-on-hand to continue to identify and address problems. Reasons for laying emphasis on prototyping than planning: The prime reason why the RAD approach lays emphasis on prototyping than planning is to accelerate the process of system development. It also allows enhanced flexibility to make any adjustment as required by the clients during any stage of the development process. Prototyping also provides the ability to explore and understand the concepts more quickly. Most importantly it has a huge impact on cost. This table briefs the advantages and disadvantages of the RAD methodology: Advantages Disadvantages Overall cost of project is amazingly less as lesser number of developers are required Involvement of the client during the entire development life cycle is mandatory Customer feedback is prevalent during all the crucial stages Managing the project is a bit more complex compared to other development models It becomes easier to accommodate changes during any stage of the development due to the shorter iterations of prototyping Projects that cannot be broken down to modules cannot be developed using this approach Progress of product development is easy to gauge through different stages May not be suitable for small-scale projects due to the deployment of powerful automated tools and techniques which turns out to be costly Usage of reusable components significantly reduces the total development time of software projects Team leaders must coordinate more closely with both the developers and clients to meet deadlines Better product quality is achieved due to the usage of powerful development tools Usage of powerful tools necessitates involvement of highly skilled professionals Is this approach suitable outside software development sector? Yes, this approach is suitable and can be used widely in various sectors other than software development. This approach can be used in scenarios when a project needs to be done quickly. Upon research we find that the application of RAD approach has been successful and beneficial in the Banking, Financial Services and Insurance (BFSI), Automobile and Online Retail industries. With the growth in technology and usage of internet, there is a huge increase in customers opting for mobile banking platforms for financial transactions. With such a demand, BFSI institutions must move onto the mobile space to keep up with the demand. In order to meet this expectation from clients, a lot of solutions are developed and provided using the RAD approach. The rapid prototyping a derivative of RAD is widely used in the automobile industry in developing physical prototypes and scaled models for their designs. Thanks to the 3D printing technology that makes the process efficient and effective for developing the prototypes at the required pace. These prototypes are subject to various experiments to identify issues / flaws and discover areas of improvement prior to commercial production. Online retailing was getting popular even before the pandemic and has significantly grown and will grow in the future. In 2018, it was found that around 40% of the e-commerce transactions were using mobile devices. This has grown upto 54% in 2021 which describes the growing demand and requirement of mobile e-commerce applications. With the application of the RAD approach, retailers can develop and put to use simple, secure mobile applications in the shortest possible time to meet the demand.

RAD – Rapid Application Development The Problems with SDLC, Waterfall Model. Software development projects are different from other projects and need to be handled in a different manner. The use of traditional and linear methods for the development of software is not the best available option. With software projects being intangible, the user finds it difficult to visualize the end product and different stakeholders visualize the end product differently. In the traditional and linear development of software, the user is generally brought into the picture at the specification stage and at the inspection/delivery stage of the project. This is detrimental to the success of the software. The end-user needs to be a part of the project while it is under development and he is gradually able to visualize the end product and requests for changes to the original Software Requirement Specifications in a phased manner. Further, with the constant change in technology both in software and hardware, the possibilities of what is achievable keep on increasing. The incorporation of evolving user requirements, advances in technology, and changing business requirements need to be encouraged throughout the software development cycle. The traditional and linear Waterfall model fails miserably in this regard. Hence in software development projects, it becomes increasingly difficult to freeze the project’s cost, requirements, and timelines. There is hence a need to develop software projects on a different methodology from other standard projects. The erstwhile Software Development Life Cycle Waterfall model was most inadequate to keep up with the quickly changing user’s requirements and changes in technology, hence there was an urgent need to come up with more appropriate methods. There was a need to be more agile to the changing requirements and various agile technologies such as waterfall method, iterative development, and incremental development, prototyping is used in software development. The Need for RAD. In an agile software development environment such as Rapid Application Development, the advantages of incorporating the changing user’s requirements and advances in technology into your project can be achieved through prototyping and iterative development of the software. In this environment, the user’s requirements are not frozen at the beginning of the project but the user is allowed to change his requirements on seeing the prototypes. The Rapid Application Development methodology was put forward by James Martin in 1991. It focuses on the rapid development of prototypes through a quick iterative process. In the field of software development, it replaces a rigid and archaic system with a flexible and proactive one. Benefits of RAD. The RAD methodology has numerous benefits. Besides being a versatile development methodology, it is highly flexible and adaptable with both the developers and end-users making quick decisions throughout the process. The process being highly collaborative and iterative reduces the development time with all stakeholders coming to a consensus quickly. The risks that may be encountered in the project are addressed as soon as they come to light. This prevents the team from being suddenly blind-sided at a later date. Steps in RAD. Ankita Singh in her blog on blog.capterra.com has divided RAD into five basic steps namely 1. Finalization of Project Requirements. This step would be similar to the Define Phase of the DMAIC methodology in that the project is very clearly defined highlighting the goals, timelines, scope, etc. 2. Prototype Building. The success of the RAD is in the quick iterative building of prototypes. The Prototypes help the end-user to visualize the project and clarify or modify their requirements. The iterative development of these prototypes with end-user/other stakeholders’ approval at each iterative stage ensures a risk-reduced, quick development lifecycle. 3. User Feedback. Prototypes are converted into working models and end-users feedback is obtained to improve the model. 4. Testing the Model. This would include the integration of various parts of the project into one system and testing it out as a system. 5. Launching of the System. After testing the model and getting stakeholder approval, the system is set for launch. A pilot launch of the system may be done before the launch of the entire system. The FBI Example. An excellent case study of the difference is the two approaches to software development is the FBI case. The FBI had tried to develop a criminal case management system using the traditional Waterfall system in 2005 over a period of 5 years with an investment of $170 million. This first attempt using the Waterfall methodology failed. The FBI finally successfully developed the system using agile methodologies. The links to these case files are given in the references. References https://en.wikipedia.org/wiki/Software_development_process https://en.wikipedia.org/wiki/Rapid_application_development https://blog.capterra.com/what-is-rapid-application-development/ The FBI Case https://www.academia.edu/12133977/IT_System_Failures_The_FBI_s_Virtual_Case_File https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=495729 Agile Project Success and Failure (The Story of the FBI Sentinel Program)

It’s a system development methodology, developed to respond to the needs of delivery system very fast. First developed in mid 1970s by New York Telephone Co Systems Development center under the guidance of Dan Gielan. RAD term was originally used to represent software development process. In 1990, James Martin documented interpretation of the methodology in more broader sense that had variety of methods and speedy application development approach. Grew out of convergence of two trends: Increased demand of speed of doing business Ready availability of high-powered technological capabilities and tools Goal: To rapidly analyse business process To design a viable system to meet user’s requirement through collaboration To provide the finished product faster It’s a strategy of developing information systems. This is agile methodology, some of similarities and differences Its incremental approach, building upon something and making it better. Components and functions are built in parallel with each other Developments have very tight timeframe, product that is usable quickly Mini projects are pulled together to a working prototype Feedback is critical, helps refine prototype. Incremental and iterative in nature until prototype meets user requirement Four phases: Phases are same, but shorter and combined to produce more faster and streamlined development technique: Outlining requirements (Analysis and quick design): combines elements of system planning and system analyses phases of the SPLC. This includes discussion between users and project team to agree on specifications, scope, system requirement and understanding of constraints. Prototype cycles (Demonstrate, Refine and Develop): This phase involve development of prototype based on user specification, and interaction with use to validate and feedback. This is an iterative process and key to success. Another important factor is Segmenting the product in multiple segments, almost as independent product that will talk to each other, treated as parallel process and different project teams work independently same time. Different project team engaged work on building the final product out of working prototype. Development phase: Earlier phases shortens system functionality and user interface requirement while in the development phase its task are programming, application development, coding, unit integration, and system testing. Cutover phase – Final phase of testing, deployment, and user training. Relies on five key factors: Extensive user involvement - customer and developers interact, so that customer can share requirements to the developer, and get specification Joint application design sessions Prototyping Integrated CASE tools Code generators Deliverable's and outcomes: Application being developed A description of users and business process requirements Logical and physical design Application construction and implement with a plan for its continued maintenance and support Advantages: Reduced time to develop Increase reusability of components Encourages customer feedback Tackling integration early avoids later issues Disadvantages: Need strong team to identify business requirements Communication – As its involves multiple team, they is a heavy requirement to communicate and engage along the lifecycle. To be able to segment and modularize, some products can not be segmented Dependency on modelling skills, one should have data, activity and process modelling capability to make sure all the modules meet end result Requires high skilled developers and designers as teams work independently When to use RAD: Clear well-defined scope and business objective Product required in 2-3 months and can be segmented High availability of design specialists and developers to position them into projects Large budget due to requirement and time limitation If Technical architecture is defined and clear, key technological components are in place and tested Reasonable and well within capabilities of technologies in use Resources available with required business knowledge, available and can work on the project, need quick and correct decisions being made Mostly with large organisation, where they have project teams and skills available. Also, for products that need to go out of door quickly. Sometimes market competition influences use of this methodology with a goal of Quick to market and/or grab market share early on.

Rapid Application Development or RAD is an approach in agile software development that focuses on user feedback in ongoing projects through rapid prototyping. RAD was started in the 1980’s by Barry Boehm and James Martin with the understanding that software resources are not tangible like raw materials. Unlike in manufacturing where a physical design sets the design in stone for a time period. RAD makes use of the inherent flexibility of software which does not have a physical model. The four steps of RAD are Define Requirements: RAD starts of by defining requirements, but in this case, they are more akin to a loose set of guidelines instead of specific requirements. The main reason is to enable the team to change requirements in any step of the project cycle. Prototyping: The team builds a prototype that can be demonstrated to the client. At early stages of the project the prototype can cut corners or not satisfy all the requirements. As the project cycle continues the prototype fills in the requirements that can be met. Feedback: After the prototype is presented to the client, the team collects feedback on everything. In this step the requirements are scrutinized. Clients may also change requirements if they find that a certain requirement is too ambitious for current technological ability. If there is negative feedback the team returns to step two and create a prototype with the feedback in mind. This cycle continues till feedback is positive or the client is satisfied. Product Finalization: In this step the project is optimized to improve stability and maintainability. The administrative steps required before project or product handoff like documentation. The reason why RAD emphasizes prototyping over planning is due to the following reasons Speed: Due to prototyping RAD projects are more likely to meet deadlines. Cost: The prototypes that are created by the RAD team consist of customer requirements. In early prototypes the client may choose to remove a requirement, thus reducing the time spent on working on the requirement before it is cut out before final implementation. The time and money spent on features that are finally cut off are actually not spent in a RAD process. RAD is not only suitable to software development but to other complex projects. For Example, the US Air Force was saddled with the much-criticized F-35 fighter jet program. The program was first initiated in 1997 with Lockheed Martin being awarded the program in 2001. The project was extremely ambitious. Some of the requirements were difficult to realize with the technology of the day, causing delays for the entire program. These delays have caused cost overrun of such mammoth proportions that some estimate that the program will cost $1.7 trillion over the project lifecycle. The United States Air Force in order to not fall into the same budget and design pitfalls decided to use RAD in agile software development, open architecture, and digital engineering, for its Next Generation Air Dominance fighter program. The program has been so successful that the US Air Force within one year designed a virtual model and constructed a working full-scale prototype – and flew it. When you compare this to the F35 which was approved in 1997 and first flew in 2006, a full nine years and the fighter still has issues in 2021. So, we can see with the NGAD that RAD & agile software development have been used successfully outside of the software development sector. Source : https://www.outsystems.com/blog/posts/rapid-application-development/ https://www.forbes.com/sites/davidaxe/2021/02/23/the-us-air-force-just-admitted-the-f-35-stealth-fighter-has-failed/ https://www.defensenews.com/air/2021/07/07/watchdog-group-finds-f-35-sustainment-costs-could-be-headed-off-affordability-cliff/#:~:text=The%20F%2D35%20program%20is,Program%20Evaluation%20office's%202020%20estimate. https://www.defensenews.com/breaking-news/2020/09/15/the-us-air-force-has-built-and-flown-a-mysterious-full-scale-prototype-of-its-future-fighter-jet/