Rapid application development: RAD model

A man sits at a laptop, focusing on his work. His monitor displays a projection of bar and pie charts, showcasing data analysis. In the background, a rocket symbolizes the speed of rapid application development (RAD), while two stacks of coins represent the fruitful outcomes this methodology can achieve.

Rapid application development model or RAD is a project management methodology, similar to agile or waterfall, that can be implemented in custom web engineering and custom mobile app development. The core idea behind the RAD model is to accelerate development through short iterations and continuous feedback, emphasizing execution over extensive planning.

The RAD model was introduced in the 1980s by Barry Boehm in his paper, “A Spiral Model of Software Development and Enhancement.” It arose as a response to the rigidity of the waterfall model. Later, in 1991, James Martin further elaborated on the model in his book, “Rapid Application Development.” Today, RAD can be used by following Martin's concepts and integrating modern technological advancements.

An image shows a spiral application development model by Boehm. This model predates the rapid application development model. It follows a cyclical structure, similar to a spiral, with each cycle encompassing the following phases: plan, design, develop, verify, and then proceeding to the next level of detail.
Spiral model of software development by B. Boehm

In this article, we will have a closer look into the rapid application development model as formulated by James Martin, explore its enduring relevance in the era of modern technologies, and examine a contemporary project management framework based on the example of Ronas IT.

Key characteristics of the rapid application development approach

The model is for commercial products

The RAD model, as described by James Martin in his book, is particularly well-suited for commercial product development rather than complex systems creation. This model remains relevant today, serving as an effective approach for any enterprise or business developing a new product.

RAD model promises lower costs

The key characteristic of the RAD approach is developing in small, agile teams, using code generation to speed up the process. This minimizes the need for large development teams, resulting in lower costs and faster deployment times. Automation of tasks within the RAD model proves to be more efficient and profitable than traditional, larger team structures.

No compromise between speed and quality

Martin offers to achieve the desired quality of the product through its early reach to end users. In other words, prototyping is key. The sooner the application creator understands what a target audience needs, the better the result will be. Thus, iterative development practiced within the RAD approach helps to avoid implementing unnecessary features while meeting users' demands.

An image illustrating the key features of the Rapid Application Development (RAD) model. These include: small teams, reusable components, automated tools, user involvement, lower development costs, higher quality, better alignment with business needs, and reduced maintenance costs.
Rapid development principles formulated by James Martin in “Rapid Application Development”

There are four essentials to rapid development

These are tools, people, methodology, and management. Developing in small teams is nearly impossible without computer-aided software engineering (CASE), or rather, the latest technologies. Tools are crucial, but they are ineffective without people who know how to use them efficiently. Therefore, skilled development teams are equally important. Additionally, having a well-defined methodology that is neatly managed is essential.

There should be practical metrics

Practical metrics should be established for each project within a company, and specifically for a development team. Nowadays, team metrics are often measured through time trackers. However, the Rapid Application Development (RAD) model provides specific project and teamwork metrics. According to Martin, these metrics should be:

  • Small
  • Graphical
  • Easily computed
  • As reliable as possible
  • Objective, in that they measure external characteristics of the system
  • A basis for estimating
  • A basis for taking corrective action when needed

He also emphasizes that the main metric should be the total elapsed time or development cycle time, as it clearly shows the progress of the rapid application development process. Although specific tools for measuring progress have changed over time, the basic principles remain the same.

At Ronas IT, we help businesses visualize their data with convenient tools to better understand the company's state of affairs. You can read more about the importance of data visualization in our related article.

Automation is key

Recommendations for improving application development in the original rapid application development model might seem outdated to modern engineers. Nevertheless, they can be boiled down to two critical concepts: automation and reusability. Martin praises development with reusable components, which modern frameworks often include. For example, the current React Native and Expo ecosystems help our team significantly speed up mobile app development.

This principle can be applied to pre-developed features that a skilled team doesn't need to recreate for every new project. For instance, once a payment gateway is developed, the development team doesn't need to “reinvent the wheel” for every new commercial app they create.

Phases of the rapid application development methodology

