Rapid Prototyping is being able to quickly provide a proof of concept solution to a problem. It is not developing a fully-featured, production-ready application. Rapid prototypes may only provide one function or only a partial solution and are often needed in a short timeframe.
Rapid Software Prototyping Vs Application Development
Rapid prototyping is best for situations that need solutions based on a short schedule or where a fast fail is preferred. Why would someone want to fail fast? If the solution does not meet the needs of the user, then failing fast, allows for a quick change of direction and refocus of resources on a different solution, which might prove to be more useful. Another reason to fail fast is if you are unsure if something is possible. Maybe an API doesn’t provide the data you need and a quick prototype that pulls from the API will tell you that so you can look at other options.
When the requirements are not clear, or the environment will lead to rapidly changing requirements or direction. If the customer is not quite sure what they are looking for in a solution, providing them with a quick prototype will help identify what works or not, which will then help with identifying requirement details and priorities. Perhaps you are working in a cyber field, where adversaries change tactics often. You’ll need quick solutions often if you want to stay ahead of them.
Prototypes are also very useful when the system will have a lot of user interaction. Developing using evolutionary prototypes will allow for feedback on ease of use or correction of requirement details at each iterative delivery. Eventually, you’ll have a good idea of the full scope of requirements and needs of the customer which can then be documented and handed over to a production application development team.
Rapid Software Prototyping Types
We choose Rapid Prototyping for several reasons. As mentioned above, one of the reasons would be a short deadline. A solution is needed quickly, or any solution delivered after the deadline will be OBE. Other times it makes sense to use Rapid Prototyping include:
- Throw Away Prototypes: Good for when you need to test an API call, especially one that is not well documented, to figure out what information it provides, if you have access, and what format it returns. These prototypes are throw-away prototypes since they do not actually provide any permanent functionality but provide information you will need to create a functional prototype.
- Incremental Development: To deliver stand-alone functionalities, which will eventually be wrapped into a complete application.
- Evolutionary: To develop and deliver increasing functionality. Be cautious of scope creep during feedback cycles using this method.
- Extreme: Often used during GUI development. You start with a static GUI to layout the look, feel, and flow. Then you work on creating a more functional and interactive GUI using simulated services, and then finally creating the backend services and delivering a functional prototype.
To be clear, none of these prototypes are production-worthy solutions. At best when we mention a complete solution, we’ve identified all the requirements and have proved the solution, which is now ready to be given to a production team.
Where Would You Use A Rapid Software Prototype?
Rapid prototyping should be done in a sandboxed or development environment. Since these types of prototypes do not go through thorough testing and are often throw away scripts to test feasibility, they should not be used in a production environment. Depending on the needs of your prototype and the permissions you have, you may even decide to prototype on your local machine.
While you should prototype in a non-production environment, you should still know the limitations or availability of resources on the production system to ensure you are prototyping something that will be useful and provide accurate proof of concept/feasibility. Such as does the system the final product will be run on having the same accesses as the system you are prototyping on. If the systems are on different non-connected networks, then access to specific data or an API may not be available on the other network and therefore your prototype may not prove feasibility for your customer.
In Conclusion
Set Expectations
When requirements first come in from the customer and it has been determined a Rapid Prototype is the best solution, work with the customer to prioritize the features. Determine which features are must-haves and based on the customer’s requirement schedule, scope the prototype so the highest priority features can be delivered on schedule. As the schedule allows, build, demo, and incorporate feedback to add additional features.
Make Assumptions
There may be cases where you are developing a prototype and making a well thought out assumption will enable you to demo a feature quicker than verifying details with a customer. Due to working closely with the customer, knowing the environment and the fast build, demo, feedback loop you have established, go ahead and make assumptions, you will soon have a chance for the customer to verify your solution.
Prototypes Are Functional, Not Always Pretty
Prototypes don’t need to be pretty; they need to be functional. They should be user friendly and not require intensive training or large manuals. Functional may mean different things during different development stages of your prototype. For example, when doing extreme prototyping, a static HTML website can still be functional in that it is demonstrating relationships and flows between pages and layouts.
Don’t Skip Security
You also should not skip over security when prototyping. While it seems like adding in security will add to your timeline, and it will, it’s also very important to ensure data remains secure and access is not given to those who don’t have a need to know.
Be Prepared To Change Direction
Prototypes often have short deadlines or are being developed against a high level or generalized requirements. Be prepared for requirements or priorities to change and be okay with stopping development mid prototype development and switch to a new priority. Dropping one prototype doesn’t mean your work wasn’t important, just means the customer has new higher priorities that need to be worked.
In part two, of our three-part rapid prototyping series, we’ll look at “How to Become a Rapid Prototyper.” Being able to rapidly prototype solutions means being knowledgeable across several technology areas, remaining flexible, and being able to learn new technologies quickly. These skills will allow you to choose the best approach to the solution.