Software Development Life-Cycle Models

Introduction

A software development life cycle (SDLC) model is a structured way of organizing the activities through which software is conceived, specified, designed, built, tested, deployed, operated, and retired. An SDLC model is not merely a diagram or a project schedule. It expresses assumptions about how requirements are discovered, how change is controlled, when verification occurs, how stakeholders participate, and how risk is managed.

No single model is universally superior. A safety-critical system, a startup product, an internal administrative application, and a regulated financial platform may require different development processes. Selecting a model is therefore an engineering and governance decision. The appropriate choice depends on uncertainty, technical and business risk, compliance obligations, organizational capability, customer access, delivery urgency, and the cost of late change.

Learning Objectives

By the end of this chapter, you should be able to:

• explain the purpose and structure of an SDLC model;
• compare waterfall, V-model, iterative, incremental, spiral, prototyping, Rational Unified Process, agile, and hybrid approaches;
• distinguish verification from validation and relate them to life-cycle activities;
• select a process according to uncertainty, risk, compliance, and organizational context;
• identify limitations, governance requirements, and common implementation failures; and
• justify a life-cycle recommendation in a professional case.

1. Foundations of Life-Cycle Thinking

A life cycle normally includes the following concerns:

1. Problem definition and feasibility: Why is the system needed, and is it viable technically, economically, legally, and operationally?
2. Requirements: What capabilities, qualities, constraints, interfaces, and acceptance conditions are required?
3. Architecture and design: What structure will satisfy the requirements and accommodate change?
4. Construction: How will components be implemented, integrated, and configured?
5. Verification: Has the product been built according to specified requirements and design? Reviews, static analysis, and testing contribute to verification.
6. Validation: Does the product solve the users’ and organization’s actual problem? Acceptance evaluation and operational trials contribute to validation.
7. Release, operation, and maintenance: How will the system be deployed, monitored, supported, secured, enhanced, and eventually retired?

These activities are logically related but need not occur once, in a fixed sequence, or in isolation. Modern practice commonly combines continuous integration, automated testing, security analysis, user research, deployment automation, and service monitoring with a broader life-cycle model.

Important dimensions for comparing models

• Change tolerance: How easily can requirements change after planning?
• Feedback timing: How soon do users see and evaluate working software?
• Risk exposure: How early are major technical, operational, and security risks addressed?
• Traceability: Can requirements be linked to design elements, tests, approvals, and releases?
• Governance: How clearly are baselines, responsibilities, decisions, and evidence controlled?
• Delivery structure: Is value delivered at the end, in increments, or continuously?

2. Sequential and Verification-Oriented Models

2.1 Waterfall

The waterfall model organizes work into largely sequential phases such as requirements, design, implementation, integration and testing, deployment, and maintenance. A phase is normally baselined before the next phase proceeds. Feedback is possible, but returning to an earlier phase is treated as a controlled change rather than as the normal rhythm of work.

Strengths

• clear milestones, deliverables, and approval points;
• useful documentation and contractual visibility;
• straightforward planning when requirements and technology are stable; and
• appropriate where audits require formal baselines and sign-offs.

Limitations

• users may not see working software until late;
• incorrect assumptions can remain hidden for a long time;
• late changes may be expensive; and
• integration and usability problems can be discovered too late.

Waterfall is not automatically poor engineering. It becomes unsuitable when it is used to conceal high uncertainty or when its documents are treated as substitutes for stakeholder learning.

2.2 The V-model

The V-model makes the relationship between development and testing explicit. The descending side defines and decomposes the product; the ascending side integrates and evaluates it. A conventional mapping is:

The exact terminology varies by organization, but the principle is stable: test planning begins early, and each specification level has a corresponding evaluation level. Acceptance testing asks whether the delivered system satisfies business or user needs. System testing evaluates the complete system against system-level requirements. These are related but not interchangeable.

Figure: Conventional V-model relationship between development specifications and corresponding test levels.

The V-model is valuable in regulated, safety-related, and contractually controlled environments. Its weakness is that a rigorous test plan does not compensate for incorrect requirements. Frequent reviews, prototypes, simulations, and operational feedback remain necessary.

3. Feedback-Driven and Delivery-Oriented Models

3.1 Iterative development

In an iterative model, the team revisits the solution repeatedly. Each cycle may refine requirements, architecture, design, implementation, and evaluation. The objective is learning and progressive improvement, not necessarily delivery of a complete feature set in every cycle.

Figure: Iterative development is a closed cycle in which evaluation informs the next planning and refinement cycle.

Iteration is useful when the team can learn from experiments, prototypes, user feedback, or technical spikes. It may produce a better architecture over time, but uncontrolled iteration can cause scope drift, design erosion, and indefinite development.