The rapid application development methodology laid the foundation for the agile methodology. Like RAD, agile methodology implies breaking the product creation process into phases and focusing on continuous improvement. Both RAD and agile development are cyclic, but agile has more phases than the RAD model. Nevertheless, let's begin by looking at the phases of Agile's predecessor.

In RAD methodology, the software development life cycle is divided into four phases:

An image illustrates the phases of the rapid application development (RAD) model. The first arrow and step is "define project requirements." Next, there is a user design phase represented by a circle surrounded by arrows moving clockwise. The circle is labeled "user design," and the arrows around it are labeled "prototype," "test," and "iterate." The following step and arrow is called "rapid construction and feedback." An arrow connects this phase to the user design phase, illustrating that after feedback, developers enter a new cycle of iterations. Finally, the fourth arrow represents "finalize product/implementation."

Requirement planning phase

No matter which stakeholders are involved in this phase, the planning should be performed from the end user's standpoint. Martin suggests involving users in planning and design. This rapid application development method persists today and is conducted through customer interviews and prototyping. It's beneficial to revisit the original source of RAD, which recommends two techniques for user involvement: Joint Requirements Planning (JRP) and Joint Application Design (JAD). The first technique, JRP, is conducted during the requirements planning phase.

The results of the joint requirements planning should be the following and are still quite informative and useful for the startups:

Outputs of the joint requirements planning from Martin's “Rapid Application Development”

  • List of departments and locations served by the system
  • List of system objectives
  • Details of possible system functions: benefits, ROI, prioritization
  • A process decomposition diagram of the system
  • A process flow diagram of the system
  • A flow diagram showing interfaces with other systems
  • Listing of unresolved issues: responsibilities, deadlines, details
  • Implementation target dates
  • What happens next

User design phase

Martin advocates for involving end users in the nontechnical parts of the development process. User convenience should always be a priority in the UI/UX design of any application. However, considering the extensive study of user behavior, there may not be a direct need to involve users in the design process, at least not in the UI/UX design. The goal here is to adhere to patterns familiar to users of Android or iOS platforms. Nonetheless, it is still valuable to test the design later with a focus group discussing the app's prototype.

In fact, prototyping is seen as the main approach to design within rapid application development methodology. Martin gives the following definition to the term, “Prototyping is a technique for building a quick and rough version of a desired system or parts of the system. The prototype illustrates the system to users and designers.” So it's about testing the functionality and design before they are fully elaborated, which eventually is very important in exploring the right way to product-market fit. Today we use a clickable prototype to verify it.

Construction phase

This is the phase where design is transmitted to code with the generous use of automated rapid application development tools. Testing of the code should be performed in parallel with transforming data models and processes into the final working product. The construction itself should be carried out by SWAT teams, which stands for Skilled With Advanced Tools. This means the team should be small, highly skilled, and equipped with tools that allow for faster product development.

Cutover phase

Testing should not be performed manually after the code is written, as it takes substantial time. This approach aligns with modern development practices, where automated tests eliminate the need for a lengthy manual testing process. For example, in React Native development, we use tools like Maestro and Detox to conduct end-to-end (E2E) tests. End-to-end testing mimics real-life scenarios to assess the app’s performance effectively.

Waterfall development model phases, from top to bottom: requirements, design, development, testing, deployment, maintenance. Each phase is distinct.
Waterfall model in software engineering

The rapid app development model as opposed to the waterfall model eliminates the need to adjust to a strict plan and adds flexibility to the development process. The following are the points in which the two approaches differ.

RADWaterfall
Project flowEven though RAD has phases, development is performed in iterations that include coding, testing, and feedback gathering.Has a sequential process where development cannot move to the next step without finishing the previous one.
Development stagesConsists of four phases: user requirements gathering, user design or prototyping, construction, and cutover.Usually has the following structure: requirement gathering, system design, implementation, testing, deployment, maintenance.
Required timelineTakes less time due to iterative approach allowing for faster delivery of functionality. RAD doesn’t rely on strict planning and rather focuses on user feedback in iterations.Takes more time as each phase is completed fully. Requires extensive upfront planning.
User feedbackUser feedback is integrated continuously throughout the whole process of development.User feedback is limited to the planning and final delivery phases.
TestingInspires continuous testing with the use of automation.Quality check is conducted later in the process which might make it costlier.
Project typeGood for web and mobile app development where user feedback is crucial and time-to-market is essential.Suits projects that are well-defined and have strict requirements. These are usually large-scale systems associated with high risks.
Pros and consIn general: flexible, rapid, lower risks. But: resource-intensive, requires constant user engagement, inconvenient for large projects.In general: clear, manageable, and predictable. But: Inflexible, hard to change, risky in case they are needed.

