Chapter 2 – Software Development Life Cycle (SDLC) Models

Lesson 1: Waterfall Model – Stages, Advantages and Disadvantages

1. Lesson Overview

The Waterfall model is one of the earliest and most traditional approaches to software
development. It is a linear, sequential model in which each phase must be completed before the
next one begins. Although many organisations now favour agile approaches, the Waterfall model
remains important because it is still used in certain types of projects and forms the conceptual
foundation for understanding SDLC in general.

This lesson explains:

• What the Waterfall model is

• The main stages of the Waterfall model
• The advantages (pros) of the model
• The disadvantages (cons) of the model
• When the Waterfall model is appropriate and when it is risky

2. Brief Reminder: What is an SDLC Model?

A Software Development Life Cycle (SDLC) model describes the structured process followed
to build, deliver, and maintain software.

It answers questions such as:

• In what order do activities (requirements, design, coding, testing, deployment,

maintenance) happen?
• How do we manage time, cost, and quality?
• How do the stakeholders (clients, users, developers, testers, managers) interact at each
stage?

The Waterfall model is one specific way of organising these activities in a step-by-step manner.

3. Concept of the Waterfall Model

The Waterfall model is called "Waterfall" because the process flows downwards through a
series of phases, similar to water cascading over a series of steps. Once the development team
completes a phase and moves to the next, they are not expected to move backwards, except in
rare and usually costly situations.

Key characteristics:

• Sequential: Phases are executed one after another.

 • Document-driven: Each phase produces formal documents (e.g., requirements
specification, design documents).
• Plan-driven: Extensive planning and estimation are done at the beginning of the project.
• Low flexibility: Changes later in the process are difficult and expensive to handle.

4. Stages of the Waterfall Model

Different sources sometimes label the stages slightly differently, but the typical phases are:

1. Requirements Analysis
2. System and Software Design
3. Implementation (Coding)
4. Integration and Testing
5. Deployment (Installation)
6. Maintenance

We go through each in more detail.

4.1 Requirements Analysis

Purpose:
To understand and document what the customer or end-users need the software to do.

Activities:

• Meeting with stakeholders (clients, end-users, managers, domain experts).

• Collecting functional and non-functional requirements.
• Analysing feasibility (technical, economic, legal, operational).
• Producing a Software Requirements Specification (SRS) document that describes the
system’s expected behaviour, constraints, and interfaces.

Outputs:

• Approved SRS document

• Initial project scope, constraints, and assumptions

In the Waterfall model, once the requirements are “frozen”, changes are discouraged because all
later stages depend directly on this document.

4.2 System and Software Design

Purpose:
To translate the requirements into a technical solution that can be implemented.

Activities:
 • High-level design (HLD):
o Define the system architecture.
o Identify main modules, subsystems, databases, interfaces, and external
components.
• Low-level design (LLD):
o Specify detailed logic for each module or component.
o Design data structures, algorithms, and interface details.

Outputs:

• Design specifications (e.g., architectural diagrams, database schemas, interface designs)

• Technology choices (programming languages, frameworks, hardware requirements)

The success of later coding and testing phases depends heavily on the clarity and completeness
of the design.

4.3 Implementation (Coding)

Purpose:
To convert the design into working source code.

Activities:

• Assign modules to developers or development teams.

• Write code according to coding standards and design specifications.
• Perform unit testing on individual components to check basic correctness.

Outputs:

• Source code for all modules

• Unit test results

In the Waterfall model, coding begins only after the design phase is formally completed and
approved.

4.4 Integration and Testing

Purpose:
To combine all implemented modules and verify that the complete system functions correctly
and meets the specified requirements.

Activities:

• Integrate modules into a complete system.

• Perform different levels of testing:
o Integration testing – Do modules interact correctly?
 oSystem testing – Does the entire system work as a whole?
oAcceptance testing – Does the system satisfy user requirements and
expectations?
• Identify and fix defects (bugs).

Outputs:

• Tested software ready for delivery

• Test reports and defect logs

In the Waterfall approach, system-level testing is often concentrated near the end of the project,
which can be risky if major problems are discovered late.

4.5 Deployment (Installation)

Purpose:
To deliver the finished software product to the customer or users and make it operational in the
real environment.

Activities:

• Install software on client machines, servers, or cloud infrastructure.

