The SDLC: Never-ending fun – the philosophy of software development life cycle
Greetings, dear readers! Earlier in the articles of this blog, we have already touched on various aspects of the methodology and principles of software development. For example, in one of the recent articles, we discussed in detail the definition of a sprint in Agile methodology. We recommend you to read this one if you have not done it yet – It is really very interesting and useful information.
However, the more we write, the more questions arise, since software development is indeed very multifaceted and complex. Therefore, in this article we would like to pay attention to a fairly global thing, the understanding of which will help our regular readers to better navigate the subsequent narrower topics. This one is Software development life cycle – SDLC.
What is SDLC and why to use it?
Okay, first of all, let’s define the meaning of SDLC. Most often, when it comes to software development lifecycle, they mean the process of creating software from A to Z. But such a definition of SDLC is appropriate only when it comes to a specific project. In a broader sense, the software development life cycle is a standardized framework, based on which a team can release a product faster, make it better, minimize risks and avoid situations when you have to rush to finalize already finished software.
Here it is appropriate to pay attention to the word “cycle” in the wording itself. You may have seen this picture before:
Note that deployment (the last phase of the cycle) invariably leads us to the very first one: requirements analysis. This means that the software life cycle never ends. Indeed, there are no products that would be forgotten by the development team immediately after the release. Any software solution periodically needs to be updated, refined, and scaled. That is, after deploying your product, you will invariably have to return to requirements analysis, having already received real feedback from end users in one form or another.
If we are talking specifically about the creation of new software, the SDLC methodology ensures the coherence of the actions of the entire team, since each of the stages consistently and effectively influences the next one. This avoids many mistakes that could later lead to serious difficulties or even failure of the project. In other words, the software dev lifecycle is a kind of development plan template.
Software development life cycle methodology step by step
Well, let`s back to our picture. Here you can see the standard SDLC model with six main software development life cycle phases, which are:
- requirement analysis;
- architectural design;
- software development;
The first step is quite simple but no less important! Answer the fundamental question: “What are the requirements our product needs to meet?”. At this stage, it is very important to achieve maximum mutual understanding with the customer. Typically, the customer, business analyst, project manager, and members of the project team are involved in this process.
When all the requirements and expectations of the customer are specified, a document called the Software Requirement Specification is drawn up. It contains everything that has been said before. Subsequently, the developers will be guided by the SRS, so that all requirements must be clearly stated, and the document itself must be pre-approved by the customer.
An interesting fact is that during the development process of Instagram, it was the requirements analysis that took the most time. Social networks were not yet so popular, and the developers had almost no reference points, but today it is difficult to find a person who would not have an Instagram account. Isn’t this a great example of how important requirements analysis is and how effective SDLC in software engineering can be? We think it is!
An integral part of software development life cycle models is the planning process. Often it is combined with requirements analysis, but we believe that these stages should be separated. The fact is that requirements analysis involves communication between the customer and the client in order to understand what the software should be like. And the result of planning is the estimated cost of the project, risks and plans to reduce them, etc.
Simply put, at the planning stage, the team finds out whether what the customer wants is feasible, how much time and resources it will take, and how to implement it with the least loss.
Architectural design in software life cycle usually raises the most questions for those who are just starting to delve into the SDLC. As you surf the web, you can find a lot of different statements like “at this stage you convert your SRS into a project specification” (which is also a kind of plan, so it’s not clear how this stage differs from planning) or “this is the process of creating a software architecture, on the basis of which you will develop your system”, etc.
Many of them do not give a complete understanding of the essence of architectural design. Here we need to correctly pose the question, the answer to which we give at this stage (yes, this is still a process of preparation for real work). So, the question is: “How are we going to achieve our goals?”.
In this phase, we recommend considering several key design elements to make final design decisions: operational excellence, safety, reliability, performance efficiency, and cost optimization.
Finally, we no longer answer any questions, but get down to business! So, your main task is to do an amazing job, justify the trust of the customer and be satisfied with the result. Fill up with hot coffee, roll up your sleeves and do it! There’s nothing more to say.
Developers vs testers is a never ending story. However, the systems development life cycle methodology does not prioritize one over the other. You must understand that there will be no release of the product until your product meets the specifications. Everyone makes mistakes, even developers (and here one tester smiled).
Each development cycle ends with software deployment. And then it starts all over again.
You see, in theory, deployment is all that makes a program usable in a production environment, from installing it on a computer to releasing updates. But we have already understood that the cycle inevitably moves to a new round. Therefore, by deployment we mean the processes accompanying the release of programs, but not their support in the future – for this we have to start again with a requirements analysis.
By the way, congratulations on the release!
For the sake of completeness, another phase of the software development life cycle should also be mentioned. This is maintenance, which is not always distinguished as a separate stage. DevOps engineers are working in this direction. In fact, they are engaged in the maintenance of the system after its deployment. But in a broader sense, they have a more significant mission – to be a bridge between the OPS and development teams. When both use common tools for error detection or performance checks, this fundamentally changes the SDLC experience.
SDLC models to implement: benefits and peculiarities
Now let’s take a look at the most popular examples of SDLC models
Of all the known software development lifecycle models, the waterfall is the oldest and, to some extent, the most primitive. According to this concept, the entire development process is divided into several stages, and each next cannot be started until the previous one is completed. The waterfall has one significant drawback: if small tasks were not completed during any stage, they can create a big problem in the future, because the plan for subsequent stages does not involve patching these “holes”.
Based on the name of the agile methodology, it is clear that this approach is designed for the flexibility of the development team. The project is broken down into continuous cycles, which are also divided into smaller iterations. At the end of each iteration, the product (or some part of it) is tested, which prevents small unsolved problems from becoming a serious problem in the next stages.
Today, more and more teams are abandoning the waterfall in favor of an agile methodology. It should be noted that among the newer SDLC approaches, agile is the most developed. It is also divided into several different sub-methodologies: Scrum, Kanban, etc.
The project is divided into several iterations, and at the end of each we have a version of the product ready for deployment/ The version already meets some functional and non-functional requirements (not all). The final iteration leads to the release of a product that meets the full list of requirements.
A more flexible version of the waterfall. The development stages also strictly follow each other, but testing is carried out at each stage, which allows you to respond to shortcomings in time.
This model is also based on iterations, but the spiral approach can also include methods that are characteristic of other models.
The development process is managed by the project risk assessment system, which will be unique in each case. Thus, the spiral is the most flexible of the SDLC models.
The Big Bang
A very simple SDLC model that does not require careful planning, but is associated with the greatest risks. In view of this, the Big Bang model is only applied to small projects where the developer has more opportunities to show their creativity.
It’s also a very fast development, even spontaneous in a way. On the other hand, we all know how much beauty the Big Bang created, right?
On a final note
The SDLC framework helps development teams reduce production time, increase productivity and potential profit, save budget and minimize project risks. In general, this is a plan for conducting technical work, but if you look more broadly, you can think of it as a guide to life. You can apply SDLC to a variety of topics. Think of the SDLC as a blueprint for expected success and it won’t take long.