3.2 Incremental development

Incremental development delivers the product through separate, usable additions. An increment may provide a coherent business capability, such as registration, payment, or reporting. Each increment should meet agreed quality criteria and integrate with the existing product.

Iteration concerns repeated learning and refinement; increment concerns the staged delivery of capability. They often occur together, but they are not synonyms. A team can iterate internally without releasing each iteration, or release increments built through several internal iterations.

Benefits include earlier value, reduced batch size, easier prioritization, and practical feedback. Risks include architectural inconsistency, dependency problems, and a tendency to deliver visible features while neglecting security, performance, accessibility, documentation, or technical debt.

3.3 Prototyping

A prototype is a model built to explore requirements, usability, feasibility, architecture, or stakeholder expectations. It may be:

• Throwaway: built for learning and then discarded;
• Evolutionary: progressively transformed into the production system; or
• Operational: sufficiently realistic to test workflows, performance, or integration.

A prototype can expose ambiguous terminology and usability defects earlier than formal documents. However, stakeholders may mistake a visual mock-up for a nearly complete product. A prototype built with weak security, poor structure, or unsuitable technology should not automatically become production software.

3.4 Spiral model

The spiral model organizes development around repeated risk-driven cycles. A typical cycle identifies objectives and alternatives, analyzes risks, develops and verifies a solution, and plans the next cycle. Prototyping, simulation, benchmarking, and formal analysis can be selected as risk-reduction activities.

The spiral model is especially useful for large, expensive, technically uncertain systems. It makes risk analysis a central organizing principle rather than an occasional review. Its disadvantages are the need for skilled risk management, relatively high process overhead, and difficulty applying it superficially to small projects.

4. Rational Unified Process

The Rational Unified Process (RUP) is an iterative framework organized around four phases:

1. Inception: establish scope, business case, stakeholders, and feasibility.
2. Elaboration: stabilize the architecture, refine important requirements, and retire major risks.
3. Construction: build and integrate the product through iterations.
4. Transition: deploy, train users, correct defects, and move into operational use.

RUP also describes disciplines such as requirements, analysis and design, implementation, testing, configuration and change management, project management, and environment management. Its defining idea is not a rigid sequence but iterative development with architecture and risk receiving early attention.

RUP can support traceability and disciplined governance, but organizations sometimes implement it as excessive documentation and ceremony. The framework should be tailored: artifacts and approvals must serve decisions, communication, quality, or compliance rather than exist as paperwork alone.

5. Agile Approaches

Agile is a family of approaches and principles emphasizing customer collaboration, working software, adaptation, technical excellence, and frequent feedback. Scrum commonly uses product goals, a product backlog, time-boxed sprints, reviews, and retrospectives. These practices are characteristic of Scrum, not universal requirements of every agile approach.

Kanban, for example, visualizes workflow, limits work in progress, and manages flow continuously. It does not require fixed-length iterations, sprint planning, or a product backlog in the Scrum sense. Extreme Programming emphasizes practices such as test-first development, pair programming, continuous integration, and small releases. Lean software development emphasizes flow, waste reduction, and learning.

Agile approaches are effective when requirements evolve, users can provide regular feedback, and teams can deliver small slices of value. They require technical discipline: automated regression tests, continuous integration, refactoring, secure coding, observability, and explicit quality criteria. “Agile” does not mean undocumented, unplanned, or exempt from architecture and compliance.

Common failure modes include treating velocity as a productivity score, changing priorities without protecting team focus, excluding testers or operations from the team, and calling unfinished work “done.” A useful definition of done may include code review, automated tests, security checks, documentation, accessibility checks, and deployability.

6. Hybrid Models

A hybrid model deliberately combines practices from different approaches. Examples include:

• predictive governance and stage approvals around agile delivery teams;
• a V-model verification framework with iterative prototyping;
• a spiral risk-analysis phase followed by incremental releases; or
• Scrum for product development with Kanban for production support.

Hybrid design should be explicit. The organization should define decision rights, entry and exit criteria, required evidence, change authority, quality gates, and how planning horizons connect. A hybrid process becomes harmful when it combines every ceremony without resolving contradictory assumptions—for example, demanding fixed scope and fixed dates while also claiming unlimited reprioritization.

7. Comparative Selection Framework

Selection should assess at least five dimensions:

1. Requirement uncertainty: Is the problem understood, or must users discover what they need?
2. Technical uncertainty: Are architecture, performance, integration, and security solutions proven?
3. Cost of failure: Could failure cause injury, financial loss, legal exposure, or major service disruption?
4. Compliance and assurance: What evidence, approvals, segregation of duties, and traceability are required?
5. Organizational context: Can the organization provide empowered product ownership, cross-functional teams, automation, and rapid decisions?