• Configure necessary environments (databases, networks, security settings).
• Provide user training and documentation (user manuals, technical manuals).
• Obtain formal sign-off from the client.

Outputs:

• Running system in the production environment

• Trained users and support staff

Deployment in the Waterfall model typically happens once, after testing confirms that the system
is acceptable.

4.6 Maintenance

Purpose:
To correct problems discovered after deployment and to adapt the system to new requirements or
changes in the environment.

Types of maintenance:

• Corrective maintenance: Fixing bugs that were not discovered during testing.
• Adaptive maintenance: Modifying the system to work in a new environment (new
hardware, operating system, or regulations).
• Perfective maintenance: Enhancing performance or improving usability.
 • Preventive maintenance: Refactoring or improving the code to prevent future issues.

Outputs:

• Updated versions of the software

• Maintenance reports

In the Waterfall model, maintenance is considered a separate phase that continues for as long as
the system is in use.

5. Advantages of the Waterfall Model

Despite its age, the Waterfall model has clear strengths, especially for certain categories of
projects.

1. Simple and Easy to Understand

o The linear structure is straightforward.
o Students and new professionals can easily grasp the sequence of phases.
2. Well-Defined Phases and Deliverables
o Each phase has specific objectives, inputs, and outputs.
o This makes project tracking and management simpler for organisations that prefer
formal processes.
3. Strong Documentation
o Emphasis on detailed documents (SRS, design documents, test plans, etc.).
o Useful for maintenance, handover to new teams, and regulated environments.
4. Good for Stable and Well-Understood Requirements
o Works well when the requirements are clear, complete, and unlikely to change,
for example in:
 Certain government or defence projects
 Some embedded systems
 Projects with strict regulatory standards
5. Easier to Manage Using Traditional Project Management
o Fits well with classical project management techniques (Gantt charts, milestone
tracking).
o Progress is measured by the completion of phases.

6. Disadvantages of the Waterfall Model

The same features that make the Waterfall model simple also create serious limitations.

1. Poor Handling of Change

o Requirements are “frozen” early.
o Any change after the requirements or design phase can be very costly and
disruptive.
o In practice, users often refine or change their needs after seeing early versions of
the system, which Waterfall does not support well.
 2. Late Discovery of Problems
o Working software is only available after coding and integration.
o If there are fundamental misunderstandings in requirements or design, these may
be discovered very late, during testing, when major rework is expensive.
3. Customer Involvement is Limited After Requirements Phase
o Clients are heavily involved at the beginning (requirements phase) and then at the
end (acceptance testing).
o Long periods without visible progress may cause misalignment with expectations.
4. High Risk for Complex and Long-Term Projects
o For large, innovative, or research-oriented systems, it is difficult to know all
requirements upfront.
o The model assumes that the team can plan everything correctly at the start, which
is often unrealistic.
5. No Overlapping or Iteration Between Phases
o The strict sequential nature does not support feedback loops between phases.
o Learning from later phases cannot easily influence earlier ones.
6. Less Suitable for Modern, Rapidly Changing Environments
o Many current software projects operate in dynamic business environments where
requirements change frequently.
o Agile and iterative models are better suited for such contexts.

7. When is the Waterfall Model Appropriate?

Although many organisations have moved to agile methods, the Waterfall model is still
appropriate in some situations:

• Projects with stable, clearly defined requirements

e.g., rewriting an existing system with minimal changes, or implementing a well-
established standard.
• Projects with strong regulatory or contractual constraints
e.g., defence, aerospace, medical devices, banking systems where full documentation and
formal approvals are required.
• Short, low-uncertainty projects
where the problem is well-understood and the technology is mature.

In contrast, Waterfall is less suitable for:

• Projects with uncertain or evolving requirements.

• Projects that require frequent user feedback and continuous improvement.
• Highly innovative or exploratory projects.

Lesson 2: Agile Methodology – Principles and Frameworks (Scrum, Kanban)

1. Introduction to Agile Methodology

Agile is a family of software development approaches that emphasise flexibility, collaboration,
and rapid delivery of working software. Unlike traditional plan-driven models such as
Waterfall, Agile accepts that requirements often change during a project and attempts to respond
to this change instead of resisting it.

Core ideas behind Agile include:

• Delivering value to the customer quickly and frequently

• Working in small, manageable increments rather than one big release at the end
• Encouraging close collaboration between developers, testers, and users
• Welcoming changing requirements, even late in the project

