As we have seen, there are many different methodologies, and we will now learn that this is also true for software development life cycles.

By the life cycle, we mean the period that starts with the decision to develop something and ends with the actual completion of the project. This is also relevant to the context of an IT company engaged in a software development project.

Unlike philosophies and methodologies, which show us what values we profess and what principles and practices we want to achieve, when it comes to life cycles, we can combine several approaches to development in a single project.

Let's talk about four approaches, which are more than enough to give the big picture:

• Predictive Life Cycle
• Iterative Life Cycle
• Incremental Life Cycle
• Agile Life Cycle

Predictive approach

Also called the traditional/classical approach.

This approach is fully focused on planning and ascertaining the requirements before the start of a project. Ideally, this development process implies that potential changes during implementation will be reduced to zero due to the clarity of customer requirements from the outset.

The most popular example of a predictable approach is the cascade model, also known as Waterfall. This approach was widely used in the days before Agile gained its popularity. The essence of the predicted approach can be summed up in four phases:

• Development of the project design
• Software development
• Software testing
• Project delivery

The approach began to be actively used in the 80s. Over time, it gained extensive popularity in the IT field, since it allowed practitioners to minimize the many risks arising.

In particular, there was a risk that the customer could request changes, which would result in increased cost and longer development periods. Accordingly, the zero phases entailed a thorough collection of information about the system being developed, as well as identification of all potential issues that might arise in the future. Based on the data collected, an SRS document (System Requirements Specification) was compiled, which described everything that is going to be developed. Once the customer had approved the SRS, the development team divided it into epics, user stories, and technical tasks, identifying those responsible for the development and adhering to deadlines. As implementation proceeded, the completed tasks were transferred to the 3rd phase - testing, where testers checked them for compliance with the documentation agreed with the customer, and, if everything was in order, they were marked as completed and waited in the wings.

So, the project was implemented gradually; once all the tasks had been completed, regression testing was conducted, which involved testers checking all the software for compliance with the documentation. At the end of all procedures, they wrote up the project and submitted it for delivery to the customer.

The rudeness of this approach has always been that only the final result was shown to the customer, and it was only at the end of the development of the project that the customer could express his opinion and request changes. It was aggravated by the fact that the implementing company could simply refuse to make the changes, as the document had been agreed and signed long ago ☺.

Iterative approach

The iterative approach, in contrast to the predictive one, does not require that all requirements be finalized before the start of the project. In the beginning, it is sufficient if the customer knows more or less what he wants.

The project is conventionally divided into an indefinite number of iterations (time periods). In each iteration, the developers bring the software closer to the customer's wishes, who, in turn, after each iteration, evaluates what has been done and determines where to go next - whether to change direction or continue as planned. The emphasis is on making sure that, after each iteration, the program is functional – albeit not in its final state – and thus, the main rule of the iterative approach is the completion of each segment so that what is developed in that iteration benefits the product as a whole. (It is also important to emphasize that if the customer wants to delete the result of the last iteration because it did not meet his expectations, this is also a positive result since all involved learn from their mistakes and improve the quality of their performance.

For example, a customer orders a web project for a dating site. He wants users on this site to find each other and communicate directly, and the system should introduce users to each other based on their shared interests.

Suppose that we already have this website developed, but there is no automatic matching system. Users are obliged to manually search for each other in long lists filtered only by gender. 

In the logic of the iterative approach, for one iteration, you can implement several fields to the website user profile, where s/ he could choose one of twenty interests scattered in a few interest categories. 

After that, you can analyze the data to understand how interesting this feature was for users, and in the next development iteration, implement an automatic matching system. At some point, the system will "learn" to determine the most likely candidates for a user who is just completed the registration process. Our client is happy. We're also happy as we chose the most proper approach for the implementation and saved time and money.

It is obvious that the duration of the iterations is variable and is determined by the project participants themselves.

The key difficulty of this approach is that at the start, it is complicated to estimate the cost and duration of project development because we assume changes in requirements.

Incremental approach

