#5. Software development life cycles

In simple words, the software development life cycle (SDLC) is a process that software engineers use to plan, design, develop, test, deploy, and maintain software applications. The SDLC provides a framework for the development and maintenance of software applications. It is a systematic approach to software development, which involves following a set of steps and procedures. Each stage, in its turn, has specific objectives and deliverables.

There are four main SDLCs:

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

Predictive, Iterative, Incremental and Agile life cycles illustrated

Predictive approach

The predictive approach, also known as the traditional or classical approach, is focused on planning and determining the needs of a project before it begins. The goal is to reduce the chance of changes during the project. A popular example of this approach is the Waterfall model, which was commonly used before Agile became popular. This approach is divided into four phases:

designing the project;
developing the software;
testing the software;
and delivering the project.

In the 80s, this approach began to be widely used in the IT field, as it enabled project teams to reduce potential risks. Business analysts were collecting the requirements, and a single document called "SRS (System Requirement Specification)" was written.

Nowadays, instead of SRS, the project teams compose "PRDs (Product Requirements Documents)" and pass them to the design (UI-UX) team. Then it goes to the development stage (actual coding of the software), then testing of the software, and once completed - the handover stage (project delivery).

With this approach, there was one major flaw - the customer only got to see the final outcome and could only ask for modifications after the project was completed. Any change requests could be rejected by the software development company, referring to the contract points that were agreed and signed a while ago.

Iterative approach

The iterative approach doesn't require finalizing all requirements before starting a project; enough if the customer knows roughly what they want. The project is being broken into iterations (time periods). In each iteration, the development team brings software closer to the customer's wishes. By conducting DEMOs for the customer, they evaluate progress together and decide the next priority.

The emphasis here is on making sure the program is functional after each iteration, so the main rule is completing tasks that benefit the whole product. For example, our project is a dating website. The customer wants users to enhance the matching algorithm.

We have the website but no auto-matching system. In the iterative approach, one iteration could be implementing user profile fields with interests. Another iteration could be used to implement analysis mechanisms to process the data of those fields. And the last iteration could be the development of the matching system itself.

The iteration's duration is determined by project participants. The main difficulty of this approach is the inability to estimate the project budget and its duration precisely. Both of them can change as the project goes on and the customer comes up with new requirements.

Incremental approach

This approach, as well as iterative, foresees that software is developed in stages, but unlike iterative, these stages' output is always a 100% completed software piece (feature). Documentation for each increment is prepared beforehand to reduce the risk of changing requirements. This approach sometimes is called multi-waterfall.

Software requirements are being broken into functional, complete modules. And then, the software piece is processed by the development team.

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)

Agile's popularity grew in tandem with the rapid growth of the IT industry and software development technologies. It became apparent in the early 2000s that, for long-term projects, a different approach was needed to ensure the end product met current market needs and consumer expectations.

This posed a challenge as consumers sought more features on a daily basis. Agile provides a solution, being a hybrid of the Iterative and Incremental approaches. These approaches are guided by the goal of increasing the customer's value of the software after each iteration. The Agile Manifesto and its 4 points form the basis of its philosophy.

Let's go through and describe the principles of Agile:

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.

We should always be guided by whether or not we will be able to deliver the output currently needed by the customer.
For example, suppose we want to complete a module, but it is obvious that we will not manage to do it in one iteration. In that case, 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.

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

It's not easy to convince programmers to remove code that's no longer needed, especially if it was created with many late nights of hard work. The manager should take this into account before starting the project, as everyone must have the same goal in mind. Our mission is not to code or make reports but to help the customer stay competitive.

We must be ready to rewrite or kill the old project if necessary. Even though it can be hard to accept, it's this ability to come together and tackle new tasks that make us experts. The project manager plays a major role here, as they often hear the news first.

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

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

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

This point is often overlooked due to hierarchy and bureaucracy. Yet, the reader will recognize the logic behind this principle: to ensure success for the customer, developers must have a thorough understanding of their business.

Familiarizing developers with the business prior to the project will give them ideas for improvement and allow them to identify technical risks that the client may have missed. Agile emphasizes the importance of transparency between team members, further stressing this point.

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

Motivated professionals are attracted to projects where they understand the goals and prospects. Explaining the significance of the project and the importance of each individual's contribution is key to motivating the team. Without this, a task is just a task, and the desire to work and improve the project may wane. To ensure harmony and progress, a supportive, transparent environment must be created between team members, with the project manager monitoring the team's mood.

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

Chatting is becoming popular, but live communication is still important. It's a good idea to make time for it, as long as it doesn't get in the way of work.

Working software is the primary measure of progress.

We may work hard for a long time and think things are going well, but the only way to gauge our progress is if we have a working product. That's why many start-ups focus on launching quickly and then improving it later.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.

Maintaining the quality of a project's code and documentation is essential in the long run. To achieve technical excellence and design quality, the code must be 'cleaned' of old elements, and advanced technologies must be utilized.

Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.

A self-organizing team in Agile is one that has worked together for a long time, so they know how to effectively collaborate and act as one. This team has a unified understanding of the project's values, eliminating the need to ask questions about how to do the work. Such teams are usually formed after years of working together in the same composition in larger companies where team members rarely switch.

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.

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:

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, not bureaucracy.

In the next article, we will talk about the most popular Agile framework: Scrum (SCRUM).