SDLC Models and Process Theories

Introduction

The software development life cycle (SDLC) is a structured way of planning, creating, testing, deploying, operating, and retiring software. An SDLC model is not merely a diagram of activities. It expresses assumptions about how software work should be organized, how requirements are discovered, how change is controlled, when quality is assessed, and how stakeholders receive value.

No single model is universally best. A model that is appropriate for safety-critical medical software may be unsuitable for a rapidly changing mobile application. Professional software engineers therefore select or tailor a process model according to requirements stability, technical uncertainty, risk, regulatory obligations, stakeholder availability, team capability, delivery urgency, and the cost of change.

This chapter compares eight influential models: waterfall, V-model, iterative, incremental, prototyping, rapid application development (RAD), spiral, and the Unified Process. It also explains process theories that help practitioners understand why these models succeed or fail.

Learning Objectives

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

1. Explain the purpose and structure of major SDLC models.
2. Compare the assumptions, strengths, limitations, and risks of different models.
3. Select a suitable model for a given project context.
4. Distinguish iterative development from incremental delivery and prototyping.
5. Explain how risk, feedback, verification, validation, and change control influence process selection.
6. Apply SDLC reasoning to a realistic software project.

1. Process Models as Theories of Development

A process model is a simplified representation of software work. It identifies activities, their relationships, decision points, work products, and feedback mechanisms. Typical activities include requirements engineering, architecture and design, implementation, integration, testing, deployment, operation, and maintenance.

A model is also a theory because it makes claims about development. For example:

• Waterfall assumes that substantial requirements and design decisions can be established before construction.
• Iterative development assumes that repeated learning cycles can improve the solution.
• Incremental development assumes that a system can be divided into useful portions and delivered progressively.
• Spiral development assumes that explicit risk analysis should guide each development cycle.
• Prototyping assumes that building an exploratory version can reveal unclear requirements.

These assumptions should be examined rather than accepted automatically.

Verification and validation

Verification asks whether the product has been built according to its specified design: “Are we building the product right?” Validation asks whether the product satisfies user and business needs: “Are we building the right product?” Both are necessary. A technically correct system can still fail if it solves the wrong problem.

Feedback and control

Every SDLC balances two forces:

• Feedback: learning from users, tests, operations, and changing circumstances.
• Control: maintaining scope, traceability, budget, architecture, compliance, and predictability.

Sequential models emphasize control and predictability. Adaptive models emphasize feedback and learning. Mature projects usually require both.

Cost of change

A common process assumption is that change becomes more expensive later because more artifacts, code, tests, training, and operational commitments depend on an earlier decision. This is a useful planning principle, not a universal law. Automation, modular architecture, continuous integration, and effective testing can reduce the cost of late change. Conversely, poor requirements or tightly coupled systems can make change expensive even in an iterative process.

2. Waterfall Model

The waterfall model organizes development into predominantly sequential phases. A typical sequence is:

1. Feasibility and planning
2. Requirements specification
3. System and software design
4. Implementation
5. Integration and testing
6. Deployment
7. Operation and maintenance

In a strict interpretation, a phase is completed and approved before the next begins. Real projects often use a modified waterfall with limited feedback between phases.

Assumptions

Waterfall is most suitable when:

• requirements are stable and well understood;
• the technology and problem domain are familiar;
• contractual deliverables must be defined early;
• extensive documentation and formal approval are required; and
• change is relatively infrequent or can be handled through controlled change requests.

Strengths

Waterfall provides clear milestones, defined deliverables, straightforward management reporting, and strong traceability. It can support procurement and fixed-scope contracting because requirements, schedules, and acceptance criteria are documented early. It is also useful where regulatory bodies require formal evidence of review and approval.

Limitations and risks

The principal weakness is delayed feedback. Users may not see a working system until late in the project, when correcting a misunderstood requirement is costly. The model can encourage a false distinction between “requirements” and “design,” even though requirements often evolve when stakeholders see feasible solutions. A project may also appear to progress because documents are completed while technical or usability risks remain unresolved.

Waterfall should not be confused with “no testing until the end.” Good sequential projects plan quality activities from the beginning and conduct reviews, inspections, prototypes, and test planning throughout.

3. V-Model

The V-model extends sequential development by explicitly pairing each development activity with a corresponding test or evaluation activity. The left side defines and designs the system; the right side integrates and tests it.

System requirements       ↔ Acceptance testing
       ↓                            ↑