This approach, as well as iterative, foresees that the software will be developed in stages but, unlike iterative, the software stages will be standalone. In other words, once a part of the system has been completed, the presumption is that it is 100% complete and ready to use. Often, the documentation for each increment is prepared even before the start of development, in order to minimize the risks associated with changing requirements. For this reason, the incremental approach is sometimes called multi-waterfall.

In this approach, the software is broken down into several independent, functional modules, and developed accordingly.

For example, let's suppose our client is a gambling company that wants to have its own website with different games. Using the logic of the incremental approach, we will separately develop a module for live games, a separate module for supporting e-sports bets, a separate module for poker (poker rooms , tournaments) and so on. I am exaggerating of course, but I think you get the idea in general.

Each module developed through the incremental approach is called an increment (surprise, surprise!).

The incremental approach is not flexible, since it requires one to specify the precise requirements for each increment beforehand. On the other hand, it makes it possible to determine the cost and development period for each increment.

Agile approach (also known as Agile development)

The birth and growing popularity of Agile was in proportion to the speed of development of the IT industry in general, and software development technologies in particular. In the early 2000s, it became clear to intelligent observers that the world is developing more and more rapidly, and whereas for a project of a short duration (say a month and a half or two) it is still possible to collect all the requirements at the beginning, compile documentation, and only then proceed development, for longer duration projects (e.g. several months or even years), a different approach is needed, otherwise you will end up releasing on the market an outdated product based on a list of requirements which had been finalized half a year ago, as opposed to a product that corresponds to the current needs of the market. Moreover, as consumers increasingly demand new features on an almost daily basis, and the current generation already has a whole list of constantly expanding expectations from Apps, to survive in today's dynamic market, you have to be "modern." This is where Agile appears.

Agile, in the context of the approaches that we have described, is a hybrid of the Iterative and Incremental approaches. In line with the goals set by the customer, the project team may decide to resort to a partially iterative approach, or a partially incremental approach, guided solely by the fact that the software increases its value to the customer upon completion of each iteration.

Agile, as we noted in the previous article, has a set of values enshrined in the 4 points of its manifesto, which are the basis of Agile's philosophy.

Here we will analyze the principles of Agile.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

This item emphasizes the importance of early and continuous delivery, which in turn implies that we should forget about iterations (time spans) that last too long, and try to provide the customer with updated software versions as soon as we can. The second important aspect – delivery of valuable software – guides us when making choices about what items to include in the current iteration, and what work to earmark for inclusion in the development of the next iteration. We should always be guided by whether or not we will be able to deliver the output currently needed by the customer.

For example, if we want to complete a module, but it is obvious that we will not manage to do it in one iteration, we can divide this module into several parts and split them between several iterations, so that in each iteration they occupy 15% of the total time spent on the project tasks, and in addition to this module add value for the customer to other, more complete parts of the product developed in these iterations.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage

It's not easy to "sell" this concept to programmers, because it can be exasperating to have to remove a piece of code that is no longer relevant and is not needed by the customer when you have spent many sleepless nights designing it. The manager needs to take this principle into account before the project commences, because this is obviously an issue on which it is necessary to achieve complete agreement in the team at the very start. It is vital that in the mind of all the project participants there should be a clear picture of what we are going to achieve. Our main task is not to write thousands of lines of code, and not to generate monthly reports. We must make every effort to ensure that the customer consolidates their position in the market, and for this we must do everything in our power. If for this you need to rewrite a part of the system, we will do it. If the market has changed, and we need to start a new project, killing the old one - we will do it. We have to understand that in spite of the sadness and disappointment that can hit a team in such difficult moments, it is the ability to get together and solve new tasks with the same enthusiasm that is the key reason why we consider ourselves experts. Of course, it is at such moments that the role of the project manager is particularly important, not least because they will, in fact, be one of the first to hear the news about changing course, or abandoning previously agreed ideas.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

At the moment, most agile companies prefer two-week iterations. In practice, I have not seen iterations of more than a month.

