What Is Software Development Life Cycle And What You Plan For?

Software development projects are becoming increasingly complex. As a result, they depend more and more on better planning to ensure success. Understanding the software development life cycle is key to this planning.

Are you planning a software development project? If so, knowing your  project’s software development life cycle and knowing what to plan for is imperative. In this article, I will guide you though all the basics.

Contents

Software development life cycle: a working definition
The importance of SDLC
Software development life cycle phases: an overview
Software development life cycle models: Explained
Undertaking a strategic software project?

Software development life cycle: a working definition

 

Let’s first understand what software development life cycle (SDLC) is. SDLC is the entire gamut of activities that software development teams undertake to develop and maintain a software product or feature.

Development teams have certain high-level objectives, and they follow SDLC to meet them. These objectives are as follows:

  • They want to create a software application system that meets the all the desired business requirements.
  • The intention is to create a software system that works and efficiently and effectively.
  • Such an ideal application system should work in the organizations current IT environment, moreover, it should be easy to make it work in a future IT environment.
  • Maintaining and enhancing such a system should be easy.

Read more about this definition in “Software development life cycle – SDLC | Software testing material”.

The importance of SDLC

A CompTIA report estimates that the global IT industry will reach $5 trillion at the end of 2019. On the other hand, a “Project Management Institute” (PMI) report released in February 2017 found that organizations are losing $97 million to failed projects for every $1 billion they invest! That’s a staggering amount of wastage! Read “Pulse of the profession 2017” for more details.

Software project failures are attributed to several reasons. Inadequate understanding of SDLC is one. This is because of the following reasons:

  • Project teams that don’t appreciate the SDLC phases and so often request for a lower budget than what they really need. Budget overruns follow. This might even result in permanently shelving the project! Read the adverse impact of setting unrealistic expectations in “10 reasons why software development projects fail”.
  • Inadequate understanding of SDLC may prompt the project manager or PM to plan for a long drawn-out project, whereas rapidly evolving technology might soon make the project redundant! The team still needed to use SDLC. However, they should take intermittent market feedback and course-correct.

Software development life cycle phases: an overview

What are the activities that come under the purview of SDLC? It’s time we understand this. This will help us in understanding the different SDLC phases. The activities are as follows:

Phase #1: Requirements gathering and analysis

The 1st SDLC activity or phase involves the following:

  • Business analysts (BAs) interact with customers to gather business requirements. There are various key questions, e.g., product/system characteristics, target audience, the purpose of the system, etc.
  • An analysis follows, where the business analysts determine the feasibility of requirements. They follow-up with customers and obtain clarity if they have questions.
  • BAs prepare a “Software Requirement Specification” (SRS) document at the end of this phase.

Read “Software development life cycle (SDLC) phases, models, process and methodologies” for more insights.

Download Our Project Specification Template

BAs often use modern software requirement tools, e.g.:

These tools help in capturing, analyzing, and management of requirements. They also help in maintaining a robust requirements traceability matrix (RTM). An RTM helps in ensuring test coverage of all requirements. Read more about it in “What is requirements traceability matrix (RTM)? Example template”.

Phase #2: Design

Technical architects and design “Subject Matter Experts” (SMEs) take the requirements and prepare a high-level design of the system. This phase involves the following:

  • High-level design of components and how they interact;
  • Integration with 3rd party services;
  • The software architecture;
  • Choice of the technology stack;
  • Risks and constraints;
  • Detailed design at the component/module level.

We often call the output of this phase “Design Specification Document” (DSD). Note that the project manager uses the work done in phases 1 and 2 for project planning. Read “Software development life cycle – SDLC phases” for more details.

The team might use a variety of tools in this phase, e.g.:

  • Data flow diagrams;
  • Structure charts;
  • “Hierarchical Input Process Output” (HIPO) diagrams.

Read “Software analysis & design tools” for more examples of software design tools.

Software architecture, a key outcome of this phase is crucial for the overall success of the project. It’s a pictorial representation of the system components, their structure, and how they interact with each other. Read “Software architecture and design introduction” for more information.

It also encompasses key architectural decisions. These are the first set of decisions made in the course of the project, therefore, the software architect needs to get these right.

