Software Development Life Cycle- Why Waterfall model is not for the new age startups
The Waterfall model is one of the oldest and most widely used models for software developers around the world. In this traditional model, the developers move on to the next phase of development once the previous phase is completed and each phase begins with the previous phase’s output. The development cycle is fully planned, including the turnaround time and the budget.
Following is the process that the development goes through in the Waterfall model:
First, the business needs are analyzed, and elicitations and documentation are done. The solutions are then designed to meet the requirements and hardware and software requirements are analyzed. Once the designs are discussed and approved, the developers start coding each segment. After the development, the system moves to an official testing phase where all the segments are tested end-to-end as one, by the test engineers as well as the business. Finally, the software is deployed into the production environment and released to the market.
Now, when we talk about new age Startups, especially startups at their nascent stage, though the goal maybe crystal clear but the process to reach their lacks clarity. People involved are often confused about the features and functionalities to be incorporated which leads to fallacy in the first stage of the development itself. Besides being the most widely accepted model, it has certain very basic shortcomings which can hamper software development, especially if it is tight on budget and delivery time.
Inflexible and cumbersome:
This is one of the biggest weaknesses in the model. The process is very inflexible, very rigid. The phases are defined and you have to go through them, one by one. You cant go to change a requirement if you are in the development phase, I mean you can, but that would be an extremely costly and time taking process.
Long pole from project start to be seeing something tangible
Right from starting from the requirement to design and after working completely on the coding part, it’s only in the testing phase that the business gets to see a tangible product. And its only in the deployment phase that the business could understand the benefits of it. This usually is a pretty long time.
Problems are discovered at user testing.
Because the user doesn’t get to see or use the product anytime before the testing phase, there are a lot of problems and shortcomings that are not discovered while development. There may be something that the analysts may have missed on, or that didn’t come out in the requirements or as it happens the business requirements may have changed because of the long-time of development.
Written documentation is seldom kept updated and lose their usefulness
It’s great to have those detailed written and agreed documentations before starting any development. The problem, however, is they are hardly kept updated with the changes and after some time, they become useless. To keep the document alive and breathing up to the last stages of deployment and maintenance is always a losing battle in the Waterfall model
Promotes gap between business users and the development team
Since the business team works on the business needs and the requirements and the development team works on the design and development here is a rift. The business users sometimes never understand what’s taking the development so long as they are not able to see something concrete for very long time. This creates not so good vibes between the teams and often lead to bad misunderstandings.
So yes, the Waterfall model may be great but it won’t give you best results until you don’t have very clear objectives and have no pressure for immediate returns on ROI for implementation.
Ever met a startup like that?
In the next blog, we will talk about some better models for software development lifecycle.
Till then, keep discovering.