Software Development Life Cycle

Software development life cycle (SDLC), also known as system development life cycle, is an end-to-end software development process including requirement analysis, design specification, feasibility, risk analysis, development, testing, deployment maintenance, and support. In this article, we will learn in detail about the different phases of SDLC; understand various SDLC methodologies (models) and tools; and discuss how DevOps and SDLC complement each other.

Table of contents

• What is SDLC?
• Why is SDLC important?
• Different phases in the SDLC process
• SDLC models
• SDLC and DevOps
• Quick comparison chart of traditional, agile, and DevOps SDLC
• SDLC tools
• Secure SDLC
• AI in SDLC
• FAQs

What is SDLC?

SDLC is a framework that defines the life cycle of a project from its initial stages to completion. “Life cycle” indicates the continuously evolving development, maintenance, and changes driven by user/client feedback. For example, when you first develop a website, you may have thought of a particular design and implementation. However, after the site goes live, based on user feedback or a comparison between your website and a competitor's website, you may think of a few changes to make your website unique and more user-friendly. This would mean another iteration or cycle of SDLC. While all the phases are not always essential, these are common phases for every software development project.

Why is SDLC important?

SDLC defines a framework and the approach to be followed by a team in the development of a project. It also focuses on documentation at each step, thus ensuring that even if the entire team changes, the development process does not halt. Some benefits of SDLC are:

• Better coordination between various teams, like design, development, and testing.
• More visibility into the activities of each phase.
• Early detection of risks, reducing the chances of failure.
• Effective and realistic project planning, feasibility, and risk assessment.
• Understanding of the bigger picture — i.e., overall project purpose and business needs.
• Faster time-to-market and response to feedback.
• Development of high-quality software.

Different phases in the SDLC process

Different projects have their own unique set of phases. However, in general, projects include the following phases:

1. Business requirement definition: Here, the client, stakeholders, or business analyst defines the business problem that needs to be solved through the project. For example, in a data-driven application, how and what data is to be stored is decided during this phase.
2. Feasibility and risk analysis: A team of stakeholders, business representatives, and analysts analyze the feasibility of the proposed solutions and the best approach to solve the given problem. They also list down the high-level risks (if any) involved in the solution.
3. Design plan: A team of architects and designers create a high-level design plan using flowcharts, algorithms, and pseudocode. They also visualize alternate paths and workflows in the solution. For example, based on the data requirements of an application, the schema design should be chalked out in this stage. MongoDB provides a flexible schema design that can easily adapt to requirements and design changes at any stage of SDLC.
4. Software development: A team of developers convert the design into code using the latest tools, technologies, and best practices to create the draft solution. This also includes defining data types, validation rules, and overall application structure.
5. Software testing: Once the software is ready, various testing teams work on it to perform thorough testing of the piece, like unit testing, integration testing, and user acceptance testing. Any bugs reported during each testing phase must be fixed by developers to proceed to the next phase.
6. Deployment: The software or module is deployed and ready to be published once all the above steps are complete. The database is also deployed along with the application deployment. MongoDB Atlas is a popular NoSQL database that lets you access your database and other services over the cloud.
7. Support and maintenance: Once the software is live, continuous support and maintenance are required to keep it up-to-date and error-free.

The core phases of SDLC, which are cyclic and continuous

Like a cycle, the software development process is iterative, and for each cycle, the project team has to go through one or more phases.

Business requirement definition

The first step of the software development life cycle is to clearly define the business requirements or the problem that needs to be addressed through the project.

The requirement could be as simple as adding a text box for users to describe the specific problem they are facing while placing an order, or as complex as building an entire app to place online orders for milk and groceries.

This phase usually consists of creating a business requirements document (BRD) that contains:

• Details and scope of the project (what the project is and why it is required).
• Functional requirements (responsibilities, plan, and measurable milestones).
• Resources required (hardware, software, and human resources).
• Estimated cost and timelines of the project (total cost, budget, and expected deadlines).
• Assumptions and expected standards for the project (best practices, changing market and customer needs, current scope).

Feasibility and risk analysis

Critical projects require detailed risk analysis and a thorough assessment of the feasibility of proposed solutions. One effective approach to gain certainty is through a well-executed proof of concept (POC). This crucial step helps identify the most viable approach while uncovering potential risks involved.

