Systems Development Life Cycle Explained: Phases, Models, and How It Differs From a Project Plan

Short answer

• The systems development life cycle (SDLC) is the full sequence of activities for a system, from initiation through development or acquisition, implementation, operation and maintenance, and finally disposal. A common textbook version names seven phases: preliminary analysis, system analysis, system design, programming, testing, implementation, and maintenance. NIST uses a shorter five phase view with the same overall span: initiation, development or acquisition, implementation, operation or maintenance, and disposal. The life cycle is the journey itself. A project plan, a methodology, and a model are different things: the plan schedules and resources the work, a methodology prescribes how the work is done, and a model describes the order and repetition of the phases.

Every organization that builds or buys a computer system faces the same basic problem. A system must solve a real problem, work reliably for the people who use it, stay secure as conditions change, and eventually be replaced without losing important information. The systems development life cycle, usually shortened to SDLC, is the organized path a system follows from the first statement of a need to its final retirement. It is not a single document, a single tool, or a single method. It is the whole span of work, in order, with checks along the way.

This article explains what the life cycle is, what happens in each phase, how the main models differ, and how a life cycle differs from a project plan. It draws on definitions from the National Institute of Standards and Technology (NIST) and on the process view in the ISO/IEC/IEEE 12207 standard, alongside a university level textbook account of the classic phases.

What the Systems Development Life Cycle Is

NIST defines the system development life cycle as the scope of activities associated with a system, encompassing initiation, development and acquisition, implementation, operation and maintenance, and ultimately disposal. That definition matters for two reasons. First, it covers the whole life of the system, not only the build. A system that is live but unsupported, or retired without a plan for its data, is still inside its life cycle. Second, it describes activities, not a fixed recipe. Different organizations divide the same span into different numbers of phases and give those phases different names, yet the work remains recognizable.

The term is also used with different scopes, which causes confusion. “Systems development life cycle” in its broad sense covers a whole system, including hardware, software, people, procedures, and data. “Software development life cycle” uses the same abbreviation, SDLC, but focuses on the software part. “Application development life cycle” narrows the scope further, to an application.

Why Phase Lists Differ

A phase is a way of grouping work and placing a decision point, not a law of nature. NIST SP 800-12, the NIST handbook on computer security, notes that many models exist for the computer system life cycle but most contain five basic phases: initiation, development or acquisition, implementation, operation or maintenance, and disposal.

The textbook version used here names seven phases because it splits the broad development span into smaller, teachable steps: preliminary analysis, system analysis, system design, programming, testing, implementation, and maintenance. Neither list contradicts the other. The seven phase version is a closer look at the middle of the five phase version.

The ISO/IEC/IEEE 12207 standard adds a further distinction. It defines processes, not stages. A stage is a period within the life of an entity that ends with a primary decision gate. A process is a set of interrelated activities that transforms inputs into outputs, and the same process can recur in different stages. The standard deliberately does not prescribe a specific life cycle model, methodology, or technique. Its technical processes include requirements definition, architecture definition, design definition, implementation, integration, verification, transition, validation, operation, maintenance, and disposal.

The Phases, Step by Step

The seven phases below follow the textbook account, mapped to the NIST five phase span. For each phase, note three things: the question it must answer, the result it should produce, and the failure that follows when it is skipped.

1. Preliminary Analysis: Should We Do This at All?

Preliminary analysis begins with a request for a new system or a replacement. The review asks what problem is to be solved, whether a solution is possible, what alternatives exist, what is currently being done about the problem, and whether the project fits the organization. After these questions are addressed, a feasibility study is launched. Technical feasibility asks whether the system can be built and run with available technology and skills. Economic feasibility asks whether the expected benefit justifies the cost, including running costs. Operational feasibility asks whether the organization can actually use the system in practice. The deliverables are typically a project charter and a feasibility study. The decision at the end is whether to start, reshape, or stop.

2. System Analysis: What Must the System Do?

In system analysis, analysts work with stakeholder groups to determine the specific requirements for the new system. No programming is done in this step. Procedures are documented, users are interviewed, and data requirements are developed, so the team gains a clear picture of exactly what the system is supposed to do. The result is a requirements document, often called a system requirements specification or user requirements specification. Good requirements describe behavior, data, performance, security, and constraints in terms a stakeholder can confirm. A requirement such as “the system must be fast” cannot be tested. A requirement that states a measurable response for a defined workload can be tested, and later testing can trace back to it.

3. System Design: How Will It Work?

Design takes the requirements document and develops the specific technical details required for the system. Business requirements are translated into technical requirements. The design covers the user interface, the database, data inputs and outputs, reporting, and how components fit together. The result is a system design document that gives programmers what they need to build the system. Design decisions made here are hard to reverse later. Choices about data structure, access control, interfaces with other systems, and error handling shape cost, security, and maintainability for years. That is why design review matters: stakeholders check that the design still matches the requirements, and technical reviewers check that it can be built, tested, and operated.

