Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

What is Rapid Application Development


Published on

Conceived in the 1980s, rapid application development, or RAD, was the first development methodology to challenge traditional waterfall development practices. Though often mistaken for a specific model, rapid application development is the idea that we benefit by treating our software projects like clay, rather than steel.

Software is a unique engineering structure because it is transient. With traditional engineering projects like bridge construction, engineers cannot begin to build a bridge then change their minds half way through the process—that’s pure chaos. But a bridge built in software? Engineers can change that every day. RAD takes advantage of this by emphasizing rapid prototyping over costly planning.

1. A Brief History of RAD
2. RAD vs Agile
3. RAD Methodology
4. RAD Advantages and Disadvantages
5. Tools Which Enable RAD
6. How OutSystems Enables RAD

2 Minute Demo:

Published in: Technology
  • Be the first to comment

What is Rapid Application Development

  1. 1. What Is Rapid Application Development? Stanley Idesis
  2. 2. An 80s Baby 2 Rapid application development, or RAD, was among the first development methods to challenge traditional waterfall development practices. Though often mistaken for a specific model, rapid application development is the idea that we benefit when we treat our software projects like clay, rather than steel.
  3. 3. 3 “Software is clay, not steel” - RAD
  4. 4. A Coded Bridge? 4 Software is a unique engineering structure because it is highly transient, unlike traditional engineering projects. Engineers cannot begin to build a bridge and change the design partway — that’s chaotic and costly. But a bridge built in software? Engineers can modify it daily. RAD favors rapid prototyping over costly planning
  5. 5. 5 A Brief History of RAD
  6. 6. In the 1970s... 6 Humanity began to want software. Software projects took months of laborious planning and even more time in development — just like traditional engineering projects. Software architects worked with business and IT management to draft functional requirements, then spent countless hours defining them in spec sheets.
  7. 7. With Specifications Prepared... 7 Development began. Anywhere from months to years later, business and IT stakeholders received their first glimpse of the software product they requested. And if it failed to meet their expectations, the engineers would refactor — the costs of which were often extraordinary.
  8. 8. This Process... 8 Which began with the blackboard, moved to spec sheet, then to software, and terminated at the user, is known colloquially as the waterfall approach. It mirrored traditional engineering assignments that worked with physical materials like wood, cement, and iron. Once set and paid for, changing these resources is a massive undertaking and prohibitively expensive.
  9. 9. In the 1980s 9 Barry Boehm and James Martin recognized the obvious: software is not built of material resources. They understood software for what it was: infinitely and affordably malleable. Boehm and Martin took advantage of software’s inherent pliability to design brand new development models: the Spiral Model and the James Martin RAD model.
  10. 10. Both Models Evolved 1 To take on other forms which ultimately acted as precursors to the Agile Method. Though often used interchangeably, as if they mean the same thing, RAD and agile are quite different. Snow leopards are agile, magnificent creatures Just FYI
  11. 11. 1 RAD vs Agile
  12. 12. RAD vs Agile 1 Rapid application development is not only thought of as interchangeable with agile, but also frequently directly contrasted with it. Unfortunately, it’s more complicated than that. RAD is a forbear of agile, but agile encompasses far more than a development model. It more closely resembles a philosophy than a methodology. RAD is a methodology, Agile is a philosophy
  13. 13. Agile Says... 1. “Customer satisfaction by early and continuous delivery of valuable software.” This is a core RAD principle. 1 ...RAD Says
  14. 14. Agile Says... 2. “Welcome changing requirements, even in late development.” Also found in RAD practice 1 ...RAD Says
  15. 15. Agile Says... 3. “Working software is delivered frequently (weeks rather than months).” Specific time-frames are not recommended by RAD, though speed is clearly emphasized. 1 ...RAD Says
  16. 16. Agile Says... 4. “Close, daily cooperation between business people and developers.” No direct equivalent in RAD, but feedback from end- users is critical to the RAD process. 1 ...RAD Says
  17. 17. Agile Says... 5. “Projects are built around motivated individuals, who should be trusted.” RAD has no opinion on the makeup of individual team members. 1 ...RAD Says
  18. 18. Agile Says... 6. “Face-to-face conversation is the best form of communication (co-location).” RAD has no opinion regarding locality of team members. 1 ...RAD Says
  19. 19. Agile Says... 7. “Working software is the primary measure of progress.” RAD focuses on delivering working software as frequently as possible. 1 ...RAD Says
  20. 20. Agile Says... 8. “Sustainable development, able to maintain a constant pace” RAD offers no opinion regarding the pace of development other than “rapid.” 2 ...RAD Says
  21. 21. Agile Says... 9. “Continuous attention to technical excellence and good design” RAD principles focus on functionality and user satisfaction. Quality of design and implementation are unnecessary, but ideal byproducts. 2 ...RAD Says
  22. 22. Agile Says... 10. “Simplicity—the art of maximizing the amount of work not done—is essential” Here again, RAD does not emphasize reduction of work, but proclaims that RAD projects will require less work in the long term. 2 ...RAD Says
  23. 23. Agile Says... 11. “Best architectures, requirements and designs emerge from self-organizing teams.” RAD does not limit itself to a team structure. 2 ...RAD Says
  24. 24. Agile Says... 12. “Regularly, the team reflects on how to become more effective and adjusts accordingly.” Not necessary or inherent to RAD practices 2 ...RAD Says
  25. 25. Agile... 2 Takes several steps beyond the scope of RAD. While agile dictates the ideal working environment (just shy of how many rubber ducks to keep on your desk), RAD focuses on how to build software products for your clients and end-users. Let’s take a closer look at what RAD entails. Two. In case the first duck doesn’t “get you”
  26. 26. 2 RAD Methodology
  27. 27. 1. Define Requirements 2 A RAD project begins by defining a loose set of requirements. And they’re kept loose because RAD permits requirements to change at any point in the cycle. The client provides their vision for the product and comes to an agreement with developers on the initial requirements that satisfy that vision.
  28. 28. 2. Prototype 2 Developers demonstrate something to the client. This can be a prototype that satisfies all or only a portion of requirements (as in early-stage prototyping). This prototype may cut corners to reach a working state, and that’s acceptable. Most RAD approaches have a finalization stage at which developers pay down technical debts accrued by early prototypes.
  29. 29. 3. Incorporate Feedback 2 Developers present work to the client or end-user. They collect feedback on everything from interface to functionality—it is here where product requirements may come under scrutiny. Clients may change their minds or discover that something which seemed right on paper, made no sense in practice.
  30. 30. 4. Finalize Product 3 Developers optimize their implementation to improve stability, maintainability and a third word ending in ‘-ility.’ Both Boehm’s Spiral Model and James Martin’s RAD Model make use of these four steps to help development teams reduce risk and build excellent products. But RAD has drawbacks as well...
  31. 31. 3 Advantages and Disadvantages
  32. 32. Speed 3 ScaleVS In the traditional waterfall approach, clients invariably requested changes after delivery. With RAD, projects are more likely to finish on time and to the client’s satisfaction. When a RAD project expands beyond a single team, the development cycle invariably slows and muddles the project’s direction. Simply put, it’s difficult to keep a large group of people on the same page when your story changes constantly.
  33. 33. Cost 3 CommitmentVS In waterfall, IT risks building and fleshing out complex feature sets that clients may choose to gut from the final product. The time spent building zombie features can never be recovered, and that translates to sunk costs. RAD developers build the exact systems that clients require and nothing more. In waterfall, clients focused on their primary tasks while developers focused on theirs: building the product. In RAD, the prototyping cycles require developers and clients to commit to more frequent meetings.
  34. 34. Developer Satisfaction 3 Interface-FocusVS In waterfall, developers work in silos. And when they finally present their product to an unappreciative client, their ego takes a hit. In RAD, the client is there every step of the way. This gives developers the confidence that upon delivery, their work is appreciated. RAD motivates developers to find the perfect solution for clients. The clients judge the solution only by what they can interact with—and often, that is merely a facade. As a consequence, some developers forego best back- end practices to accelerate front-end development.
  35. 35. Good RAD Projects 3 ● Internal employee tools ● Customer portals ● B2C applications Not so good RAD projects… ● Mission-critical software ● Flight controls ● Pacemakers… A team building a RAD pacemaker will struggle to collect user feedback from the deceased.
  36. 36. 3 Tools Which Enable RAD
  37. 37. Design and Prototyping Tools The products in this category help teams craft interactive designs at impressive speeds. And some tools on this list, like Webflow, allow designers to export completed designs as functional cross-browser prototypes. 3 Tool Prototype Requires Origami Studio Mobile macOS InVision Web, Mobile, Wearables macOS Webflow Web, Mobile Web Mockplus Web, Mobile macOS, Windows Balsamiq Web, Mobile macOS, Windows Adobe XD Web, Mobile macOS, Windows Sketch Web, Mobile macOS JustInMind Web, Mobile, Wearable macOS, Windows Web, Mobile, Wearable Web
  38. 38. User Testing and Feedback Tools RAD methodology requires frequent feedback from clients and end-users. And in modern workflows, developers who work offsite prefer to solicit feedback remotely rather than book travel and accommodations whenever they require input from clients. 3 Tool Feedback For Best For InVision Web, Mobile Clients Red Pen Web, Mobile Clients Conjure Web Clients Usability Sciences Web, Mobile End-Users UserTesting Web, Mobile End-Users Validately Web End-Users UserBrain Web End-Users
  39. 39. Rapid Development Tools If your team has strict technology requirements or a limited skill set, it’s easier to stick with what they know. But if you’re willing to consider a new approach to development, the tools in this category will accelerate your production cycle. 3 Tool App Types Tool Type Salesforce AppCloud Web, Mobile No-Code, Low-Code Alpha Software Windows, Web, Mobile Low-Code Zoho Creator Web Low-Code Appian Web, Mobile Low-Code WaveMaker Web, Mobile Low-Code Spring Desktop, Web, Mobile SDK Mendix Web, Mobile Low-Code Kony Web, Mobile Low-Code, SDK OutSystems Web, Mobile Low-Code, SDK
  40. 40. 4 How OutSystems Enables RAD
  41. 41. Truly Integrated Development 4 At the core of OutSystems lies a powerful development environment. Our tool enables everyone from IT- adjacent roles to veteran developers to build enterprise- grade web and mobile applications without code. Seasoned developers can override behavior with custom front and backend scripts.
  42. 42. Beyond RAD 4 OutSystems goes past enabling rapid application development by including hosting, dynamic scaling, release automation, performance monitoring, user management, version control, and much more on top of a battle-tested cloud platform. Check? Nope. That would be checkmate.
  43. 43. 4 ▶ Two-minute demo ▶ Ready to develop 6x faster?