As software continues to develop at an overwhelming speed, it’s important to back it up, and look at how it’s made. Two of the most popular development methods are waterfall and RAD (Rapid Application Development). Here’s a good comparison of the two, along with some extra notes about how Agile development principles compare.
The waterfall model of development was established many decades ago as a definitive way to approach engineering projects. Its name comes from the fact that progress flows down sequential steps.
The engineering team will first meet with the client to discern all of the requirements. Then the engineers design a solution to meet the requirements. Next, they build the solution. Once it is ready, they take the solution back to the client for testing, and after fixing all the bugs, they deploy it and carry out scheduled maintenance.
Rapid application development came as a response to problems when applying the waterfall model to software development. Software is uniquely different than other types of engineering because changes can be made almost immediately and even very late in the development process.
The client and developer work together to create an end product that functions exactly as the client wants.
Although RAD is a unique model for software development, that doesn’t mean it’s always better. In fact, many developers still prefer the waterfall model. Here are several different factors that can help you choose which model is best for you.
|Time||Sticks to a planned schedule, needs to start back at the beginning if significant changes emerge||Open-ended, the project is done when the client is happy|
|Ideal Size of the Project||Very small and very large projects||Small and medium-sized projects|
|Developer Team Size||Can be small to large||Needs to be small|
|Developer Experience Level||Can be junior to senior if the specs are clear||Multi-talented, very experienced and flexible|
|Ideal Project Type||On-premise, desktop applications||Web-based, mobile apps|
|Ideal Client||Extremely hands-off, knows exactly what he/she wants from the beginning||Good communicator, open to suggestions, has the big picture, available|
|Worst client||Changes mind frequently, wants to be involved all the time, scope creep||Inaccessible, indecisive, uninterested|
|Risk||Risk assessed at the beginning is accounted for, but not in the middle||Respond and prepare for risks continuously|
|Approach to change||Change is extremely negative||Change is welcome|
|Best time for changes||At the very beginning||Anytime|
|Project Management Style||Stick to the original plans and dates||Very adaptive, more like driving an elephant|
|Use of new technologies||No changes after specs are set||New changes can be brought in anytime|
|Feature Management||Every feature in the spec is built||Only features that prove to be useful are built|
|Updates and Versions||Planned and methodical||Ad-hoc and quick|
|Costs||Fixed costs, assuming no changes||Variable, depending on the number of iterations|
|Prototype||Delivered after the entire app is fully functional||Working model delivered as soon as possible|
When you look at RAD vs. Agile, they are very similar concepts. Both are reactions to the standard waterfall method. The differences between RAD and Agile are still emerging, as they aren’t usually seen as conflicting. However, there are some key distinctions you can make.
Agile is a set of principles about software development. It focuses mostly on breaking down the project into features, each built in a different sprint (usually focusing on the most difficult one first). In some ways, it still uses the basic waterfall concepts, but creates dozens of iterations to get more feedback and testing done as each feature is finished.
RAD is more focused on prototypes. In RAD, the primary focus is to get something usable in front of the client as quickly as possible to get feedback. In the RAD model, you may show the client something still in the development phase, whereas Agile will usually wait until a specific feature is designed and built before showing it.
Also, RAD tends to be less focused on the UI/UX in favor of functionality, while Agile is more likely to consider the design as an essential part of the product.
If you are considering waterfall vs. RAD or even RAD vs. Agile, the key questions you should ask have to do with the nature of the project and what kind of developers you have.
As clients, project leads, and developers become more skilled, there may be less of a need to follow the typical waterfall methodology. You can move to a more adaptive and faster means of development. But if your team is fairly inexperienced, relying on a traditional development model may be better in the beginning.
Kissflow is an example of a business process application platform that works best with RAD principles. Users can create their own apps extremely fast and can make changes instantly. Try it today with a free trial and see just how fast process app development can be!