SDLC Models: How to Effectively Manage Your Project Throughout Its Life Cycle

As a custom software development company, MindK applies different SDLC models depending on the type of project and desired outcomes. Based on this experience, we’ll explain the main principles of SDLC, review different models in SDLC as well as advantages and disadvantages of SDLC models.

What is the software development life cycle and why does it matter?

When talking about SDLC, we mean a structured and predefined plan of action, so-called algorithms, needed to deliver high-quality products. Following the software development life cycle leads to systematic and more effective workflows.

To better understand the term, let’s dive deeper into its processes. There is an international standard ISO/IEC/IEEE 12207 that defines all the processes needed to develop and maintain software systems. It divides the software life cycle into four main process groups, namely:

• Agreement processes include activities related to establishing an agreement between a tech vendor and the client.
• Organizational project-enabling processes help enable, control and support the system life cycle. For example, they ensure the necessary resources and quality controls are available.
• Technical management processes deal with planning, assessment, and control of software and involve project planning, decision management, risk management, quality assurance, and so on.
• Technical processes involve technical activities and specialists along the whole development process.

In addition, the ISO standard determines that a software life cycle can be divided into stages (or phases). Different phases of SDLC model represent periods within the life cycle that determines the state of software product realization.

However, processes are not the same as stages. The standard doesn’t align the process to any specific stage in a software life cycle. According to the standard, some processes which involve planning, performance, and evaluation should be considered at every stage.

Although the international standard ISO/IEC/IEEE 12207 doesn’t list a number of stages involved in the software development lifecycle, based on our experience, we break down the software development into:

• Requirements gathering to define problems that should be solved.
• Planning, when we work on the action plan to solve each problem.
• Architectural design to decide how to achieve the goals.
• Software development to control the process of product development.
• Testing to govern quality assurance of the product.
• Deployment when the final product is released.

In view of the above, we can conclude that SDLC is a process of planning, developing, testing, and deploying software products that allow to:

• visualize a complex development process;
• manage a project;
• predict and plan the delivery of working pieces of the software throughout the development process;
• manage the budget cost overrun and missing deadlines; and
• quickly determine at what stage the development is at the moment.

One of the fundamental notions of the software development life cycle is the model. What is the SDLC model? Software SDLC models (also called process models) are an illustrative representation of the software life cycle. The model represents a certain structure required to make a software product transit through its life cycle stages.

What are the models of SDLC and what is the difference between them?

There are various SDLC life cycle models used to run the development project. They all consist of the same basic steps we’ve mentioned above,which are equally important. The main difference between the models is that they all plan the necessary development activities and steps in different ways.

That is why the development teams choose the model in view of their project needs and requirements. However, each of the SDLC life cycle models can be customized to work best for specific teams or projects. Let’s review the most popular SDLC models and highlight their strong and weak points.

Waterfall model: the sequential one

SDLC Waterfall model is a linear and sequential software development model in which project phases follow one another. The process goes forward like water in a cascading waterfall, hence the name Waterfall. The model presupposes that the team moves one step at a time making sure their work is complete before going to the next phase:

It means that first, the team should gather all the requirements for the whole project. After the requirements are fully defined, the team is ready to go to the design stage, where all the documents describing how to implement these requirements are created. The Waterfall model requires very strong documentation – goals, specifications, and tasks have to be as precise as possible.

After that, the developers are ready to do their job – transform requirements into the working product. When the coding stage is over, the product is tested to reveal possible errors and inconsistencies. This gives a team the possibility to finetune the software, eliminate all shortcomings and prepare the product for deployment. The working software product is then demonstrated to the customer.

Why choose Waterfall: strong points of the model

Due to all phases in Waterfall being strictly predefined, the process is quite predictable and allows for accurate budgeting and scheduling. This is one of the most important strengths. Among other advantages of Waterfall model in SDLC are:

• high transparency of all the project phases, because all phases are well documented;
• pre-defined plan of actions;
• stable requirements;
• stable project stages allow planning the duration of the project and the corresponding resources (finances and human efforts); and
• ability to strictly control the project every step of the way.

What to consider when choosing Waterfall: weak points of the model

Strictly defined phases are almost the biggest advantage of this model, but also the key drawback. Here are a number of related disadvantages:

• a lengthy discovery phase is needed to extract complete requirements;
• adjusting the scope during the life cycle may cause problems since each stage fully relies on the previous one;
• various teams (design, development, quality control, and others) are isolated and the interaction between them is limited;
• testing starts only in the middle of the project development;
• lack of intermediate results – without customer feedback, the product risks not to meet expectations; and
• long time-to-market.