4. Programming: Building the System

In the programming phase, also called development or build, programmers write code using the design document as a guide. The result is an initial working program that meets the requirements from the analysis phase and the design from the design phase. Building in small, testable pieces is more reliable than building everything at once and testing at the end. When a system is bought rather than built, this phase changes shape: the team configures, integrates, or adapts a purchased system instead of writing code from scratch. NIST groups both cases under development or acquisition for exactly this reason. Either way, the phase should produce a system that can be tested against the requirements, with documentation that lets another person understand and maintain it.

5. Testing: Does It Do What Was Required?

In testing, the program is put through structured tests. Unit testing evaluates individual parts of the code for errors. System testing checks that the different components work together properly. User acceptance testing lets the people who will use the system test it against their standards and their real tasks. Problems found during testing are fixed, and the software is tested again. Verification asks whether the system was built correctly against its specification. Validation asks whether the right system was built for its intended use. Both questions matter, and they are different. That is why acceptance testing by users, with realistic data and realistic tasks, belongs in the plan rather than being treated as a formality.

6. Implementation: Putting the System Into Use

Once the system is developed and tested, it must be implemented in the organization. This phase includes training users, providing documentation, and converting data from the previous system to the new system. Implementation can take several forms. A direct changeover replaces the old system at once. A phased changeover introduces the new system group by group or site by site. A parallel changeover runs old and new systems side by side for a period, so results can be compared. A pilot introduces the system to a limited group first. A post implementation review closes this phase by recording what worked, what did not, and what still needs fixing. Implementation ends when the system is live and supported, not when it is merely installed.

7. Maintenance: Keeping the System Working and Improving

Maintenance begins once implementation is complete, and it is the longest phase for most successful systems. Reported defects are fixed, requests for new features are evaluated and implemented, and updates and backups are made for each new version. Maintenance takes several forms. Corrective maintenance fixes defects. Adaptive maintenance changes the system to fit a changed environment, such as a new regulation or a new platform. Perfective maintenance improves performance or usability without changing the core purpose. Preventive maintenance addresses potential problems before they cause failure. Each change, however small, should pass through control: what changed, why, what was tested, and what can be rolled back.

Retirement and Disposal: The Phase Textbooks Often Omit

The classic seven phase list ends at maintenance, but the NIST span ends at disposal, and that ending matters. A system is disposed of once the transition to a new system is complete. Disposal includes archiving or migrating data that must be kept, removing access, and handling records, licenses, and hardware according to policy. Retiring a system without a data plan risks losing information the organization is required to keep, or keeping sensitive information in a forgotten system that is no longer patched. A retirement plan should state what is kept, where, for how long, who can access it, and how the old system is confirmed to be closed.

How a Life Cycle Differs From a Project Plan

This is the distinction readers most often miss. A life cycle describes the sequence of work and the decision points for a system over its whole life. A project plan describes how a specific piece of that work will be staffed, scheduled, budgeted, and tracked over a defined period. The life cycle is the map. The project plan is the schedule for one journey across part of that map.

A project plan typically covers one project, such as building version one of a system, with a start date, an end date, named people, tasks, milestones, dependencies, and a budget. The life cycle covers many projects over many years: the original build, later upgrades, maintenance releases, and eventual retirement. A single project plan ends when its project ends. The life cycle continues into operation and maintenance long after the project team has disbanded. A plan without a life cycle view misses the long tail: who supports the system after launch, how changes are controlled, and how retirement is handled.

Life Cycle, Methodology, and Model: Three Different Words

Three terms are often used as if they meant the same thing. They do not. The life cycle is the span itself: the activities from initiation to disposal, whatever order or repetition an organization chooses. A model is a description of how those activities are ordered and repeated. The waterfall model orders phases in sequence. An iterative model repeats a smaller loop of analysis, design, build, and test several times. A model is a shape for the journey. A methodology is a prescribed way of working within that shape: its roles, practices, documents, and rules. The ISO/IEC/IEEE 12207 standard is careful on this point: it defines processes and outcomes, and it does not prescribe a specific life cycle model, methodology, method, or technique. That restraint lets an organization adopt the processes it needs and tailor them, rather than pretending one shape fits every system.

Major Models, Without a Winner

No model is best for every system. Each model trades early certainty against the ability to learn and change. The summaries below describe the shape, the strength, and the risk of each, so a reader can judge fit rather than follow fashion. No tool or vendor is recommended here, because the choice of model is independent of any product.

Waterfall

