Introduction to Rapid Application Development (RAD)Model
Looking for some faster way of development? Does not want to implement an Agile methodology fully? Suffering from the slowness of waterfall methodology? Are you irritated on the restarting the development over and over for every change or new requirements? If all of the question’s answers are yes, Well, You need Rapid Application Development(RAD) methodology.
RAD is a framework that is for event-driven system development like call back or state machine.
RAD was invented by James Martin in the year of 1991. There are many upgrades and tweaks happened since then to finetune RAD model. But it is still a very popular methodology among software developers. It is very useful due to its semi agile and micro waterfall work principles.
Software Development Models:
A software cycle deals with various parts and phases from planning to testing and deploying. All these activities are carried out in different ways, as per the needs. Each way is known as a Software Development Lifecycle Model (SDLC).
Software life cycle models describe phases of the software cycle and the order in which those phases are executed. There are lots of models, and many companies adopt their own, but all have very similar patterns.
The issues with the traditional development model
Users are always better when it comes to providing exact requirements and specifications. In the traditional system if some requirement or specification gets changed after it was provided it is not easy to alter. The new and exact requirement will then come as a change requirement and may not be picked up for development in the first place itself. By the time it is picked and delivered, the necessity of the same may have changed again or may have been scrapped.
My Journey in Waterfall model
I can very well remember the days after our final code went to production. Numerous calls, tickets, bugs and change requests bombarded our mailboxes. We were puzzled if we had developed the wrong product. We were like seating in a war room to fix and test all the issues. After spending days and nights before production, we could not even go for a vacation for at least three months.
In this war room like situation if we got a regression bug. That was Cherry on the top. We used to start interacting with clients whose name, we never heard before!!
Sound familiar?? I know that you are smiling.
Rapid Application Development Model:
RAD is a linear sequential software development process model that emphasizes an extremely short development cycle using a component-based construction approach. If the requirements are well understood and defined, and the project scope is a constraint, the RAD process enables a development team to create a fully functional system within a very short time period.
Professor Clifford Kettemborough of Whitehead College, University of Redlands, defines Rapid Application Development as “an approach to building computer systems which combine Computer-Assisted Software Engineering (CASE) tools and techniques, user-driven prototyping, and stringent project delivery time limits into a potent, tested, reliable formula for top-notch quality and productivity. RAD drastically raises the quality of finished systems while reducing the time it takes to build them.”
Online Knowledge defines Rapid Application Development as “a methodology that enables organizations to develop strategically important systems faster while reducing development costs and maintaining quality. This is achieved by using a series of proven application development techniques, within a well-defined methodology.”
RAD mainly focuses on rapid prototyping. Once the quick prototype is created, the same is displayed to all. Stakeholders for feedback
on the contrary over a lengthy development and testing cycle. The concept of RAD is to treat a requirement as soft clay than a solid iron. It is a very necessary model due to the highly volatile market condition and super competitive market.
Over minimal iterations, these feedbacks are incorporated into the prototype and finally merged to the original code line.
History of RAD(Rapid Application Development)
Stanley Marcus of Neiman Marcus said, “There are only two things of importance. One is the customer, and the other is the product. If you take care of customers, they come back. If you take care of the product, it doesn’t come back. It’s just that simple. And it’s just that difficult.”
With the traditional, Waterfall model has a rigid, cascading, one-way steps of stage-wise of development. This code-driven approach is a major roadblock to the new generation software development.
Rapid Application Development(RAD) otherwise known as Rapid application Building(RAB) was a response to the plan driver waterfall process, inspired by the structured system analysis and design method(SSADM).
RAD in current days follows an open standard otherwise known as Dynamic System Development Method.
Barry Boehm initially came up with a spiral model which was(is now also) a risk driven development. In this approach, he introduced process modelling than methodology phases.
During the initial phase, Prototyping was seen as a way of reducing the risk. Later Tom Gilb’s rework on the prototype refinement became the Rapid Iterative Production Prototyping (RIPP). James Martin then further extended the RIPP model to today’s RAD(Rapid Application Development) model.
Definition of Rapid application development
As per fundamentals of information system 7th edition by Ralph Stair and George Reynolds -” a system development approach that employees tools, techniques and methodologies designed to speed application development”.
RAD promotes a very highly collaborative, team-based yet individual excellence dependent approach by evolving the requirements and delivering micro components. It promotes “to try before the client actually buys” culture.
Key Features of RAD
As per James Martin, the key features of RAD are as follows:-
- High-quality system
- Fast development
- Fast delivery
- Low costs
Four Pillers of RAD(Rapid Application Development)
The below section is about rapid application development stages explained on rapid application development framework. RAD idea was matured from the concept of business reengineering via radically rethinking the core business process. The prototype is the thinking out of the box” innovative model that helps reinvent the core business process.
Rapid application development has four pillars of success. They are
If one of the pillars are not up to the mark, RAD(Rapid Application Development) may not accomplish the project goal. Here are the details on the characteristics of rapid application development.
People are the first pillar of rapid application development. Rapid Action development needs correct skilled peoples involvement. These smart, cross skilled people can operate equally good CASE tools to achieve success.
Of course fast development of rapid application development heavily dependent on people. But these people need to be highly trained, highly motivated towards the end goal. When a similar mindset people form a close-knit team, each team member can play different, impact-oriented roles. The key players of rapid application development project all as follows-
Sponsor-A senior executive who approves and provides funds.
People Coordinator– They look at the project from the user perspective and provide necessary feedback to sponsor and team. In general, they are appointed by the sponsor.
Requirement planning team-A team comprised of the high-level user who determines the requirements and provides clarifications to the teams.
The user design team– A set of stakeholders who participate in the design workshop.
User review Board-A set of stakeholders who review the system and decide to go or no go.
Training Manager-A training manager is responsible for providing the team to RAD team members.
Project Manager:-The project manager looks after the development efforts, progress and clears any roadblocks.
SWAT team:-SWAT team is a very small team inside of the development (testing) team. They are highly trained and cross skilled. They can work together at a very high speed. Basically, They are the firefighters who comes handy during the high-pressure situation.
Workshop leader:-These leaders are specialist in conducting several series of workshop.
The second pillar of rapid application development (RAD)is the management. Being complex and fast RAD needs committed managers. They remove all bureaucracy inside the team and political obstacles. They promote the change in culture inside the team. They own, prepare, motivate individuals and SWAT team towards the delivery of the final product.
360-degree transparent management is ideal for building the system faster. A manager should pick and nurture the “Early Adapters” and motivates the “slow movers” by either money or pride or prestige or excitement or whatever makes them happy.
As per whitten (2004) “RAD is a merger of various structured techniques especially data-driven information engineering with prototyping technique to accelerate software system development” where management role is very crucial.
The methodology is the pillar of RAD.RAD methodology advocates the followings
- It combines the best available techniques and best available workforce.
- A software system can be implemented using RAD if the project is available in pieces. (small modules).Each RAD team is responsible to develop each component (module) to create the final product. However, each module follows a micro waterfall model provide it but in a shorter time frame.
- It processes the tasks in an effective sequence manner that eliminates waste(Lean manner) that makes the process even more powerful.
- It uses the prototypes that can be transferred to the final product quickly.
- It uses a workshop technique that becomes multi-stakeholders Logue instead of interviews or monologue.
- It uses CASE tools to rapidly generate prototypes, code generation reusability.
- It works on timeboxed manner as a result dev team can quickly generate the core then builds the refinements in an iterative manner in the subsequent releases.
- RAD follow a mixture of iterative and incremental model.
- User can provide their comments and feedback to a live system, not on the design document.
- Finally, it provides the success guidelines to follow and failure points to avoid
Phases of the RAD model:
RAD model is a combination of the iterative and micro-hybrid waterfall model. Iterative model and micro-hybrid waterfall method both are independent two working principles found in RAD(Rapid application development).
The iterative and micro waterfall phase
The iterative model in RAD(Rapid Application Development) is a four-step process. They are as follows:
- Requirement Planning
- User Design
- Construction and Implementation
This is the initial step of RAD where all stakeholders effectively collaborate define and prioritise the requirements. Apart from the requirements, the below items can also be finalized for each requirement.
- Project goal
- In and out of the scope
- System requirements
- Current and potential challenges
Rapid application development is no or very less planning oriented. During this phase, the customer provides the vision statements as a minimalistic way(gist) and all clarification regarding requirements also get clarified. Along with these the experts talks about the business modelling, data modelling, process modelling of the target scenario.
This is a critical step that helps to avoid expensive changes and miscommunication.
RAD advocates just enough planning(minimal)for the prototype development. It uses various techniques like brainstorming, task analysis, from analysis, user scenario elicitation.FAST(Facilitated Application Development Technique).
Requirements gathering techniques are as follows:
The information flow among business functions is defined by answering questions like what information drives the business process, what information is generated, who generates it, where does the information go, who process it and so on.
The business model shows and it is designed to depict how the information flows, how the information is distributed within the business components(channels). A detailed business analysis needs to be performed to find this information flow. The analysis also tells how the information can be fetched, when the information is processed and what are the factors affecting a successful flow of information.
In this phase, the whole group tries to find out several business-related queries like-
- What kind of data actually drives the whole business?
- What is the business-critical data?
- What Kind of data normally gets generated?
- What are the methods for obtaining the data?
- Who and which portion of business generates the data?
- What the path of flow of data or business information?
- What happens to those data or information?
- How these data are processed?
In this phase, a complete picture of the business is depicted.
In short, this phase gathers all information about
- Process input, output
- Integration Points
- Productivity measurements
The information collected from business modelling is refined into a set of data objects (entities) that are needed to support the business. The attributes (character of each entry) are identified and the relation between these data objects (entities) is defined.
The vital information obtained from business modelling is reviewed and analyzed to create more meaningful sets of the data object in the data modelling phase. In this phase, all attributes for the data sets are identified, defined and recorded. The relationship between the different Data set is also recorded.
The information collected from the business model is accessed for customer benefit. Data modelling phase gets repeated several times as the project evolves.
In short, this phase gathers all information about
- Data input and output
- Different systems to gather and analyze.
- Data source
The data object defined in the data modelling phase is transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting or retrieving a data object.
The data objects identified in data modelling are converted to business process guided by business Modeling. The flow of data or information is established. The ability to add, remove, fetch and modify to a data object is provided.
Process modelling phase also gets repeated several times as the project evolves.
User Design/Building prototype
During this page designers, Architects, developers create the prototypes. The team may consult with the client for building the prototypes. Feedbacks are not only functional, but it can also be of any type models, visuals, UI, interfaces etc.
The team uses joint application development(JAD) technique with CASE tools. This will translate the user needs to a working model test team if exists(separate) create and automate test cases by seeing the requirements.
User design is a continuous interactive process where the users are allowed to understand, modify and finally approve the working model of the system. This developing and refinement happens in parallel to the iterative process.
The delivered prototypes, when transformed into working code, is known as components.RAD’s working prototypes mostly does not have full-scale capabilities.
What is a Prototype?
A prototype is a lightweight version of the actual product that shows the actual behaviour of that application component. Prototypes can be categorised as
- Wireframe prototype:-it is a very basic pictorial representation of the product.
- Designed prototype:-it is the prototype that follows the projects specific colour scheme and implements user interfaces.
- Functional prototype:-it is a button lead, clickable prototype. These prototypes are purely driven by the user interface.
The prototype building process is often referred to as sprints. In each sprint, developers need to deliver prototypes. Each sprint duration maybe one to two weeks. RAD is often called model-driven development. The models are as similar as the business/ Domain.
Component (model/prototype)-The components are created keeping reusability in mind. A non-reusable component/module/prototype is very specific to a project/client. The fundamental objective of module creation is to reuse.
Reusable components are kept in the domain-specific repository. If needed they can be reused across projects/clients. This phenomenon provides quicker development.
The components can be inhouse developed or a set of the third party procurements.
Similarities between Prototype and MVP
Minimum Viable Product(MVP) is used in Agile that refers to the “first draft” of an application or component. MVPs are not ready for the market but it is developed by capturing enough of the requirements that it can be shown as a Prototype for the iteration.
The Prototype in RAD (RApid application development) is similar to “first draft” of the component with the usage of the “gist” of the requirements. But the prototypes are developed “quick and dirty” manner. Then the refinements start.
Automated tools are used to facilitate construction of the software; even they use the 4th GL techniques. The actual system is built and the corresponding code is generated to create a prototype from process and data models.
The prototypes(Some prefers to call it as beta systems).As most of the challenges are already addressed in the design phase, this stage can go relatively faster. However, This stage is also open to changes.
4GL languages offer object-oriented programming techniques that allow reusable components. This object-oriented feature allows developers to rewrite the component code in case they need to redesign the application and relink them back with the newly/ updated component.
The latest container Technology improves the code generation proves thus further improves the coder’s efficiency. It also keeps testing the application in a different environment.
Construction with live feedback
Construction is having two different phases like
- Finetune prototypes with Feedback
- Testing the solution
Finetuning the solution with feedback
The working prototypes are converted to working models then the models are displayed to the customer and other stakeholders for feedback. The best prototype among all the developed one is selected and discussed upon. The scrapped models and codes are preserved for documentation and future release.
All feedbacks are there in Incorporated into the best one. Test team can fine-tune the test cases and create more negative-positive scenarios against the model.
Testing the solution
The automated and manual test cases develop so far starts testing the model. It ensures that the model is working as per expectations and requirements. The prototypes are now tested to find differences with the requirements.
The testing phase is significantly shorter for individual prototypes as during development phase most of the testing is done.
When Bugs will be fixed in RAD?
Prototyping actually allows the development team to carry out feasibility analysis in a very fast manner particularly for Complex and risky components. This makes the software more robust, list defect. The bugs are fixed over iterations. As many discussion and prototypes involved, lesser defect formed.
Do we need to create Documentation?
During the final stage, the prototype is connected to backend via a live system. The best practice says developers need to create exhaustive documentation of the prototype. However, in reality, developers produce just enough or very little documentation. They do not do it intentionally rather they have constant pressure to deliver the next task. However, the functional team prepares the SRS documentation.
The cutover phase is also known as the transition phase. Cutover has two inbuilt phases
- Present the System(User Acceptance Testing)
- Go live
Present the system(User Acceptance Testing)
The working software model now placed in front of the customer to carry out acceptance testing. Once this step passes the code moves to version control for further processing. Test team carries out integrations testing as the code merge happens before Go_live and after acceptance.
The operations team accepts the code and pushes the same to the server for successful go live.
Tools of RAD
The fourth pillar of RAD is the tools. Human brain along with the powerful tool makes RAD even more powerful.RAD uses CASE (Computer Aided Systems Engineering) tools for system models data models process models, detailed designed and program structure creation. The availability of powerful CASE tools provides an ability to make software faster, cheaper, better.
Diagrams play a vital role in representing planning information, an overview of the system, system modelling, data modelling, process modelling, detailed designed. Diagram also propelled clear thinking.
Data Modeling diagram should show the entity-relationship diagram(ERD),which in turn define each entity file(via File Descriptor(FD)). Data Set Diagram(DSD) should also represent the FD(File Descriptor).
Tight integration of analysis and design tools with a feature of code generator provides higher productivity. As a result, the developers get the structure of the code in parallel while designing the software.
RAD must be supported by a code repository which can store the generated and developed code for future use.
Rapid application development should
- Not use a procedural language
- Always generate a prototype model.
- Support plans, models and designs that can be expressed
- Generate source code from high-level constructer.
- Provide important functionality like – object-oriented coding, use of pointers, exceptions information.
A quick concept of the technology and tools
- Configuration >AML files
- Messaging –ZMQ
- Deserialization -Google protoBuf
- Logging—Easylogging, Log4j
- Online DB—Redis in memory
- DB offline—mongo
- Fiolemaker- Cystalreport
- Design and prototyping- Figma,
- Development- LCAP,HPA PaaS,MXDP
- Development focus platform- Embarcadero, RAD Studio,CUBA
CASE tool provides interoperability, extensibility and portability to the application. RAD uses PaaS( platform as a service) heavily as to build quick. PaaS provides seamless cloud hosting, platforms for designers code creation, installing and managing custom made business applications.
Apart from these PaaS also provides infrastructure data security, data management and user interface. In PaaS developers do not need to concern on anything else except the model or prototype.
Tools Used in Design and Prototyping
|InVision||Web, Mobile, Wearable||macOS|
|Mockplus||Web, Mobile||macOS, Windows|
|Balsamiq||Web, Mobile||macOS, Windows|
|Adobe Experience Design||Web, Mobile||macOS, Windows|
|JustInMind||Web, Mobile, Wearable||macOS, Windows|
|Proto.io||Web, Mobile, Wearable||Web|
Tools Used in Testing and capturing feedback
|Red Pen||Web, Mobile||Clients|
|Usability Sciences||Web, Mobile||End-Users|
|Validately||Web, Desktop, Mobile||End-Users|
Tools core development
|Salesforce AppCloud||Web, Mobile||No-Code, Low-Code, SDK|
|Alpha Software||Windows, Web, Mobile||Low-Code|
|Visual LANSA||Windows, Web, Mobile||Low-Code|
|Spring||Desktop, Web, Mobile||SDK|
|Kony||Web, Mobile||Low-Code, SDK|
|OutSystems||Web, Mobile||Low-Code, SDK|
|HokuApps||Web, Mobile||Low-Code, SDK|
|Mendix||Web, Mobile||Low-Code, SDK|
Rapid application development generally follows the “no vendor lock-in” category. Even though there are fabulous tools available in the proprietary section using open source technologies is a way to go on the current era. Using an automated code generator reduces 85% manual coding.
Advantages and Disadvantages of RAD(Rapid Application Development):
RAD reduces the development time and reusability of components help to speed up development. All functions are modularized so it is easy to work with. For large projects, RAD requires highly-skilled engineers in the team. Both end customer and developer should be committed to complete the system in a much – abbreviated time frame. If commitment is lacking RAD will fail. RAD is based on Object-Oriented approach and if it is difficult to modularize the project the RAD may not work well. Rapid application development advantages and disadvantages are explained pointwise as below:
Advantages of RAD(Rapid Application Development)
- Provide greater flexibility and adaptability for change requests or on the fly demands.
- Provides quick adjustments to the new requirements.
- It provides better quality as lot more interactions, prototypes are involved before the delivery.
- It incurs lesser development cost as less number of developers needed.
- RAD provides simple adaptability. The code can be changed even after the whole software is built to alter the functionality of the system or to create/ modify new components.
- Reduces development time by providing quick and effective iterations. Hence no waste of time, created components, rather, provide quick reviews and feedback.
- RAD model can transfer deliverables as code, script, high-level of abstractions.
- Very quick internal review parallel to development is possible so lesser Integration issues as it is spiral in nature.
- Overall speed up the delivery time due to shorter iterative models.
- Provides a great shift-left approach hence no new surprises.
- Provides the opportunity to communicate and collaborate better. All key stakeholders can discuss and remove the darker side/ grey area of the requirements.
- RAD encourages customer feedback thus provides higher risk management via constant discussion with the client and key stakeholders.
- RAD allows Rapid low-cost iteration that in turn allows the organisation to a fast and series of releases to improve their products.
- User can get the requested product in less time. That means quick to market.
- RAD encourages newer innovations into practice and reduces the number of information silos into the system.
- Provides much more customer satisfaction as the RAD process can be measured, tracked and delivered as per schedule.
- Provides an ability for the developer to reuse the code. Reusability brings speed in development by reducing manual coding. Fewer codings generate less manual touchpoint hence reduces manual errors.
- RAD model generates a task-oriented structure of the project. The task can be allocated to specialized and experienced team members. Except for the SWAT team, everybody works in their comfort zone. Managers can optimize this task for better team productivity and efficiency.
The shortfall of Rapid Application development or disadvantages of RAD model.
No software development models in software engineering are flowless. Here are some disadvantages of RAD.
- RAD brings the development, business, testing team together for better collaboration and communication.
- The model is very much dependant on the individual experts. If due to any reason, the member is not available the process of delivery slows down.
- This model needs highly cross skilled developers and designers as well as highly dependant on modelling skills.
- Due to the huge costs for modelling and automated tools, lower budgeted projects are not suitable.
- Only distinct modular systems can be produced using RAD.So scalable component-based systems are applicable to uptake RAD.
- The system has to module driven. Each module should have the capability to be flexible enough to accommodate new elements. Each module also should be independent enough not to disturb the whole system if removed.
- Need user feedback doubt clearing session more frequently. This customer engagement may create dissatisfaction among clients as business to invest their time and money along with the development team.
- RAD is only applicable when the development cycle is shorter.
- RAD does not focus on non-functional requirements.
- If finally, the prototypes when transformed to components are not reusable, the model will fail.
- The RAD manager needs to work very closely with RAD team members, SWAT team and customer to steer the project in the correct path.
- In case the gist about the requirement is not clear or ambiguous, the first prototype will be always a failure. The effort, energy and money is often lost.
- In case reusable components count increases that in turn increases the chances of project failure.
- When technical risks are high, RAD may not be applicable for the projects.
- As there is no documentation concept, it is very difficult to show progress and accomplished tasks.
- Bureaucracy, Igo, and other management issues impact the delivery very quickly.
- When project scope increases and volume of delivery increases, multiple teams need to be added to complete the demand. It is seen that if becomes very tough to handle a big RAD team. This results in inconsistent delivery and unsatisfied customers.
- Being a new approach that deviates from the traditional process creates an obstacle in the human mind. As human always reluctant to change.
- If the system is constantly getting micro-changes after sometimes the system deviates very much from the original one. All these changes it does not follow the system architecture may cause poor design. These may later need an overhaul of the entire system.
When to use the RAD(Rapid Application Development), model?
In the following cases, we can adopt the rapid application development model-
- Requirements are changing frequently in other words dynamic requirements for your project.
- Enough business analysts are available along with cross tools skilled available in your project.
- Enough skilled designers are available to carry out modelling.
- When you know the basic requirements upfront and your technical risk is less.
- you can uptake RAD when you have a strict deadline to finish the development.RAD provides coding on-the-fly approach that saves huge unproductive time of development.
- You can adopt the RAD model if your user is comfortable to work with prototyping model and feedback system.
- You have enough budget to acquire the modelling tool along with automatic code generation tool and equally skilled persons.
- If your team has experts who can decide which model to peak(RAD or SDLC)
- When you are transferring application with a pilot project with prototypes, RAD is extremely helpful.
- Finally, if your client agrees to this module driven approach and available to classify doubts quickly.
How do check if our team is RAD ready?
The answers of the below questions will give you an idea about the teams RAD readiness.
- People-Do you have cross skilled, experienced developers, designers who can carry out a time-boxed delivery? Does your team members have an all hands on desk mindset?.
- Openness to adapt– Do your team and other stakeholders are open to RAD?
- Timeboxed delivery-Do you need a timeboxed delivery? Does everybody is aware of and adhere to the timeline?
- Tool support-Do you have enough tools to implement RAD?
How to make RAD work for your Organization?
RAD is a phased development that actually divides the whole process (System) into a series of versions. These versions are developed sequentially. The most basic and obvious requirements go into the first version.
When the prototype od the first version is being made, the functional team can generate the set of second version’s requirements.
These requirements can be presented when the first version’s demo happens.
For the developers, these are the inputs for the second version. This process continues until the model is completed.
The first phase of development is always “quick and dirty”. From then the refinement starts towards perfection.
You need a basic project map to keep track (measure) the development. This project map is evolving in nature.
Hire highly cross skilled employees or train your employees to be multi-skilled.
Once you have chosen RAD for your project, you can follow the below steps to make RAD a successful model
- Create a plan for building capabilities to deliver incrementally.
- Set clear expectations with all the stakeholders(client, developers, business experts, SME(Subject matters experts))
- Promote “Pull your socks” attitude for firefighting.
- Identify resources who can be part of the SWAT team members.
- Identify a balanced and experienced project manager.
- Incorporate tight security.
- Maintain RAD’s philosophy – Flexible, Fast and Open-ended solution
There are several development methods available for RAD like:
- Classic RAD development
- The dynamic system development model(DSDM- Stapleton-1997)
- Information System Development Model(ISDM- Avison and Fitzgerald-19195)
- Architecture Driven Development and Architecture Tradeoff analysis
You need to pick any one model and start building the solution.
3 Best languages of RAD
All 4 GL languages support RAD but here is a list of languages that supports RAD :
RAD has a huge market share. This market can be divided into
- Business Function
The Type can be further divided into
- No code development platform
- Low code development platform
RAD application development market can be further divided into
- On-premises development
- Cloud development
Case Studies on RAD
- According to PWC research, Non-Waterfall projects are 28% more successful than projects involved in the traditional approach.
- As per Mendix research 71% of IT, teams are behind their schedule due to increasing demand for IT products and slow traditional system.
- Another study shows 65% of the turnaround time expected by the business is cut shorted to meet user demand.
- RAD is having 80% lesser coding than traditional development process.
- RAD is having 75% lower maintenance cost than the traditional development process.
- British Rail carried out a RAD project in 1996 on recording time and attendance of employees. The project was completed in 4 months.
- UL Football Association developed three ways interlinked information system in 1996 to support EURO-96 football championship. The project duration was 3 months.
- UK financial company, Norwich Union created an electronic trading system in 1996 just in 3 months using RAD.
Difference between RAD and Traditional development Model(waterfall)
RAD is the new future. Slowly and steadily RAD will replace the traditional development model for sure. Apart from the replacement of the traditional model, RAD can also replace ADDIE or instructional system designs.
let us check out the difference between traditional software development and rapid application development.
|Traditional Development model||Rapid Application Development|
|In the regular Waterfall model, developers generally work in silos, they hardly get direct feedback(appreciations) for their hard work. Most of the time it is the managers who get the limelight and actual developers work in shadow.||RAD provides an opportunity for the actual developers to showcase their hard work and get fast hand feedback along with appreciation.(they need for personal satisfaction and appraisal) by this process a satisfied developer gets motivated.|
|Delivery is late. Possibly after 6-9 months. It uses a linear approach to software development.||Customers get what they wanted with/ without feedback. This gives them confidence in the people, process and product. It is a Win-Win situation.RAD follows an incremental and iterative model to develop the software.|
|In Traditional waterfall or V model, testing happens after coding is completed||Rapid application development allows testing to happen in every iteration.|
|In the traditional approach, developers interact with the customer at the beginning of the project, during delivery, bug fixing and acceptance testing-time frame.||In Rapid application development, the developers regularly interact with client or user for feedback|
|In traditional application development, there is a lot of planning and analysis done before actual coding||In Rapid application development planning is minimalistic. Analysis and live discussion happen with LiveCode development.|
|In traditional application development, we Spent time and resources to build a Zombie feature that cannot be recovered. As a result, effort and money are lost.||RAD focuses on specific requirements. Build them via a prototype. Hence there is no loss of time and resource. It is a cost-effective process.|
|Traditional development model focuses on working software.||RAD focuses on speed of delivery.|
|In traditional development, the team size is huge.||RAD team size is relatively very low.|
|In traditional development, input comes as a requirement document at the start of the project.||In RAD the gist or loosely set of requirements are given at first. With every interaction, the requirement gets better shape.|
|In Traditional development, change in requirement is treated as a new requirement.||Change in the requirement is treated as an input for the requirement.|
|In the traditional development-any change in the requirement is very tough to integrate and prioritized at last to implement.||RAD supports and welcomes changes in the requirement.|
|The process of visualization and definition of project details before starting the project leads to high customization. This, in turn, leads to high development time.||RAD uses several predefined libraries that leads to faster development.|
|It is best suitable for medium to long projects with higher development and maintenance costs.||RAD is best suited for a short project with quick development and low maintenance cost.|
|Testing is only performed at the end of the development.||Testing is performed at every iteration.|
|The application and related elements are further customized as per requirements. Hence they are exclusively applicable for that project only.||RAD uses predefined, tested, ready to use components. This reusability of components across projects make it faster.|
Difference between RAD and Agile
Agile methodology came later than RAD hence Agile methodology is more evolved, refined and mature. You can get more idea on Agile here.
|Agile focuses more on process, models and work environment.||RAD, even though it is an elastic model focuses on quality delivery, modelling and prototyping techniques and timeboxiness.|
|It does not fully dependent on personal excellence. Agile focus on many teams (geographically distributed) and a large number of engineers.||RAD focuses on single teams with very limited people.|
|Agile focus on mid-size and large projects.||RAD focus on smaller projects|
|Agile uses prototype to design or to gather business analysis data during the discovery phase.||Prototype creation is the heart of RAD. After prototyping, developers create actual production code by reengineering on the prototype.|
|The solution is divided into feature and feature is divided into task and subtasks.||Developers create a feature at the first attempt and improve it until perfection.|
|There is no specific project manager available. The team is self-managing and self-organising.||There is a project manager who manages the project.|
|Agile follows its own standard process.||There are no specific standards in RAD.|
|No silo mode of working hence quality product gets generated as a whole team.||Mostly developer works in the silo that generates unmaintainable and Poorly designed code if the individual coders are not so skilled.|
|Agile focuses on quality working software.||RAD focus on speed.|
Will RAD(Rapid Application Development) helps a startup?
Change is the only constant in today’s market. Due to the ever-changing nature of demand, companies need to be flexible enough to adapt to these changes. Competitors and numerous startups make the situation even more competitive.
Have breakfast or you will be somebody’s breakfast” with this philosophy, the companies need to drive business keeping the customer as a king. The development has to be client requirement driven then another way around.
In my views, Yes is the perfect tool and methodology that helps the startups? Let me explain which are the features will help a startup most:
- Getting user feedback is difficult, costly and time-consuming, long and never-ending meeting, phone calls, review of large design doers are the foundation of software design in traditional methodology. But RAD methodology advocates feedback system throughout the developmental model but cuts down documentation non-productive developmental activities.
- Prototyping acts as a tentative alternative to design specifications. Hence RAD works beautifully where project focus is more on GUI than the non-GUI.
- Faster go to market for any application development solutions.
- Innovative applications that have less budget but need to go to market as soon as possible.
- RAD does not allow huge specification documentation rather it starts by defining a gist of the requirement. These gists are set of loose requirements. They are loose in nature as RAD welcomes requirement changes. This is a perfect fit for a startup.
- All pre-created, ready-made components are customisable to create a new component out of it. This is the main fuel for speed.
- RAD methodology supports a homogenous environment to support a complicated application architecture with an organisation by standardizing them. The developer can then improve maintenance of the application and several reusability characteristics including user-friendliness in the upcoming patches.
- RAD is a graphical model-driven approach with pre-built application components that allow users/ clients to visually construct complex business processes and application without much or no coding at all.
- RAD is a tailor-made solution” what you need is what you get” is followed.
RAD is best suited for mobile application development that has user experience rich consumer-facing along with small scale e-commerce,web-based development
RAD team members need to be skilled both socially and business along with the usage of sophisticated tools. Hence team-building activities (like team outing, team dinner etc) are very important. Remember all work no play attitude may break the team.
For startups, client judge the quality of the solution by using the UI(User Interface) Where they can quickly interact with the system. This put more importance in the UI rather background framework and code.
Finally RAD offers a value-driven development that in turn helps the start-up to increase ROI.
When RAD(Rapid Application Development) will not work?
RAD emphasizes a quick development cycle(typically-30-90 days). This methodology is not applicable for developing highly Complex application or an application that processes a huge volume of transactional data(like batch processing application).
RAD model needs a new way of managing and leading projects requirements. the whole team including manager need to adopt this paradigm shift. Else the project may not go well.
As per General Dwight D Eisenhower “In preparing for battle, I have always found that plans are useless, but planning is indispensable”. Similarly in RAD, it needs some planning but they may change quickly.
Collaborative does necessarily mean co-locating. The distributed working team can work on RAD effectively if the setup is done correctly. So if the setup is not good, RAD may fail.
In the case where the project is not dependent on prototypes, RAD is not applicable to those projects. In these cases, if a prototype fails, it may cause huge harm and damage.
Few applications where the RAD is not applicable are as follows:
- Flight control software
- Coronary implement firmware
- Finance and accounting system(huge)
5 Alternatives models to the RAD model
In RAD as it focuses speed over quality, so the prototypes mat lack of quality. The quality can be regained by using experts technical people with the right tools.
Below are the best alternatives to the RAD model:
- Waterfall model
- Lean Development
- JAD- Joint Application Development
- DSDM- Dynamic System Development Method
Michael Hammer writes, “Radical surgery is needed in IS processes. One of the first ideas that will have to go is the whole notion of traditional development lifecycles.”
So we can conclude RAD is a super active model that generates software at a rapid speed. With comparison to the traditional model, we can observe the shift-left approach that reduces risk and bugs(defects at later stage costs a lot).
Professor Clifford Kettemborough thus states, “It is believed that the dominant trend of our era—in technology no less than anywhere else in our businesses—is unrelenting, accelerating change, and we expect that trend to continue for the foreseeable future. If we are correct, [organizations] that fail to adopt RAD…will simply be left behind.”
Modern companies rely on RAD to create web and mobile related application to meet their daily business requirements. Important note-most businesses are in the adoption phase and yet to get the full benefits of RAD. They are still trying to operate RAD on full capacity.
What is your thought on RAD? Do you understand RAD from this article? Share your story, experience or via the comment box below. If you like this article please consider it sharing. You can also pin the Twitter, Facebook, LinkedIn to get such an update. Alternatively, you can join the mailing list.