Software engineering relies on a software development life cycle (SDLC) to organize work, reduce uncertainty, and improve quality. At a high level, most SDLCs include recurring activities such as requirements engineering, design, implementation, testing, deployment, and maintenance.2 Importantly, these activities do not always occur in a single one-way sequence; authoritative software engineering guidance emphasizes that requirements and testing span the full life cycle and are often iterative, concurrent, and change-driven rather than purely linear.2

In this course section, the goal is not only to define the major SDLC models, but to evaluate them critically in terms of flexibility, cost, risk handling, stakeholder involvement, and suitability when requirements are stable or volatile.2 This is especially important because different models encode different assumptions about uncertainty: some assume requirements can be specified early, while others are explicitly designed to learn, refine, and reduce risk over time.2

A useful starting point is to distinguish between a process model and the engineering activities that appear inside it. Whether a team uses Waterfall, Evolutionary Development, Incremental Implementation, Prototyping, Spiral, or reuse-oriented development, it must still perform core work such as analysis, design, construction, verification, and change control.2

Footnotes

1. What is the Software Development Lifecycle (SDLC)? | IBM - Overview of common SDLC phases, activities, and deliverables. ↩ ↩²

2. Software Development Life Cycle (SDLC) | IBM - Describes planning, analysis, design, coding, testing, deployment, and maintenance as standard lifecycle phases. ↩ ↩²

3. Chapter 1: Software Requirements - SWEBOK - Explains that requirements activities span the whole life cycle and are not merely a front-end one-time task. ↩ ↩²

4. Chapter 4: Software Testing - SWEBOK - States that testing should be planned early and conducted throughout development and maintenance. ↩

5. A Spiral Model of Software Development and Enhancement - Barry Boehm - Classic paper describing Code-and-Fix, Waterfall, Evolutionary Development, and the Spiral model. ↩ ↩²

6. SWEBOK Guide V3.0 PDF - Notes that software processes involve tightly coupled sequential and concurrent activities, not only linear execution. ↩

Purpose of a Software Development Process

A software process exists because ad hoc development scales poorly. Without an explicit process, teams struggle to coordinate changes, validate assumptions, manage defects, estimate effort, and preserve architectural integrity.2 Formalized life cycle processes provide predictable checkpoints, documented outputs, and clearer responsibilities across planning, engineering, quality assurance, and maintenance.2

From a management perspective, the SDLC supports:

• scope definition and project planning,
• traceable requirements and controlled change management,
• earlier and more systematic testing,
• auditable risk-based decisions,
• and long-term maintainability through documentation, configuration management, and structured evolution.2

From a technical perspective, the SDLC helps teams answer three recurring questions:

1. What should be built?
2. How should it be built?
3. How do we know it works and remains fit for use over time?3

A major implication for software engineering education is that lifecycle models should be compared not only by their order of phases, but by the kind of uncertainty they are built to handle. A model that performs well under stable, regulated, well-understood requirements may perform badly when users cannot state their needs clearly at the outset.2

Footnotes

1. A Spiral Model of Software Development and Enhancement - Barry Boehm - Classic paper describing Code-and-Fix, Waterfall, Evolutionary Development, and the Spiral model. ↩ ↩²

2. SWEBOK Guide V3.0 PDF - Notes that software processes involve tightly coupled sequential and concurrent activities, not only linear execution. ↩

3. Software Development Life Cycle (SDLC) | IBM - Describes planning, analysis, design, coding, testing, deployment, and maintenance as standard lifecycle phases. ↩ ↩² ↩³ ↩⁴

4. NIST SP 800-64 Rev. 2 - Discusses SDLC choices, iterative and prototyping models, and integration of risk management throughout the life cycle. ↩ ↩² ↩³

5. Chapter 1: Software Requirements - SWEBOK - Explains that requirements activities span the whole life cycle and are not merely a front-end one-time task. ↩ ↩²

6. Chapter 4: Software Testing - SWEBOK - States that testing should be planned early and conducted throughout development and maintenance. ↩ ↩²

7. What is the Software Development Lifecycle (SDLC)? | IBM - Overview of common SDLC phases, activities, and deliverables. ↩

The Code-and-Fix Model

The Code-and-Fix model is historically important because it illustrates why software engineering needed disciplined lifecycle models in the first place. In Barry Boehm's classic discussion of software process evolution, the model is essentially: write some code, then fix whatever problems appear. Requirements, design, structured testing, documentation, and maintainability are deferred or treated informally.

This model can seem attractive for very small or experimental tasks because it minimizes up-front ceremony. However, it performs poorly as complexity grows. Boehm identifies a key failure pattern: after repeated fixes, the code becomes poorly structured, making subsequent changes increasingly expensive. This leads directly to risks in four major areas:

The model is therefore least suitable for multi-person, safety-relevant, long-lived, or customer-facing systems where traceability and systematic quality matter. At best, it is tolerable for very small disposable scripts or quick experiments with no long-term maintenance expectation.

Footnotes

1. A Spiral Model of Software Development and Enhancement - Barry Boehm - Classic paper describing Code-and-Fix, Waterfall, Evolutionary Development, and the Spiral model. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. Chapter 4: Software Testing - SWEBOK - States that testing should be planned early and conducted throughout development and maintenance. ↩

3. Software Development Life Cycle (SDLC) | IBM - Describes planning, analysis, design, coding, testing, deployment, and maintenance as standard lifecycle phases. ↩

Waterfall Model

The Waterfall model organizes development into sequential phases such as requirements, design, implementation, testing, deployment, and maintenance.2 Its defining idea is phase completion before major downstream work proceeds, which creates clear milestones, documentation, and managerial visibility.

Waterfall is most appropriate when:

• requirements are stable and well understood,2
• the domain is familiar and technically low-risk,
• strong documentation and approvals are required,
• and late change is relatively unlikely or expensive but manageable through control boards.

Its main strengths are clarity, predictability, and disciplined documentation. In regulated or contract-driven settings, these features can be valuable because each phase produces reviewable artifacts and auditable decisions.2

However, Waterfall is least appropriate when users are unsure of their needs, when feedback must shape the product continuously, or when technical uncertainty is high. A key critique from software engineering literature is that important problems are often discovered late, especially if working software appears only after substantial requirements and design effort. Additionally, treating requirements as a one-time front-end activity conflicts with the reality that requirements evolve across the lifecycle.

Footnotes

1. What is the Software Development Lifecycle (SDLC)? | IBM - Overview of common SDLC phases, activities, and deliverables. ↩

2. Software Development Life Cycle (SDLC) | IBM - Describes planning, analysis, design, coding, testing, deployment, and maintenance as standard lifecycle phases. ↩ ↩² ↩³ ↩⁴

3. NIST SP 800-64 Rev. 2 - Discusses SDLC choices, iterative and prototyping models, and integration of risk management throughout the life cycle. ↩ ↩² ↩³

4. Chapter 1: Software Requirements - SWEBOK - Explains that requirements activities span the whole life cycle and are not merely a front-end one-time task. ↩ ↩²

5. A Spiral Model of Software Development and Enhancement - Barry Boehm - Classic paper describing Code-and-Fix, Waterfall, Evolutionary Development, and the Spiral model. ↩

Evolutionary Development

The Evolutionary model differs from linear models by treating software development as progressive learning. Instead of assuming complete and stable requirements up front, it delivers a working basis early and refines the system through repeated feedback cycles.2

This is valuable when stakeholders say, in effect, "I will know it when I see it." Boehm notes that evolutionary development can provide a realistic operational basis for determining later improvements. Compared with Waterfall, the model supports changing requirements more naturally because it assumes refinement is part of the process, not a failure of planning.

The key advantage is iterative refinement:

• users see partial working functionality earlier,
• misunderstandings surface sooner,
• requirements can be adjusted based on evidence rather than speculation,
• and the team can prioritize what matters most in later iterations.

However, evolutionary approaches must not degrade into undisciplined Code-and-Fix. Without architectural control, documentation, and quality practices, iteration can become chaotic. The model therefore requires disciplined feedback loops, technical governance, and explicit criteria for each iteration.

Footnotes

1. A Spiral Model of Software Development and Enhancement - Barry Boehm - Classic paper describing Code-and-Fix, Waterfall, Evolutionary Development, and the Spiral model. ↩ ↩² ↩³ ↩⁴

2. NIST SP 800-64 Rev. 2 - Discusses SDLC choices, iterative and prototyping models, and integration of risk management throughout the life cycle. ↩ ↩²

3. Chapter 1: Software Requirements - SWEBOK - Explains that requirements activities span the whole life cycle and are not merely a front-end one-time task. ↩

Incremental Implementation

Incremental implementation is closely related to iterative development, but the emphasis is on staged delivery of distinct usable portions of the system.2 Instead of waiting for the entire product to be complete, teams release increments that provide partial value sooner.

This improves feedback and risk management in several ways:

• earlier delivery reveals integration and usability issues sooner,
• business value can be realized before the whole system is finished,
• defects and estimation errors are localized to smaller scopes,
• and stakeholders can reprioritize future increments based on evidence.

Incremental implementation is particularly effective when the system can be partitioned into coherent feature sets or service slices. It is less effective when the architecture cannot support modular delivery or when most value depends on full-system completion.

A subtle but important distinction:

• iterative development emphasizes repeated refinement of the product,
• incremental development emphasizes staged addition of functionality,
• and many real projects combine both.2

Footnotes

1. A Spiral Model of Software Development and Enhancement - Barry Boehm - Classic paper describing Code-and-Fix, Waterfall, Evolutionary Development, and the Spiral model. ↩ ↩² ↩³

2. Software Development Life Cycle (SDLC) Models - GeeksforGeeks - Summarizes incremental delivery and iterative version-based development characteristics. ↩ ↩² ↩³

3. Software Development Life Cycle (SDLC) | IBM - Describes planning, analysis, design, coding, testing, deployment, and maintenance as standard lifecycle phases. ↩

4. NIST SP 800-64 Rev. 2 - Discusses SDLC choices, iterative and prototyping models, and integration of risk management throughout the life cycle. ↩

Prototyping

Prototyping is especially useful when requirements are uncertain, interfaces are novel, or stakeholders cannot easily articulate expectations abstractly.2 NIST guidance notes that prototyping is often used to develop an understanding of system requirements without necessarily building the final operational system directly from the prototype.

Two important forms should be distinguished:

1. Exploratory or evolutionary prototype: a prototype that is refined toward the final system over time.2
2. Throwaway prototype: a prototype built primarily to learn, test assumptions, or clarify requirements, then discarded before production development.

Prototyping helps requirements clarification by making ideas visible and testable. Instead of debating hypothetical features, users can react to screens, workflows, reports, or simplified system behaviors.2 This is particularly valuable for user interfaces, workflow-heavy systems, decision support tools, and innovative products.

Still, prototyping has risks. Stakeholders may assume a quick prototype is nearly production-ready, even when quality attributes such as security, scalability, test coverage, and maintainability are absent.2 Teams must therefore label prototype intent clearly and distinguish learning artifacts from deployable software.

Footnotes

1. NIST SP 800-64 Rev. 2 - Discusses SDLC choices, iterative and prototyping models, and integration of risk management throughout the life cycle. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. Management Guide for Software Reuse - NIST - Explains prototyping as an iterative process for refining requirements and specifications and connects it to reuse. ↩

3. A Spiral Model of Software Development and Enhancement - Barry Boehm - Classic paper describing Code-and-Fix, Waterfall, Evolutionary Development, and the Spiral model. ↩

4. Chapter 1: Software Requirements - SWEBOK - Explains that requirements activities span the whole life cycle and are not merely a front-end one-time task. ↩

5. Secure Software Development Framework (SSDF) Version 1.1 - NIST - Emphasizes that lifecycle practices must preserve documented requirements, risks, and design decisions across the software life cycle. ↩

Spiral Model

The Spiral model is one of the most influential lifecycle models because it explicitly integrates risk management into iterative development.2 Rather than prescribing a single fixed sequence for all projects, it treats each loop of the spiral as a structured cycle that includes objective setting, risk analysis, development, and stakeholder review.

This model is especially appropriate for large, complex, high-risk systems where uncertainty must be addressed deliberately. In the Spiral model:

• each iteration defines objectives and alternatives,
• major risks are identified and analyzed,2
• prototypes or other mitigations may be used to reduce uncertainty,2
• engineering work is performed for the next-level product,
• and stakeholders review results before committing to the next cycle.

Its strengths are strong risk handling, progressive elaboration, and continuous stakeholder evaluation. Its main weakness is management complexity: it requires mature teams capable of explicit risk assessment and disciplined iteration planning.2

Footnotes

1. A Spiral Model of Software Development and Enhancement - Barry Boehm - Classic paper describing Code-and-Fix, Waterfall, Evolutionary Development, and the Spiral model. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸

2. NIST SP 800-64 Rev. 2 - Discusses SDLC choices, iterative and prototyping models, and integration of risk management throughout the life cycle. ↩ ↩² ↩³

3. Management Guide for Software Reuse - NIST - Explains prototyping as an iterative process for refining requirements and specifications and connects it to reuse. ↩

Software Reuse

Software reuse aims to reduce development effort by building with proven assets instead of creating everything from scratch.2 Reuse can involve libraries, frameworks, services, test assets, architectures, templates, or even process knowledge.

A reuse-oriented strategy reduces effort through:

• shorter implementation time when existing components satisfy requirements,
• reduced defect introduction because reused assets may be mature and previously tested,2
• more consistent architecture and design through shared frameworks,
• and lower duplication of engineering work across products or versions.2

However, reuse is not free. Effective reuse requires asset discovery, compatibility analysis, integration work, configuration management, licensing or data-rights clarity, documentation, and quality assurance.2 In other words, reuse shifts effort from invention toward selection, adaptation, and integration.