Agile is not a single process or technique; it is a mindset supported by various frameworks, the
most popular of which include Scrum and Kanban.

2. Agile Values and Principles

Agile grew from dissatisfaction with rigid, document-heavy approaches that struggled in fast-
changing environments. The Agile movement is guided by a set of values and principles that
shape how teams plan, build, and deliver software.

2.1 Key Agile Values

Commonly cited Agile values include:

1. Individuals and interactions over processes and tools

The skills, communication, and collaboration of people are more important than strict
adherence to rigid procedures.
2. Working software over comprehensive documentation
Documentation is still important, but the main measure of progress is software that
actually works and can be used.
3. Customer collaboration over contract negotiation
Instead of treating the contract as a fixed checklist, Agile teams work continuously with
customers to refine what is needed.
4. Responding to change over following a plan
Planning is useful, but the team must be able to change direction when new information
appears.

These values do not reject processes, documentation, contracts, or plans; they simply place
greater weight on people, working systems, collaboration, and adaptability.

2.2 Core Agile Principles (Summarised)

From these values, several practical principles follow. They can be grouped into a few themes:

1. Customer Focus and Continuous Delivery

 o Satisfy the customer through early and continuous delivery of valuable software.
o Deliver working software frequently (for example, every 1–4 weeks).
2. Embracing Change
o Welcome changing requirements, even late in development, if they increase the
customer’s competitive advantage.
o Use short cycles (iterations) so that feedback can quickly influence upcoming
work.
3. Collaboration and Communication
o Business people and developers should work together daily.
o Face-to-face communication is encouraged as the most effective method of
conveying information.
4. Technical Excellence and Good Design
o Continuous attention to technical quality and good design enhances agility.
o Simplicity is valued: focusing on the most essential features first.
5. Self-Organising Teams
o Teams should be trusted to organise their own work.
o The best architectures and designs often emerge from teams who understand their
context and have autonomy.
6. Inspection, Adaptation, and Reflection
o Teams regularly reflect on how to become more effective and then adjust their
behaviour and processes accordingly.
o Metrics, feedback, and retrospectives support continuous improvement.

These principles are operationalised through specific frameworks such as Scrum and Kanban,
which provide concrete structures, roles, and practices.

3. Scrum Framework

Scrum is one of the most widely used Agile frameworks. It organises work into short, fixed-
length cycles called sprints, typically lasting between one and four weeks. The goal of each
sprint is to produce a potentially shippable increment of the product.

Scrum provides:

• Clearly defined roles

• A regular set of events (ceremonies)
• Key artifacts that help manage work and transparency

3.1 Scrum Roles

1. Product Owner (PO)

o Represents the customer or business.
o Responsible for defining and prioritising what should be built.
o Manages the Product Backlog (the ordered list of features, enhancements, and
fixes).
o Ensures that the team works on the most valuable items first.
 2. Scrum Master
o Serves as a facilitator and coach for the Scrum team.
o Ensures that Scrum practices are understood and correctly applied.
o Removes obstacles (impediments) that block the team’s progress.
o Protects the team from unnecessary interruptions.
3. Development Team (or Scrum Team Members)
o Cross-functional group that actually builds the product (developers, testers,
designers, etc.).
o Typically small (often 5–9 members).
o Self-organising: they decide internally how to perform the work.
o Jointly responsible for delivering the sprint goal.

3.2 Scrum Artifacts

1. Product Backlog
o A prioritised list of everything that might be needed in the product.
o Items in the backlog are often written as user stories (e.g., “As a student, I want to
register online so that I can…”)
o Continuously refined and re-ordered as new information emerges.
2. Sprint Backlog
o Subset of Product Backlog items that the team commits to completing in a given
sprint.
o Includes the sprint goal and the tasks needed to finish the selected items.
3. Increment
o The sum of all completed Product Backlog items at the end of a sprint.
o Should be in a usable, potentially releasable state, even if the organisation decides
not to release it immediately.

3.3 Scrum Events (Ceremonies)