A useful professional recommendation states not only the selected model but also what is deliberately excluded, which risks are addressed first, and how success will be measured.

8. Case Study: A Regulated Digital Lending Platform

This is an illustrative case.

Background

A financial institution plans a web and mobile lending platform. It must integrate identity verification, credit assessment, payment services, customer support, and regulatory reporting. The product team expects frequent changes to user workflows, while regulators require audit trails, data protection, controlled releases, and evidence that critical calculations have been tested.

Problem

A pure waterfall approach could provide strong documentation but might delay usability feedback. A purely informal agile approach could respond quickly to users but fail to provide adequate traceability and release control. The platform also has significant security and integration risks.

Analysis and approach

The institution chooses a hybrid process:

• a predictive governance layer defines architecture principles, data classification, risk ownership, release approvals, and mandatory evidence;
• an elaboration or spiral-like phase investigates identity integration, fraud controls, performance, and regulatory reporting through prototypes and technical experiments;
• cross-functional teams deliver customer-facing capabilities incrementally;
• Scrum-like time-boxed iterations are used for product discovery and delivery, while the operations team uses Kanban for incidents and service requests;
• each increment must satisfy a definition of done including automated tests, security scanning, accessibility review, audit logging, updated traceability, and deployment readiness;
• acceptance testing is conducted with business representatives, while system testing evaluates the complete platform against system requirements.

Outcome

The organization obtains early feedback on the application process without abandoning controlled evidence. High-risk integrations are tested before broad rollout. The process costs more than an informal startup workflow, but the additional governance is proportionate to regulatory and financial exposure.

Learning points

• Process selection should reflect both uncertainty and consequence of failure.
• Compliance is stronger when built into ordinary engineering activities rather than postponed to a final audit.
• Different work types may need different flow mechanisms within one governance model.
• A hybrid model is defensible only when its interfaces and responsibilities are explicit.

9. Governance, Ethics, and Contemporary Practice

Life-cycle decisions affect privacy, accessibility, safety, labor, and public trust. Requirements should include lawful data use, retention limits, consent where applicable, accessibility, security, and explainability for consequential automated decisions. Teams should maintain change records and identify who is accountable for approval and operation.

Artificial intelligence can assist with code suggestions, test generation, defect triage, documentation, and requirements analysis. It does not remove the need for human accountability. Generated code may contain vulnerabilities or license concerns; generated requirements may reproduce bias or omit edge cases; and confidential data must not be exposed to unauthorized tools. AI-assisted development should therefore use approved tools, review, testing, provenance controls, and data-governance rules.

Contemporary engineering increasingly connects development with operations through continuous integration, continuous delivery, infrastructure as code, observability, and automated security controls. These practices do not constitute a single SDLC model; they are capabilities that can support iterative, incremental, hybrid, or even highly regulated processes.

10. Best Practices for Process Selection and Tailoring

• Start with risks and learning needs, not with fashionable terminology.
• Separate user/business requirements from system requirements and map each to suitable evaluation activities.
• Deliver thin, valuable increments rather than technically convenient fragments.
• Establish quality criteria before implementation begins.
• Use prototypes to answer explicit questions and label their production status clearly.
• Preserve necessary traceability without producing documents that nobody uses.
• Make change authority and escalation paths visible.
• Include security, privacy, accessibility, operations, and support early.
• Measure outcomes such as escaped defects, lead time, deployment reliability, user value, and risk retirement—not merely activity or velocity.
• Review the process itself and adapt it based on evidence.

Chapter Summary

SDLC models organize the relationship among requirements, design, construction, testing, deployment, and learning. Waterfall emphasizes sequential baselines; the V-model links specification levels to corresponding verification and validation activities. Iterative development emphasizes repeated refinement, while incremental development emphasizes staged delivery of usable capability. Prototyping supports discovery, the spiral model centers risk analysis, and RUP combines iterative phases with architecture and governance. Agile is a family of approaches rather than one universal procedure: Scrum uses time-boxed sprints and a product backlog, whereas Kanban manages continuous flow and work-in-progress. Hybrid models combine practices intentionally and must define their governance interfaces. The best process is selected according to uncertainty, risk, compliance, delivery needs, and organizational capability.

Key Terms

SDLC: A structured life cycle for developing, operating, and retiring software.

Waterfall: A predominantly sequential, phase-based development model.

V-model: A model that explicitly pairs specification activities with corresponding test levels.

Verification: Evaluation of whether the product conforms to specified requirements and design.

Validation: Evaluation of whether the product satisfies real user and business needs.

Iteration: A repeated cycle of learning, development, evaluation, and refinement.

Increment: A usable addition delivered to an existing product.

Prototype: A model used to explore requirements, design, feasibility, or usability.