System architecture       ↔ System testing
       ↓                            ↑
Detailed design           ↔ Integration testing
       ↓                            ↑
       Implementation and unit testing

The pairings are conceptual rather than a claim that all testing occurs only after coding. Test planning begins alongside requirements and design.

Strengths

The V-model emphasizes traceability, early test design, verification, validation, and measurable completion criteria. It is valuable in aerospace, medical, automotive, industrial control, and public-sector environments where failures may cause serious harm and evidence of compliance is required.

Limitations

Like waterfall, the V-model handles major requirement changes inefficiently. It can become document-heavy and may encourage conformance to a specification instead of continuous discovery of user needs. A complete test plan cannot compensate for an incorrect requirement.

Suitable context

Use the V-model when requirements are sufficiently stable, system failure has significant consequences, interfaces require formal coordination, and independent reviews or regulatory evidence are important. It can be combined with prototyping or iterative engineering for uncertain subsystems.

4. Iterative and Incremental Development

Iterative and incremental development are related but distinct.

• Iterative development improves the solution through repeated cycles. Each cycle revisits understanding, design, implementation, and evaluation.
• Incremental development delivers the system in functional portions. Each increment adds capability to the product.

A project may be iterative without releasing every iteration, incremental without substantially revisiting earlier decisions, or both iterative and incremental.

A typical cycle is:

Plan → Analyse/design → Build → Test → Demonstrate/evaluate → Replan
          ↑_______________________________________________↓

Assumptions

These approaches assume that useful feedback can be obtained during development, the architecture can support staged growth, and priorities can be managed over time. They are especially appropriate when requirements are expected to evolve or when early delivery has business value.

Strengths

Benefits include earlier validation, visible progress, risk discovery before final delivery, and the ability to prioritize high-value features. Stakeholders can change priorities in response to evidence. A technically difficult feature can be investigated early rather than left as a late surprise.

Limitations and risks

Incremental delivery can produce architectural erosion if each feature is added locally without design stewardship. Teams may also optimize for visible features while neglecting security, performance, maintainability, documentation, and technical debt. Iteration does not automatically mean agility: a team can repeat ineffective work without learning.

Each increment should have explicit acceptance criteria, regression testing, integration controls, and a definition of what “done” means. The product architecture must be intentionally evolved.

5. Prototyping Model

A prototype is an experimental version of a system or part of a system. It may be:

• Throwaway: built to learn and then discarded.
• Evolutionary: progressively refined into the operational product.
• Horizontal: broad but shallow, showing many interfaces with limited internal functionality.
• Vertical: narrow but deep, implementing one feature through the full technology stack.

Prototypes are valuable when requirements are unclear, user interaction is important, or technical feasibility is uncertain.

Strengths

Users can react to something concrete rather than abstract descriptions. Prototyping exposes ambiguous terminology, usability problems, missing rules, integration challenges, and unrealistic expectations. It is particularly effective for web interfaces, mobile applications, dashboards, and workflow systems.

Risks

Stakeholders may mistake a prototype for a production-ready system. A prototype often has weak security, performance, error handling, accessibility, and maintainability. If an exploratory prototype is converted directly into the final product, temporary shortcuts can become permanent defects. The team must label prototypes clearly and define whether the code will be discarded or engineered further.

6. Rapid Application Development (RAD)

RAD emphasizes rapid construction through time-boxed development, intensive user involvement, reusable components, visual tools, prototyping, and parallel work where feasible. A common RAD sequence includes requirements planning, user design workshops, construction, and cutover.

Assumptions

RAD assumes that users can participate regularly, the system can be modularized, development tools and reusable components are available, and decisions can be made quickly. It is most suitable for information systems with well-understood business processes and moderate technical complexity.

Strengths

RAD can reduce delivery time, improve usability through frequent workshops, and produce visible results quickly. It is effective where business rules and interfaces can be explored collaboratively.

Limitations

RAD is less suitable for large, tightly coupled, safety-critical, or highly performance-sensitive systems. Speed may encourage insufficient architecture, testing, documentation, security review, or stakeholder representation. It can also exclude users who cannot attend frequent workshops. Rapid delivery is not the same as responsible delivery.

7. Spiral Model

The spiral model organizes development into repeated cycles driven by risk analysis. Each cycle generally includes:

1. Establish objectives, alternatives, and constraints.
2. Identify and analyse risks.
3. Develop and verify the next-level product.
4. Review results and plan the next cycle.

The model is often represented as a spiral because each loop increases the maturity and scope of the system. Prototypes, simulations, experiments, and architectural proofs may be used to reduce uncertainty.

Assumptions

The spiral model assumes that major risks can be identified and analysed, stakeholders can review decisions, and the project can afford specialist risk-management effort. It is designed for situations where uncertainty and consequences are high.

Strengths

Spiral development makes risk a first-class planning concern. It supports progressive commitment: the organization invests more only after learning enough about feasibility, cost, and risk. It combines the feedback advantages of iterative development with explicit management control.

Limitations

Risk analysis is difficult and can be subjective. The model may be too complex for a small, low-risk project. If risk reviews are superficial, the process becomes an expensive repetition of generic iterations. Spiral projects require experienced managers and engineers who can distinguish significant risks from minor issues.

8. Unified Process

The Unified Process is an iterative, architecture-centred, use-case-driven framework. Its four commonly named phases are:

• Inception: establish scope, business case, stakeholders, and feasibility.
• Elaboration: refine requirements, address major risks, and establish the architectural baseline.
• Construction: build and test the product through iterations.
• Transition: release, train users, correct deployment defects, and move into operation.

Each phase may contain several iterations and disciplines, such as requirements, analysis and design, implementation, testing, configuration management, and project management. Rational Unified Process (RUP) is a detailed process framework associated historically with this family, but organizations commonly tailor Unified Process ideas rather than adopt every prescribed artifact.

Strengths

Unified Process integrates iterative delivery, use cases, architecture, risk management, configuration management, and disciplined documentation. It is suitable for medium-to-large systems where architecture and governance matter but requirements cannot be frozen at the beginning.

Limitations

It can become bureaucratic if every role, artifact, and workflow is applied without tailoring. Its benefits depend on competent architecture, realistic iteration planning, and active stakeholder participation. It is a framework, not a guarantee of successful teamwork.

9. Comparative Evaluation

The labels are not mutually exclusive. A project may use a V-model for regulatory evidence, prototypes for user-interface discovery, incremental releases for business delivery, and iterative risk reduction for technically uncertain components.

10. Selecting a Model

Model selection should begin with project characteristics rather than organizational fashion. Useful questions include:

1. How stable and complete are the requirements?
2. How costly would failure be?
3. How much technical uncertainty exists?
4. How frequently can users provide feedback?
5. Is early partial delivery valuable?
6. Are formal approvals, audits, or safety cases required?
7. Can the architecture support increments and change?
8. What skills, tools, budget, and time are available?
9. How will security, privacy, accessibility, and performance be verified?

A decision should also consider the product’s lifetime. A fast initial release may be a poor choice if maintenance, integration, and regulatory costs dominate total ownership.

A practical selection approach

First, classify uncertainty into requirements uncertainty, technical uncertainty, organizational uncertainty, and external uncertainty. Next, identify consequences of failure and mandatory governance. Then choose a baseline model and deliberately add practices that address weaknesses. For example, a sequential project can add prototypes and early test design; an iterative project can add architecture reviews, compliance traceability, and release gates.

11. Applied Case: University Student Advising System

Background

This illustrative case concerns a university planning a system that allows students to view degree requirements, receive alerts, book advisers, and obtain approval for module selections. The system must exchange data with an existing student-record system and must protect personal information.

Problem analysis

Some requirements are stable: users must authenticate, records must be protected, and approved module choices must be auditable. Other requirements are uncertain: students and advisers disagree about preferred workflows, and the legacy integration has undocumented limitations. Usability and privacy risks are significant, but the system is not a safety-critical control system.

A pure waterfall approach would document all workflows before users could try them. This creates a risk that the documented process will reflect assumptions rather than actual advising practice. A pure RAD approach could deliver screens quickly but might neglect integration reliability, authorization, and auditability.

Approach

The project adopts a tailored hybrid:

• Inception uses Unified Process practices to define scope, stakeholders, and governance.
• A throwaway prototype explores student and adviser workflows.
• An early technical spike tests integration with the legacy record system.
• Elaboration establishes an architecture, privacy controls, and an audit design.
• Incremental iterations deliver authentication and viewing first, followed by booking, recommendations, and approvals.
• V-model-style traceability links privacy and access-control requirements to verification tests.
• Each iteration includes demonstrations, usability evaluation, regression testing, and security review.

Outcome

The prototype reveals that students need a simple “what can I take next?” view rather than a copy of the complex administrative data model. The integration experiment discovers that updates are delayed, so the interface is redesigned to display the time of the last synchronization. Incremental delivery allows a pilot with advisers before institution-wide deployment.

Learning points

The case demonstrates that model selection is a design decision, not a competition between labels. Stable compliance obligations benefit from formal control; uncertain interaction design benefits from prototyping; technical uncertainty benefits from experiments; and business value benefits from incremental delivery.

12. Professional, Ethical, and Governance Considerations

Process models influence who has authority and whose feedback is heard. A process that consults only managers may produce a technically compliant but socially unsuitable system. Inclusive stakeholder analysis should consider users with disabilities, different levels of digital literacy, language needs, and unequal access to technology.

Security and privacy must not be postponed until deployment. Requirements should address least privilege, authentication, authorization, secure data handling, logging, retention, and incident response. Where personal or sensitive data is processed, the project should follow applicable privacy law and institutional policy.

Accessibility should be designed and tested throughout the lifecycle rather than treated as a final cosmetic check. Similarly, AI-assisted coding and requirements tools can accelerate work but introduce risks involving confidential data, licensing, hallucinated requirements, insecure code, bias, and unclear accountability. Human review, approved tools, traceability, and testing remain necessary.

13. Contemporary Practice and Best Practices

Modern organizations often use a tailored lifecycle that combines model elements. Continuous integration, automated testing, infrastructure automation, observability, and continuous delivery make frequent feedback technically practical. DevOps extends lifecycle responsibility across development and operations, while product-oriented approaches connect delivery to measurable user outcomes.

Regardless of the named model, effective practice includes:

• defining outcomes and acceptance criteria;
• involving real users and affected stakeholders;
• addressing high-risk assumptions early;
• maintaining a coherent architecture;
• integrating and testing frequently;
• controlling versions and changes;
• measuring quality, not only activity;
• documenting decisions at an appropriate level;
• protecting security, privacy, and accessibility;
• reviewing and improving the process itself.

A useful process is neither maximally rigid nor maximally flexible. It is sufficiently controlled to protect quality and sufficiently adaptive to learn.

Chapter Summary

SDLC models are theories about how software work, learning, control, and change should be organized. Waterfall provides sequential structure and is appropriate when requirements and technology are stable. The V-model strengthens waterfall with explicit links between development activities and corresponding verification and validation activities.

Iterative development uses repeated cycles of learning and refinement, while incremental development delivers capability in stages. Prototyping is especially useful for discovering requirements and evaluating user interaction, but prototypes must not be confused with production systems. RAD emphasizes rapid, collaborative construction and is effective for modular business applications, although speed can weaken architecture and quality. The spiral model places risk analysis at the centre of each cycle and is valuable for complex, high-risk work. Unified Process combines iterative development, architecture, use cases, risk management, and structured phases.

Model selection should consider requirements stability, technical uncertainty, failure consequences, stakeholder access, regulatory obligations, architecture, delivery priorities, and team capability. In professional practice, hybrid and tailored approaches are common. The central principle is to obtain useful feedback early while applying enough governance to ensure security, quality, maintainability, and accountability.

Key Terms

SDLC: The organized lifecycle of planning, developing, deploying, operating, and retiring software.

Process model: A structured representation of software activities, relationships, controls, and work products.

Waterfall model: A predominantly sequential lifecycle model based on completing phases in order.

V-model: A lifecycle model that pairs development activities with corresponding testing and evaluation activities.

Verification: Checking whether a product conforms to specified requirements and design.

Validation: Checking whether a product satisfies actual stakeholder and business needs.

Iteration: A repeated development cycle used to learn, refine, and improve a solution.

Increment: A delivered portion of a system that adds usable capability.

Prototype: An experimental version used to explore requirements, design, usability, or feasibility.

Throwaway prototype: A prototype intended to provide learning and then be discarded.

Evolutionary prototype: A prototype progressively developed toward the final product.

RAD: Rapid Application Development, emphasizing time boxes, user workshops, reuse, and fast construction.

Spiral model: A risk-driven iterative model in which each cycle identifies and addresses important risks.

Unified Process: An iterative, architecture-centred, use-case-driven process framework.

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

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

Regression testing: Testing performed to detect unintended effects of changes.

Stakeholder: A person or organization affected by, involved in, or able to influence the system.

