12/20/2016
in Methods
Software Prototyping – Rapid Application Development
Table of Contents
Prototypes are a great way to get feedback on design ideas and the feasibility of technical solutions. RAD (Rapid Application Development) is a methodology that focuses on starting development ASAP instead of writing rigorous design specifications. In contrast to the advice from the first post on software prototyping, to never use a prototype in production, RAD does exactly that. That is why we want to take a closer look at it. If you first need a quick overview of software prototyping, take a look here.
The RAD methodology was developed as an alternative to the classic waterfall approach. In addition there is also a specific development method that is called RAD. So don’t get confused about the term RAD. In this post we will stick to the general methodology.
Rapid Application Development (RAD)
The idea of RAD is that software development is a knowledge intensive process. During the process of developing an application you’re gaining new knowledge that you can use to improve the product. In the waterfall model you don’t have the opportunity to use this newly gained knowledge, because all specifications were already described in detail before the development started. RAD on the other hand enables you to take advantage of gained knowledge, thus to improve your software products continuously, because it is an iterative process.
Using RAD you first develop prototypes instead of writing extensive design specifications. Then you demonstrate the prototype, gather feedback and adjust it again. This way the prototype evolves and at a certain point it becomes the product (or parts can be integrated into the product). This sounds a lot like Scrum, where you’re aiming on producing a running system by the end of each sprint. So each sprint is an evolutionary step of the prototype, but applying RAD doesn’t require the roles, artifacts and events of Scrum.
RAD is not for all projects
In our first post about prototyping we said that you should never use prototypes in production, because they they concentrate on their main purpose and neglect other topics (often topics like security, performance or sustainable architecture). If you follow RAD and develop a prototype into a final product you need to take these aspects into consideration at a certain point, depending on your priorities. In general, prototype based development is not suitable for all projects and it comes with several advantages and disadvantages.
Pros of Rapid application development
- Risk reduction: By focusing on incremental changes to the system the risk of a catastrophic failure is reduced. By using RAD it’s less likely that a fundamental redesign of the product is necessary.
- Higher efficiency: Humans are better at using and reacting than writing specifications based on their imagination. By being able to use a prototype, users realize that they want something different or optimization potential becomes clear.
- High quality: The constant interaction with users during the evolution of the prototype ensures a high user-acceptance of the final product.
- Flexibility: Thanks to the iterative development, changing requirements can be taken into account.
- Low integration barrier: Having to integrate each stage of the prototype solves a lot of integration issues.
Cons of Rapid application development
- Poor Design: Since the design never gets overall planned and it’s being developed with each iteration or new prototype, the design might have weaknesses.
- Not for all projects (not too big): For large projects this methodology presents special challenges, especially because of the poor design, less control and extensive user interaction.
- Modularization: This methodology can only be used if the product can be modularized into several stages of prototypes.
- Customer involvement: Just like for other incremental or iterative methodologies, the constant availability of the customer is a fundamental prerequisite, but it is not always given.
RAD is agile
If you have a small project that can be modularized and the customer/users are highly available it might be a good idea to start the project with the development of a prototype and to evolve it into the final product. This way you would get a lot of feedback that you can incorporate right away and you don’t have to the product besides the prototype. As with all iterative approaches there is always the risk of discovering a condition that would require a redesign of the product. In that case it’s a question of prioritization – is the requirement so important that we should realize the redesign. All that sounds a lot like an agile approach, doesn’t it?
