It is curious to see how the concept of “life cycle,” one of the most fundamental and transcendental pieces of software management (or Software development life cycle, produces so much confusion. It is not surprising either because there is no single terminology in this regard, and there are many definitions, confusing concepts, etc.
However, in this post, I wanted to touch on the subject of life cycles because it seems fundamental to me, and I find that there are many doubts about it. And knowing that the topic is too deep to settle in a post and that I will have to leave in it only concepts and definitions on which there is more consensus, knowing that there are authors who give many of the following terms others names and particularize them.
Waterfall
The phases of the life cycle (requirements, analysis, design, etc.) are carried out (in theory) in a linear way, only once, and the beginning of a phase does not start until the previous phase ends.
Its nature is linear, typical of the construction of physical products (we discussed two reasons why making software is not the same as driving cars or building houses), and its main problem comes from the fact that it does not make clear how to respond when the result of a phase is not as expected.
Most of the time, the most criticized life cycle in recent years, but not all, rightly so. In many projects, its implementation has been a failure. At the same time, other projects go perfectly in this way (although they are fewer and fewer due to how the nature of what we “create” has been changing, which has been moving to more changing environments and uncertainty).
Mistakenly, this life cycle has been synonymous with the word “process,” as we discussed in myths of Software Development: Process is synonymous with the waterfall life cycle.
Spiral
To solve the above problems, in 1984, Boehm presented the spiral life cycle, in which each of the phases of the waterfall end with a risk assessment and prototype.
Prototypes allow users to determine whether the project should continue, return to earlier phases, or end. However, the phases are still linear; requirements are realized in the requirements phase, design in the design phase, etc.
The incremental life cycle
Each iteration (an iteration is a timeframe, not to be confused with the iterative life cycle, which we will see later, this being one of the main messes that come from confusing definitions) contains the phases of the standard waterfall. Still, each iteration works on a subset of functionality. The total project delivery is divided into prioritized subsystems. Develop the software product in parts and then integrate them as they are completed. An example of purely incremental development can be aggregating modules in different phases to add more functionalities to the system.
The iterative lifecycle
In each cycle or iteration, the product is reviewed and improved. An example of iterative development is the one based on refactoring (I leave you the introductory post to refactoring ), in which each cycle further enhances the quality of the product.
It is important to say that this cycle does not imply adding functionalities to the product but rather reviewing and improving it.
Life cycles of agile «methodologies»
Going to a minimum definition, it would be an iterative and incremental life cycle, with short iterations (weeks) and without linear phases (cascade type) within each iteration. Starting from the previous one, nuances, adaptations, etc., there are for each agile «methodology» that exists.
Perhaps, the most famous case is Scrum. Years ago, in 1985, and in the first official presentation of Scrum, Ken Schwaber, one of its creators, spoke about the Scrum life cycle, and its differences from previous life cycles
As Ken Schwaber comments, the Cascade and Spiral lifecycles close the context and delivery at the start of a project. The main difference between waterfall, spiral, and iterative and agile life cycles, specifically in Scrum, is that the latter assumes that each iteration or Sprint’s analysis, design, etc., are unpredictable. Sprints, or short iterations, are not (or a priori, they don’t have to be) linear and are flexible. But, as I mentioned, each “methodology” of the agile calls, FDD, Crystal, DSDM, XP, etc., will nuance its life cycle.