CS/SE/IT1211-Software Engineering

Lecture 02
Software Development Life Cycle Models

BSc (Hons) Computer Science|Software Engineering|Information Technology

Department of Computer Science
Faculty of Computing &
Technology
Saegis Campus
Nugegoda.

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 1

 Content
•Software Process
•SDLC (Software Development Lifecycle)
•Life Cycle Models
•Waterfall Model
•Prototyping Model
•Incremental Model
•Spiral Model

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 2

What is an Engineering Process?

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 3

What is a Software Development Process?

•A set of Activities and Associated

Results that produce a Software.

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 4

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 5
Fundamental Process Activities

1. Software Specification
2. Software Development
3. Software Validation
4. Software Evolution

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 6

1. Software Specification

•Specification involves clearly documenting the expectations on the

system to be built

•Lays out requirements, and may include written and diagrammatic

description of the services that the future system must provide.

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 7

2. Software Development

•Software development involves designing and implementing the

system according to the software specification

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 8

3. Software Validation

•Software validation involves checking and verifying whether the

system fulfills the requirements.

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 9

4. Software Evolution

•Software needs to be changed and upgraded with time.

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 10

What is a SDLC?

•The Software Development Life Cycle

(SDLC) is a framework that defines
activities performed throughout the
software development process.

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 11

Life Cycle Model (Process Model)

•A software life cycle (process) model:

• is a descriptive and diagrammatic model of the life cycle of a software
product;
• identifies all the activities and phases necessary for software
development;
• establishes a precedence ordering among the different activities.

•Life cycle models encourage systematic and disciplined software

development.

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 12

Life Cycle Models
•Traditional Approaches
 Waterfall Model
 Incremental Model
 Prototyping Model
 Spiral Model
 Unified Process

•Modern Approaches
Agile Methods (XP, Scrum)
Secure Software Development

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 13

Software Development
Life Cycle Models

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh)

Waterfall Model

•Waterfall model is the most well known

software lifecycle development model.
•It is very simple to understand and use.

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 15

Waterfall Model

•Each phase begins only after the previous phase is over.

•Also called Linear Model.

•This model specifies what the system is supposed to do (i.e.

define the requirements) before building the system (i.e.
designing)

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 16

1. Feasibility Study

•This is the first phase of any SDLC model.

•The project objective is determined during this phase.
•The client and company developing the software decide if they
should ;
• Keep the existing system as is, or
• Build a new software

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 17

Why do a feasibility study?

•To provide management with enough information to know:

• Whether the project can be done
• Whether the final product will benefit its users
• What the alternative solutions are
• Whether there is a preferred alternative

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 18

Example – Library System

•What are the feasibility criteria for a ‘Library System’?

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 19

2. The Requirements Phase

•Aim: to understand the customer’s requirements:

•A customer may be a single person, a group, a department,
or an entire organization:
•This phase involves two distinct activities:
1. Requirements Gathering and Requirements Analysis
2. Requirements Specification

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 20

2a.1 Requirement Gathering
•The goal of this phase is for the stakeholders to find out the ‘what to
be done’.
•Questions answered during this phase include:
• Who will use the system?
• How will they use the system?
• What will be the input for the system?
• What will be the output from the system?

•Requirement Gathering involve collecting information through

meetings, interviews and discussions
Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 21
2a.2 Requirements Analysis
•Aim: To understand exactly what the customer needs…
which may not be what they ask for:
• data to be input to the system;
• processing to be performed on these data;
• data to be output from the system;
• characteristics of the system as a whole;
• constraints on the system/project.

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 22

2b Requirements Specification
•Requirements are documented in a Software Requirements
Specification (SRS).
•The SRS forms the basis of a legal contract with the
customer:
•Software Engineers who specialize in requirements
gathering, analysis, and specification are called (Systems/
Business / Requirement) Analysts.

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 23

3. Design
•Architects and Designers craft a high-level and low level
design of the software.
• Architectural Design
• Low level Design
•Decisions are made about hardware, software and the
system architecture.
•A design specification document (DSD) records this
information.
Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 24
4. Development
•On receiving system design documents, the work is divided
in modules.
•A set of developers code the software as per the established
design specification, using a chosen programming language
•Programmers carry out some program testing to discover
faults in the program and remove these faults in the
debugging process

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 25

5. Testing
•The testing phase ensures that the software requirements are in
place and that the software works as expected.
•When a defect is identified, testers inform the developers.
•If the defect is valid, developers resolve it and create a new version
of the software which then repeats the testing phase.
•The cycle continues until all defects are mitigated and the software is
ready for deployment into the production environment.

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 26

6. Deployment and Maintenance
•Once the software is error free, it is deployed into the operating
environment.
•While the customers are using the software, any issues will be
brought to the attention of the maintenance team
•They work to resolve them immediately.

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 27