Depending on the business requirements, the software architect might select one of several software architecture patterns. Examples of these patterns are as follows:

  • Layered (n-tier) architecture;
  • Event-driven architecture;
  • Microkernel architectures;
  • Microservices architecture.

I have explained these patterns earlier in “Large enterprise Java projects architecture”.

Phase #3: Development

Programmers take the design documents and code the modules. They might use various tools and aids, e.g.:

  • “Integrated Development Environments” (IDEs) like Ecplise or Android Studio;
  • “Software Development Kits” (SDKs);
  • “Application Programming Interfaces” (APIs).
  • Coding guidelines and checklists.

Note that developers might use SDKs and APIs according to the functional requirements, e.g.:

The source code is the outcome of this phase. Read about this phase in “SDLC (Software development life cycle) tutorial: what is, phases, model”.

Phase #4: Testing

Testers take over after developers have coded the modules to execute the testing phase. Note that developers typically take care of the unit testing. Testers address the other types of testing, for e.g.:

  • System testing often called “Systems Integration Testing” (SIT);
  • Performance testing;
  • Regression testing;

Testing involves the following tasks:

  • Writing test plan and test cases;
  • Preparing the “test bed”, i.e., test environment with test data;
  • Executing test cycles, which could mean test automation scripts;
  • Documenting test results, and analyzing them.

Remember that several testing tools have reporting capabilities, therefore, using such tools can eliminate manual test reporting.

Software development project teams often use test automation tools to improve their productivity. Following are a few examples of such tools:

Keep in mind that these individual types of testing may often comprise of various subsets. For example, performance testing may include the following:

  • Load testing;
  • Stress testing;
  • Endurance testing;
  • Scalability testing;
  • Volume testing.

The project team should also plan for “User Acceptance Testing” (UAT), and users of the proposed system must actively participate in it. Read “Software development life cycle: the phases of SDLC” for more insights.

Phase #5: Deployment

Software deployment is about deploying the application in the production environment, however, deployment in QA and UAT environments are also important. Deployment involves the following:

  • Collect the code for deployment in appropriate packages;
  • Document version/release information, including notes;
  • Validate the readiness of the target environment;
  • Configure the various target environments;
  • Deploy in QA/UAT environment, and wait for the tests to complete;
  • Manually, or by using tools, deploy the code to the production environment.

Read more about it in “Software deployment”.

Modern IT projects, especially Agile projects use DevOps processes, methods, and tools (PM&T) for deployment. This helps them in incorporating both “Continuous Integration” (CI) and “Continuous Delivery” (CD). Following are examples of popular DevOps tools:

  • Gradle;
  • Git;
  • Jenkins;
  • Bamboo;

You can find more examples of DevOps tools in “The 10 best DevOps tools for 2019”.

Phase #6: Maintenance

The last phase of software development life cycle is maintenance. It kicks in after the production deployment stage. There are various approaches to this phase, as follows:

  • Post-deployment support: This is when the project team supports the system after the production roll-out. This mode of support typically lasts for a short duration. The team works on bugs or other issues, stabilizes the system, and disengages.
  • Warranty support: This kind of maintenance may span a few months. The project team stabilizes the system before then handing it over to a designated maintenance team.
  • Long-term maintenance: This is typically a long-term engagement as the name suggests. Most often, a separate team maintains the system over several years, and not the development team. The engagement model can be different, e.g., a “Time & Material” (T&M) engagement. The work typically includes ticket resolution, bug fixes, addressing user queries, and enhancements.

Read more about it in “The SDLC: 7 phases, popular models, benefits & more [2019]”.

Note: Several experts consider “Planning” a separate SDLC phase preceding the requirements gathering and analysis. However, there are differences of opinion here, since other experts consider it a part of the overall project management and not exclusive to software development. For the purpose of this article, we are excluding it from the list of SDLC phases.

Read How We Helped a Marketing Company to Build a Back-Office Custom Ads Dashboard

Software development life cycle models: Explained

So now that you know about SDLC phases, the next step is to plan for them. Your planning for SDLC phases should suit your project type, and this brings us to different SDLC models. SDLC models are shaped to fit various project types or complexities. These are as follows:

Model #1: Waterfall