The waterfall model runs phases in sequence, with each phase completed before the next begins, and a decision before moving on. Its strength is clarity. Requirements, design, and acceptance criteria are agreed early, and progress is easy to report. Its risk is rigidity. If requirements were wrong or the world changed during a long build, the error is discovered late, when fixing it is expensive. The textbook criticism is direct: changes to requirements are not allowed once the process has begun, and no usable software is available until after the programming phase.

Iterative and Incremental

An iterative model repeats a smaller loop several times. Each iteration passes through analysis, design, build, and test for a slice of the system, and each increment adds working function. Early iterations test risky or unclear parts while there is still time to adjust. The strength is learning: users see working function early, and feedback corrects the course while correction is still cheap. The risk is scope drift and weak architecture, when iterations add features without a stable overall design or a clear definition of done. Iterative work still needs requirements, design records, and testing.

Prototyping

Prototyping builds a working mock up early to explore a question: how a screen should behave, whether users understand a flow, or whether a technical approach is viable. A prototype can be thrown away after it answers the question, or it can evolve into the real system, but that choice should be explicit. A throwaway prototype built quickly is a poor foundation for a live system, because it was not designed for security, performance, or maintenance. The strength of prototyping is that it replaces argument with evidence: users react to something real. The risk is mistaking the prototype for the product and skipping the design, testing, and documentation that a live system requires.

Spiral

The spiral model organizes work as repeated cycles, each passing through planning, risk analysis, engineering, and evaluation. Each cycle addresses the largest remaining risks first, and the project can stop or change direction at a cycle boundary. Its strength is explicit risk management: uncertain or high stakes work gets attention early, rather than being discovered at the end. Its risk is overhead. Risk analysis and evaluation take time and expertise, and a small, well understood system may not need that weight.

V-Model

The V-model pairs each development step with a matching test step. Requirements pair with acceptance testing. Design pairs with integration and system testing. Detailed design pairs with unit testing. Building sits at the bottom of the V. The strength is traceability: every requirement has a planned test, and testing is planned early rather than invented at the end. The risk is the same as the waterfall risk when the model is run strictly in sequence, because late feedback can still arrive late.

Agile Related Adaptations

Agile related approaches adapt the life cycle to short cycles, frequent working increments, and regular feedback from users. These adaptations keep the same life cycle concerns, such as requirements, design, testing, operation, and retirement, but they distribute them across many short cycles instead of one long pass. Their strength is responsiveness: changing needs can be absorbed in the next cycle rather than waiting for a new project. Their risk is drift: without a stable overall design, clear acceptance criteria, and disciplined change control, short cycles can produce motion without direction. Calling work agile does not remove the need for requirements, testing, security, operation, and retirement planning.

Choosing and Tailoring a Model

Model choice should follow the character of the work. Stable requirements, strict external checks, and high change costs favor a sequential approach with strong gates. Uncertain requirements, a need for early user feedback, and a system that can be released in useful slices favor iterative work. High risk and high stakes favor explicit risk cycles. Large or regulated systems often combine approaches: a sequential frame for approval and release, with iterative work inside the build, and prototyping for the riskiest unknowns. Tailoring means selecting and adjusting processes to fit the system, not deleting checks because they are inconvenient. The ISO/IEC/IEEE 12207 standard supports tailored conformance, where an organization declares the processes it uses and how they are adapted. The test of tailoring is whether a stranger could reconstruct what was decided, what was tested, and who is responsible.

Security and Quality Across the Life Cycle

Security is not a phase. NIST SP 800-12 states that security is most effective and efficient when planned and managed throughout a system’s life cycle, from initial planning through design, implementation, and operation, to disposal. Early security work includes a sensitivity assessment: what information the system handles, what damage error, unauthorized disclosure, unauthorized modification, or unavailability could cause, which laws and policies apply, and what threats the system faces. The handbook notes a long standing tenet of the computer community, that adding a feature after design costs far more than including it at design, and that adding security late tends to disrupt operations. That tenet is a rule of thumb from practice, not a measured price ratio, and it should be read that way. Implementation should include configuring and enabling those features, not leaving them at defaults, plus testing before authorization to operate.

Roles, Gates, and Change Control

A life cycle needs people and decisions, not only phases. Typical roles include a system owner who is accountable for the system and its outcomes, users and stakeholders who define needs and accept the result, analysts who record requirements, designers and architects who shape the technical solution, builders who implement it, testers who verify and validate it, and operators who run and support it. Decision gates sit between phases or iterations. A gate asks whether the work so far is good enough to continue, reshape, or stop. Useful gate questions are concrete: Are requirements testable and agreed? Does the design cover security, data, and failure cases? What was tested, what failed, and what was retested? Is training, data conversion, and support ready for go live? Is there a rollback plan? Change control runs alongside gates, and configuration management keeps the record straight: which version of code, data, documents, and settings make up the live system.

