SOFTWARE

DEVELOPMENT
LIFECYCLES

Software Lifecycles – Part 1

What is an Engineering Process?
What is a Software Development Process?
Fundamental Process Activities
1. Software Specification
2. Software Development
3. Software Validation
4. Software Evolution
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.
2. Software Development
• Software development involves designing and implementing
the system according to the software specification
3. Software Validation
• Software validation involves checking and verifying whether
the system fulfills the requirements.
4. Software Evolution
• Software needs to be changed and upgraded with time.
What is a SDLC?
• The Software Development Life Cycle (SDLC) is a framework
that defines activities performed throughout the software
development process
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.
Life Cycle Models
• Traditional Approaches
1. Waterfall Model
2. Incremental Model
3. Prototyping Model
4. Spiral Model
5. Unified Process
• Modern Approaches
• Agile Methods (XP, Scrum)
• Secure Software Development
Waterfall Model
Waterfall Model
Waterfall model
• Waterfall model is the most well known SDLC.
• It is very simple to understand and use.
• Each phase begins only after the previous phase is over.
• Also called Linear Model
• A document driven process
• This model specifies what the system is supposed to do (i.e. define
the requirements) before building the system (i.e. designing)
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
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
Feasibility Study - Criteria

• Technical Feasibility
• Economic Feasibility
• Operational Feasibility
• Schedule Feasibility
IT 1060 Example – Library System
• What are the feasibility criteria for a ‘Library System’?
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
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
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.

• WHAT, not HOW!

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.
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.
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
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.
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.
Waterfall in Practice
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.
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
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
• Ample resources with required expertise are available
Iterative Model
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….
Iterative Waterfall Model
Iterative Waterfall Model
Strengths
• Defects are detected and fixed early through the feedback path

Weaknesses
• Limited customer interactions
• Difficult to incorporate change requests