One of the best-known among SDLC models, “Waterfall” works as follows:

  • SDLC phases follow each other sequentially, i.e., design can only start after gathering and analysis has been completed. Development can start only after design, and so on.
  • Each phase has clearly defined entry and exit criteria.
  • Detailed reviews take place before we can consider that a predecessor phase has completed and the subsequent phase can start.

Read “SDLC – Waterfall model” for more insights.

This model offers the following advantages:

  • It’s easy to understand. It’s also easy to manage since we have well-defined entry and exit criteria for each phase.
  • Development teams have a high familiarity with it, and they know about the documents required.
  • Small projects with clearly defined requirements and stable technology stacks can make good use of this model, due to its’ simplicity.

There are also some drawbacks, as follows:

  • The project owners will see the product only after the deployment phase. If there are frequent disruptive innovations in the industry and technology, the system might become obsolete by then!
  • The intermediate phases don’t produce a working system, therefore, it’s hard to judge if the team is building the desired software. This increases risk.
  • It’s a rigid model, and it can’t accommodate changes to requirements. Long drawn-out complex projects might find the model very restrictive.

I have earlier explained the pros and cons of this model in “Waterfall vs Agile: which methodology is right for your project”.

Model #2: Iterative

“Iterative” model works for projects where the core set of requirements are well-defined, however, auxiliary requirements may change. It involves the following:

  • Design and development can start with the core requirements that we already know.
  • Iterations are typically short, i.e. of 2-6 weeks duration.
  • The team can develop a working product with the bare-bones requirements, and therefore quickly obtain helpful user feedback.
  • BAs can develop the auxiliary requirements in parallel, and provide them to the design and development teams.
  • The team then starts a new iteration with the latest batch of requirements.

Read more about this model in “What is iterative model?”.

The advantages of this model are as follows:

  • The team can quickly develop a functional system with the core requirements. This enables real feedback from users. This helps in risk mitigation.
  • We can set up multiple development teams to work in parallel with different sets of requirements.
  • Testing is easier with shorter iterations.

This model isn’t perfect. It has the following disadvantages:

  • Parallel development streams typically require more developers and testers, therefore, the project cost increases.
  • The non-core requirements typically undergo frequent changes. It increases the project complexity.
  • Some non-core requirements might force architectural changes later in the cycle, thereby increasing the risks and the chance of potential delays to the project. The team needs highly experienced professionals to handle this kind of projects. The project also requires a high degree of management oversight.

Model #3: Spiral

Spiral SDLC model is a combination of “Waterfall” and “Iterative” models. When represented pictorially, it resembles a spiral with multiple loops. The diagram itself has 4 quadrants, as follows:

  1. Objective determination and identify alternative solutions;
  2. Identify and resolve risks;
  3. Develop the next version of the product;
  4. Review and plan for the next phase.

The model works as follows:

  • A loop starts with identifying objectives and finding alternative solutions.
  • The project manager (PM) identifies risks for each solution and prepares mitigation plans.
  • The loop proceeds and the team develops a working version of the software.
  • Customers review the product, provide feedback, and the team plans the next loop.
  • Each loop represents one iteration.
  • The radius of the loop at any point represents the cost at that point.
  • The PM determines the number of loops, based on the customer feedback at the last quadrant of each loop.

Read more about this model in “Software engineering | Spiral model”.

The advantages of this model are as follows:

  • Each loop creates a working product, therefore customer feedback is available for every loop.
  • The model allows for flexibility since customers can change business requirements after reviewing the working product in each loop.
  • The project team handles the project risks during every loop, thus eliminating unforeseen risks.
  • Complex projects with a large set of fluid requirements benefit from this model.

There are some disadvantages to this model, as follows:

  • It’s a complex model, therefore, you need to build a team with considerable expertise. The PM and the technical risk assessors need an especially a high degree of skill.
  • Each loop has four distinct quadrants, and there can be multiple loops. This can make the project costlier.
  • As you would expect with a complex model like this, the team must maintain comprehensive documentation for every phase. This further increases project costs.
  • With so many uncertainties to start with, an upfront project budgeting exercise can be hard.

Read “What is spiral model? When to use? Advantages & disadvantages” for more insights into this model.

