Software Development Life Cycles and Process Models

Introduction

Software rarely succeeds through programming alone. A software product must be understood, planned, designed, built, tested, deployed, operated and eventually retired. The organized set of activities used to develop and maintain software is called a software development life cycle (SDLC). An SDLC provides a framework for coordinating people, processes, technologies, documentation, quality assurance and stakeholder decisions.

A process model is a particular way of organizing SDLC activities. Waterfall, iterative, incremental, prototyping, spiral, V-model, Agile and hybrid approaches are not simply competing lists of tasks. They represent different assumptions about requirements, change, risk, feedback, governance and delivery. Selecting a process model is therefore an engineering decision rather than a matter of personal preference.

A small internal application with uncertain user needs may benefit from short iterations and prototypes. A safety-critical medical device may require rigorous traceability, formal verification and documented approvals. A government system may combine contractual milestones with Agile delivery teams. The appropriate model depends on the context.

Learning Objectives

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

• explain the purpose and principal activities of an SDLC;
• distinguish a life-cycle model from a development method or framework;
• describe the characteristics, strengths and limitations of waterfall, iterative, incremental, prototyping, spiral, V-model, Agile and hybrid approaches;
• compare models using requirements stability, risk, compliance, team and delivery considerations;
• select and justify an appropriate model for a project;
• explain how governance, quality assurance, ethics and contemporary technologies influence process selection.

1. Foundations of Software Life Cycles

1.1 What is an SDLC?

An SDLC is a structured view of the work required to create, change and operate a software system. Although terminology differs among organizations, typical activities include:

1. Feasibility and initiation – determining whether the proposed system is technically, financially and operationally viable.
2. Requirements engineering – discovering, analyzing, documenting and validating stakeholder needs.
3. Architecture and design – defining system structure, interfaces, data, components and important technical decisions.
4. Implementation – producing source code, configuration and related technical artifacts.
5. Verification and validation – checking that the system was built correctly and that it satisfies its intended purpose.
6. Deployment and transition – releasing the system into its operational environment and supporting users.
7. Operation, maintenance and retirement – correcting faults, adapting the system, improving it and eventually decommissioning it.

These activities are not necessarily performed once or in a fixed sequence. A life-cycle model specifies how they are related, repeated and governed.

1.2 Life-cycle model, methodology and framework

These terms are related but should not be treated as synonyms.

• A life-cycle model describes the overall flow of development, such as sequential, iterative or risk-driven work.
• A methodology provides principles, practices, roles and techniques for conducting development.
• A framework provides a structured implementation approach, often with defined events and artifacts. Scrum is an Agile framework, for example.
• A standard states agreed requirements or guidance. ISO/IEC/IEEE 12207 describes software life-cycle processes, but it does not force every organization to use one specific model.

A team can therefore use an iterative life-cycle model with Scrum practices, formal architecture reviews and an organization’s quality standard.

1.3 Common process concerns

Every process model must address several recurring concerns:

• Scope: What product or service is being developed?
• Value: Which capabilities deliver the greatest benefit?
• Quality: How will correctness, security, usability, reliability and maintainability be judged?
• Risk: What could prevent success, and when will uncertainty be reduced?
• Change: How will new or altered requirements be evaluated?
• Traceability: Can requirements be connected to design decisions, code, tests and approvals?
• Governance: Who authorizes scope, expenditure, release and acceptance?
• Feedback: How quickly can users and technical specialists inspect results?

A mature process makes these concerns visible rather than assuming that coding activity automatically resolves them.

2. Sequential and Plan-Driven Models

2.1 Waterfall model

The waterfall model organizes development into largely sequential phases. A common arrangement is requirements, design, implementation, testing, deployment and maintenance. A phase is substantially completed before the next phase begins, and formal documents or reviews may serve as gates.

Figure: A simplified waterfall sequence. Real projects may include feedback and controlled rework between phases.

Strengths. Waterfall is easy to explain and manage. It can support contractual milestones, budget planning, extensive documentation and regulated approval. It is useful when requirements are stable, technology is well understood and late change is expensive or undesirable.