1. Sprint
o The fixed time-box during which the team works to achieve a specific goal.
o Typically 1–4 weeks, and the length is consistent across sprints once chosen.
2. Sprint Planning
o Held at the start of each sprint.
o The Product Owner presents the highest-priority items from the Product Backlog.
o The team discusses these items and decides what it can realistically complete.
o Output: a Sprint Backlog and a clear sprint goal.
3. Daily Scrum (Daily Stand-up)
o Short meeting (often 15 minutes) held every day of the sprint.
o Team members briefly state what they did yesterday, what they will do today, and
any impediments.
o Helps coordinate work and highlight issues early.
4. Sprint Review
o Held at the end of the sprint.
o The team demonstrates the completed work to stakeholders.
 o Stakeholders provide feedback, which can lead to new or modified backlog items.
5. Sprint Retrospective
o Also held at the end of the sprint, after the review.
o The Scrum team reflects on the process: what went well, what did not, and what
could be improved.
o Action points for improvement are identified for the next sprint.

3.4 How Scrum Supports Agile Principles

• Short sprints enable frequent delivery of working software.

• Regular interaction with the Product Owner and stakeholders ensures customer
collaboration.
• The Sprint Review and Retrospective create a cycle of inspection and adaptation.
• A self-organising development team aligns with Agile’s emphasis on team autonomy.

4. Kanban Framework

Kanban is another Agile framework, originally influenced by lean manufacturing. Rather than
working in fixed-length sprints, Kanban focuses on visualising work, limiting work in
progress, and optimising flow.

Kanban is particularly suitable when work arrives in an irregular, continuous stream and when
teams need flexibility rather than time-boxed iterations.

4.1 Core Practices of Kanban

1. Visualise the Workflow

o Work is displayed on a Kanban board divided into columns representing stages
of the process, such as:
 “To Do” → “In Progress” → “Testing” → “Done”
o Each task is represented by a card that moves across the board as work
progresses.
o This makes the status of work highly visible to the entire team.
2. Limit Work in Progress (WIP)
o Each column or stage has a maximum number of tasks allowed at the same time
(the WIP limit).
o For example, the “In Progress” column may have a WIP limit of 3 tasks.
o If the limit is reached, no new task is started until one is finished.
o This helps avoid overloading the team and encourages completion of tasks.
3. Manage and Improve Flow
o The team monitors how long tasks take to move through the system and identifies
bottlenecks (e.g., too many tasks stuck in “Testing”).
o Changes are made to improve the flow of work and reduce delays.
4. Make Process Policies Explicit
o The rules for moving tasks between columns, WIP limits, and definitions of
“Done” are clearly stated and agreed upon.
 oThis creates clarity and shared understanding.
5. Feedback and Continuous Improvement
o Teams hold regular meetings to review performance metrics, discuss problems,
and propose improvements.
o Short daily check-ins are common, similar in spirit to the Daily Scrum, but less
formalised.

4.2 Typical Kanban Board Layout

A simple Kanban board might include:

• Backlog – Ideas or tasks not yet selected.

• To Do – Tasks selected and ready to start.
• In Progress – Tasks currently being worked on (with a WIP limit).
• Testing / Review – Tasks undergoing quality checks.
• Done – Completed tasks.

More complex boards can include additional stages (e.g., “Code Review”, “Deploying”), but the
underlying idea remains the same: visualise the process and control work in progress.

4.3 How Kanban Supports Agile Principles

• Visual boards and regular discussions encourage collaboration and transparency.

• WIP limits and flow management help teams adapt to changing demands without losing
control.
• Continuous delivery becomes possible because completed tasks can be released whenever
they are ready, rather than waiting for the end of a sprint.
• Ongoing adjustments to the workflow support continuous improvement.

5. Comparing Scrum and Kanban

Both Scrum and Kanban are Agile frameworks, but they differ in how they organise work.

Scrum

• Uses sprints (time-boxed iterations).

• Has defined roles (Product Owner, Scrum Master, Development Team).
• Uses formal events (planning, daily scrum, review, retrospective).
• Scope is fixed during each sprint (though exceptions may be allowed in practice).

Kanban

• Uses continuous flow instead of fixed-length iterations.

• Does not prescribe specific roles; existing organisational roles can be used.
• Focuses on visualising work and limiting WIP; meetings are more flexible.
 • Work items can be added or re-prioritised at any time, as long as WIP limits are
respected.

In practice:

• Teams that need more structure and rhythm often start with Scrum.
• Teams that already have a process but want to improve flow and efficiency may adopt
Kanban.
• Some teams combine elements of both, sometimes referred to as “Scrumban”.

Lesson 3: Iterative and Spiral Models

1. Lesson Focus