Limitations regarding the steel-concrete scope and possible changes make the Waterfall model less popular among the development teams today. When the business environment forces companies to be more adaptable to changes throughout the development project, no one can be sure that the requirements defined at the very beginning of the project will be relevant a few months later.

When is the Waterfall model a good fit?

Taking into account all the strong and weak points of the Waterfall model, it is easy to conclude whether this classic model fits your project. Here at MindK, we believe that Waterfall works best for projects where:

• the project is short and risk-free (for example, Proof of Concept or Minimum Viable Product (MVP));
• requirements are clear, unambiguous, and won’t change on the go; and
• all necessary resources are available.

At MindK, less than 15% of our projects use the Waterfall model for software development. Such projects include those that were built with Waterfall and then transferred to thec iterative model. There are clients who require a predictable and transparent development model at the early stages of a partnership like building MVP. The Waterfall model is transparent and predictable enough, so it’s ideal for establishing trust with a new partner or modeling productive internal workflows.

For example, we used Waterfall for building CHOO, a member management system for Norwegian associations. Then for system redesign and product improvements we followed the iterative approach. It allowed us to develop an event management module in a short timeframe. The client needed this functionality as soon as possible because of the pandemic. The event module allows to easily arrange online and offline courses, conferences, meetings, and other activities.

Another part of the projects that use Waterfall are projects applying a hybrid approach to software development. It is when the project uses different SDLC models together to create a unique approach to developing products.

For example, one of our projects we developed was an enterprise recruiting system for a company in Europe, using a hybrid model that combined Waterfall and Iterative approaches. As a complex enterprise platform, it required detailed documentation to make sure all the workflows were covered right, high transparency of all the project phases, and a predefined plan of actions. That is what Waterfall provides.

However, the planned project duration was around a year and a half. It meant that according to Waterfall, the client wouldn’t be able to see and test the product until after a year of development. It is quite risky both for us as a vendor and for the client. So, to mitigate this risk, we split the development into four parts called releases or iterations. Each release lasted for 3 months. After each iteration, we demonstrated the intermediate result to the client, collected feedback, and improved.

Now, here comes the question: What exactly is the iterative model? Why do more and more projects opt for it?

Iterative model: the adaptive one

Instead of one lengthy Waterfall project life cycle, the iterative SDLC model presupposes breaking down the entire life cycle into smaller parts, called iterations. Each iteration involves the same basic software development stages. The result of each iteration is a piece of working software. In fact, iteration is a project in a nutshell.

The iterative model processes are very close to the so-called Plan-Do-Check-Act (PDCA) management method or learning cycle. It is used in business to control and continuously improve processes and products. In terms of the iterative model, it looks like this:

1. Planning – after all the requirements are analyzed, the team makes a plan, creates a backlog of features that should be implemented as a result of the iteration.
2. Doing – involves actual design, development, and testing of the features from the iteration backlog.
3. Checking – the piece of the working software is demonstrated to the client and receives feedback.
4. Acting – the team meets to evaluate the entire iteration and analyze what can or should change, and so on.

This four-step process is repeated indefinitely as part of a never-ending cycle of progress and learning until the product is finished. The goal of this method is to continually improve the product and reach the desired goal by systematically testing the intermediate versions of the product, evaluating the outcomes, and making improvements to the further process.

The main characteristic of this model is that it allows a company or a startup to navigate the fast-changing business environment. This means you don’t need to define a complete list of requirements and create a detailed specification in advance, like in the Waterfall model.

For example, let’s say you want to develop a task planner for your business. You make a list of the required functionality, sketch out the interface of the product, and challenge the development team to develop a trial version of the task planner to see how it will look. In the software development world, it is called Proof of Concept (or PoC).

When the trial version is ready, you test it in the narrow circle of colleagues, partners, or those whose opinions you can trust. Let’s say the first version has met your expectations, it is really convenient to plan things for the week and users began to work more efficiently.

You understand that the product is worth improving and offering to a wider audience. To make that happen, you collect a list of improvements and new features that will make the product valuable to a wider audience. This is what is called Minimum Viable Product (MVP). We’ve already explained how to take the maximum value out of MVP in our previous article on how to do the MVP right.

Such an approach enables consistent funding of expensive projects, the ability to find additional unplanned resources and implement the product step-by-step. Due to this, the company can offer users not a full-featured product having a number of hidden, non-obvious drawbacks, but test versions of the product that can be gradually improved based on the user’s feedback and business environment.