Modern development practices enhancing the rapid app development approach

Even though the RAD model was originally formulated over 30 years ago, its core ideas — such as the necessity of user feedback, prototyping, iterative development, reusable components, and the reduction of bureaucracy and formality within team communication — remain relevant. So, what can be added to the RAD approach if one decides to stick to its principles?

Agile integration

RAD laid the foundation for agile project management, encouraging businesses to seek flexible methodologies to adapt products to user requirements. Sprints, Scrum, and Kanban methodologies are frequently integrated with RAD principles to provide a structured yet flexible framework for rapid and iterative software development.

Improved prototyping

Modern tools allow for the creation of high-fidelity prototypes that closely resemble the final product, as Martin originally required in his methodology. Today, tools such as Argo CD, Gitlab CI, Adobe XD, Sketch, Figma, and InVision enable rapid creation of interactive prototypes and facilitate collaboration among team members and stakeholders.

DevOps practices

In modern development, continuous integration and continuous delivery pipelines are responsible for sped-up processes. Continuous integration is a procedure where developers integrate code changes in the shared repository, integrations are automatically verified by running tests, while CD is an automated process of delivering code to testing and development environments. Tools like Jenkins, CircleCI, Travis CI, and Azure DevOps automate testing, integration, and deployment to ensure quick and reliable delivery of updates. CI/CD pipelines perfectly correspond to the idea of an ongoing testing process and rapid construction of the RAD model.

Cloud services

Another technology that adds to the flexibility and enhancement of the development process are cloud services for scalable infrastructure, development environments, and deployment. Among the most reliable and popular services are AWS, Google Cloud, and Microsoft Azure. Their usage helps developers reduce setup time and allows for easier scaling, which is crucial for iterative app development within the RAD frame.

Version control systems

Versioning is critical for application development, as previous versions of the app must coexist on users’ devices alongside new versions. Utilization of Git and platforms like GitHub, GitLab, and Bitbucket help in efficient code management, collaboration, and maintaining a history of code changes.

Containerization

Containerization is a deployment process that allows applications to run smoothly across different platforms. Technologies such as Kubernetes and Docker are commonly used for containerization.

Collaborative tools

The RAD model designed by James Martin even offered how to organize an office space for effective workshops and communication within teams. Today’s work processes are enhanced and managed with tools such as Slack, Jira, ClickUp, Microsoft Teams, and others to facilitate collaboration between engineers, designers, managers, and stakeholders.

Microservice architecture

This architectural style aligns well with the rapid app development methodology. In the microservice approach, an app is built from independently deployable and loosely coupled services, enhancing flexibility and scalability.

Modern implementations of the RAD leverage advanced technologies, tools, and contemporary practices to enhance the principles of rapid and iterative software development, flexibility, and user involvement. However, companies often use a combination of methodologies that complement RAD ideas. Usually, it’s not a single approach but a combination of them, where one methodology can be enhanced to meet the specific demands of a project. Thus, rapid application development can be one of the techniques applied if there is a need. For example, at Ronas IT, we integrate various approaches to tailor our processes to the distinct needs of each project. Let us show how.

Methodologies that modern companies use: Example of Ronas IT

Rather than implementing a ready model in project development, Ronas IT team prefers to study the requirements of the projects and the needs of the clients. Depending on how much flexibility or strict structuring an application demands, we choose one or another methodology.

Scrumban

Scrumban is a methodology that suits most of the projects that we work with. It allows us to work with projects with a predictable scope, for example, when we have a ready design and know exactly what features we should engineer, and with projects that have evolving requirements where we can flexibly change the scope of work on the run. Working in this approach helps to eliminate the need to choose between strict Waterfall and loose RAD.