This lesson examines two closely related approaches to software development: the Iterative
model and the Spiral model. Both models were developed to address the limitations of strictly
linear processes such as the Waterfall model, especially in situations where requirements are
likely to evolve or are initially uncertain.

The lesson aims to:

• Clarify the concept of iterative development

• Explain the structure and logic of the iterative model
• Present the Spiral model as a risk-driven extension of iterative development
• Highlight the advantages, limitations, and appropriate uses of each model

2. Iterative Development Model

2.1 Basic Idea

The Iterative model is based on the idea of building a system step by step, through a series of
repeated development cycles called iterations. Instead of delivering the entire system at once,
the team develops a partial but working version of the system, then revisits and expands it in
subsequent cycles.

Key ideas include:

• Early delivery of a basic version of the product

• Repeated refinement and extension based on feedback
• Progressive enhancement of functionality and quality

Rather than trying to get everything perfect in a single pass, the team accepts that understanding
will improve over time, and the product will evolve accordingly.

2.2 Structure of an Iteration

Each iteration in the iterative model typically passes through a miniature version of the standard
SDLC phases. A single iteration may include:

1. Planning and Requirements for this Iteration

o Select a subset of requirements to address.
o Clarify goals and constraints for the current cycle.
2. Design
o Design or refine the architecture and components needed for the selected features.
o Adjust previous design decisions if necessary.
3. Implementation (Coding)
o Implement the selected features or improvements.
o Integrate them with the existing system.
4. Testing and Evaluation
o Test the new and modified components.
o Evaluate the iteration’s result with users or stakeholders where possible.
o Identify defects, usability issues, and new insights about requirements.

At the end of each iteration, the team reviews progress and plans the next cycle. Over multiple
iterations, the system matures into a more complete and stable product.

2.3 Characteristics of the Iterative Model

• Incremental growth: Each iteration adds more functionality or improves existing

features.
• Feedback-driven: User or stakeholder feedback after each iteration influences the next
cycle.
• Flexibility: Requirements can be refined, re-prioritised, or even dropped between
iterations.
• Learning-oriented: The team gains better understanding of both the technical aspects
and the users’ needs as the project unfolds.

The iterative model is sometimes combined with incremental ideas: the system is built in
increments, and each increment is developed iteratively.

2.4 Advantages of the Iterative Model

1. Early Visibility of the Product

A basic working version can be shown to users relatively early, which increases
confidence and allows for meaningful feedback.
2. Better Requirement Refinement
Requirements that were initially vague or uncertain can be clarified as users interact with
early versions of the system.
3. Reduced Risk of Total Failure
Problems are detected and addressed early, rather than being discovered only at the end
of a long, single-pass process.
 4. Continuous Improvement
The quality of the system can be improved iteratively through refactoring, redesign, and
repeated testing.
5. More Responsive to Change
Between iterations, the team can change priorities or adjust the scope to respond to new
circumstances or constraints.

2.5 Limitations of the Iterative Model

1. Complexity of Planning and Management

Managing multiple iterations, each with its own goals and deliverables, requires
disciplined planning and coordination.
2. Risk of Poor Architecture if Not Carefully Managed
If early iterations are rushed or poorly designed, the system architecture may become
fragile, making later changes more expensive.
3. Potential for Scope Creep
Flexibility in changing requirements can lead to uncontrolled growth in scope if there is
no clear vision or strong product management.
4. Need for Continuous User Involvement
To benefit fully from the model, users and stakeholders must be available to provide
feedback regularly, which may not always be realistic.

2.6 Suitable Contexts for Iterative Development

The iterative model is particularly appropriate when:

• Requirements are not fully understood at the beginning.

• Users can provide regular feedback and are willing to participate actively.
• There is a need to show progress early and maintain stakeholder confidence.
• The problem domain is complex, and learning through experimentation is necessary.

3. Spiral Model
3.1 Concept and Origin

The Spiral model can be seen as an advanced form of iterative development that explicitly
integrates risk management into each cycle. It is often associated with large, complex, and
high-risk projects where failure would be very costly.

The model is visualised as a spiral that starts at the centre and moves outward through
successive loops. Each loop represents one phase of the project and includes activities related to
planning, risk analysis, engineering, and evaluation.

The core idea is that the team should regularly:

 • Identify and analyse risks
• Take specific actions to reduce those risks
• Review the outcomes before moving further outward into more detailed development