A Worked Example

Consider a small clinic that replaces paper appointment books with a booking system. Preliminary analysis asks whether the problem is booking, reminders, or record keeping, and whether a purchased or a built system fits better. Analysis records real requirements: appointment types, staff schedules, patient contact preferences, privacy rules for patient information, and what happens when a patient cancels. Design covers the booking flow, the data model, access rules, and reminders. Testing checks booking, cancellation, double booking, reminders, and access control, with clinic staff testing real tasks. Implementation trains staff, converts existing appointments, and runs the new system alongside the old book for a short period. Maintenance fixes problems and adds features such as a waiting list. Retirement, years later, archives appointment history as required, closes staff access, and confirms that patient information is handled under the clinic’s retention rules.

Common Mistakes

The most common mistakes are not technical. They are decisions skipped early and paid for late. Starting to build before requirements are understood produces a polished version of the wrong system. Treating testing as a final hurdle lets defects accumulate until they are expensive. Skipping user acceptance testing means the first real users are the live users. Launching without training, data checks, and support turns a good system into a failed change. Neglecting maintenance turns a successful launch into slow decay, as small fixes accumulate without records. Forgetting retirement leaves sensitive data in a system nobody owns.

Frequently Asked Questions

What does SDLC stand for?

SDLC stands for systems development life cycle, and the same abbreviation is also used for software development life cycle. The broad form covers a whole system, including people, procedures, hardware, software, and data. The software form narrows the focus to software. Check which scope a source means before comparing phase lists.

How many phases are in the SDLC?

There is no single official count. NIST describes five basic phases: initiation, development or acquisition, implementation, operation or maintenance, and disposal. Many textbooks describe seven: preliminary analysis, system analysis, system design, programming, testing, implementation, and maintenance. Both describe the same overall span at different levels of detail.

What is the difference between SDLC and a project plan?

The SDLC is the sequence of work and decision points for a system over its whole life, from need to retirement. A project plan schedules, staffs, budgets, and tracks one project or release within that life.

Is SDLC the same as waterfall?

No. Waterfall is one model for running the life cycle, in which phases run in sequence and each phase is completed before the next begins. The life cycle itself is the broader span of activities.

Is agile a replacement for the SDLC?

No. Agile related approaches change how the life cycle is run, using short cycles, frequent working increments, and regular feedback, but they do not remove the life cycle concerns. Requirements, design, testing, security, operation, maintenance, and retirement still need attention.

What is the difference between verification and validation?

Verification asks whether the system was built correctly against its specification: does it do what the design and requirements said it should do? Validation asks whether the right system was built for its intended use: does it meet stakeholder needs in real work? A system can pass verification and fail validation, when the specification missed a real need.

What happens during system maintenance?

Maintenance keeps a live system working and improving. It includes fixing defects, adapting the system to changed rules or platforms, improving performance or usability, and preventing foreseeable problems.

Why does disposal matter?

Disposal matters because information often outlives the system that held it, and because a forgotten system can still hold sensitive data and unpatched weaknesses. A retirement plan should state what data is kept, where, for how long, who can access it, and how the old system is confirmed closed.

Sources & references

• National Institute of Standards and Technology, Computer Security Resource Center Glossary, "System Development Life Cycle (SDLC)." Definition: the scope of activities associated with a system, encompassing initiation, development and acquisition, implementation, operation and maintenance, and ultimately disposal. https://csrc.nist.gov/glossary/term/system_development_life_cycle
• National Institute of Standards and Technology, SP 800-12, An Introduction to Computer Security: The NIST Handbook, Chapter 8, Security and Planning in the Computer System Life Cycle. Five basic phases, sensitivity assessment, and security throughout the life cycle. https://csrc.nist.rip/publications/nistpubs/800-12/800-12-html/chapter8.html
• Information Systems for Business and Beyond, Chapter 7.3, Systems Development Life Cycle, eCampusOntario Pressbooks. Seven phase account, phase tasks and deliverables, and the waterfall criticism. https://ecampusontario.pressbooks.pub/informationsystemscdn/chapter/7-3-systems-development-life-cycle/
• ISO/IEC/IEEE 12207, Systems and software engineering: Software life cycle processes, as summarized in the CodeDocs reference. Processes not stages, no prescribed life cycle model, and the technical process list including requirements definition, architecture, design, implementation, integration, verification, transition, validation, operation, maintenance, and disposal. https://codedocs.org/what-is/iso-iec-12207
• ISO/IEC/IEEE 12207:2017 summary, arc42 quality reference. Maintenance process categories including corrective, adaptive, perfective, and preventive maintenance activities. https://quality.arc42.org/standards/iso12207