Waterfall Model - Strengths
•Simple and easy to manage– each phase has specific deliverables.
•Milestones are better understood
•Sets requirements stability
•Works well for smaller projects where requirements are very well
understood.
•A schedule can be set with deadlines

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 28

Waterfall Model - Weaknesses
•No working software is produced until end.
•High uncertainty.
•Delays discovery of serious errors.
•After requirements phase, there is no formal way to make changes to
the requirements.
•Not a good model for
• complex projects
• projects where requirements are at a moderate to high risk of changing
Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 29
When to use Waterfall Model

•Software requirements clearly defined and known

•Product definition is stable
•New version of the existing software system is created
•Software development technologies and tools are well
known

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 30

Iterative Waterfall Model

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 31

Iterative Waterfall Model
•The classical waterfall model is idealistic:
• It assumes that no defects are introduced during any of the
development phases.
•In practice, defects are introduced during every phase of the
software life cycle:
• Hence feedback paths must be added to the classical waterfall
model.
•The resulting Iterative Waterfall Model is one of the most widely
used process models….
Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 32
Iterative Waterfall Model
•Strengths
• Defects are detected and fixed early through the feedback path

•Weaknesses
• Limited customer interactions
• Difficult to incorporate change requests

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 33

Incremental model

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 34

Incremental model
•Incremental model is an evolution of waterfall model.
The product is designed, implemented, integrated and tested as a
series of incremental builds.
•The incremental model prioritizes requirements of the
system and then implements them in groups.
•It is the process of constructing a partial implementation of
a total system and slowly adding increased functionality or
performance.
Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 35
Incremental model - Strengths
•Generates working software quickly and early during the software
life cycle.
•More flexible - less costly to change scope and requirements.
•Easier to test and debug.
•Easier to manage risk.
•Lowers initial delivery cost.
•Less stress for the development team.

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 36

Incremental model - Weaknesses
•Requires good planning and design
•Demarcation of increments can be difficult in a practical application.
•Each phase of an iteration is rigid and do not overlap each other.
•Total cost of the system might not be lower.
•Problems may arise pertaining to system architecture because not all
requirements are gathered up front for the entire software life cycle.

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 37

When to use Incremental model
•On projects which have lengthy development schedules
•A need to get basic functionality to the market early
•Most of the requirements are known upfront but are expected to
evolve over time
•On a project with new technology

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 38

Prototype Model

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 39

Prototype Model
•Instead of freezing the requirements before coding or design, a
prototype is built to clearly understand the requirements.
•This prototype is built based on the current requirements.
•Through examining this prototype, the client gets a better
understanding of the features of the final product.
•Requirements may be changed with the client feedback on the
prototype.

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 40

Prototyping Model - Strengths
•Ability to clarify user’s expectations for the system to be developed
•Prototype stimulates awareness of additional needed functionality
•Better user satisfaction
•Early user feedback

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 41

Prototyping Model - Weaknesses
•Scope Creep - The system scope may expand beyond original plans.
•Overall maintainability may be overlooked.
•The customer may want the prototype be delivered.
•Process may continue forever

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 42

When to Use Prototyping
•Requirements are unstable or have to be clarified
•Many user interfaces
•New technology
•New, original development
•Developers are not familiar with the technical and development tools

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 43

Question
•A company is developing an advanced version of their current
software available in the market, what model approach would they
prefer ?
a) Waterfall
b) Incremental
c) Prototyping

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 44

Spiral Model

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 45

Spiral Model
•Meta Model - combines iterative and prototype development with
the systematic, controlled aspects of the waterfall model.
•Allows for incremental releases
•Introduced by Barry Boehm in 1986.
•Allows elements of the product to be added in when they become
available or known.
•Emphasise on risk management

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 46

Spiral Model
•Quadrant 1: Planning
Determine objectives, alternatives, and constraints.
•Quadrant 2: Risk Analysis
Evaluate alternatives, identify, resolve risks.
•Quadrant 3: Development & Test
Develop, verify, next-level product.
•Quadrant 4: Evaluation
Analyze feedback and plan next phases.

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 47

Spiral Model - Strengths
•Focus on risk analysis.
•Good for large and mission critical projects
•A working software is produced early
•The design does not have to be perfect
•Early and frequent feedback from users
•Cumulative costs assessed frequently

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 48

Spiral Model - Weaknesses
•Can be a costly model to use.
•Risk analysis requires expertise.
•Success is highly dependent on the risk analysis phase.
•Doesn’t work well for smaller projects.

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 49

When to use Spiral Model
•For medium to high-risk projects
•New technology to be used
•Complex, constantly changing and continuous Requirements
•Significant changes are expected (research and exploration)
•Users are unsure of their needs

Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 50

Next Lecture…?

Requirements Engineering
Ms. Chathurangi D. Weerasinghe, MSc(UCSC Col), BSc(Ruh) Seagis Campus 51