Model #4: V-shaped model

An SDLC model with strict step-by-step process control, the “V-shaped” model works as follows:

  • It follows the “Waterfall” model, however, adds process control steps in between phases.
  • Take the example of the “Requirements gathering and analysis” phase. In the “V-shaped” model, the subsequent step is “Acceptance test design”. This is because requirements come directly from customers, and customers perform UAT. This model requires UAT design right after requirements gathering so that nothing falls through the cracks!
  • Similarly, “System test design” follows “System design”, “Integration test design” follows “Architecture design”, etc.
  • In order to introduce these quality checkpoints, the model breaks down the “Design” phase of the “Waterfall” model into “System design”, “Architecture design”, and “Module design”.
  • The testing phase is divided into neat sub-phases, as follows: “Unit testing”, “Integration testing”, “System testing”, and “Acceptance testing”.

The pictorial representation of the model resembles a “V”. Read more about this model in “SDLC – V-model”.

“V-shaped” model has the following advantages:

  • It enforces strict discipline, resulting in high quality.
  • The model is very simple to follow, therefore, small projects with clear requirements will have a high success rate with it.

There are disadvantages to this model too, as follows:

  • Like the “Waterfall” model, here too the final software application is available only after the deployment. Customers can’t provide any interim feedback.
  • This model is too rigid for complex projects.

Read more about it in “Software engineering | SDLC V-model”.

Model #5: Agile

Agile software development life cycle model is increasingly popular with the growth of the internet-based economy. Web and mobile apps are becoming an essential part of our daily lives.

These are “Systems of Engagement” (SoEs). While the project team knows the use case, the detailed requirements are always somewhat fluid. Agile projects can start even with very limited requirements. It works in the following manner:

  • The PM forms small cross-functional teams.
  • Even with limited requirements, the team goes ahead with the project and plans iterations.
  • Each iteration includes design, development, testing, and deployment.
  • The business users get a fully functional system after each iteration, even if with limited features.
  • They can provide real feedback, allowing the project team can more effectively plan the next set of iterations to include the results of this feedback.
  • Agile projects follow software engineering processes, but only to the extent that’s required to deliver the features included for each iteration.
  • Agile teams are empowered teams and can make crucial technical decisions. This doesn’t mean that the PM has no role. The PM has a key role in removing the project roadblocks and actually empowering the teams.

Read more about Agile in “How to build an Agile development team?”.

There are different techniques that support Agile, for e.g., “Extreme Programming”, “Scrum”, etc. Scrum is a particularly popular technique, where the team is called a “Scrum team” and the iterations are called “Sprints”. The team is empowered and conducts status meetings like “Daily stand-up meetings” and review meetings like “Sprint review meetings”. Read our guide “How to build a Scrum development team?” to learn more.

Agile projects use metrics that specifically support this methodology, e.g.:

  • “Sprint Burndown”: This measures how many requirements are completed in a sprint and how many remain.
  • “Agile Velocity”: This measures how many requirements a team has completed on an average over the last few sprints.
  • “Lead time”: This is the elapsed time between a requirement entering the “Product Backlog”, i.e., the list of requirement, and its’ completion.

Read “10 powerful Agile metrics – and 1 missing metric” for more insights into Agile metrics.

Agile SDLC model offers several advantages:

  • Users can see a fully functional product after every iteration, therefore, the project team gets real market feedback.
  • The model allows flexibility since users can change requirements.
  • Short iterations improve testing and minimize risks.

There are a few advantages too, for e.g.:

  • Fluid requirements make upfront project budgeting hard.
  • An empowered team required highly skilled professionals that prioritize the success of the client over everything else.

 

Undertaking a strategic software project?

If you have plans to undertake an important software project, you will need to carefully analyze SDLC models and make the right choice.

This requires considerable skills. Fully preoccupied with your core business activities, you might find it hard to free up such skilled software consultants or architects. Consider taking professional help if you find yourself without the relevant expertise.

Read our guide “How to find the best software development company?” to learn more about engaging professional consultation and development partners.

Download Our Project Specification Template

Aran Davies

Blockchain Expert | Developer | Writer | Photographer
Aran Davies

Latest posts by Aran Davies (see all)