4. Business people and developers must work together daily throughout the project.

Alas, this point is often underestimated, falling foul to the hierarchy and corporate bureaucracy concerning information flows. However, no doubt, the attentive reader has noticed the logic of this principle because if we want each step of the process to bring success to the customer, then obviously, we have to have intimate knowledge of their business. Yep, an understanding of how our client's business functions are one of the keys to the success of a project. By briefly familiarizing developers with the business before the start of the project, we increase the chance that they will have good ideas about things that can be added, or, more probably, they will identify some technical risks that have escaped the client's attention. Agile stresses the value of transparency between all team members, and this point once again underlines the importance of this transparency.

5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.

Motivated professionals appear where they understand the goals and prospects for each of the participants. There is value in explaining to the participants the significance of the project as well as the importance of each individual contribution. For a professional, often, a task is just a task, and so, if we want to motivate the team, we must encourage them to make this task their mission. In that way, the desire to work and improve the project does not wane. "Environment" in this context means ease and transparency between team members so that everyone knows who does what. The immediate task of the project manager is to support, to keep a "finger on the pulse" and closely monitor the team's mood so that the work proceeds harmoniously and without interruption.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

In the modern world, communication in chat rooms is becoming more and more popular; however, because human beings are essentially social animals, for the foreseeable future, chat rooms will not replace live communication. Practicing live communication – provided it is not at the expense of work – is a great habit.

7. Working software is the primary measure of progress.

We can work zealously for many months, and all this time, we may be under the impression that everything is coming along just fine, but the key indicator of our progress will be: do we have a working product? That is why most modern start-ups strive to launch a product in the market as quickly as possible, and only after that do they work on improving it.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Looks like advertising in disguise, doesn't it? :) No comments, let's move on to the next item.

9. Continuous attention to technical excellence and good design enhances agility.

This item is as important as the quality of the project in the long term. Striving for technical excellence and design quality means "cleaning" the program code from old garbage and using advanced technologies regardless of their complexity or the lack of detailed documentation on them. Not many technical specialists are particularly pedantic about this item, but they exist. I will not discuss this point in more detail right now since this issue deserves a separate article.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

Again, if, at the beginning of the project, we clearly outline the values that we are going to follow, and provided we can follow them, then simplicity is achieved by itself.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

In Agile, a self-organizing team is a team that has worked together, in the same composition, long enough to learn how to work extremely smoothly and in unison. In such teams, there are rarely questions about how to do the work, or what to consider, because ideally, all members of this team have a common understanding of the values (philosophy) of the project. Such teams are created over years of work, often in large companies, where the composition of teams rarely change.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Or, more precisely, the project manager should systematically analyze possible ways to improve the team's performance, find options for correcting the team's work style, publicly discuss problems and agree on solutions to be incorporated in future work behavior.

Thus, the principles of Agile provide us with a foundation on which we can assemble the practices and tools we need, regardless of how we will combine the incremental and iterative approaches.

A few words about the documentation in Agile:

(Found in my notes; if previous thoughts are being repeated here, never mind: it's still valuable.)

• AGILE does not need to adhere to strict documentation;
• Documentation can be both for internal use by the development team and a technical document describing the product itself, with all its properties and features;
• Excessively detailed documentation increases the risk of ambiguity, misunderstanding, and divergence of views between team members;
• It is almost impossible to write exhaustive documentation for managing an AGILE project;
• The task of writing documentation should be entrusted to one person to avoid the problem of fragmented vision;
• A company that confines itself to developing only the documentation necessary for a project creates an environment in which the team is entrusted to do exactly what is necessary according to the document, even if changes occur. This, of course, is good for reporting but disastrous for the project.

Conclusion

So, in this article, we have learned what popular software development cycles exist, why they arose, and what tasks they solve. We have a general understanding of the pros and cons of these approaches and have seen that Agile – true to its name – has the most flexible approach and is aimed at creating a result and not bureaucracy.

Via KeepSimple

A A A A

Explore more on these topics