3.2 Structure of the Spiral

Each loop (or cycle) of the spiral is usually divided into four main quadrants:

1. Determine Objectives, Alternatives, and Constraints

o Define the goals for this cycle (e.g., clarify certain requirements, design a
subsystem, build a prototype).
o Identify alternative solutions or approaches.
o Recognise constraints such as budget, schedule, technology, and regulations.
2. Identify and Resolve Risks
o Analyse risks associated with each alternative (technical risks, cost risks, schedule
risks, safety risks, and so on).
o Decide how to reduce or manage these risks.
o Common strategies include building prototypes, conducting simulations, or
performing additional research.
3. Develop and Verify the Product for this Cycle
o Carry out the planned engineering tasks: design, coding, integration, and testing
of the chosen solution.
o The concrete output depends on the cycle’s objectives (it could be a prototype, a
component, or a more complete version of the system).
4. Plan the Next Cycle
o Evaluate the results of the current cycle with stakeholders.
o Decide whether to continue the project, stop it, or change direction.
o Plan the objectives, risk analysis, and work for the next loop of the spiral.

As the spiral expands outward, the project moves from high-level concept and feasibility
questions toward more detailed design, implementation, and deployment activities.

3.3 Risk-Driven Nature of the Spiral Model

The defining feature of the Spiral model is that risk analysis and risk mitigation are central,
not optional.

Types of risk that may be considered:

• Technical risks (e.g., uncertainty about whether a technology will work at scale)
• Cost and schedule risks
• Operational risks (e.g., performance issues, integration difficulties)
• Safety, security, or regulatory risks

By addressing the most critical risks early in the project, the Spiral model attempts to:
 • Avoid investing heavily in a direction that later turns out to be infeasible
• Improve the quality and reliability of the system
• Give stakeholders better information about the project’s viability

In extreme cases, a cycle of the spiral may lead to the decision to cancel the project if the risks
are judged too high or unmanageable. This is also considered a successful outcome, because it
prevents the organisation from wasting further resources.

3.4 Advantages of the Spiral Model

1. Explicit Risk Management

The model systematically forces the team to think about and address major risks at every
cycle.
2. Flexibility and Iterative Refinement
Like other iterative approaches, the Spiral model allows requirements and designs to
evolve over time.
3. Early Detection of Critical Problems
High-risk issues are investigated early, often through prototypes or experiments.
4. Stakeholder Involvement
Stakeholders are engaged in reviewing objectives, risks, and results at each loop, which
promotes informed decision-making.
5. Scalability to Large and Complex Projects
The model was designed with large-scale, mission-critical systems in mind, where a
purely linear process would be too risky.

3.5 Limitations of the Spiral Model

1. High Management and Expertise Requirements

Effective risk identification and analysis demand experienced personnel. If risks are
misjudged, the benefits of the model are reduced.
2. Complexity and Overhead
The process is more complex than simple iterative or incremental models, and it may
introduce significant administrative overhead.
3. Potentially High Cost
Prototyping and repeated risk analysis can increase early costs, although they may reduce
long-term losses.
4. Less Suitable for Small, Low-Risk Projects
For small applications with clear, stable requirements, the formal structure of the Spiral
model may be unnecessary and inefficient.

3.6 Suitable Contexts for the Spiral Model

The Spiral model is particularly appropriate when:

• The project is large, complex, and high-risk.

• New or unproven technologies are involved.
 • Safety, security, or regulatory compliance is critical.
• Management is willing to invest in systematic risk analysis and sophisticated planning.

Examples might include large defence systems, aerospace software, or critical infrastructure
systems.

4. Relationship Between Iterative and Spiral Models

Although they are often presented separately, the Iterative and Spiral models share important
similarities:

• Both rely on repeated development cycles rather than a single pass.

• Both allow for progressive refinement of requirements, design, and implementation.
• Both aim to reduce the risk of late discovery of major problems.

However, they differ in emphasis:

• The Iterative model primarily emphasises repeated development and feedback. Risk
management may be present, but it is not necessarily the central organising principle.
• The Spiral model explicitly organises each cycle around risk identification and
mitigation, using prototypes and experiments as tools to reduce uncertainty before
moving forward.

In many modern practices, elements from both models are combined. For example, teams may
run iterations or releases and, within each one, devote explicit attention to identifying and
managing key risks.