Limitations. Users may not see a working system until late in the project. Incorrect assumptions can remain hidden until testing or acceptance. Requirements are not truly frozen merely because a document was signed; business, legal and technical conditions can change. Late discovery of defects or usability problems may cause expensive rework.

Waterfall should therefore not be equated with carelessness or with “no testing until the end.” Good plan-driven projects perform reviews, analyses, prototypes and test planning early, even if major construction is sequential.

2.2 V-model

The V-model is a refinement of plan-driven development that emphasizes correspondence between development activities and test levels. On the descending side, stakeholder requirements lead to system requirements, architecture and detailed design, followed by implementation at the bottom. On the ascending side, unit, integration, system and acceptance testing provide evidence against the corresponding specifications.

The model’s central principle is verification and validation planned from the beginning. For example, acceptance criteria should be derived from stakeholder requirements, not invented after coding. Traceability links can connect a requirement to design elements, implementation units, test cases and test results.

The V-model is valuable in projects requiring documented assurance, such as aerospace, medical, automotive, financial or public-sector systems. However, it does not eliminate change and is not automatically safer than every other model. Its effectiveness depends on the quality of requirements, independence and competence of testing, configuration control and management of risks. Excessive documentation without meaningful technical review can become bureaucratic rather than protective.

3. Evolutionary and Delivery-Oriented Models

3.1 Iterative development

In an iterative process, the team revisits and improves the product through repeated cycles. Each iteration may include analysis, design, coding and testing. Knowledge gained from one cycle informs the next.

Iteration is particularly useful when requirements or design decisions are uncertain. A team can implement a modest version of a capability, obtain feedback, and revise the solution. Iteration does not necessarily mean that users receive a production release after every cycle; an iteration may produce an internal or technical increment.

A risk of iteration is uncontrolled rework. Teams need an explicit product vision, architectural direction, decision records, quality standards and prioritization. Otherwise, repeated changes may produce inconsistent design or technical debt.

3.2 Incremental development

In incremental development, the product is delivered in functional portions called increments. Each increment adds capability to the previously delivered system. An increment should be integrated, tested and potentially releasable, although business decisions may delay public release.

Iteration concerns repeated learning and refinement; increment concerns the addition of usable capability. They often occur together. For example, a team might develop a payment increment over three iterations and then release it with an earlier account-management increment.

Incremental delivery can provide early value, reduce the size of each release and expose integration problems sooner. It also requires sound architecture, interface management, regression testing, data migration planning and a clear definition of “done.” A weakly designed system may become difficult to extend as increments accumulate.

3.3 Prototyping

A prototype is a partial or experimental representation used to learn about requirements, design or feasibility. Prototypes may be:

• Throwaway prototypes, created to answer questions and then discarded;
• Evolutionary prototypes, progressively refined into the eventual product;
• Horizontal prototypes, showing broad interface coverage with little depth;
• Vertical prototypes, implementing one narrow feature across several technical layers.

Prototypes are effective for unclear workflows, novel interfaces, difficult integrations and uncertain technical feasibility. They make assumptions visible and allow stakeholders to react to something concrete.

A prototype is not automatically production-quality software. It may omit security, error handling, performance engineering, accessibility, maintainability or data protection. A common failure occurs when stakeholders assume that a visually attractive demonstration is nearly complete. Teams should label prototypes clearly, document their purpose and decide explicitly whether any code will be retained.

3.4 Spiral model

The spiral model organizes development around repeated cycles of risk analysis. A typical cycle includes establishing objectives and alternatives, identifying and resolving risks, developing and verifying the next product portion, and reviewing the results before planning the next cycle.

The model is appropriate when uncertainty and consequences are high—for example, large systems, new technology, complex integration or safety and security concerns. Risk reduction may involve simulation, proof of concept, prototype, threat analysis, performance testing or architectural experiments.

Its strength is deliberate attention to risk before committing to extensive construction. Its limitation is management complexity. Risk analysis requires expertise, evidence and time; a small, routine project may gain little from a formal spiral process. The model also needs clear exit criteria, because an endless sequence of risk studies is not delivery.

4. Agile Approaches

4.1 Meaning of Agile

