Prototyping software before development means faster, more efficient project cycles, especially when you implement one of these 4 prototyping process models.
Iterative, agile, spiral, RAD, incremental, prototyping, waterfall… when it comes to software development there’s no shortage of methodologies to choose from. While traditional approaches such as waterfall have fallen a little out of favor in an increasingly agile world, project and product managers still aim to maintain an open mind when it comes to organizing product workflow. After all, an agile approach could work best on a project that demands speedy production and trashing of rough wireframes (we’ve written about the agile project cycle before if you’re curious), but an incremental approach might be a better fit for mammoth-scale projects with disparate teams.
With so many software development methodologies floating around, it helps to know your RAD (rapid application development) from your spiral and so on. So we’re taking a closer look at one particular methodology that’s close to our hearts here at Justinmind (being a prototyping tool and all) – the prototyping process model.
Prototyping process model – the benefits
Before we get started, it’s important to point out that the prototyping approach to software development isn’t a stand-alone methodology in and of itself; rather, prototyping can be built into a wider methodology such as RAD or agile to improve creativity and efficiency. Software prototyping reduces project risk by breaking the project cycle into manageable sections, getting the user involved from the jump, increasing chances of user adoption, and providing a chance to try out ideas that can either be built on or thrown out without extra project cost.
Find out more about how to reduce SDLC costs
The basic prototyping process model
All software prototyping follows a basic 6 step model:
- Requirements gathering and analysis: functional and non-functional requirements are broken out in detail
- Quick design: quick and dirty wireframes or paper prototypes are built
- Prototype building: an initial prototype produced, based on wireframes
- User evaluation: strengths and weaknesses of the prototype revealed by usability testing
- Refinement: the prototype is refined based on new requirements and user feedback. At this stage, the prototype can go through evaluation and reiteration as many times as necessary
- Product build: on meeting of requirements and needs, it’s time to get developing
We’ve spoken before about how prototyping can improve communication, reduce costs and even avoid common software project pain points, but how can project/product managers be sure they’re implementing the prototyping methodology correctly?
Answer: by following one of these 4 popular prototyping process models, applied when using a prototyping methodology to design and develop winning software.
It goes by many names – rapid, throwaway, close-ended – but all terms refer to the same methodology: a rough prototype is built with the bare minimum of requirements definition; once detailed requirements have been elicited through this rough prototype, the prototype is completely discarded (hence the name ‘throwaway’) and the developers get to work on the actual software. Knowing that none of the throwaway prototype will be used in the actual software frees designers up – forget about maintainability or even style, just get the quick and dirty prototype out, tested and discarded. Focus on features and functions without expanding scope or cost.
Rapid/throwaway prototyping has plenty advantages – it’s cost-effective, low effort and fast, while still producing a prototype that can be tested by users in the early stages of the project cycle. Accurate definition of requirements with minimum time and manpower is a powerful reason to implement rapid/throwaway prototyping into the software development lifecycle.
Of course, the throwaway approach won’t suit every project or product. The focus on fast build-discard cycles can mean that developers are distracted from analyzing requirements fully, so better solutions might be overlooked in the rush to get stuff out there. It’s smart to do throwaway prototyping with known and trusted teams.
Evolutionary prototyping takes a more slow and steady approach to software prototyping. Requirements that are well understood and defined are used to build an initial functional prototype; gradually, as more and more requirements come into focus through feedback, testing and building, new prototypes are built around the original. Evolutionary is in many ways the opposite of throwaway prototyping, as the initial prototype is at the heart of the final product.
This considered prototyping approach means that refinement is a constant, changes are allowed to develop organically and developers don’t get stressed by having to develop the whole system in a oner, instead focusing on prototyping what they understand and letting the rest play out. The resulting prototypes can sometimes be strong enough to stand in for the final system for a short time if needs be.
However, this Darwinian approach has one potential negative side – like any evolution, it takes time, and some projects don’t dispose of a ton of time for making super detailed prototypes. Also, if using an evolutionary prototyping approach with stakeholders inexperienced in software development, there’s a risk some may confuse the prototype for the final product – when this happens they can get attached to features that might not make the final cut, or demand 100% functionality in all use cases. It’s important to make it clear that this is a prototype, albeit an awesome evolutionary one.
Incremental prototyping has correlations with the evolutionary approach, but it certainly isn’t the same. Whereas in evolutionary you’ll have one prototype that develops organically, an incremental approach involves building different prototypes of different features, then merging them all into one over-arching design concept. Multiple small-scale prototyping cycles go on simultaneously, each going through the basic prototyping process – requirements, design, testing, redesigning – individually.
Sound complicated? Incremental can be tough on the project manager, but the advantages it brings can outweigh the disadvantages: time between project kick-off and final delivery is significantly reduced, because all parts of the system are prototyped and tested simultaneously. Of course, there’s always the possibility the pieces just won’t fit together – this can only be avoided by careful and complete plotting of the entire system before prototyping starts.
If extreme prototyping sounds intense, that’s because it is. Reserved pretty much exclusively for web prototyping, design and development, extreme prototyping consists of three interdependent phases: phase 1 involves building a static prototype out of HTML pages; in phase 2, functional screens are created with a simulated services layer; finally, phase 3 all the services are activated. It’s known as ‘extreme’ because developers are basically creating functional UIs blind.
This extreme approach makes for super fast project cycling and delivery, and keeps the whole team focused on deliverables rather than discovering every possible requirement and adding unnecessary features.
The downside? Teams have to work on top of each other, and managing egos and workloads can get tricky. Also, ‘extras’ such as QA can get left by the wayside in the rush towards product launch
Prototyping process models – the takeaway
These 4 process models mean that a prototyping approach can be taken to almost any software development project, regardless of resources or scope. Whatever the overarching development framework, throwaway, evolutionary, incremental or extreme prototyping can contribute to projects being brought home faster and cheaper.