For the uninitiated, Waterfall and Agile Development probably sound unimportant, and you probably don’t care what the difference is. In one recent survey, only 2% of the respondents said management knew what Agile was.
But if you’re about embark on a large scale custom software or software modernization project, there are a lot of reasons why you should care about how your software is created. I’d like to cover the differences between Agile and Waterfall development methodologies in a two-part series. This week, I’ll cover Waterfall Development.
The five phases show in the figured to the left show how Waterfall Development is a linear process. To get started, all of the requirements must be established in the beginning and all of the design work must be completed before any solution development commences. This is very much like building a house in that the full architectural plans are complete before construction begins.
When utilizing the Waterfall development process, we spend a lot of time at the front-end of the project gathering all requirements and designing the entire solution during the Envision and Plan phases. The implementation of the solution (e.g. SharePoint implementation, a custom application, etc.) begins in the Build phase once all of the requirements are enumerated and screen mock-ups are approved. When the implementation is complete, functional testing and User Acceptance Testing (UAT) are carried out in the Stabilize phase against the requirements captured in the Envision and Plan phases. Once testing is complete and we have sign-off from users and business owners, we transition into the Deploy phase where the solution is delivered into a production environment.
This process works best when the requirements can be captured in full at the beginning of the project and there is very little change in requirements over time. One major thought to consider before you commit to Waterfall development is that no matter how sure you and your team are that you know what you want, generally as projects develop, perceptions of what is required tend to evolve too.
The Waterfall process does allow for changes in requirements to be made through a Change Request process. The Change Request process requires the source, rationale and impact of the change to be documented and signed off on before the change can be implemented. This process is administratively intensive and can impact the overall timeline for delivery of the solution depending on the scope of the changes requested.
Next week I’ll cover how Agile development is different and why we generally recommend it as the best method for achieving quick results for our clients.
For more on custom software development and how Entrance develops software, visit our resources on the subject in the Knowledge Base!