Lesson 4: Choosing the Right SDLC Model Based on Project Needs

1. Lesson Focus

By this stage, the main SDLC models have already been introduced:

• Waterfall
• Agile (with frameworks such as Scrum and Kanban)
• Iterative
• Spiral

This lesson brings them together and addresses a practical question:

“Given a specific project, how do we decide which SDLC model is most appropriate?”

There is no single “best” model for all situations. Each model reflects a particular way of
thinking about planning, risk, flexibility, documentation, and customer involvement. Good
software engineers are therefore expected not only to know these models in theory but also to
justify their choice in a given context.
2. Key Factors That Influence the Choice of SDLC Model

When selecting an SDLC model, it is helpful to consider a structured set of questions about the
project and its environment. The following factors are particularly important.

2.1 Clarity and Stability of Requirements

• Are the requirements well-understood and unlikely to change?

• Or are they uncertain, evolving, or dependent on user feedback?

Implications:

• Stable, well-defined requirements favour more plan-driven models such as Waterfall.

• Vague or changing requirements point towards Agile, Iterative, or Spiral approaches
that can accommodate learning and change.

2.2 Project Size and Complexity

• Is the project small and relatively simple, or is it large-scale, multi-team, and

technically complex?

Implications:

• Small to medium, low-complexity projects may successfully use Waterfall or light

Iterative approaches.
• Large, complex systems—especially those involving many components and
dependencies—often benefit from Iterative, Agile at scale, or Spiral models, which
allow risk management and progressive refinement.

2.3 Risk Level and Criticality

• What is at stake if the system fails?

• Are there significant technical, safety, security, or financial risks?

Implications:

• High-risk projects (e.g. defence, aerospace, safety-critical systems) are better served by
models that explicitly address risk, such as the Spiral model, possibly combined with
phases resembling Waterfall for documentation and verification.
• Lower-risk business applications may be comfortably developed using Agile or Iterative
approaches with simpler risk management practices.

2.4 Regulatory, Legal, or Contractual Constraints

• Is the project subject to strict industry standards, audits, or legal requirements?

 • Does the contract require extensive documentation, formal sign-offs, and fixed
deliverables?

Implications:

• Highly regulated environments (for example, banking, healthcare, public sector

procurement) often expect formal documentation and clear phase boundaries, which
aligns with Waterfall or hybrid models that incorporate Waterfall structure with
iterative or agile elements.
• Projects with fewer formal constraints have more freedom to adopt Agile or purely
Iterative models.

2.5 Level of Customer and User Involvement

• Will the customer or end-users be available and willing to give regular feedback?
• Or will they be present mainly at the beginning and end of the project?

Implications:

• If frequent feedback is possible and desired, Agile methods (e.g. Scrum with regular
reviews) or Iterative development are highly suitable.
• If user access is limited, the team may need to rely more on upfront requirements
gathering, which moves the project closer to Waterfall or a plan-driven iterative
model.

2.6 Time-to-Market and Delivery Expectations

• Is there pressure to deliver something usable very quickly?

• Can the system be released in increments, or must it be delivered as a single, complete
product?

Implications:

• If early partial releases are acceptable, Agile or Iterative/Incremental models are

appropriate.
• If the client expects a single, fully finished system (for example, a one-off replacement of
an existing system), a Waterfall-like approach may be more realistic, sometimes with
internal iterations.

2.7 Team Experience and Organisational Culture

• Does the team have experience with Agile practices, or is the organisation accustomed to
traditional, document-heavy processes?
• Is management comfortable with flexible planning and evolving scope?

Implications:
 • Teams and organisations used to formal, hierarchical processes may initially find
Waterfall or carefully structured Iterative models more manageable.
• Where the culture supports collaboration, self-organisation, and continuous
improvement, Agile methods can thrive.

2.8 Technology and Domain Uncertainty

• Is the project using familiar, proven technologies or experimenting with new, untested
tools and approaches?

Implications:

• High technological uncertainty and innovation favour development models with strong
prototyping and risk analysis, such as Spiral or Iterative with frequent technical spikes
and experiments.
• Stable technologies can work well under Waterfall or Agile, depending on other factors.

3. Matching Models to Project Characteristics

The sections below summarise the type of project for which each model is particularly well
suited.

3.1 Waterfall Model

Best suited when:

• Requirements are clear, stable, and well-documented.

