DIVISION E – GROUP 4

SOFTWARE DEVELOPMENT
LIFE CYCLE
“You’ve got to be very careful if you don’t know where
you’re going, because you might not get there.”

Devesh Chaube E014

Vipul Jha E038
Ashish Pandey E048
Aurindum Mukherjee E045
Rajat Sajnani E054
Krishanu Dasgupta E019
Nitish Rai E051
• All software have a life cycle or a series of stages they naturally undergo

• Number and name of the stages varies, but the primary stages are
conception, development, maturity and decline

• The software development life cycle (SDLC) therefore, refers to the

development stage of the software’s life cycle

• A term used in systems engineering, information systems and software

engineering to describe a process for planning, creating, testing, and
deploying an information system

• ISO/IEC 12207 is an international standard for software life-cycle

processes

• Aims to produce a high quality software that meets or exceeds customer

expectations, reaches completion within times and cost estimates.
 Requirement
Gathering &
Analysis

Evolution Design

SDLC
Phases

Testing Implementation
 REQUIREMENT GATHERING & ANALYSIS

• Most important and fundamental stage in SDLC

• Can be broken down into two distinct activities: Capturing requirements

and Analyzing requirements

• Capturing requirements - task of communicating with stakeholders to

determine what the requirements are.

• Commonly done via formal and informal meetings, e-mails and phone
calls

• Analyzing requirements- task of using standard tools and practices to

generate a single unambiguous baseline of the requirements

• Once all the stakeholders agree on the requirements, the baseline is

created and becomes the formal requirements source
.
• BA develops a plan for how the requirements analysis activity will be
accomplished
• Documents the business process descriptions and collects the
requirements of the system from the SME’s in a manner which allows
traceability to documents generated in previous activities and creates a
framework for future activities.
• A requirements traceability matrix is generated which becomes the basis
for the Design activity.
Artifacts:-
• Requirement Gathering-
– Business Requirement Specification that details the complete requirement.
– Functional in nature.
– Accompanied by test case scenarios. This serves as a guideline to the development
team as well to build the scope of the functionality and validations.
• Requirement Analysis-
– BA associated with the project carries out the impact analysis and feasibility analysis.
The limitations if any in the requirements, constraints, assumptions are documented,
shared with the business users and signed-off to avoid any further surprises.
 DESIGN
Logical Design
• Concentrates on business aspects of the system

Physical Design
• Technical specifications

• SRS is the reference for product architects to come out with the best
architecture for the product to be developed.

• Usually more than one design approach for the product architecture is
proposed and documented in a DDS - Design Document Specification.

• DDS is reviewed by all the important stakeholders and based on various

parameters, the best design approach is selected for the product

• Design is finalized after Risk Analysis and considering the Functional

and Non-functional specifications
 IMPLEMENTATION

• Required hardware and software installations take place

• Actual development starts and the product is built
• Programming code is generated as per DDS.
• If the design is performed in a detailed and organized manner, code
generation can be accomplished without much hassle
• User training & Documentation

TESTING

• A subset of all the stages as in the modern SDLC models, the testing
activities are mostly involved in all the stages of SDLC
• Refers to the testing only stage of the product where products defects
are reported, tracked, fixed and retested, until the product reaches the
quality standards defined in the SRS
• Functional Testing, Integration testing, System testing & Acceptance
testing
 EVOLUTION

• Most enterprise applications are in production for several years

• During this time, the application must evolve to meet the changing
requirements of the enterprise

Example- A landscaping business may decide to expand into sprinkler

system installation. If the billing application developed for the
landscaping business does not have the ability to handle the new
product line, it must be modified

• This evolution of the application will continue until it is finally replaced by

a new application
SDLC models are frameworks defining tasks performed at each step in the
software development process

Waterfall
Model

Iterative
RAD
Model

SDLC
Models Spiral
Agile
Model

Big
Bang V- Model
Model

Majority of the projects across the Software industry use Waterfall and Agile
models for Software development
 WATERFALL MODEL

Used when-
• Requirements are very well known
• Product definition is stable
• Technology is understood
• New version of an existing product
• Porting an existing product to a new platform..
AGILE MODEL
• Tasks are divided to time boxes (small time frames) to deliver specific
features for a release
• Iterative approach is taken and working software build is delivered after
each iteration
• Each build is incremental in terms of features; the final build holds all
the features required by the customer.

AGILE MANIFESTO PRINCIPLES

Individuals and interactions – in agile development, self-organization

and motivation are important, as are interactions like co-location and
pair programming.
Working software – Demo working software is considered the best
means of communication with the customer to understand their
requirement, instead of just depending on documentation.
Customer collaboration – As the requirements cannot be gathered
completely in the beginning of the project due to various factors,
continuous customer interaction is very important to get proper product
requirements.
Responding to change – agile development is focused on quick
responses to change and continuous development.
 Agile Vs Traditional SDLC Models

Traditional Models
• Based on predictive approach
• Teams in the traditional SDLC models work with detailed planning and have a
complete forecast of the exact tasks and features to be delivered in the next few
months or during the product life cycle.
• Depends on the requirement analysis and planning done in the beginning of cycle
• Any changes to be incorporated go through a strict change control management and
prioritization

Agile Model
• Based on adaptive software development methods
• No detailed planning and there is clarity on future tasks only in respect of what
features need to be developed
• Feature driven development and the team adapts to the changing product
requirements dynamically
• Product is tested very frequently through the release iterations
THANK YOU