Agile is a family of approaches emphasizing early and continuous delivery of valuable software, close collaboration, adaptation to change and frequent feedback. The Agile Manifesto values individuals and interactions, working software, customer collaboration and responding to change, while still recognizing the value of processes, documentation, contracts and plans.

Agile is not synonymous with “no planning,” “no documentation” or “coding without design.” Agile planning occurs at multiple horizons: product vision, release goals, iteration or sprint objectives, and daily coordination. Documentation is created when it supports understanding, operation, compliance or maintenance.

Common Agile practices include a prioritized product backlog, short timeboxes, user stories, acceptance criteria, continuous integration, automated testing, code review, demonstrations and retrospectives. Scrum, Kanban and extreme programming represent different practices and emphases; an organization should not adopt labels without understanding the underlying work system.

4.2 Benefits and limitations

Agile approaches can reduce feedback time, accommodate changing priorities and reveal integration or usability problems early. They are particularly useful where users can collaborate regularly and value can be delivered in slices.

Agile becomes difficult when stakeholders are unavailable, requirements are constrained by fixed external interfaces, architecture is ignored, teams lack engineering discipline or a contract requires an artificially fixed scope and price. Short iterations do not remove the need for security, accessibility, performance, compliance or long-term architecture. These qualities must be planned, measured and tested continuously.

A practical Agile team may maintain architectural decision records, a risk register, test evidence, threat models, release documentation and traceability links. This is compatible with Agile when artifacts are purposeful and kept current.

5. Hybrid Models

A hybrid model deliberately combines elements of two or more approaches. Examples include:

• fixed regulatory gates with Agile development between gates;
• a waterfall feasibility and procurement stage followed by incremental delivery;
• a V-model assurance process with iterative implementation;
• a spiral risk-analysis stage followed by Scrum-based product development;
• a plan-driven infrastructure and data-migration stream coordinated with Agile application teams.

Hybrid design should solve a real contextual problem, not merely combine terminology. The interfaces between approaches must be defined: who approves requirements, how changes are controlled, what evidence is required, how increments are accepted and how dependencies are managed. A poorly designed hybrid can inherit the disadvantages of each model while creating additional coordination overhead.

6. Selecting an Appropriate Model

Process selection should be evidence-based. The following dimensions are useful.

No dimension should be considered in isolation. A project may have uncertain requirements but severe safety consequences. The answer may be iterative development with formal verification and regulatory gates, rather than an informal Agile process.

6.1 A practical selection procedure

1. Characterize the product and context. Identify users, business goals, system boundaries, dependencies and operational environment.
2. Assess requirements volatility. Distinguish genuine uncertainty from poor analysis. Identify which requirements are fixed by law, hardware, contracts or interfaces.
3. Identify major risks. Consider technical feasibility, security, safety, privacy, schedule, suppliers, data migration and organizational change.
4. Determine feedback access. Ask whether representative users and domain experts can participate frequently.
5. Define assurance and governance needs. Determine required documentation, approvals, audits, traceability, independent testing and evidence.
6. Evaluate delivery strategy. Decide whether early increments are valuable and technically feasible.
7. Select and tailor a model. Specify roles, activities, artifacts, decision gates, quality criteria and change control.
8. Inspect and adapt the process. Use project evidence to improve the process without weakening required controls.

A simple qualitative decision matrix can support discussion. Rate each candidate model against criteria such as requirement uncertainty, risk reduction, compliance fit, feedback speed and delivery suitability. Ratings are aids to judgment, not a substitute for professional analysis. Numerical scores can create false precision if criteria and evidence are poorly defined.

6.2 Worked selection example

Consider an illustrative project to replace a university’s student advising portal. Existing regulations require privacy controls and audit logs, but the user experience is known to be poor. Academic departments have different workflows, and representatives can meet the team every two weeks. The team must integrate with an established identity service and student database.

A pure waterfall approach would support formal procurement and integration documentation, but it would risk encoding incorrect workflows. A purely informal Agile approach could expose the project to privacy, audit and data-migration failures. A suitable choice is a hybrid incremental model: establish privacy, architecture, integration and data requirements through an initial controlled stage; then deliver advising, appointment and reporting capabilities in prioritized increments; use demonstrations and usability testing every two weeks; and apply formal security, privacy and release gates.