During the POC, the feasibility challenges — such as technical and infrastructural support availability, cost-benefit analysis, and legal compliance — can be carefully examined. Simultaneously, risks — including integration issues with existing software, performance, and stability concerns — and budgetary risks are assessed.

By conducting a comprehensive POC, the project team can make informed decisions, mitigate potential pitfalls, and implement the most practical solution.

Design plan

In the design phase, architects, designers, and project managers create a detailed outline for the entire project in the SRS (software requirement specification) document. This includes functional and non-functional, external and internal interfaces, system requirements, use of existing and new frameworks, programming languages, database, reusable modules, and components.

For example, if the requirement is to create a new screen to sign-in/sign up users for an app, the different workflows for a new user, existing user, existing user but new mobile, defaulter, VIP user, and so on are detailed in this phase. Even small details — like which fields are mandatory, the type of validations to be placed on fields, etc. — are detailed in this phase.

The designer or architect may create flowcharts, pseudocodes, or algorithms to detail the flow and also list the variable names and descriptions for developers to understand. Similarly, if a call has to be made to an external system for scenarios like authentication, to fetch details, or inserting details into a database, the details of the different tools and systems to be used are mentioned in this phase.

Software development

The actual work begins in the software development phase, where the development team closely works with the designers and analysts to code and bring to life the design they created. The SRS already contains details only about the overall framework and workflow. The developers create the necessary classes, objects, and handle exceptions. They follow code best practices, create reusable components, and make the code lightweight. They also need to follow the security protocols and ensure high software performance. Usually, developers also conduct unit testing of the code before handing it over to the testing team.

Software testing

The testing phase includes both functional and non-functional testing. The testing team prepares a framework for testing and writes test cases covering all the project scenarios based on the SRS document, as the software development phase starts. As each module is developed, they run the relevant test cases and mark them as passed or failed. In case a test case does not pass, it is marked as a bug and goes back to the development team for a fix.

Once unit testing is complete, the modules go through the next levels of testing, like integration testing, system testing, performance testing, and security testing. There are many tools that testers use to automate many of the tests, saving time and resources.

Deployment

Once testing is done in different stages, the software is ready to be deployed. It is first deployed to a staging or pilot environment, to perform another round of regression, integration, and user acceptance testing (UAT), before finally being put into the production environment. With DevOps and continuous integration and deployment (CI/CD) in place, many projects have automated deployments.

Support and maintenance

Once the software is available to users, they might require assistance or encounter challenges using certain features. Additionally, unexpected bugs may surface, all of which require fixes during the support phase. Some issues may manifest as change requests, initiating another software development lifecycle.

Apart from providing support, continuous monitoring, upgrading, and maintenance are essential to ensure the software's seamless functionality.

SDLC models

The SDLC framework started with the waterfall model, the earliest model of all. Today, with the advancements in various technologies and the need for better collaboration, more projects are opting for agile methodology, particularly the DevOps model for continuous integration and continuous delivery of project modules. The different software development life cycle methodologies are:

1. Traditional models: waterfall, spiral, prototype, iterative.
2. Agile models: rapid application development (RAD), scrum, kanban, eXtreme programming (XP).
3. DevOps.

For this article, we will cover the following SDLC models:

1. Classic waterfall model
2. Iterative waterfall model
3. V-model
4. Prototype model
5. Spiral model
6. Iterative incremental model
7. Agile model

There are many other models like the Big Bang model, fish model, and Pham-Nordmann-Zhem (PNZ). However, they are not as widely used as the above models. Hence, we will focus on the above-mentioned models in this article.

Classic waterfall model

The waterfall model is the simplest model used in SDLC. It is not used much nowadays, due to the time taken for execution of all the phases. Just like water falling from the mountain, in a waterfall model, each phase is sequentially executed. For example, after development, testing can happen, and only after testing is complete, the deployment is done. This is a systematic but time-consuming approach. The waterfall model relies on rigorous planning and thorough documentation for each phase. It is a good approach for complex projects that need high quality.

The traditional classic waterfall model, where each stage is executed after the previous is complete

Iterative waterfall model

The iterative waterfall model makes some adjustments to the classic waterfall model to improve the efficiency of the software development lifecycle. In this model, feedback is given from the current phase to the previous phase. The feedback allows for faster defect fixing and iteration at each stage starting from requirement specification and planning, and gives room for better collaboration amongst different teams during each phase.

