Systems Development Life Cycle (SDLC) Explained

SDLC is a structured approach that is used in planning, developing, testing, implementing and maintaining a piece of software or information system. There’s only answer here; it’s to address one question, and that is: how to get from need to operational system without wasting time, money or trust? The guides merely go so far as to passively state Phases. This one also gives clarity when it is time to determine which model to choose for your project as well as a recognition of the problems to be addressed in each of these stages in order to avoid impactful expenses.

What is SDLC?

The steps involved in systems development from conception to retirement are known as the systems development life cycle (SDLC). Each phase is given a purpose or objective, activities and an outcome that is used during the following phase.

Systems development life cycle (SDLC) consists of planning stage followed by analysing, designing, building, testing, deployment and maintenance stage. It aims to provide a high quality system satisfying the requirements and delivered on time and budget.

The concept at its heart remains unchanged over the last number of decades. It’s about how teams transition through the stages: as one stretch-or as a loop-or in a continuous circle.

The 7 Phases of the Systems Development Life Cycle

There are varying lists of the phases (five vs. eight). The seven-phase version below is the most common, and the easiest to apply.

1. Planning. Outline the problem, objectives, scope, budget, and the audience. Deliverable is a feasibility and a project plan that includes technical, financial and operational viability.

2. Requirements analysis. Collect system required functions from users, stakeholders, and other processes. Deliverable is a Requirements Document. It’s here that most of the time, the demise of most of the projects is rooted: vague, absent, or uncontrolled changing requirements.

3. Design. Convert requirements to architectural, data and security controls and interfaces. The result is a code specification that developers will use to start coding.

4. Development. Develop and implement code, infrastructure and the integration of components. The product achieved is functional software that realizes the design.

5. Testing. Test system for operational and requirement caches with unit, integration, system, security and user acceptance testing. Deliverable is a tested working version with known and documented defects.

6. Deployment. Put the system in the hands of the users, move the data over and educate them. The outcome is a live system (and rollback plan).

7. Maintenance. Discover and correct bugs, apply security patches, general upscale and performance enhancements, and implement features. This stage typically extends over all the other stages put together and comes to a final conclusion during retirement when the system is swapped out.

Here is a comparison of 5 SDLC Models (Original Comparison).

These phases remain same in all the models. The difference lies with how the team progress through them.

A model of the sorts, how it works and what situations it is ideal for and what its main risk is.

Clear division between phases, known environments.

Model	How it works	Best for	Main risk
Scrum	Iterations are usually short and result in working increments of software	Requirements or product teams are allowed to change	Sops code: scope creep without discipline
Iterative	Build the core and then polish it in successive iterations	Large systems that have an incremental approach to growth	Uncertainty of ending time point
Iterative	Risk analysis done after every iteration of the cycles	High-risk, high-cost projects	Complexity and cost of management
V-Model	Each development phase has its corresponding testing phase	Safety critical systems	Not flexible for changes in requirements

No single model is best. DevOps is frequently referred to as a sixth approach, but it is actually more of an operating practice that integrates development, deployment and maintenance into a continuous cycle.

The SDLC Model-Picker Framework (Original) was used to develop the model.

A common mistake is to pick a certain model because it is already what you’re used to. Use the table below to score your project using these 5 questions:

1. Are the needs long term or changing? If so, opt for Waterfall or V-Model. If no, you should lean towards Agile.
2. What is the expense of failure? If yes (healthcare, aviation, finance, etc.) then think of V-Model or Spiral.
3. Is there a need for functional software early in the user experience? If yes, select Agile/Iterative.
4. Have you got a team that has experience with the selected solution? Whether it fits well or not, an unfamiliar model will have more risk.
5. Are there any specific provisions or obligations? If so, even when you’re using iterative construction within the gates, you might have to use documented phase gates.

If this is the case in your project, begin with

• Increased documentation, strict adherence, fixed scope, heavy documentation, Fixed scope, heavy documentation, Fixed scope, heavy documentation, Waterfall.
• Evolving product, frequent feedback – Agile
• Safety or life critical outcomes – V-Model
• Unpredictable, big, expensive project – Spiral
• Designing for all essentials first, features second.

Combined or hybrid system for many real projects. Agile sprints could be conducted in a regulated company within a framework that is essentially Waterfall. This is only a framework, not a rule.

Original Checklist of Common SDLC Failure Points (and how to spot them)

Few errors show up where they occur. This checklist takes you step-by-step in search of catching community bank early.

Normal	No announcement in the morning.Warning sign	Early fix.
Unless they can be measured, write success criteria first, before planning	Goals.
Requirements	Stakeholders do not agree on requirements / Requirements continually change	Sign-off and a change control process are used
Incorporated into design	As a thought-after addition	Review security during design
Degree of development to maintain	None: No code review, no version control discipline	All the for every change.
Testing	Testing squeezed at the end	Test continuously, not only before release
Rollout	No rollback plan	Practice deploy and rollback
Security copy	Copy every time the file is updated	Copy only once it’s a security copy

Where Security Fits: The Secure SDLC

It’s best to make security an integral part of the process and not test for it at the end. A secure SDLC, also known as SSDLC, includes security operations like threat modeling during SDLC design, secure coding practices during SDLC development, security testing prior to SDLC release, and patch management during SDLC maintenance. It’s much better to fix the design flaw than to fix it in the field.

SDLC Quick Takeaway

• Each of these stages of the SDLC consists of several steps: planning, requirements analysis, design, development, testing, deployment, and maintenance.
• The phases don’t change in Models like Waterfall, Agile, Iterative, Spiral and V-Model; only the manner of execution changes.
• Select a model based on requirement stability, risk, feedback desired, team experience and compliance.
• The longest period is the maintenance portion; therefore, have your plan in place from the beginning.
• Integrate Security and Testing into All Phases.

Guest Post Angles

If you are an editor on any of the following topics, there could be interest for you:

• SDLC vs Agile: What’s the connection and does it mean they are mutually exclusive?
• Selecting SDLC model with small team of developers.
• Secure SDLC – Including security in all phases without slowing delivery.
• There are several reasons for most software projects getting stalled at the requirements stage:

Conclusion

Systems development life cycle is more a common vocabulary, than a strict and step-by-step process for creating systems responsibly. Build an understanding of the 7 phases, make sure your model applies to your project’s risk and uncertainty, and look for failure points before they start to bite! Usually, a team which follows a simple but well chosen process, will outperform badly a team which follows a complex process.