When a development team faces a new project, they must choose a development model that is appropriate for that project. Knowing how to choose what your work methodology will be, is a great challenge, which can bring consequences, the choice and execution will be the one that indicates what type of consequences you will get.
Knowing the different models and methodologies for development will be a great contribution to your experience as a developer and highly appreciated in development teams.
Cascade model or classic life cycle
The phases are carried out sequentially, at the end of each one the necessary information is required to start the next one. Having to wait at the end of each phase causes several situations:
- Part of the team that does not work in this phase, remains still, waiting to start. This generates a crash.
- The client will not see their program running until the last stages of the project.
In reality, this methodology does not have many advantages. And less and less development teams use it, and in this classification of advantages and disadvantages, we can see the reason.
| Advantages | Drowbacks |
|---|---|
| At the end of each phase the technical staff and users they have an opportunity to review the progress of the project. | You need to have each and every one of the requirements well defined at the beginning of the project |
| It takes a long time to go through the entire cycle. | |
| If mistakes have been made and are not detected at the stage immediately afterwards it is costly and difficult to go back to make the correction. | |
| It accentuates the failure in its communication with the end user. |
In summary, this model represents a great cost, both in time and money, so it is hardly used much among companies dedicated to technology.
But it is always good to remember it to make better recommendations in the team when someone proposes to use it.
Evolutionary model
Methodologies based on this type of model are more easily adapted to the changes introduced throughout development. They are iterative. In each iteration more complete versions are obtained of the software. Within this model we distinguish two:
- Spiral model
- Incremental model
Spiral model
At the end of each iteration the team that develops the software and the client analyze the prototype or MVP (Minimum viable product) obtained and they will agree whether to start a new iteration.
This model always works on a prototype, so when the team decides not to run new iterations and finalize the product, the prototype will be refined to achieve the finished, stable and robust final version.
This model revolves around risks. For each iteration, if it is decided that an improvement or modification of the prototype is needed, the option that supposes a lower risk for the equipment and the product is taken.
With each iteration around the spiral (starting in the center and continuing towards the outside), they are built successive versions of the software, increasingly complete and, in the end, the fully functional software system itself.
Used in long projects such as creation of an OS, which need constant changes. We will visualize its advantages and disadvantages.
| Advatages | Drowbacks |
|---|---|
| Allows for iterations, backtracking, and quick endings. | Time cost that adds up to each turn of the spiral. |
| Eliminate mistakes and unattractive alternatives at the beginning | Need to constantly assess the risks, seeking continuous communication with the customer or user. |
| It incorporates quality objectives and risk management. | Difficult to predict the cost and duration of the project. |
| It allows development work in conjunction with other models. |
Incremental model
It is based on the construction of the program increasing its functionalities. Its methodology is based on modular design. It allows to gradually increase the capacities of the software.
This methodology allows each member of the team to develop a particular module, making teamwork more productive and creating serial development. A repetition of the cascade life cycle is performed, applying this cycle on each functionality to develop. Something advantageous about this model is that it allows a fully functional version of the product to be delivered to the customer at the end of each cycle. What is favorable for the client and for the team.
We will visualize its advantages and disadvantages.
| Advatages | Drowbacks |
|---|---|
| Building a small system is always less risky than build a big one. | If the requirements to be implemented in each phase are not well selected, we can reach an incremental phase in which important parts of the software or design have to be redone. |
| As independent functionalities are developed, it becomes easier to release user requirements. | |
| If a fatal error is detected, only the last one is discarded iteration. | |
| Facilitates the development of divide and conquer. | |
| It is not necessary to have all the requirements of all functionalities at the beginning of the project. | |
| Corrects the need for a non-linear sequence of steps developmental. | |
| Long projects are avoided and “something of value” is delivered to users with some frequency. | |
| The user gets more involved. | |
| Higher return on investment. |
Now, we can understand why it is so important to know how to choose which model will be most convenient for us when we work.
In part two of this post, we will be learning about the most used methodologies currently in development teams.
See you soon...
Top comments (2)
We have to be careful tho, Waterfall/Cascade sometimes is the only acceptable option, sometimes you can't deliver a constant stream of changes and the client is not interested in give feedback, specially in areas like embedded the product has to be finished when delivered, you can't have an important embedded system half baked, because of the cost of failure and because you'll not have a happy client if you are messing with production because you have to patch the system. They usually give you a window to ask all you'll need for your design and not much more after that, you have to be extra careful and thorough to collect all the requirements at first, each additional information request is not well received and the client will take it like a lack of preparation and a poorly planned design.
Not everything is web development. There are also other projects in which the MVP is on itself big, so it will look a lot less as agile and a lot more as waterfall. Rarely things are as black and white as agile promoters want to convince us, no methodology is a replacement to common sense, experience and good judjment. :)
Good article, In the States this one is called Waterfall