Scrumban is a combination of Scrum and Kanban, which are agile project management frameworks. From Scrum, it took work in sprints which are similar to iterations. Sprint is a period by which a team has to complete a particular amount of work. Usually, the sprint takes two weeks and up until it ends, a team does not receive the next tasks. Also, Scrumbun includes daily standups to catch up on the progress and retrospectives at the end of every sprint to analyze the performance.

An image illustrates two agile methodologies: Kanban and Scrum. Kanban is shown with three columns of sticky notes. The first column is "To Do," the second "Current," and the third "Done." Scrum shows two cyclical processes illustrated with arrows running in circles: a sprint lasting 2-4 weeks and a daily scrum. The combination of this two approaches is called scrumban.
Scrumbun combines Kanban progress visualization in separate phases and Scrum's workflow and sprints

As for the Kanban, it became a source of work process visualization. Scrumban uses its board with columns indicating the phase of the project. The classic Kanban columns are “to do”, “in progress”, and “done”. Each task is described in a card, and once a developer starts to work on a certain task, they drag a task from one column to the next. Kanban makes capabilities and progress visible. Thus, a team can see how many cards and in what period a single developer can work. This very much helps to plan wisely and prevent burnouts. On the other hand, a development team can show its accomplishments to stakeholders and make processes transparent.

It is important for us that the chosen methodology meets the requirements of flexibility - sometimes customers want to be able to change something during development, sometimes they don't, and our team should be able to adapt. Scrumban allows for such adaptability.

How do we choose methodology?

Sometimes the project might require a waterfall approach, and there’s nothing wrong with following a strictly scheduled workflow. The main criteria in choosing the right project management framework is common sense — the methodology should be chosen so that the projects would be delivered as required, within a timeframe and budget.

All in all

Despite the fact that the rapid application development methodology was formulated a long time ago, many of its ideas have been preserved in modern approaches. Although the technologies mentioned in Martin's original theory are already outdated, the ideas of working in iterations, the priority of automation, and a careful attitude to testing will always be relevant.

From our own experience, we can conclude that the choice of development methodology should first be inspired by the specifics of the project. The team should consist of skilled professionals who can adapt to different conditions — this is exactly what Martin was talking about in his book.

We also value flexibility in processes, which is why our team employs only skilled engineers ready for any challenges. If you want to build your app with us, we are always happy to help. Just tap the ‘Get in Touch’ button below to start.

Related posts

guide to mobile development
guide to mobile development
How to
Guide to mobile development
2021-09-30 8 min read
A cover to the article metaphorically representing the process helping to automate business workflow.
A cover to the article metaphorically representing the process helping to automate business workflow.
Case study
Implementing business workflow automation: Explanations and use cases
2024-02-21 20 min read
Guide on how to build compelling telemedicine software solutions
Guide on how to build compelling telemedicine software solutions
How to
How to build compelling telemedicine software solutions: Essential features, related law restrictions, and UI/UX design tips to use
2024-01-29 20 min read
Building a React Native chat app
Building a React Native chat app
Tech
Building a chat app with React Native
2023-05-22 11 min read
Ins and outs of banking app development in 2023-2024
Ins and outs of banking app development in 2023-2024
How to
How to create a mobile banking app in 2023-2024: Key features, tech stack, and common pitfalls
2023-12-20 23 min read
How to make a music app step-by-step
How to make a music app step-by-step
How to
How to develop a music app: Startup guide with key features and costs
2023-02-10 8 min read
How to build an app like Uber
How to build an app like Uber
How to
How to build an app like Uber?
2023-04-20 11 min read
How to make a dating app and what are the costs?
How to make a dating app and what are the costs?
How to
How to make a dating app like Tinder, and what are the costs?
2022-09-13 12 min read
How to build a social media website
How to build a social media website
Tech
How to build a social media website?
2023-03-23 14 min read

Related Services

This site uses cookies to store information on your device. Some are essential, while others help us enhance your experience by providing insights into how our website is used.
Necessary Cookies
Always Active
Enable core functionality like navigation and access to secure areas. The website may not function properly without these and can only be disabled through browser settings.
Analytics Cookies
Help us improve our website by collecting and reporting usage information.
This site uses cookies to store information on your device.