This model is simple and cost-effective; However, there is no room for any change requests. Additionally, as the entire product needs to be tested before delivery, the customer has to wait for a long time. There is also very limited customer interaction during the start and end of the project, which could lead to requirement gaps.

A variation of classic waterfall model, where feedback is given for each stage

V-model

The V-model, also referred to as the verification and validation model, follows the same sequential approach as the waterfall model, with the difference that testing (validation) happens at each stage of development (verification).

In the verification phase, the actual code is written much later, but the first focus is to ensure that the requirements are well-defined and feasible with the available resources. The V-model is costlier than the waterfall model but produces a high-quality product as testing is done at different levels in parallel with the development.

The V-model is suitable for small and medium projects, where requirements are fixed and easy to understand — for example, systems with fixed workflows like a bus management system, or a library management system.

Verification and validation model, where testing happens at each stage of the process

As we can see in the diagram, the stages are executed sequentially, and verification and validation are done at each stage of the model to map the requirements and the actuals. However, there is no scope for feedback or evolution of changes, as the implementation and testing happen in parallel.

Prototype model

Quite contrary to the waterfall and V-model, which are organized and have well-defined requirements, the prototyping model follows an iterative, trial-and-error approach, where initially all the project requirements are not known. As a sample or dummy prototype is built, more features are introduced to create a final requirement, based on feedback.

The actual implementation starts once the prototype is in an acceptable state. This way, we can achieve maximum customer satisfaction, as they are involved from early phases, and also any missing functionalities can be detected easily. However, the entire process can be time-consuming as customers can make many change requests, which may also lead to additional costs. The prototype model can be of different types:

• Rapid throwaway: Here, a prototype is rapidly built based on the preliminary requirements. Based on the customer feedback, the prototype may or may not be a part of the final product, hence the name “throwaway.”
• Evolutionary: This is a continuous approach where, after each iteration, improvements are incorporated in the same prototype.
• Incremental: In this method, the product requirement is broken into multiple parts, and prototypes are created separately for each. Later, all the prototypes are merged into one.
• Extreme: This approach is used for web development, where the prototypes are built in an HTML format, and functionality is added once the prototypes are approved.

A prototype is created before finalizing the complete project

Spiral model

The spiral model provides support for risk handling. Instead of linear phases, it has phases in the form of loops. Each phase represents one quadrant of the loop, and one loop is one cycle of development, forming a spiral shape when represented in the diagrammatic form. The number of phases is not fixed.

The process is iterative and accommodates risks with each iteration. The spiral model is also called the meta model, as it encompasses many other models, like the iterative waterfall model (each loop) and the prototype model (to evaluate risks).

The spiral model is good for large projects due to its iterative approach and flexibility in accommodating changes as the project evolves. However, it can be expensive and time-consuming for small projects. Also, due to the unknown number of iterations at the beginning of the project, a time estimation cannot be set.

Supports risk modeling, iterative approach and flexibility in accommodating requirement changes

Iterative incremental model

In an iterative incremental model, the most important features of the entire application are built and delivered first. The other components or features are then added in an incremental mode until all the features are complete and the final product is ready. This makes the initial delivery faster and promotes faster development. Furthermore, any feedback and requirement changes can be accommodated in future iterations along with the increments.

Divide the project into smaller modules, deliver the top features first.

The benefit of the iterative incremental model is that there will always be one working product, with top features. Also, even though the project team needs to know the well-defined requirements, any requirement changes can be accommodated easily. However, the implementation needs well-defined design, interfaces, and structure, as some features (modules) may be developed long before others.

Agile model

So far, we have discussed many traditional models of software development life cycle. The agile model has taken over all the traditional methods as the agile methodology splits bigger projects into smaller, more organized modules that can be easily implemented and delivered, saving time, cost, and resources. The agile methodology encourages a direct relationship between clients and software development teams for a better understanding of the requirements and faster two-way communication.

Rapid application development (RAD)

RAD, as the name suggests, is a development model where a project is split into various modules, a rapid prototype is built, and it’s submitted to the client for feedback in sprints. The model involves all or most of the steps of the waterfall model. However, the maximum delivery time for each module is 60 to 90 days.

