There are so many different SDLC models in software engineering, and choosing the best one for your project is half the battle on the way to creating a successful product. People have already developed frameworks for efficient project management called software development methodologies. In the article, we’ll look at the most common ones, see what steps they include, and discuss how to choose the most suitable option according to the requirements.
What is software development life cycle, and why does this notion seem so challenging and complicated at first? SDLC is one of the basic notions of software development. It stands for Software Development Life Cycle. SDLC is a continuous process, which starts when a decision to launch the project is made and ends at the moment of its complete removal from the exploitation. There is no universal SDLC model. They are divided into groups according to some factors, and each approach has its strengths and weaknesses.
Evolving from the first and oldest “waterfall” SDLC model, their variety significantly expanded. The diversity of SDLC models is predetermined by the vast number of product types – starting with web application development services to complex medical software implementation. And if you take one of the SDLC models mentioned below as the basis – in any case, it should be adjusted to the features of the product, project, and company. You can see the most used and reliable SDLC models on the list below:
The SDLC models define how the process is organized, in which order the potential risks are eliminated, and the problems are solved. We’ll look into some of the models, discuss their similarities and differences, and name some of the most beneficial and comfortable to work with.
By the way, the frequency of communication between the programmers and other details related to the collaboration within a team are also defined by the SDLC model. While planning all details, the project manager should choose the model according to the team size, working schedule, etc.
For example, all software development life cycle models under the adaptive type will not be suitable for large teams and yield results only in groups of approximately 5 to 10 people. Later in the article, we’ll discuss two main types of SDLC models – “adaptive and predictive” or “heavyweight and agile.”
So, no matter what software development approach you’ve chosen, each has the core stages which every software product goes through.Let’s explore those stages as it is essential to understand different SDLC models in detail.
There are many different SDLC models in software engineering, and they vary according to many factors. Still, the sequence of software life cycle phases usually remains the same, with a few exceptions. Let’s see what software life cycle phases there are and what should be done during each.
Requirement gathering and analysis are crucial for a software life cycle. There are many people taking part in this stage and many processes going on. In short, specialists try to look at the project from the business perspective and understand whether it’s worth the investment.
Each software development life cycle model starts with the analysis, in which the stakeholders of the process discuss the requirements for the final product. The goal of this stage is the detailed definition of the system requirements. Besides, it is necessary to ensure that all the process participants clearly understand the tasks and how specialists will implement every requirement. Often, the discussion involves the QA specialists who can interrupt the process with the adjustments even during the development stage if it is necessary. Also, a project manager defines the technologies used in the project, team load, limitations, time frames, and budget. The most appropriate project decisions are made according to the specified requirements.
Business analysts perform the most crucial part of the work at this stage. They actively communicate with a client, conduct meetings, and ask questions. The goal is to receive a precise application’s concept, document it, and present it to the team to rely on during the further stages.
To be more specific, let’s name the deliverables of this stage. Along with the project manager, the business analyst does the cost estimate and defines the scope of work. Depending on the software development model, the requirements may be very strict or just sufficient to start the work. The project manager, in turn, should form the initial working plan and split all tasks correctly between the team members.
During this stage, specialists form the basis needed for further development. It includes a Software Requirement Specification document, application wireframes, mockups, and a prototype (optional).
Requirement analysis should be approached seriously by the specialists because it is a foundation of all further work.
The system design stage is practically an extended version of the plan developed during the first phase. So, all gathered info about the product is being analyzed and systematized. The information received during the requirement analysis stage was primarily described in words, and at the design stage, the plan is amended with the technical details.
So, the developers are designing the architecture at this phase of the software life cycle. All the different technical questions that may appear at this stage are discussed by all the stakeholders, including the customer.
Specialists who work actively at this phase are software engineers, system architects, database specialists, designers. And of course, BA, PM, and tech leads remain a permanent part of the software development process.
So, to conclude, the deliverables of the system design stage include system and database architecture, wireframes and mockups of the app’s screens, etc. Each time a system component is created, it should be documented at once.
After the requirements are approved, the process goes to the next stage – actual development. It is the most lengthy stage of the SDLC. Up to this point, all necessary information about the product is ready, and all details are thought out and designed. Developers’ task is to assemble them into one working infrastructure by putting them into code. So, they start to write the source code while keeping in mind previously defined requirements. The system administrators adjust the software environment. Frontend programmers develop the user interface of the program and the logic for its interaction with the server.
Programmers actively communicate with the designers because the functionality must be consistent with the design. That’s why designers may change something in the mockups, or devs may make minor changes to the features’ implementation.
The programming itself assumes four stages:
Apart from the developers, PM plays an essential role by controlling that the documentation, system design, and other components fall under the relevant standards. He is also responsible for managing teams and consistent product delivery.
So, before moving on to the next phase, programmers need to code back-end, front-end, databases, APIs, integrations, etc. After everything described is completed, the team moves to the testing stage.
The testing phase includes the debugging process. All the code flaws missed during the development are detected here. QA specialists document them and pass them back to the developers for fixing. The testing process repeats until all the critical issues are removed, and the software workflow is stable.
The activity during this phase may vary depending on the testing types adopted by the QA engineers. They do manual testing with the help of such methods:
If QA specialists opt for automated testing, they use numerous frameworks and solutions that ease the process.
QA engineers can receive some testing results only after the demo version of an app is published, and they can interact with it as users. The data based on it helps to understand whether the product corresponds to business requirements as well as to the technical ones.
When the program is finalized and has no critical issues, it is time to launch it for the end-users. After the initial program version release, the tech support team joins. This department gathers user feedback for further analysis. They also consult and support users during the exploitation.
In Agile development, a DevOps engineer is responsible for app releases and deployments. DevOps specialists use the CI/CD principles (continuous integration and delivery) to facilitate the release processes. Among their responsibilities there are:
DevOps engineers use various tools to achieve faster product deployment — for example, Jenkins, Docker, Git, and others.
Sometimes, the DevOps team includes from 3 to 5 specialists. So that, separate people are in charge of release management, automation, QA overseeing, and security management. But, in some cases, only one high-skilled person takes on all of these responsibilities.
A product manager is responsible for analyzing the data gathered based on the first feedback from real users. So that a team can make conclusions about which practices were successful and which ones they better replace.
This information helps a business analyst or a product manager understand whether all features are necessary or missing. It provides them with a clear picture of what people want. So, the application adjustments are not uncommon after the initial release.
Maintenance includes two types of work if we divide it roughly: supporting initially created functionality and adding new features. Usually, it involves the maintenance agreement, where the responsibilities of a software provider are strictly defined. It targets more the support of the existing features and outlines how many online consultations and departures to the client are included, what time is suitable for contacting the team, and other details. However, this document also covers the frequency of software updates.
When it comes to the technical side of the issue, a project manager analyzes the feedback after the initial release and assigns the developers to fix bugs and add updates. Significant updates are made according to a particular schedule, and some minor changes are implemented by a DevOps engineer frequently.
While programmers fix bugs and add new features, a DevOps specialist plans, and schedules the ongoing release. After the developers’ work is done, DevOps releases a new version to an app distribution platform or the server if we’re talking about the web apps.
So, if support and maintenance are entirely entrusted to the software development provider, this process doesn’t have timeframes. However, customers may take responsibility for the product maintenance themselves, and in this case, they contact a service provider only in some critical cases they can’t manage on their own.
Curious to find out what specialists take part in each stage, how long it takes, and how much it costs?
If we’re speaking about the classification of SDLC models and methodologies, they can be divided into numerous groups according to different criteria. However, let’s see what the main types of SDLC models are.
There are two core software development life cycle models: heavyweight (predictive) and lightweight (agile). Heavyweight processes imply that the scope of work is predefined in advance. That’s why they are also called predictive. They require a significant contribution from the programmers and weighty documentation. Traditionally, companies chose a heavyweight approach for streamlining and organizing extensive projects. However, now this type of SDLC models has lost its popularity. It decreases project efficiency because of the unnecessary bureaucracy implied.
Today, it is replaced by lightweight or agile processes, also called adaptive. They are a good compromise between overly strict discipline and its total absence. Agile methodologies require a much smaller amount of documentation in terms of a software life cycle.
For example, an adaptive approach considers various customer requirements, such as the necessity of constant application modifications. Predictive SDLC models, in turn, are only growing in complexity with the emergence of unplanned changes.
Heavyweight methodologies are pertinent in the context of strictly defined requirements and large teams of specialists. Agile tactics are best implemented in terms of frequent amendments to the initial plan and relatively small groups (up to 10 people working in one team).
Predictive (heavyweight) models include:
There are many more options, but these are the most common ones. Let’s discover the main characteristics of each. We won’t dive deep into the phases of each model because they are pretty similar. So, let’s find out each model’s peculiarities and pros and cons.
Among different SDLC models and methodologies, adaptive (agile) are the brightest candidates nowadays. The agile approach opens up new possibilities for specialists, enables more flexibility, and puts the communication between people ahead of the blind plan following.
Realizations of Agile models include:
Later in the article, we’ll look into each in detail.
The waterfall is a cascade SDLC model that presents the development process like the flow, moving step by step through the phases of analysis, projecting, realization, testing, implementation, and support. This SDLC model includes gradual execution of every stage. Waterfall implies strict documentation. The features expected of each phase of this SDLC model are predefined in advance.
The waterfall life cycle model is considered one of the best-established ways to handle complex projects. This approach allows avoiding many mistakes that may appear because of insufficient control over the project. However, it results in pervasive documentation development. It is beneficial to the developers who may be working with the product in the future, but it takes a long time to write everything down.
In some cases, the feedback loop is included. It allows making short reviews of each stage’s result and applying some minor amendments. This loop enables specialists to return to the previous phase for a short period.
If something significant changes in the initial plan, a team should wait until the very last stage to return to the beginning and pass all software life cycle phases again.
In the table below, you will find the advantages and disadvantages of the Waterfall SDLC model.
| Simple to use and understand | The software is ready only after the last stage is over |
| Management simplicity thanks to its rigidity: every phase has a defined result and process review | High risks and uncertainty |
| Development stages go one by one | Not the best choice for complex and object-oriented projects |
| Perfect for the small or mid-sized projects where requirements are clear and not equivocal | Inappropriate for the long-term projects |
| Easy to determine the key points in the development cycle | The progress of the stage is hard to measure while it is still in the development |
| Easy to classify and prioritize tasks | Integration is done at the very end, which does not give the option of identifying the problem in advance |
| ADVANTAGES | DISADVANTAGES |
|---|
Use cases for the Waterfall SDLC model:
The iterative model resembles a waterfall model, but there is quite a considerable difference between them. For example, let’s suppose there’s an app that contains ten core features. In the waterfall case, all ten functions will be thoroughly planned during the requirement analysis and design phases and then steadily implemented during the development stage. The iterative model is quite different. It implies that the whole process is divided into a particular number of iterations, and during each of them, developers build a limited number of features.
So, the Iterative SDLC model does not require a complete list of requirements before the project starts. The development process may start with the requirements to the functional part, which can be expanded later. The process is repetitive, allowing to make new versions of the product for every cycle. Every iteration (that lasts from two to six weeks) includes the development of a separate component of the system. After that, this component is added to the features developed earlier. Speaking with math terminology, the iterative model is a realization of the sequential approximation method; that means a gradual closeness to the planned final product shape.
For example, during the first iteration, the team has decided to work on three features out of 10. While creating them, developers pass all stages of the software development process, starting from the requirement gathering to the deployment and maintenance. When they move to the next set of functions, the development cycle starts over.
| ADVANTAGES | DISADVANTAGES |
|---|---|
| Some functions can be quickly developed at the beginning of the development lifecycle | Iterative model requires more resources than the waterfall model |
| The paralleled development can be applied | Constant management is required |
| The progress is easy measurable | Issues with architecture or design may occur because not all the requirements are foreseen during the short planning stage |
| The shorter iteration is – the easier testing and debugging stages are | Bad choice for the small projects |
| It is easier to control the risks as high-risk tasks are completed first | The process is difficult to manage |
| Problems and risks defined within one iteration can be prevented in the next sprints | The risks may not be completely determined even at the final stage of the project |
| Flexibility and readiness to the changes in the requirements | Risks analysis requires involvement of the highly-qualified specialists |
Use cases for the Iteration model:
This approach results in constant learning, meaning that during each iteration, the team makes observations and brings new ideas to the next iteration.
Spiral model is a combination of the Iterative and Waterfall SDLC models with a significant accent on the risk analysis. The main issue of the spiral model is defining the right moment to take a step into the next stage. The preliminary set timeframes are recommended as the solution to this issue. The shift to the next stage is done according to the plan, even if the work on the previous step isn’t done yet. The plan is introduced based on the statistical data received in the last projects and even from the personal developer’s experience.
| Lifecycle is divided into small parts, and if the risk concentration is higher, the phase can be finished earlier to address the treats | Can be quite expensive |
| The development process is precisely documented yet scalable to the changes | The risk control demands involvement of the highly-skilled professionals |
| The scalability allows to make changes and add new functionality even at the relatively late stages | Can be ineffective for the small projects |
| The earlier working prototype is done – sooner users can point out the flaws | Big number of the intermediate stages requires excessive documentation |
| ADVANTAGES | DISADVANTAGES |
|---|
Use cases for the Spiral model
The V-shaped algorithm differs from the previous ones by the work approach and the architecture. If we visualize this model, we’ll see that there appears one more axis, unlike the waterfall and iterative models. Along with the first one, they constitute the V letter.
The V-model is called this way because of the scheme’s appearance and because its primary priorities are Verification and Validation. Stages positioned along the left axis display the verification phases, and the ones on the right are responsible for validation.
Let’s clear the terms in a few words, so there’s no misconception. Verification and validation mean different things, though they seem pretty similar. The goal of verification is to determine whether the software is consistent with the initial technical requirements. Validation, in turn, should confirm whether the product corresponds to the business needs, whether it serves its intended purpose, whether it acts as planned. To summarize, verification accounts for aligning features with the technical requirements based on the business requirements. Validation manages the last ones.
These concepts include different types of product testing. These methods are located along the respective axes. One on the left side necessarily has an associated one on the right. For example, the requirement analysis stage corresponds to acceptance testing, system design to system testing, architecture design to integration testing, etc.
To summarize, the V-shaped SDLC model is an expansion of the classic waterfall model, and it’s based on the associated test stage for every development stage. This is a rigorous model, and the next step is started only after the previous one is over. Every phase includes the current process control to ensure that the conversion to the next stage is possible.
| Every stage of V-shaped model has strict results so it’s easy to control | Lack of the flexibility |
| Testing and verification take place in the early stages | Bad choice for the small projects |
| Good for the small projects, where requirements are static and clear | Relatively big risks |
| ADVANTAGES | DISADVANTAGES |
|---|
Use cases for the V-shaped model:
Agile is a philosophy, not a specific development approach. It is a whole family of methodologies. Scrum, Kanban, or XP (extreme programming) are among the most common realizations of the Agile SDLC. Let’s find out the core principles of Agile in general and then take a brief look at some of its realizations.
Its first peculiarity is that all work is split into iterations like the iterative model. These iterations are named sprints. The team initially defines what actions they’ll need to perform in a particular timeframe. The main difference with the iterative approach is that this amount of work is not strict and can be changed in the middle of the process.
The following distinction is that Agile doesn’t ever leave customers in ignorance. Specialists on a provider’s side constantly stay in contact with the client. They give him updates on the performed work and familiarize him with the plan. All changes are also discussed with the customer and approved by him. Each stage in Agile should be analyzed and accepted by all sides before the development team can move on to the next one.
Agile includes daily or weekly calls and Sprint reviews. Sprint reviews have such a structure – the first half of the meeting is dedicated to the performed work, and the second half is about planning the next Sprint.
One more aspect of the Agile software life cycle is face-to-face communication. It is one of 12 Agile principles. Considering that companies often outsource, meeting a customer face-to-face is problematic, but Agile offers video conferencing instead of audio calls to observe the body language. It helps to avoid some misunderstandings and build better relationships with clients.
A lot more can be said on Agile SDLC, but let’s better look at specific numbers. Research on Agile methodology shows incredible results. Here are the main key points:
| Corrections of functional requirements are implemented into the development process to provide the competitiveness | Difficulties with measuring the final cost because of permanent changes |
| Project is divided by short and transparent iterations | The team should be highly professional and client-oriented |
| Risks are minimized thanks to the flexible change process | New requirements may conflict with the existing architecture |
| Fast release of the first product version | With all the corrections and changes there is possibility that the project will exceed expected time |
| ADVANTAGES | DISADVANTAGES |
|---|
Use cases for the Agile model:
So, in general, the agile methodology allows the customer to see the result and understand if he is satisfied with it or not after every development iteration. This is one of the advantages of the agile software development life cycle model. One of its disadvantages is that it is difficult to estimate the resources and development cost with the absence of defined requirements.
On the one hand, the flexibility of the Agile approaches is an advantage. However, at the same time, it may become a downside. Developers may face some pitfalls if they aren’t familiarized enough with the Agile methodology. Read about the 10 most common mistakes in Agile development to know what to pay attention to while implementing this approach.
Let’s see what realizations of Agile SDLC are the most common ones and how they are organized.
People consider Scrum and Extreme programming the two different implementations of Agile. Together, they make an excellent approach to software development, but it’s apples and oranges separately. Scrum is a project management methodology, and XP is a development technique.
Extreme programming contains methods targeting specifically the technical side of the software development process. They include continuous integration, pair programming, test-driven development, etc. Scrum, in turn, is oriented towards the organization of the process.
Sprints lie at the core of Scrum. A sprint is an iteration that lasts from 2 to 4 weeks. It starts with the planning of the product and an iteration itself. Then, the product passes the stages of a chosen software development methodology (XP is the most popular option in terms of Scrum). At the end of the sprint, the team delivers the developed part of the product, and then it’s time for the retrospective – sprint review and analysis.
The core methods of Scrum contain sprint planning, daily meet-ups, demos and reviews, and a retrospective at the end of each sprint. Its main principles are сourage, commitment, focus, openness, respect.
Also, Scrum, as a realization of Agile, is subject to 12 Agle principles.
The visibility and obviousness of the process are what make Scrum stand out. Sprint backlogs (SB) and product backlogs (PB) would be excellent proof of it.
PB is a set of objectives that should be achieved at the end of development. Product backlog includes the names of items, their priority, and a number of a sprint when they need to be completed. In sprint backlog, each item is divided into small steps called tasks. SB defines all tasks that developers undertake to complete during a particular sprint.
Both PB and SB are traditionally organized as a physical board named the Scrum board. It is divided into specific vertical sections. The ones for the product backlog contain:
As you can see, product backlog mainly targets the organizational part of the software life cycle. Let’s see what sections a sprint backlog includes:
In each section, team members place sticky notes with related information. However, lately, such boards have taken the shape of online spreadsheets. It saves precious time and remains very illustrative.
As you can tell, Scrum doesn’t specify developers’ actions. It is responsible for consistent product delivery and process organization. That’s why it should be combined with some methodology that focuses precisely on the programming approach.
The most common combination is Scrum and XP. In extreme programming, minor weekly releases are much better than a completed app delivery in a one-year perspective. Also, testers work along with developers during the whole process, unlike Waterfall, for example. It eliminates a tremendous amount of work during the testing stage and the derived heap of code changes. XP also implies that the code is shared between all team members, so everyone can give suggestions and look at it from the other angle.
Kanban is another realization of Agile. It somehow reminds Scrum, but still, they have some distinct differences. Both approaches use boards to track progress and have similar sections. The ones of Kanban are:
The range of statuses in Kanban is less extensive, but it is sufficient to keep up with the software development process. The key differences lie in the work approach and main principles of the method.
Let’s start with planning. Kanban doesn’t obligate devs to follow the plan, unlike Scrum strictly. It is open to constant changes. With Kanban, team members don’t track the exact time spent on a task. Instead, the board includes the “Recommended timeframe” section. It allows estimating the approximate development time in the end. Also, Scrum has strictly defined roles, such as scrum master, product owner, and a development team. In Kanban, no roles are set, so the flexibility is much higher. Iterations in Kanban don’t have predefined timeframes – they can change depending on the amount of work.
Scrum seems very flexible before you find out about Kanban, enabling even more flexibility. However, it’s questionable how effective such an approach will be because an undisciplined team is as destructive as an overdisciplined. So, it’s essential to consider all pros and cons before deciding on a software development methodology.
When it’s time to choose the software development approach, there’s a strong chance of getting confused over numerous options. However, if you learn a little about each, it all starts shaping up. Each software development methodology has some significant distinctions that you may proceed from. In addition, it’s usually project or delivery managers who are in charge of choosing the right approach. Their knowledge of the peculiarities of each methodology noticeably facilitates the task.
Still, let’s find out what logic is implied in choosing the technique that will make the best fit for your project. Firstly, it’s necessary to think about:
As soon as you have answered these questions, you should integrate them with your knowledge about software development techniques. Let’s briefly go over each question.
If we’re talking about the unclear requirements, the Agile software development process is a win. Iterative and Spiral models do fit as well.
When the timeframes are limited to short, Agile is the correct answer. Due to the possibility of amending changes anytime and working simultaneously on many features, it significantly reduces the timeframes.
Some people may still consider Agile not stable enough to leverage it in large projects. It may seem that predictive models provide more permanence and sustainability that should theoretically result in fast product delivery and high app quality. However, it’s nearly impossible to plan a project that lasts one year or even more. No one can predict all the minor details that may appear in the middle of the process. That’s why heavyweight methodologies often face unexpectedly increased time frames when one subtle change in the scope results in the cascade of changes and ruins all plans. Such a software development approach is suitable for smaller projects with fewer requirements.
Starting software development with the Waterfall or V-shaped model when the budget is relatively low is questionable. Such models require numerous cycle repetitions leading to increased development time and, consequently, the budget.
It’s all quite clear about the documentation. It’s already been discussed that despite all advantages an Agile approach has, extensive documentation is not among its strengths. If a client requires detailed documentation, it’s better to opt for heavyweight techniques like Waterfall, V-shaped, or Iterative methodologies.
Does it still seem like there’s too much information to make the right choice? As visualization makes it easier to perceive the data, some people form a table to put all the questions and methodologies. They mark the respective boxes as “+” or “-.” Then, choosing the best option becomes very straightforward.
| High Complexity | +/- | +/- | + | + | +/- |
| Extensive Documentation | + | +/- | + | – | – |
| Unclear Requirements | – | – | +/- | + | + |
| Tight Timeframes | – | – | +/- | + | + |
| Restricted Budget | – | – | – | + | + |
| Waterfall | V-Shaped | Iterative | Scrum/XP | Kanban |
|---|
The table may and should be amended with some more questions, but you can see the main points to understand the concept in the presented table.
One more crucial thing to say is that you can continually optimize the existing model. You don’t have to follow all instructions blindly. They exist to guide you through the process, but you can optimize the duration of the stages or add some more if you consider it necessary.
Methodologies eliminate the need to invent new management and development techniques. They are a framework for the software development process. Also, they provide every team member with a clearly defined plan so that everyone understands what they’re doing, why, and what’s the final goal.
Different models were created during the SDLC evolution to meet a wide variety of development requirements and expectations. Nowadays, the world is moving towards flexibility instead of excessive regularity and orderliness. Still, agile approaches perfectly combine responsiveness and well-organized project management.
Share your ideas with the specialists of EXISTEK. We’ve been working on different projects, so we’ll find the most appropriate approach for you.