Tailoring: Deliberately adapting a process model to project circumstances.

Governance: The structures, policies, decisions, and controls used to direct and oversee software work.

Review Questions

Short Answer Questions

1. What is the main assumption underlying the waterfall model?
2. How does the V-model relate development activities to testing?
3. Distinguish iterative development from incremental development.
4. State two risks associated with using prototypes.
5. Why is risk analysis central to the spiral model?

Long Answer Questions

1. Compare the strengths and limitations of waterfall and iterative development.
2. Explain how the V-model can support regulated or safety-critical software projects.
3. Describe the phases and major characteristics of the Unified Process.
4. Discuss the conditions under which RAD is appropriate and the conditions under which it is unsuitable.
5. Explain why organizations often combine elements of several SDLC models.

Analytical / Application Questions

1. A bank is replacing a transaction system subject to strict audit and security requirements. Requirements are mostly stable, but the legacy integration is uncertain. Recommend a lifecycle approach and justify which model elements you would combine.
2. A start-up is developing a novel mobile service, but users cannot clearly describe the required workflow. Compare prototyping, RAD, and incremental development for this project and recommend an approach.
3. A project delivers features every two weeks, but defects and architectural inconsistencies are increasing. Analyse the process weaknesses and propose controls that preserve feedback while improving quality.

Multiple Choice Questions with Answers

Question 1

Which assumption most closely characterizes the waterfall model?

A. Requirements can be substantially understood and baselined before construction.

B. All requirements must remain unknown until deployment.

C. Every feature must be released daily.

D. Risk analysis is the only required engineering activity.

Correct Answer: A. Requirements can be substantially understood and baselined before construction.

Question 2

What is the principal emphasis of the V-model?

A. Eliminating all project documentation

B. Pairing development activities with corresponding verification and validation activities

C. Delivering software without formal testing

D. Replacing requirements with prototypes

Correct Answer: B. Pairing development activities with corresponding verification and validation activities

Question 3

Which statement correctly distinguishes iterative and incremental development?

A. Iteration means adding hardware, while increment means removing software.

B. Iteration repeats learning and refinement, while an increment adds delivered capability.

C. Iteration is only for testing, while increments are only for documentation.

D. There is no meaningful distinction between the terms.

Correct Answer: B. Iteration repeats learning and refinement, while an increment adds delivered capability.

Question 4

A team builds a clickable interface to discover whether users understand a proposed workflow. What is this primarily an example of?

A. Prototyping

B. Configuration management

C. Regression testing

D. Deployment automation

Correct Answer: A. Prototyping

Question 5

Which characteristic is most strongly associated with RAD?

A. Long periods without stakeholder contact

B. Time-boxed construction, user workshops, and reuse

C. A complete prohibition on prototypes

D. Risk analysis performed only after deployment

Correct Answer: B. Time-boxed construction, user workshops, and reuse

Question 6

What guides the sequence of work in the spiral model?

A. The alphabetical order of requirements

B. Explicit identification and reduction of significant risks

C. The number of programming languages used

D. The age of the project manager

Correct Answer: B. Explicit identification and reduction of significant risks

Question 7

Which phase of the Unified Process primarily establishes the architectural baseline and addresses major risks?

A. Inception

B. Elaboration

C. Construction

D. Transition

Correct Answer: B. Elaboration

Question 8

Which is a major risk of converting a throwaway prototype directly into production software?

A. The prototype may contain weak security, performance, and maintainability qualities.

B. Users will receive too much formal traceability.

C. The system will necessarily become safety-critical.

D. Requirements will become impossible to discuss.

Correct Answer: A. The prototype may contain weak security, performance, and maintainability qualities.

Question 9

A project has stable regulatory requirements but uncertain user workflows. Which approach is most appropriate?

A. Use only an unstructured process with no testing.

B. Combine formal traceability with prototyping and iterative user evaluation.

C. Freeze all interface decisions without user feedback.

D. Avoid architecture until after release.

Correct Answer: B. Combine formal traceability with prototyping and iterative user evaluation.

Question 10

Which practice best reduces the risk of architectural fragmentation during incremental development?

A. Adding each feature without reviewing existing design

B. Maintaining architecture stewardship, integration controls, and regression testing

C. Deferring all testing until the final increment

D. Allowing every developer to use unrelated interfaces

Correct Answer: B. Maintaining architecture stewardship, integration controls, and regression testing