• The project environment demands formal documentation, approvals, and fixed
contracts.
• The organisation prefers a linear, predictable plan with well-defined milestones.
• The technology is well-understood and not experimental.

Typical examples:

• Migration of a well-understood legacy system to a newer platform with minimal

functional changes.
• Government or public sector systems with strict procurement procedures and formal
acceptance tests.

3.2 Agile Methodology (Scrum, Kanban)

Best suited when:

• Requirements are likely to evolve or are initially incomplete.

• The client is available for continuous collaboration and accepts incremental delivery.
 • The team is relatively small to medium-sized and can be cross-functional and self-
organising.
• Early and frequent delivery of working software is a priority.

Typical examples:

• Development of a new mobile application for a start-up where user preferences are not
yet clear.
• Web-based platforms that are expected to change regularly based on analytics and user
feedback.

3.3 Iterative Model

Best suited when:

• The problem domain is complex, and understanding will improve through

experimentation.
• There is a need for early prototypes and partial versions to refine requirements.
• The team wants to benefit from progressive improvement but does not necessarily
follow all Agile ceremonies.

Typical examples:

• Educational or research systems where features are discovered and refined as the project
advances.
• Medium-sized enterprise applications where stakeholders want to see tangible progress
every few months and are willing to review intermediate versions.

3.4 Spiral Model

Best suited when:

• The project is large, expensive, and high-risk.

• Significant technical uncertainty or safety/security risk is present.
• There is a strong need for systematic risk analysis, prototyping, and frequent evaluation
of feasibility.
• Management is prepared to invest in the overhead of risk management at every cycle.

Typical examples:

• Air-traffic control systems or railway signalling software.

• Large-scale defence or aerospace systems integrating hardware, software, and
communications.

4. Illustrative Case Scenarios

The following brief scenarios show how these factors come together in practice.

Scenario 1: University Examination Registration System

• Requirements: Largely stable (registration, fee payment, course selection).

• Risks: Moderate; failure is serious but not life-threatening.
• Regulations: Strong need for audit trails and formal acceptance.
• Customer involvement: Available mainly at key milestones.

Reasonable choice:
A Waterfall or Waterfall with internal iterations could be justified, supported by good
requirement analysis and formal testing.

Scenario 2: Start-Up Building a Social Networking Mobile App

• Requirements: Highly uncertain; features will be adjusted based on user behaviour.

• Risks: Market risk is high; technological risk moderate.
• Regulations: Minimal formal constraints at early stages.
• Customer involvement: Continuous (user feedback, analytics, beta testers).
• Time-to-market: Urgent; early release is essential.

Reasonable choice:
An Agile approach using Scrum (sprints, frequent releases) or Kanban (continuous flow) is
appropriate. The team can ship a minimal viable product (MVP) quickly and refine it through
successive iterations.

Scenario 3: Hospital Patient Monitoring System

• Requirements: Complex and partially evolving.

• Risks: Very high; incorrect functioning may endanger patients.
• Regulations: Strong; must meet health and safety standards.
• Technology: May involve integration with specialised devices.

Reasonable choice:
A Spiral model is attractive because it emphasises risk analysis and prototyping at every
cycle. Certain sub-systems might then be developed using more detailed Waterfall or Iterative
processes once risks are reduced.

Scenario 4: Internal Reporting Dashboard for a Small Company

• Requirements: Clear, limited scope.

• Risks: Low; mainly business convenience.
• Regulations: Minimal.
• Time-to-market: Moderate.
Reasonable choice:
A simplified Iterative or Agile approach can work well, delivering early versions of the
dashboard and gradually adding new reports and visualisations. In some organisations, a small,
disciplined Waterfall project could also suffice.

5. Hybrid and Tailored Approaches

In real organisations, SDLC models are often adapted and combined rather than followed in a
pure form. Examples include:

• “Water-Scrum-Fall”: Requirements and deployment handled in a Waterfall manner

(formal approvals), while development in the middle is done using Scrum sprints.
• Agile with formal gates: Agile teams work iteratively, but management imposes formal
review gates for compliance or budget control.
• Iterative Waterfall: The project is divided into phases or releases, with each release
following a mini-Waterfall.

The key point is that methodology should serve the project, not the other way round. Engineers
and managers should feel responsible for tailoring the process to match the realities of size, risk,
regulation, team skills, and stakeholder needs.