UPI Study › Courses › System Analysis and Design › Free lessons › Lesson 3.7 Free with a free account
Rapid Application Development: Definitions, Toolkits, and Frameworks
System Analysis and Design · Chapter 3: Agile Methods and Rapid DevelopmentSection 3.7 · lesson 21 of 699 min · free with a free account
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of System Analysis and Design.
Lesson complete
Earn the 3 college credits for System Analysis and Design
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: What Business Process Modeling Is and Why Organizations Use It to Optimize Workflows →← Inside JAD: Definitions, Stages, and TechniquesNext lesson: What Business Process Modeling Is and Why Organizations Use It to Optimize Workflows →
In this lesson
4 phases, prototyping in a timebox, the toolkits, and DSDM.
- Define RAD and what distinguishes it from a traditional life cycle
- Identify RAD's 4 phases
- Describe prototyping cycles and timeboxing inside RAD
- Identify RAD toolkits and DSDM, and weigh RAD's trade-offs
Transcript
Everything said in the video, section by section (1,185 words). Read along, or search it.
Agile Methods and Rapid Development
Rapid Application Development
Some organizations need a working system fast, and a long document-first process simply will not do. Rapid application development, or RAD, was built for exactly that situation. This section covers what RAD is, its four phases, and how prototyping and timeboxing drive it. Then the tools it depends on, the DSDM framework, and the trade-offs that come with speed.
What RAD Is
Compressing the Life Cycle
Rapid application development compresses the life cycle. It relies on heavy user involvement, repeated prototyping, and reusable tools, to produce a working system quickly. It was formalized by James Martin in the early nineteen nineties. It was a deliberate reaction to projects that spent months producing detailed documentation, before anyone saw a working screen. RAD makes a trade. It gives up some of that exhaustive, up-front documentation, in exchange for speed. And it discovers and confirms requirements through a working prototype, rather than through a written description alone. This does not mean RAD skips the underlying phases. It reorganizes them into four named phases, compressed and repeated more tightly around user involvement.
Figure 3.3
RAD's 4 Phases
Here are RAD's four phases. Requirements planning, user design, construction, and cutover. Notice the middle two. User design and construction do not run once, in sequence. They repeat, as a loop. Build a prototype, review it with users, refine it, and go around again. And that loop runs inside a fixed timebox. That loop is the engine of RAD. It is where the system is actually shaped.
Phase by Phase
Goals and Key Activities
Let's take the phases one at a time. Requirements planning establishes the overall business requirements and scope, at a high level, quickly enough to move into design. It usually happens through joint sessions with users and management, agreeing on scope, objectives, and constraints. User design models the system directly with users, through iterative prototypes rather than a static requirements document. Its repeated prototype, review, and refine cycles produce screen designs, process models, and data models. Construction builds and tests the system, based on the prototypes users have approved. It relies on programming or configuration, usually with heavy code generation and reuse. Details often keep being refined as building proceeds. And cutover moves the completed system into production. That means final testing, data conversion, user training, and installation.
Mapping to the Life Cycle
Same Work, Different Packaging
How do these map onto the life cycle you already know? Requirements planning corresponds to the planning phase. User design carries most of what would otherwise be separate analysis and design phases. Construction folds detailed design and implementation together. And cutover mirrors the rollout portion of a traditional implementation phase. What about maintenance? It still follows after cutover, exactly as in any life cycle. RAD simply does not count it among its four named phases.
How RAD Builds
Prototyping Cycles and Timeboxing
Two mechanisms drive RAD. The first is the prototyping cycle. Build a partial, working version of the system. Show it to users. Gather their reaction. Revise it before the next round. In RAD, this cycle is how the system is actually designed and built. It is a construction technique for discovering what to build. It is not a way of formally confirming requirements that are already written. That is covered separately later in the course. The second mechanism is timeboxing, which keeps a prototyping cycle from running forever. Traditional scheduling fixes the scope, and lets the schedule slip until that scope is finished. Timeboxing does the reverse. It fixes the deadline, and treats scope as the adjustable variable. If a feature will not fit inside the box, it is deferred to a later round, instead of pushing the deadline back. Each approach has its own risk. Traditional scheduling risks slippage. Timeboxing risks cut features quietly piling up, round after round, unless someone is tracking them.
Toolkits
Generating the Application, Not Hand-Coding It
RAD's compressed construction phase depends on tools that generate much of an application. Nobody is hand-coding every line. Two overlapping categories of tool support this. Fourth-generation languages, or four G Ls, provide screen, report, and query generators. They produce routine forms and data-access code from a higher-level specification. In RAD, they rapidly build the data-entry screens and reports a prototype needs. Low-code platforms are a more recent category. They offer a visual, drag-and-drop environment for building workflows, forms, and data models, and generate most of the application automatically. In RAD, they turn an agreed screen or process design directly into a working prototype. Often, that happens with less involvement from a specialist developer.
A Structured Framework
DSDM: RAD With Governance
Speed without structure can go badly. That is why DSDM exists. The dynamic systems development method is one of the most established formal frameworks, for applying RAD in a disciplined way. It was created specifically to add governance and rigor, so organizations would not sacrifice all structure and documentation for speed. It rests on a small set of core principles. Cost and schedule are fixed, while scope flexes. That is timeboxing, formalized. Users stay actively involved throughout, not just at the start and end. A working product is delivered frequently, rather than once at the very end. Requirements are baselined only at a high level, and refined iteratively. And testing runs throughout the project, instead of being saved for the end. DSDM is also where the MoSCoW technique originated. It fits naturally with timeboxing. When the deadline cannot move, MoSCoW tells the team exactly what gets cut first.
Weighing RAD
Advantages and Trade-offs
So how do you weigh RAD? Its first advantage is faster delivery, for well-scoped, small-to-medium projects. The trade-off is that it is less suited to very large, complex, or heavily regulated systems, where a light documentation trail becomes a liability. Its second advantage is high user engagement, since users shape the system throughout. The trade-off is that scope can quietly grow inside a timebox, without disciplined change control. Its third advantage is heavy reuse of toolkits and generated components, which reduces custom coding. The trade-off is heavy dependence on user availability. RAD struggles if users cannot commit the time. And its fourth advantage is rapid, visible progress, which builds stakeholder confidence early. The trade-off is that a polished-looking prototype can mask real gaps in performance, security, or production readiness. Notice that each strength and its trade-off come from the same feature. Speed is never free.
Key Terms
The Vocabulary of This Section
Let's lock in the key terms. Rapid application development compresses the life cycle, using heavy user involvement, prototyping, and reusable tools. A prototyping cycle builds a partial version, shows it to users, gathers their reactions, and revises it. Timeboxing fixes the deadline, and treats scope as the adjustable variable. Fourth-generation languages and low-code platforms generate much of an application, instead of hand-coding it. And DSDM, the dynamic systems development method, is a governed RAD framework, and the origin of MoSCoW.
Key Takeaways
What to Carry Forward
To pull this together. RAD compresses the life cycle into four phases. Requirements planning, user design, construction, and cutover. User design and construction typically repeat as a prototyping loop, rather than running once in sequence. Timeboxing fixes the deadline and treats scope as adjustable, the reverse of traditional scheduling. Fourth-generation languages and low-code platforms generate much of the application. DSDM formalizes RAD with fixed cost and schedule, continuous user involvement, and frequent delivery. And RAD favors well-scoped projects with available users. It is a weaker fit for very large, complex, or heavily regulated systems.
About System Analysis and Design at UPI Study
System Analysis and Design (Computer Science 390) is a self-paced online course of 69 video lessons in 9 chapters, from the analyst's role and requirements to UML modeling, interface and database design, testing, maintenance and project management. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →
Why take it here
Why students take System Analysis and Design with UPI Study
Where the credit goes
Universities that work with NCCRS
System Analysis and Design carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About Rapid Application Development: Definitions, Toolkits, and Frameworks
What is rapid application development (RAD)?
What are the four phases of RAD?
What is timeboxing in rapid application development?
What are the drawbacks of rapid application development?
About the System Analysis and Design course
How many college credits is System Analysis and Design?
How much does System Analysis and Design cost and what is included?
Which universities accept UPI Study credits?
How long does System Analysis and Design take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in System Analysis and Design.
69 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →