Tata Consultancy Services ltd.

12 October 2006 1
Software Development Life
Cycle (SDLC)
2
Objectives (1/2)
At the end of the presentation, participants
should be able to:
Realise the need for a systematic
approach to software development
Comprehend and get a feel of
Software Development Life Cycle
3
Objectives (2/2)
Get a clear idea of all the phases of SDLC
Objective
Input
Activities
Output
Role
4
Why SDLC?
Objective
To systematically develop high quality
software in timely and cost effective
manner
Approach
Systematic and engineering like approach
is inevitable for developing large and
complex software
Involves use of techniques like system
analysis, estimation, designing,
development, testing, etc
5
SDLC Overview & Phases (1/4)
A software life cycle is the series of
identifiable stages that a software product
undergoes during its lifetime
Phases of SDLC
Feasibility (pre-development)
Establishes a high-level view of the
intended project and determines its
goals
6
SDLC Overview & Phases (2/4)
Requirements
Refines project goals into defined
functions and operation of the intended
application.
Analyzes end-user information needs.
Addresses on What System should do
7
SDLC Overview & Phases (3/4)
Design
Describes desired features and
operations in detail, including screen
layouts, business rules, process
diagrams, pseudocode and other
documentation.
Coding and Unit testing
The real code is written here
8
SDLC Overview & Phases (4/4)
Testing
Brings all the pieces together into a
special testing environment, then
checks for errors, bugs and
interoperability.
Maintenance (post-development)
Incorporation of changes, corrections,
additions.
9
Pre-development Phase:
Feasibility Study (1/4)
Objective
Determine whether developing the
software is FINANCIALLY and
TECHNICALLYfeasible
Input
Inquiry from customer (Request for
Proposal)
10
Feasibility Study (2/4)
Activities
Involves high level understanding of
scope:
Inputs to the system
Processing to be carried out
Outputs from the system
Constraints to be adhered to
11
Feasibility Study (3/4)
Analyzing the data to arrive at:
Abstract definition of the problem
Formulation of different solution
strategies
Examination of alternative solutions
strategies
i.e. benefits, resources input, cost,
time, development related issues
12
Feasibility Study (4/4)
Performing cost/benefit analysis to
determine best solution under current
circumstances
Output
Feasibility Analysis Report
Role
Business Analyst
Note: May lead to a decision of NOT
pursuing the project further
13
Requirements Phase (1/6)
Objective:
To establish user requirements
Input
Contract Agreement
Feasibility Analysis Report
14
Requirements Phase (2/6)
Activities:
Requirements Gathering
Collects all the possible information
from customer
Data collection techniques include:
Interviews
Discussions
Questionnaires
Understanding the Existing
system, if any
15
Requirements Phase (3/6)
Requirements analysis
Analyze the gathered information by
resolving
Anomalies
Conflicts
Incompleteness
16
Requirements Phase (4/6)
Requirements specification
Properly documents the
requirements
Addresses What System should do
Includes Functional and Non
Functional Requirements
Serves as a contract between the
customer and the developer
17
Requirements Phase (5/6)
Guidelines of Requirement Document:
Written in a language that user can
understand
Thoroughly understood by both the
customer and developer
Reviewed
Unambiguous; Consistent; Complete;
Concise
Well structured and easily modifiable
18
Requirements Phase (6/6)
Outputs :
Requirement Specification Document
(Signed Off)
Requirements Traceability Matrix
(initiation)
Test Case Document
System Test Plan
Role:
Business Analyst
19
Design (1/6)
Objective:
To transform requirements specified in
SRS document into a design that will be
implemented using a programming
language
Inputs:
Requirement Specification Document
Requirement Traceability Matrix
Test Case Document
20
Design (2/6)
Activities:
High level design
Identification of Different modules
Control relationships amongst
modules
Interfaces amongst the modules
21
Design (3/6)
Low level design
Data structures for individual
modules
Algorithms required for individual
modules
22
Design (4/6)
Design Guidelines
Good modular design is achieved by
using the rule divide and conquer
i.e. Functionally independent modules
Functionally independent modules have
minimum interaction with each other
Reduces error propagation across
modules
Increases reuse of modules
Reduces design complexity
23
Design (5/6)
Measures of functional independence:
COHESION of a module is a
measure of functional strength of a
module
COUPLING of a module (with other
module) is a measure of degree of
functional interdependence between
the two modules
24
Design (6/6)
Outputs
High level Design Document
Low level Design Document
Updated Requirement Traceability
Matrix
Test Specification Document
Role
System Analyst, Sr. Developer
25
Coding and Unit Testing (1/5)
Objective:
Convert system design into code and
Testing of each Unit independently
Input:
High Level and Low Level Design
documents
Requirement Traceability Matrix
26
Coding and Unit Testing (2/5)
Activities:
Individual modules are coded as per
specifications by following CODING
GUIDELINES
After coding, the modules are subjected
to walkthroughs
Reduces the errors before testing
starts
After walkthroughs, the modules are
individually unit tested
27
Coding and Unit Testing (3/5)
Coding guidelines:
Keep coding style simple
Do not use same identifier for different
purposes
e.g. looping variables
Use meaningful variable names
Well document the code
e.g. suggested ratio of
code/comments is 3:1
28
Coding and Unit Testing (4/5)
Keep function size as small as possible
Minimize use of GOTO statement
Use proper error handling mechanism
Follow best practices which leads to
Improved performance, easy
maintenance, reusability
29
Coding and Unit Testing (5/5)
Output
Unit Tested Modules
Responsibility
Developers
30
Verification & Validation
Verification
Ensures that software correctly
implements a specific function (Are we
building the product right?)
Validation
Ensures that the built software is
traceable to customer requirements
(Are we building the right product?)
31
Testing (1/6)
Objective :
To identify all the defects existing in the
integrated S/W product
Input:
Individually Tested Modules
Test Specifications Document
32
Testing (2/6)
33
Testing (3/6)
Activities
Integration testing:
Modules are integrated in planned
manner
During each integration step, partially
integrated system is tested
When ALL modules are integrated (and
tested), the system is ready for system
testing
34
Testing (4/6)
System testing:
Objective:
To confirm that the developed
system meets the requirements (as
specified in SRS document)
Carried out according to the system
test plan
Note: system test plan isprepared during
requirements phase (include test cases
and expected results)
35
Testing (5/6)
Additional types of system
testing:
Alpha testing and Beta testing
(for product)
Acceptance testing (by
customer)
36
Testing (6/6)
Output
Tested System
Test Report
Responsibility
Tester
37
Testing Techniques
Black Box testing
White Box testing
Security Testing
Stress Testing
Performance Testing
Smoke Testing
Regression Testing
38
Post-development Phase:
Maintenance Phase
Objective :
Maintaining the delivered system
Incorporation of changes,
corrections, additions
Inputs :
Client approved deployed System
39
Maintenance Phase
Activities:
1) Corrective maintenance:
Fixing errors not detected during the
development phase
2) Adaptive maintenance:
Improving implemented system
(performance)
Enhancing functionalities (new
requirements)
Porting software to new environment
40
Software Maintenance
Output:
Enhanced System
Roles:
System Analyst, Developer
41
Thank You