This choice is justified because requirements are partly uncertain, feedback is available, integration risks are significant, and governance obligations are real. The model does not remove planning; it places planning and assurance at the points where they provide the greatest value.

7. Applied Case Study: Illustrative Emergency-Response System

Background

A regional emergency service plans a dispatch-support system that combines incident reports, vehicle locations and hospital capacity. Failure or delay could affect public safety. Some interfaces must comply with existing communication standards, while dispatchers need a workflow that has not previously been standardized.

Problem

The organization initially proposes a conventional waterfall contract because it wants a fixed budget and documented acceptance. Analysts discover that location data quality is uncertain, integration with older systems is technically risky, and dispatchers disagree about the best screen layout. A late discovery could be costly and dangerous.

Analysis

The project has high consequence of failure, substantial technical uncertainty, and uncertain user interaction requirements. It therefore needs both risk-driven investigation and rigorous verification. A single model used dogmatically would be inadequate.

Approach and solution

The organization adopts a hybrid model:

• a feasibility and governance stage defines safety responsibilities, privacy controls, interfaces, acceptance authorities and traceability obligations;
• a spiral-style risk cycle investigates location accuracy, resilience, cybersecurity and integration with the legacy system;
• throwaway interface prototypes are tested with dispatchers before interface requirements are baselined;
• cross-functional teams develop low-risk capabilities incrementally;
• each increment undergoes automated tests, integration tests, security assessment and operational review;
• formal system validation and release approval are conducted before operational use;
• deployment begins with a controlled pilot and monitoring plan.

Outcome

The project discovers that one proposed location feed cannot meet the required accuracy and replaces it before full-scale construction. Dispatcher testing also reveals that a map-centered interface is less effective than an incident-priority view. The project retains formal assurance evidence while gaining feedback early enough to influence design.

Learning points

1. High consequence does not automatically require a purely sequential model.
2. Prototypes can reduce usability uncertainty, but they do not constitute assurance evidence by themselves.
3. Risk analysis should influence development order.
4. Compliance and Agile or incremental delivery can coexist when evidence is planned continuously.
5. Process selection should be based on system characteristics and risks, not fashionable terminology.

8. Quality, Governance and Professional Responsibility

8.1 Quality assurance and verification

Quality is broader than absence of coding defects. Relevant attributes may include functional suitability, reliability, usability, performance efficiency, security, maintainability, compatibility and accessibility. The selected process should make quality activities timely and visible.

Verification asks whether work products conform to specified requirements: for example, whether a design follows an approved interface specification. Validation asks whether the resulting system satisfies real user and operational needs. Both are necessary. A system can conform perfectly to an incorrect requirement.

8.2 Change and configuration management

Change is inevitable, but uncontrolled change threatens cost, schedule, architecture and quality. Teams need a method for recording requests, analyzing impact, prioritizing work, approving decisions and updating affected artifacts. Configuration management identifies versions of code, requirements, environments, test data and documents so that released results can be reproduced.

Agile backlogs and continuous delivery do not remove configuration management. They change its timing and implementation. Similarly, formal change-control boards are not always required for low-risk product decisions, but regulated or safety-relevant changes may require independent review and documented authorization.

8.3 Security, privacy and ethics

Security should be addressed throughout the life cycle, not added after functional development. Threat modeling, secure design, dependency management, code review, vulnerability testing, least privilege and incident planning are examples of life-cycle practices.

Privacy requires attention to data minimization, purpose limitation, access control, retention, transparency and lawful processing. Ethical responsibility extends beyond legal compliance. A system may be legal yet unfair, inaccessible or harmful to vulnerable users. Process models should provide opportunities for affected stakeholders to identify such consequences.

8.4 AI-assisted development

AI coding assistants and generative systems can support prototyping, test generation, documentation and code explanation. They can also produce insecure, incorrect, biased or license-incompatible outputs. Professional teams should review generated code, protect confidential data, verify dependencies, preserve authorship and licensing records, and apply the same testing and security standards as for human-written code. AI can accelerate activities within a life cycle; it does not replace requirements ownership, engineering judgment, accountability or validation.