The model benefits from the usage of existing reusable components, tools, techniques, and skilled developers to complete each module on time. RAD is flexible to changes during every phase of development due to its iterative nature.

Rapidly develop the new features by reusing available existing components, tools and techniques

Scrum

Scrum is an agile framework that works well for small, medium, and complex projects, and follows an incremental approach. In the scrum methodology, the project evolves through multiple sprints. A sprint is a planned set of tasks to be completed by the team within two to four weeks of the iterative development cycle. In the sprint planning meeting, the team decides the time they need to complete a particular task (known as a user story) and the number of user stories they can take up in the sprint.

One sprint cycle involves daily team meetings of 10 to 15 minutes in duration to discuss the progress of the tasks assigned to each team member. The meeting is headed by the scrum master and includes the client, if required. After each sprint cycle, a sprint review and sprint retrospective meeting are held to discuss the sprint.

Model where the project is divided into several user stories and completed in multiple sprints

SDLC and DevOps

With the previous SDLC methods, there was always a gap between the development and the operations team. DevOps is a popular approach to integrate and automate the work between the Development team and the Operations team, enabling faster build, test, and release cycles. Using DevOps has considerably improved the efficiency of the software development lifecycle process due to better collaboration and communication between the two.

DevOps combines the agile principles of SDLC with automation to ensure continuous integration, continuous testing, continuous deployment, continuous delivery, and continuous monitoring. Through MongoDB Atlas App Services, you can set up a CI/CD pipeline in a much simpler manner, as it provides a serverless computing environment; built-in authentication and authorization; integrations with platforms like Azure and AWS; automatic scaling; monitoring; and logging.

Quick comparison chart of traditional, agile, and DevOps SDLC

Here is a quick diagrammatic representation of the software development process in the different methodologies that we have discussed. The choice of model for a particular project depends on various factors like the time, cost, resources, skills, tools, and techniques required. However, over the years, agile and DevOps have taken preference over traditional methods as they improve the overall performance and efficiency of the software development process.

Comparison between traditional, agile and devops model for SDLC

SDLC tools

There are many tools to track the entire software development process:

• Jira: Initially designed as a tool for tasks and error tracking, Jira has now become the most popular workflow management tool for managing requirements, test scenarios, agile software development, and much more.
• Confluence: Confluence is a collaboration tool for teams that are spread across the globe, for better communication and sharing of important project assets like meeting notes and project updates, all in one place.
• Git: Git is a version control system, mainly for developers to create and manage their code in one place. You can create independent multiple branches of the same codebase and later merge the branches together into the master once the development is complete. Git also supports collaboration and distributed development.
• Trello: Trello is a project management tool in which teams can collaborate on projects, create and manage workflows, and track progress in an easy-to-view dashboard. You can create boards, lists, and cards, along with deadlines, and assign them to team members for completion. This way, all those who have access to the project can track their work and also view what others are doing.

Secure SDLC

Secure SDLC (SSDLC) incorporates security in each phase of SDLC, making security an integral part of SDLC. For example, during the requirement stage, security requirements are taken into consideration. Threat modeling and risk analysis are done along with the design. And security and penetration testing are included as part of the testing stage. Adding security enhances the quality of the software without much impact on the time and cost.

MongoDB has a dedicated team for security initiatives in the SDLC. Our software development process complies with the industry standards and includes regular code reviews, strict change tracking, continuous integration, version control, thorough code analysis (both static and dynamic), proactive vulnerability management, threat identification, bug hunting, and a blend of automated and manual code analysis. These practices align with NIST and OWASP guidelines, ensuring robust security throughout our development lifecycle.

DevSecOps

DevSecOps refers to development-security-operations and integrates security with development and operations. Integrating security addresses security issues earlier on in the development process, and DevSecOps seamlessly integrates the application and IT security into the DevOps tools and practices. With DevSecOps, security becomes the collaborative effort of the development, security, and operations teams, resulting in shorter, more efficient software development cycles.

AI in SDLC

Generative AI is having a powerful impact on the SDLC process. With AI, a lot of tasks in different stages of the software development lifecycle that were previously done by humans can be automated. AI can generate boilerplate code, test cases, create documentation templates, find bugs, and improve security and performance. AI can also generate prototypes, generate insights, and accelerate the entire software development process. For example, Google and Microsoft have their own AI tools that can generate code, saving a lot of time for the developers.