© Tata Consultancy Services ltd. 12 October 2006 1

Software Development Life Cycle (SDLC)

2

Objectives (1/2)At the end of the presentation, participantsshould 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

ObjectiveInputActivitiesOutputRole

4

Why SDLC?ObjectiveTo “systematically” develop “high quality” software in “timely and cost effective” manner

ApproachSystematic 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 SDLCFeasibility (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)

DesignDescribes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.

Coding and Unit testingThe 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)

ObjectiveDetermine whether developing the software is FINANCIALLY and TECHNICALLY feasible

InputInquiry from customer (Request for Proposal)

10

Feasibility Study (2/4)

Activities Involves high level understanding of scope:

Inputs to the systemProcessing to be carried outOutputs from the systemConstraints to be adhered to

11

Feasibility Study (3/4)Analyzing the data to arrive at:

Abstract definition of the problemFormulation of different solution strategiesExamination of alternative solutions strategiesi.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

OutputFeasibility Analysis Report

RoleBusiness Analyst

Note: May lead to a decision of NOT pursuing the project further

13

Requirements Phase (1/6)Objective:

To establish user requirementsInput

Contract AgreementFeasibility Analysis Report

14

Requirements Phase (2/6)Activities:

Requirements GatheringCollects all the possible information from customerData collection techniques include:–Interviews–Discussions–Questionnaires–Understanding the Existing system, if any

15

Requirements Phase (3/6)

Requirements analysisAnalyze the gathered information by resolving

AnomaliesConflictsIncompleteness

16

Requirements Phase (4/6)Requirements specification

Properly documents the requirementsAddresses “What System should do”Includes Functional and Non Functional RequirementsServes 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 understandThoroughly understood by both the customer and developerReviewedUnambiguous; Consistent; Complete; ConciseWell structured and easily modifiable

18

Requirements Phase (6/6)Outputs :

Requirement Specification Document (Signed Off)Requirements Traceability Matrix (initiation)Test Case DocumentSystem 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 DocumentRequirement Traceability MatrixTest Case Document

20

Design (2/6)

Activities:High level design

Identification of Different modulesControl relationships amongst modulesInterfaces amongst the modules

21

Design (3/6)

Low level designData structures for individual modulesAlgorithms 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 modulesFunctionally independent modules have minimum interaction with each other

Reduces error propagation across modulesIncreases reuse of modulesReduces 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)

OutputsHigh level Design DocumentLow level Design DocumentUpdated Requirement Traceability Matrix Test Specification Document

RoleSystem 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 documentsRequirement Traceability Matrix

26

Coding and Unit Testing (2/5)Activities:

Individual modules are coded as per specifications by following CODING GUIDELINESAfter 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 simpleDo not use same identifier for different purposese.g. looping variablesUse meaningful variable namesWell document the codee.g. suggested ratio of code/comments is 3:1

28

Coding and Unit Testing (4/5)Keep function size as small as possibleMinimize use of GOTO statementUse proper error handling mechanismFollow best practices which leads to

Improved performance, easy maintenance, reusability

29

Coding and Unit Testing (5/5)Output

Unit Tested Modules

ResponsibilityDevelopers

30

Verification & ValidationVerification

Ensures that software correctly implements a specific function (Are we building the product right?)

ValidationEnsures 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 ModulesTest Specifications Document

32

Testing (2/6)

33

Testing (3/6)ActivitiesIntegration testing:

Modules are integrated in planned mannerDuring each integration step, partially integrated system is testedWhen 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 is prepared 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 SystemTest Report

ResponsibilityTester

37

Testing TechniquesBlack Box testingWhite Box testingSecurity TestingStress TestingPerformance TestingSmoke TestingRegression Testing

38

Post-development Phase:Maintenance Phase

Objective :Maintaining the delivered system

Incorporation of changes, corrections, additions

Inputs :Client approved deployed System

39

Maintenance PhaseActivities:

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 MaintenanceOutput:

Enhanced SystemRoles:

System Analyst, Developer

41

Thank You