9. Contemporary Practice and Best Practices

Modern organizations increasingly combine incremental development with continuous integration, automated testing, infrastructure as code, observability and controlled continuous delivery. DevOps extends collaboration across development and operations, while platform engineering seeks to provide reusable delivery capabilities. These practices shorten feedback loops but increase the importance of automated controls, monitoring and reversible releases.

Useful best practices include:

• choose the model from evidence about uncertainty, risk and governance;
• deliver and evaluate the smallest meaningful capability;
• make quality criteria and acceptance conditions explicit;
• test continuously, including security, accessibility and performance where relevant;
• maintain lightweight but sufficient documentation;
• preserve traceability for important requirements and decisions;
• involve representative users rather than relying only on proxy stakeholders;
• manage technical debt deliberately;
• use prototypes to answer specific questions;
• review the process as well as the product;
• tailor controls to consequence and risk, avoiding both negligence and unnecessary bureaucracy.

Challenges and Limitations

No process model guarantees project success. Waterfall may conceal changing assumptions; Agile may encourage short-term optimization; incremental delivery may produce architectural fragmentation; prototyping may create false confidence; spiral development may be expensive to manage; the V-model may become document-centered; and hybrid models may create unclear accountability.

Additional challenges include distributed teams, outsourced suppliers, legacy integration, changing regulations, cybersecurity threats, staff turnover, unrealistic deadlines and weak stakeholder participation. Process quality depends on organizational capability. A well-selected model cannot compensate for absent leadership, inadequate skills, poor communication or impossible constraints.

Chapter Summary

An SDLC organizes the work of understanding, designing, building, testing, deploying, operating and retiring software. A process model determines how these activities are sequenced, repeated, reviewed and governed. Waterfall is suited to relatively stable and well-understood contexts; the V-model strengthens the relationship between development specifications and testing evidence. Iterative development supports learning and refinement, while incremental development delivers usable capability in portions. Prototyping reduces uncertainty about requirements, interfaces and feasibility. Spiral development emphasizes systematic risk reduction. Agile approaches use collaboration, short feedback cycles and adaptation, but still require architecture, documentation, testing and governance. Hybrid models combine approaches to meet complex contextual needs.

Model selection should consider requirement volatility, technical and operational risk, compliance, stakeholder access, delivery needs, team capability and the consequences of failure. Professional software engineering requires not only an appropriate process but also disciplined quality assurance, configuration management, security, privacy, ethical judgment and accountability. The best process is tailored, evidence-based and continuously improved.

Key Terms

SDLC: The organized life-cycle activities used to develop, operate, maintain and retire software.

Process model: A structured representation of how software activities are arranged and related.

Waterfall: A largely sequential, plan-driven life-cycle model.

V-model: A plan-driven model linking development activities with corresponding testing and validation activities.

Iteration: A repeated development cycle used to learn, refine or improve a product.

Increment: A tested addition of usable capability to a product.

Prototype: A partial representation created to investigate requirements, design or feasibility.

Throwaway prototype: A prototype intended to answer questions and then be discarded.

Spiral model: A risk-driven model organized around repeated cycles of risk identification, resolution and development.

Agile: A family of approaches emphasizing collaboration, feedback, delivery and adaptation.

Backlog: An ordered collection of work items, requirements, defects or improvements.

Hybrid model: A deliberately tailored combination of practices or life-cycle approaches.

Verification: Checking whether a work product conforms to specified requirements.

Validation: Checking whether the resulting system satisfies intended user and operational needs.

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

Configuration management: Control and identification of versions and changes to software and related artifacts.

Technical debt: The future cost created by expedient technical decisions or deferred quality work.

Risk: An uncertain event or condition that may affect objectives.

Continuous integration: Frequent integration of changes into a shared codebase with automated checks.

Governance: The authority, controls and decision arrangements used to direct and oversee development.

Review Questions

Short Answer Questions

1. What is an SDLC, and how does it differ from a process model?
2. State two strengths and two limitations of the waterfall model.
3. How do iterative and incremental development differ?
4. What is the principal purpose of a prototype?
5. Why is traceability important in a regulated software project?

Long Answer Questions

1. Explain the V-model and discuss how it supports verification and validation.
2. Compare Agile and waterfall approaches in relation to requirements, stakeholder feedback, documentation and change.
3. Describe the spiral model and explain why it may be appropriate for technically uncertain projects.
4. Explain how a hybrid process can combine Agile delivery with formal governance.
5. Discuss the ethical, security and privacy responsibilities that should be addressed throughout an SDLC.

Analytical / Application Questions

1. A company is developing a small internal reporting tool. Users are available weekly, requirements are uncertain, and failure has limited consequences. Which model or combination would you recommend, and why?
2. A medical monitoring system has stable regulatory requirements but includes a new sensor technology. Design a suitable life-cycle approach and identify where prototypes, risk analysis and formal testing should occur.
3. An Agile team delivers frequent features but experiences increasing defects and architectural inconsistency. Analyze likely process weaknesses and recommend corrective practices.

Multiple Choice Questions with Answers

Question 1

Which statement best describes an SDLC?

A. A programming language used to implement software

B. An organized set of activities for developing, operating and retiring software

C. A document containing only user requirements

D. A testing tool for finding defects

Correct Answer: B. An organized set of activities for developing, operating and retiring software

Question 2

Which project condition most strongly favors a traditional waterfall approach?

A. Highly uncertain user needs and frequent priority changes

B. A novel technology requiring repeated experiments

C. Stable requirements, familiar technology and formal milestone approvals

D. Users who can review working software every week

Correct Answer: C. Stable requirements, familiar technology and formal milestone approvals

Question 3

What is the central emphasis of the V-model?

A. Avoiding all documentation

B. Linking development specifications with corresponding testing activities

C. Delivering software without planned requirements

D. Replacing testing with user demonstrations

Correct Answer: B. Linking development specifications with corresponding testing activities

Question 4

What is the main purpose of a throwaway prototype?

A. To investigate questions and then normally discard the prototype

B. To serve permanently as the production system

C. To replace security testing

D. To freeze all requirements immediately

Correct Answer: A. To investigate questions and then normally discard the prototype

Question 5

Which statement correctly distinguishes iterative from incremental development?

A. Iteration concerns repeated refinement, while an increment adds usable capability

B. Iteration is only testing, while an increment is only documentation

C. Iteration always requires waterfall, while increments require spiral development

D. There is no meaningful distinction between the terms

Correct Answer: A. Iteration concerns repeated refinement, while an increment adds usable capability

Question 6

Which characteristic is most associated with the spiral model?

A. Risk analysis and resolution in repeated cycles

B. A single coding phase with no review

C. Prohibition of prototypes

D. A requirement that all users be absent during development

Correct Answer: A. Risk analysis and resolution in repeated cycles

Question 7

Which practice is most consistent with Agile development?

A. Deferring all testing until final deployment

B. Frequent feedback and delivery of prioritized, usable capabilities

C. Rejecting all changes after project initiation

D. Treating documentation as prohibited

Correct Answer: B. Frequent feedback and delivery of prioritized, usable capabilities

Question 8

A project has uncertain workflows, significant privacy obligations and users available for regular demonstrations. Which approach is most defensible?

A. An informal process with no release controls

B. A hybrid incremental approach with frequent feedback and formal privacy gates

C. A purely sequential process that forbids prototypes

D. A prototype-only project with no production testing

Correct Answer: B. A hybrid incremental approach with frequent feedback and formal privacy gates

Question 9

What does verification primarily examine?

A. Whether the system satisfies real-world user needs only

B. Whether a work product conforms to specified requirements

C. Whether the project has a large budget

D. Whether users prefer one programming language

Correct Answer: B. Whether a work product conforms to specified requirements

Question 10

Why must AI-generated code be reviewed by software professionals?

A. AI-generated code is automatically compliant in every jurisdiction

B. Generated code may contain defects, vulnerabilities or licensing problems

C. Review is unnecessary when code compiles

D. AI tools cannot produce documentation

Correct Answer: B. Generated code may contain defects, vulnerabilities or licensing problems