A sophisticated engineering perspective recognizes two complementary strategies:

• development with reuse: assembling systems from existing assets,
• development for reuse: creating assets intentionally so they can be reused later.

Footnotes

1. Chapter 3: Software Construction - SWEBOK - References reuse processes and explains how construction can occur with reusable assets across lifecycle models. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹

2. Management Guide for Software Reuse - NIST - Discusses benefits and practical challenges of software reuse, including integration, quality assurance, cataloging, and change control. ↩ ↩² ↩³

3. Chapter 4: Software Testing - SWEBOK - States that testing should be planned early and conducted throughout development and maintenance. ↩

Comparative Analysis of SDLC Models

A critical comparison of SDLC models shows that no single model is universally best. The right choice depends on requirement volatility, technical risk, stakeholder availability, regulatory constraints, architecture, organizational maturity, and delivery pressure.3

A useful decision rule is:

• choose more linear models when change is low and accountability artifacts are paramount,
• choose more iterative models when discovery and adaptation are central,
• choose risk-driven models when failure costs are high,
• and emphasize reuse when proven assets exist and integration is feasible.3

Footnotes

1. Software Development Life Cycle (SDLC) | IBM - Describes planning, analysis, design, coding, testing, deployment, and maintenance as standard lifecycle phases. ↩ ↩²

2. A Spiral Model of Software Development and Enhancement - Barry Boehm - Classic paper describing Code-and-Fix, Waterfall, Evolutionary Development, and the Spiral model. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

3. NIST SP 800-64 Rev. 2 - Discusses SDLC choices, iterative and prototyping models, and integration of risk management throughout the life cycle. ↩ ↩² ↩³ ↩⁴ ↩⁵

4. Chapter 1: Software Requirements - SWEBOK - Explains that requirements activities span the whole life cycle and are not merely a front-end one-time task. ↩

5. Software Development Life Cycle (SDLC) Models - GeeksforGeeks - Summarizes incremental delivery and iterative version-based development characteristics. ↩

6. Management Guide for Software Reuse - NIST - Explains prototyping as an iterative process for refining requirements and specifications and connects it to reuse. ↩

7. Secure Software Development Framework (SSDF) Version 1.1 - NIST - Emphasizes that lifecycle practices must preserve documented requirements, risks, and design decisions across the software life cycle. ↩

8. Chapter 3: Software Construction - SWEBOK - References reuse processes and explains how construction can occur with reusable assets across lifecycle models. ↩ ↩²

9. Management Guide for Software Reuse - NIST - Discusses benefits and practical challenges of software reuse, including integration, quality assurance, cataloging, and change control. ↩

Practical Synthesis for Software Engineering Students

For introductory software engineering, the most important conceptual lesson is that SDLC models are engineering responses to uncertainty. Waterfall responds by controlling phases and documentation; Evolutionary and Incremental approaches respond by learning through delivery; Prototyping responds by clarifying ambiguity; Spiral responds by confronting risk explicitly; reuse-oriented approaches respond by leveraging existing assets to reduce repeated effort.4

In modern practice, many organizations use hybrid approaches rather than textbook-pure models. For example, a project may use incremental delivery, prototype a risky user workflow, apply reuse through frameworks and services, and add risk checkpoints inspired by Spiral thinking.3 This hybridization does not invalidate classic models; instead, it shows that the models are analytical tools for understanding trade-offs.

For assessment and professional reasoning, always evaluate a lifecycle model against these questions:

• Are requirements stable or volatile?
• Is technical risk low or high?
• How often can users give feedback?
• Is early partial delivery valuable?
• Do we need heavy documentation and formal approvals?
• Can reusable assets shorten development safely?5

If these questions are answered systematically, lifecycle selection becomes an engineering decision rather than a matter of preference.

Footnotes

1. Software Development Life Cycle (SDLC) | IBM - Describes planning, analysis, design, coding, testing, deployment, and maintenance as standard lifecycle phases. ↩ ↩²

2. A Spiral Model of Software Development and Enhancement - Barry Boehm - Classic paper describing Code-and-Fix, Waterfall, Evolutionary Development, and the Spiral model. ↩ ↩² ↩³

3. NIST SP 800-64 Rev. 2 - Discusses SDLC choices, iterative and prototyping models, and integration of risk management throughout the life cycle. ↩ ↩² ↩³

4. Chapter 3: Software Construction - SWEBOK - References reuse processes and explains how construction can occur with reusable assets across lifecycle models. ↩ ↩² ↩³

5. Chapter 1: Software Requirements - SWEBOK - Explains that requirements activities span the whole life cycle and are not merely a front-end one-time task. ↩