Spiral model: A risk-driven, cyclical development model.

RUP: An iterative framework with inception, elaboration, construction, and transition phases.

Agile: A family of adaptive approaches emphasizing feedback, collaboration, and working software.

Scrum: An agile framework commonly using a product backlog, sprints, reviews, and retrospectives.

Kanban: A flow-based approach using visualization and work-in-progress management.

Hybrid model: An intentional combination of practices from multiple life-cycle approaches.

Traceability: The ability to relate requirements to design, implementation, tests, and approvals.

Baseline: An agreed version of an artifact controlled against unauthorized change.

Risk retirement: The reduction or elimination of a significant uncertainty or threat.

Definition of done: Explicit quality and completeness criteria for completed work.

Continuous integration: Frequent integration of code supported by automated verification.

Governance: Structures for accountability, decision-making, control, and evidence.

Review Questions

Short Answer Questions

1. What is the difference between verification and validation?
2. Distinguish iterative development from incremental development.
3. Why does the V-model map user/business requirements to acceptance testing?
4. Name two characteristics of Kanban that distinguish it from Scrum.
5. Identify two situations in which prototyping is useful.

Long Answer Questions

1. Compare waterfall and agile approaches in terms of change, feedback, documentation, and risk.
2. Explain the four phases of RUP and the purpose of each phase.
3. Describe the spiral model and explain why risk analysis is central to it.
4. Discuss the strengths and limitations of hybrid life-cycle models.
5. Explain how compliance and security can be integrated into an incremental development process.

Analytical / Application Questions

1. A hospital is developing a patient-monitoring system with uncertain integration technology and strict safety obligations. Recommend a life-cycle approach and justify your choice.
2. A startup has unclear user needs, a small cross-functional team, and direct access to customers. Compare two suitable approaches and identify their principal risks.
3. An organization proposes using Scrum for new features and Kanban for production incidents. Explain how the two approaches can coexist and what governance rules are needed at their boundary.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes validation from verification?

A. Validation checks whether the system satisfies real user and business needs.

B. Validation checks whether source code follows a style guide.

C. Validation is performed only before requirements are written.

D. Validation is identical to unit testing.

Correct Answer: A. Validation checks whether the system satisfies real user and business needs.

Question 2

In the conventional V-model mapping, user or business requirements are most directly associated with which evaluation?

A. Unit testing

B. Acceptance testing

C. Integration testing

D. Static code formatting

Correct Answer: B. Acceptance testing

Question 3

What is the defining emphasis of iterative development?

A. One final delivery after all phases are completed

B. Repeated cycles of learning, evaluation, and refinement

C. Continuous operation without requirements

D. Eliminating all documentation

Correct Answer: B. Repeated cycles of learning, evaluation, and refinement

Question 4

What primarily distinguishes an increment from an iteration?

A. An increment is a usable addition delivered to the product

B. An increment is always a risk register

C. An iteration is always a regulatory approval

D. An increment cannot contain tested software

Correct Answer: A. An increment is a usable addition delivered to the product

Question 5

Which activity is central to the spiral model?

A. Risk analysis in each development cycle

B. Prohibiting prototypes

C. Avoiding stakeholder evaluation

D. Delivering only after maintenance ends

Correct Answer: A. Risk analysis in each development cycle

Question 6

Which phase of RUP focuses particularly on stabilizing architecture and retiring major risks?

A. Inception

B. Elaboration

C. Construction

D. Transition

Correct Answer: B. Elaboration

Question 7

Which statement about agile approaches is accurate?

A. Every agile approach requires fixed-length sprints.

B. Every agile approach requires a product backlog.

C. Kanban commonly manages continuous flow and limits work in progress.

D. Agile eliminates the need for testing and documentation.

Correct Answer: C. Kanban commonly manages continuous flow and limits work in progress.

Question 8

Which situation most strongly supports a V-model or tailored V-model?

A. Highly uncertain user preferences with no access to users

B. Strict traceability and planned verification obligations

C. A desire to avoid all approval points

D. A product whose scope changes hourly without governance

Correct Answer: B. Strict traceability and planned verification obligations

Question 9

What is a major danger of allowing a throwaway prototype to become production software without review?

A. It may contain unsuitable architecture or weak security.

B. It automatically becomes compliant with regulations.

C. It cannot provide any user feedback.

D. It guarantees excessive test coverage.

Correct Answer: A. It may contain unsuitable architecture or weak security.

Question 10

Which is the strongest description of a hybrid life-cycle model?

A. A random collection of ceremonies from different methods

B. An intentional combination with explicit responsibilities and governance interfaces

C. A process that excludes compliance activities

D. A model that forbids incremental delivery

Correct Answer: B. An intentional combination with explicit responsibilities and governance interfaces