This is exactly how we developed a melody search engine from Grammy-awarded producers. With an idea to create an intuitive melody search tool, the MindK team initially built a Proof of Concept – an app that performed great on various devices.

The PoC was developed in just 5 weeks. After the app was highly praised by the public, we developed a feature-rich web app together with mobile applications for iOS and Android. Now we keep on improving the applications and creating even more pleasure from melody search. It is what we previously called the never-ending cycle of progress and learning, remember?

As far as the concept of iterative development is too large to be covered in a few paragraphs, we’ve devoted a separate article where we explain how to get started with iterative development.

Why choose Iterative approach: strong points of the model

Here at MindK, we believe that the biggest strength of the iterative model is its ability to handle uncertainty and incorporate change into the project’s DNA. Apart from that, its strong points involve:

• quick decision making through constant communication;
• fast and regular delivery of a piece of working software meaning that results are obtained early and periodically;
• early release of a working product;
• an easier and cheaper way to make changes in project requirements;
• feedback from the client and users at an early stage and throughout the whole development life cycle;
• a better way to test and fix small pieces of software;
• the end-users being less overwhelmed since the product gets more complex gradually; and
• the ability to develop a more complete and valuable product.

What to consider when choosing an Iterative model

In spite of the number of advantages the iterative model is able to provide, there are a few things you should consider:

• The project requires strong management attention and constant communication.
• To get maximum value, high involvement of the customer through all stages of development is necessary, adjusting requirements and helping to prioritize features on the product backlog.
• When defining the scope for each iteration, it is necessary to take into account the whole product and potential changes.
• Despite the flexibility of the model, the main goal of the system should be planned from the very beginning.

When is the Iterative model a good fit?

The MindK team uses an iterative model to build the majority of projects, starting from innovative startups to large enterprise products. However, it is not a silver bullet. We can say for sure that this SDLC model has proven its effectiveness when:

• the project requirements aren’t well-thought and changes need to be implemented;
• there is an urgent need for a faster time-to-market;
• your startup needs to raise money in investment rounds: iterative approach allows building a basic version of the app to attract investors;
• the project is massive and large-scale;
• the project deals with new tech or unfamiliar domain; and
• the market is evolving at a great pace.

To see projects that we’ve delivered using the iterative software development model, just take a look at our case studies. For most of them, we used an Agile methodology which is completely based on the iterative model.

Let’s take for example the Bridge project, a US-based company with an idea to build a SaaS solution able to cover a full cycle of services for opening remote R&D offices. First, the MindK team developed an MVP and then worked on further improvements to the product. The iterative Agile development approach was one of the key factors for success because the product was developed during the pandemic in terms of high business uncertainty.

If you want to learn more about the Agile approach, we highly recommend you download our Decision Maker’s Guide to Agile Product Development. We’ve packed years of our project experience with Agile to explain everything you need to know about the flexible approach of building products.

Spiral model: the risk-driven one

The Spiral model is a special combination of the previous two models – Waterfall and Iterative approaches. The main task is to reduce the risks that affect the organization of the life cycle.

Each iteration around the spiral follows the same stages, resulting in a product that becomes increasingly stable and polished. The team starts at the center of the spiral, with a minimum set of requirements. They then go through 4 four phases of development:

• Determining objectives: the team discusses the requirements with the client, estimates costs, identifiers alternative solutions, and plans the iteration.
• Risk analysis and mitigation.
• Development and testing of a software prototype.
• Evaluation by the client.

Once the prototype passes the evaluation, the team adds fresh requirements and starts a new loop. This allows developers to break large systems into smaller components, building one feature at a time.

Unlike Waterfall, where the phase can be started only after the previous phase is completed, and unlike the Iterative model where the phases run in parallel, in the Spiral model the next phase can be started even if the preceding stage isn’t finished. But how does one determine when the appropriate time is to move to the next stage? It’s a fair question. This is considered the key issue of the model.

The four phases we’ve mentioned only outline the basic goals of a cycle and are not required to be reflected in each rotation. The spiral model doesn’t strictly determine their order either. As a result, the model can be combined at any time with other SDLC models.

Why choose Spiral process: strong points of the model

Among the main advantages of spiral software development life cycle are:

• Adjustability thanks to combining the advantages of the Waterfall and Iterative models, which do not exclude, but organically complement each other.
• Risk analysis at each iteration increases the project’s chances of success.
• Requirements can be changed between the cycles.

What to consider when choosing a Spiral model

As we’ve already mentioned, the main problem of the Spiral model is to determine when to move on to the next stage. To solve it, it is necessary to introduce time limits for each stage of the life cycle otherwise the development process turns into an endless improvement of what has already been done. Aside from this, the Spiral model:

• requires strong experience in risk management;
• has a lot of small stages need exhaustive documentation support;
• is a complex structure which often leads to desynchronization of the work of all team members; and
• has no limit on the number of iterations, so it is difficult to predict how many circles it will take to create the final product.

When is the Spiral model a good fit?

The Spiral model has proven itself well when developing large systems and innovative solutions. It is well-suited for long-term projects, during the development of which there is a need to submit intermediate versions or make changes and new requirements.

While we haven’t used the spiral model in practice at MindK yet, many companies, including NASA, Microsoft, Patni Computers, Tata Consultancy, and others have successfully implemented the methodology in their projects.

V-shaped model: the classic advanced one

The V-shaped model (also known as the Verification and Validation model) is a more advanced version of the classic Waterfall SDLC model. The main difference from Waterfall is that testing is carried out at each stage of the development. It provides deeper control of product quality before moving on to the next stage and allows identifying inconsistencies at the earliest stages of project development.

In terms of the V-shaped model, testing goes strictly in parallel to the sequential stages of development. Respectively, each stage of development is directly related to testing this stage to ensure the validation and verification process. As a result, it includes the following testing phases:

• Unit testing is developed during the software component or module design phase. It’s focused on testing at the code level and helps eliminate issues at the early stages of development.
• Integration testing is run on the architecture design phase and ensures the solution functions across all components and third-party integrations.
• System testing examines the entire application, including its functional and non-functional requirements.
• Acceptance testing is putting all of the tests that were created during the requirements gathering phase into action to ensure that the system is functional in a live environment with actual data and ready for deployment.

Why choose V-shaped model: strong points of the approach

Among the key advantages of the V-shaped is that it mitigates the snowball effect that is characterized by the pure Waterfall model. For example, when errors during the requirement analysis lead to inconsistencies in all further development stages because these stages depend on the requirements. The strengths of the model also involve:

• a structured approach with clearly defined roles and functions;
• better performance compared to waterfall model due to early testing;
• time savings up to 50% compared to the waterfall model; and
• better management for project risks.

What to consider when choosing a V-shaped model

Most of the disadvantages of the V-shaped model are very similar to Waterfall and are connected with:

• The lack of flexibility, as a result making changes in the later stages difficult and expensive.
• Development begins strictly from the beginning of the corresponding stage, meaning, no prototypes are developed in the early stages.
• Risk control is challenging – there is no certain way to solve critical problems found during the testing phase.

When is the V-shaped model a good fit?

The V-Shaped model, like Waterfall, is better suited for simple and short-term projects. It requires clear documented requirements. Changes in scope or functionality in the middle of a project can disrupt the entire development process. The model is not suitable for large and complex projects, as well as projects with rapidly changing requirements.

Big Bang model: a chaotic one

The Big Bang model doesn’t presuppose following any specific process. It involves concentrating all possible resources on developing and coding the software product, with almost no planning. At the beginning of the project, even the customer requirements are not clearly defined, thus, are collated, understood and implemented along the way.

Why choose Big Bang Model model: strong points of the approach

The main advantage of the Big Bang model is that it is very simple and requires very little or no planning at all. It is easy to operate and does not require formal procedures.

What to consider when choosing a Big Bang model

The Big Bang model is very high-risk. Changes in requirements, as well as misunderstood requirements, can lead to a complete change or revision of the product development. Moreover, applying this model can turn out to be very expensive if the requirements are unclear.

When is the Big Bang model a good fit?

This is one of the SDLC models that is commonly used for small projects involving only one or two software engineers. It is highly adaptive and allows developers to begin working on a project right away. Big Bang is not recommended for large or complex projects.

Insights about the development life cycle models from the MindK team

Our clients often ask “Which SDLC model is the best?”. Here at MindK, we’ve concluded that none of the SDLC models is a magic bullet. This means that it’s not enough to choose a model that you think may fit your project needs and follow it blindly.

In the best-case scenario, this will not improve your development process. At worst, you put the project at risk not to mention add additional, unnecessary costs. That is why choosing and implementing a software development model according to your project needs is key to making it work for you.

We believe that it’s not necessary to limit the development project to only one model. Quite often we combine several SDLC models as well as different software development methodologies depending on the current needs and the type of project.

If you plan to start the development and look for a vendor who will help choose the best combination of the SDLC approaches to increase your chances to build a better product, the MindK team is ready to help. Just share the details of your project and our manager will get back to you shortly.