12.1.4 Rapid Development with Prototypes
Rapid Application Development, usually shortened to RAD, aims to produce useful software quickly through short development cycles and working prototypes. Users review these early versions and their feedback guides revisions.
RAD can also divide a system into components that different developers build at the same time. This can reduce the delivery time, but it requires a skilled team, regular user involvement and careful integration.
By the end of this section, you should be able to:
- Explain the main principles of Rapid Application Development.
- Explain how prototypes support requirements and design decisions.
- Describe how short cycles, user feedback and parallel work are used.
- Explain the benefits and limitations of RAD.
- Judge whether RAD is appropriate for a given project scenario.
The Core Principle of RAD
RAD reduces the time spent creating a complete, detailed plan before any working software is available. Developers instead produce a working model of part of the solution, show it to users and revise it in response to what they learn.
A simplified RAD cycle can be represented as:
Select a feature → build a prototype → obtain feedback → revise → integrate
Analysis, design, coding and testing still take place. The difference is that these activities occur repeatedly within short cycles instead of being completed once for the whole system before users see a working result.
Using Prototypes
A prototype might represent one screen, one user journey or one processing feature. Its purpose is to make an idea concrete enough for users and developers to evaluate.
| Prototype focus | What users can evaluate | Possible development decision |
|---|---|---|
| Navigation | Whether important options are easy to locate | Reorganise menus or simplify the number of screens |
| Data entry | Whether the requested information is clear and practical | Remove unnecessary fields or add missing information |
| Processing rule | Whether the system makes an appropriate decision | Clarify the rule and revise the algorithm |
| Output | Whether reports or messages contain useful information | Change the layout, wording or data included |
Some prototypes are revised until they contribute to the final product. Others are used mainly to test an idea and are replaced when the team has learned enough.
Short Development Cycles
RAD combines analysis, design, coding and testing into short repeated cycles. Each cycle should have a focused goal that can be demonstrated and reviewed.
| Cycle activity | Example question | Possible output |
|---|---|---|
| Clarify | What should this prototype allow the user to achieve? | Focused requirement |
| Design | What is the quickest appropriate way to demonstrate the idea? | Interface or processing plan |
| Build | Which components must work for the review? | Working prototype |
| Test | Does the prototype perform its selected task? | Test observations and corrections |
| Review | What should be retained, changed or removed? | Feedback and revised priorities |
The short cycle gives the team a quick opportunity to test assumptions. It does not justify ignoring quality: a prototype must work sufficiently well for its intended review to produce useful evidence.
Why RAD Needs User Involvement
Users or client representatives need to review prototypes regularly. They help the team decide whether the developing system matches the real work it is supposed to support.
Useful feedback might identify:
- a misunderstood requirement;
- an awkward sequence of screens;
- a missing data field;
- an unnecessary step;
- a more useful report format;
- a rule that behaves differently in real situations.
| User comment | Question for the development team | Possible response |
|---|---|---|
| “Visitors usually choose a date before choosing an event.” | Does the current booking order reflect real behaviour? | Reverse the order of the selection screens. |
| “We need to see remaining spaces immediately.” | Is capacity information available to the interface? | Add live availability to the event list. |
| “Staff must be able to reserve places for a group.” | Is this an essential new requirement? | Prioritise group booking in the next cycle. |
Developing Components in Parallel
RAD is most practical when the proposed system can be separated into components with clear responsibilities. Different developers or teams can then work on several components during the same period.
For a booking application, parallel work might be divided as follows:
| Component | Main responsibility | Information exchanged |
|---|---|---|
| Visitor interface | Collect event, date and group-size selections | Booking request |
| Availability service | Check capacity and return available places | Event identifier, date and remaining capacity |
| Payment component | Calculate charges and record payment status | Booking total and payment result |
| Staff dashboard | Display bookings and attendance information | Confirmed booking records |
Parallel development can reduce the overall time, but the interfaces between components must be agreed. Otherwise, each component may work independently but fail when connected to the others.
Integrating Prototypes and Components
Integration should not be postponed until every component is considered finished. Connecting early prototypes can expose incompatible data formats, assumptions or interfaces while the components are still easy to revise.
| Integration question | Example problem | Possible correction |
|---|---|---|
| Do components use the same identifiers? | One component uses an event code while another expects an event name. | Agree and document one interface format. |
| Do they interpret values consistently? | One component stores money as integer cents and another expects a real value. | Add a shared representation or controlled conversion. |
| Are required results available at the right time? | The interface requests capacity before the availability component responds. | Revise the interaction sequence. |
| Are errors communicated clearly? | A failed payment returns no reason to the visitor interface. | Define standard status and error messages. |
Worked Example: Science Centre Workshop Kiosk
A science centre wants a touchscreen kiosk that allows visitors to find workshops, check available places and make a booking. Staff know the required purpose, but they are uncertain about the best screen order and the amount of information visitors need.
Why RAD is considered
- Staff and visitors can review prototypes regularly.
- The system can be separated into interface, availability and booking components.
- The centre needs a usable version before the beginning of its autumn programme.
- The development team has experience building touchscreen applications.
| Cycle | Prototype or component | Review finding | Development response |
|---|---|---|---|
| 1 | Workshop search screens | Visitors choose a date before a workshop category. | Change the selection order. |
| 2 | Date-first search and workshop details | Families need to know the minimum recommended age. | Add age guidance to workshop data and displays. |
| 3 | Search interface and availability service | Capacity updates correctly, but group bookings are awkward. | Add a group-size control and revise the availability request. |
| 4 | Integrated booking and staff dashboard | Staff need a clear warning when a workshop is almost full. | Add a capacity warning before the pilot release. |
The prototypes allow decisions to be based on observed use rather than guesses about how visitors might behave. Meanwhile, the interface and availability components can be developed partly in parallel.
Benefits of RAD
Requirements can be refined through use
Users can respond to working prototypes, making it easier to discover missing or misunderstood requirements.
Useful results can appear quickly
Short cycles produce visible progress. Selected components may become usable while other parts of the system are still being developed.
Parallel work can shorten the schedule
When the system has clear component boundaries, several parts can be developed at the same time.
Early integration exposes interface problems
Connecting prototypes throughout development can reveal incompatibilities before the final product is assembled.
Components can sometimes be reused
Existing interface controls, validation routines or software components may reduce the amount of new code required.
| RAD feature | Potential project benefit |
|---|---|
| Working prototypes | Users can give concrete feedback early. |
| Short cycles | Progress and problems become visible quickly. |
| Parallel components | Several parts may progress during the same period. |
| Regular integration | Component-interface faults can be identified earlier. |
| Reusable components | Less new implementation may be required. |
Limitations of RAD
The system must be suitable for modular development
RAD is difficult when the system cannot be separated into components that can be developed and reviewed independently.
Skilled developers are required
Developers need to make rapid design decisions, build useful prototypes and manage changing requirements without losing control of the complete system.
Users must be available
If users cannot review prototypes regularly, the team loses one of RAD’s main sources of evidence.
Parallel development needs coordination
Component interfaces, data representations and responsibilities must remain consistent across the teams.
Speed can become a distraction
If “rapid” is interpreted as rushing, the team may accept weak designs or insufficient testing. The purpose is faster learning and delivery, not uncontrolled coding.
| Limitation | Possible consequence | Control measure |
|---|---|---|
| Unavailable users | Prototypes are revised without reliable feedback. | Arrange committed representatives and scheduled reviews. |
| Weak component boundaries | Parallel work produces incompatible software. | Define interfaces and shared data clearly. |
| Insufficient technical skill | Rapid decisions introduce unstable designs. | Use experienced developers and regular technical review. |
| Uncontrolled feedback | The scope changes after every prototype review. | Prioritise changes against the project purpose and schedule. |
When Is RAD Suitable?
| More suitable when... | Less suitable when... |
|---|---|
| Users can review prototypes frequently. | Users are unavailable during development. |
| The system can be divided into clear components. | Most components depend closely on every other component. |
| The detailed requirements may emerge through feedback. | The requirements and output are already completely fixed. |
| Skilled developers and suitable tools are available. | The team has limited experience with the required technology. |
| Rapid delivery is an important project goal. | There is no meaningful partial system to demonstrate. |
| Existing components can be reused. | Every feature must be developed from the beginning. |
Interactive: RAD Prototype Studio
Explore a normal prototype cycle, parallel component development and a project where user feedback is unavailable.
Common Mistakes and Misconceptions
- “RAD means writing the full system as quickly as possible.” RAD uses focused prototypes and repeated review rather than uncontrolled speed.
- “A prototype must contain every final feature.” It normally represents a selected part or idea.
- “RAD requires no planning.” Component boundaries, interfaces, priorities and review goals still need planning.
- “Parallel development always saves time.” It can create extra integration work when interfaces are unclear.
- “Any project can use RAD.” The project must support modular development and regular user feedback.
- “Every user suggestion should be implemented.” Feedback must be checked against value, feasibility and project priorities.
Practice
Core questions
- Explain the main principle of Rapid Application Development.
- Explain the purpose of a prototype.
- Explain why RAD requires regular user participation.
- Explain how parallel component development may reduce delivery time.
- Explain one integration problem that parallel development may cause.
- Give two benefits of using short prototype cycles.
- Explain two limitations of RAD.
Scenario: Pop-up Festival Application
A local festival needs a mobile application in ten weeks. The final programme is still changing. Organisers can review a prototype twice each week. The application can be separated into programme listings, venue maps, ticket reservations and staff announcements.
- Explain three reasons why RAD may be suitable.
- Suggest one useful first prototype.
- Describe feedback the organisers could provide.
- Explain how two components could be developed in parallel.
- Identify one risk the development team must manage.
Counter-scenario
A company asks for rapid development but cannot provide any users or managers for reviews until the final week.
- Explain why this weakens the case for using RAD.
- Describe one possible consequence for the prototypes.
- Suggest what the development team would need before RAD became more suitable.
Review
| Prompt | A strong response should include |
|---|---|
| RAD principle | Short cycles, working prototypes, feedback and rapid revision. |
| Prototype | A working model used to test and communicate an idea. |
| User role | Review prototypes and help refine requirements and designs. |
| Parallel development | Separate components are built during the same period. |
| Integration | Components are connected and tested as one system. |
| Main benefits | Rapid feedback, visible progress, parallel work and earlier integration. |
| Main limitations | Need for modularity, skilled developers, user availability and coordination. |
| Suitable project | A modular system needing rapid delivery whose users can review prototypes frequently. |