Software Development Life Cycle

Software Development Life Cycle

Ø      Requirement (gathering & analysis)

Ø      Design (HLD, LLD)

Ø      Develop (Code)

Ø      Test (Validate)

Ø      Deploy (Implement)

Ø      Support (Maintain) 

Requirements

Types of requirements

• Functional Requirements

• Data flow diagrams

• Entity-relationship diagrams

• State transition diagrams

• Data Dictionary

• System parameters

Ø Security, integrity, performance, reliability

• External Interfaces

• Acceptance Criteria

Ø Validation and Performance criteria 

Design

High Level:

• Functional Design

• Activity Flows / Work Flows

• System Flows and Application Flows

• Logical Data Model

• Program Inventory

• Architectural Diagrams

Low Level:

• Program Specs - Database Design

• Architectural diagrams - Data Access Design

• Interface design - Class Specifications

Build (Code)

Ø Environment Setup

Ø Test Data Creation

Ø Coding

Testing

• Test plans

• Test specifications

Ø Test cases + Test data + Expected Results

• Testing

• Test Results

Implement

Ø Data Conversion

Ø Data Migration

Ø Database Creation

Ø Production Tests

Ø Contingency Planning

Ø User Training

Support

Ø Production Support

Ø Enhancements 

Myths of SDLC

»Once the program is written and working, job is done.

»Until I get the program running, I have no way of assessing its quality. 

SDLC Models

Waterfall Model

The waterfall model is a sequential software development model (a process for the creation of software) in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance.

V Model

V model is the software development model which encapsulates the steps in Verification and Validation phases for each step in the SDLC. For each phase, the subsequent phase becomes the verification (QA) phase and the corresponding testing phase in the other arm of the V becomes the validating (Testing) phase

Iterative Development Models

Prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster.

Example: RUP, RAD, Prototyping, Agile

Testing within each lifecycle

In any life cycle model, there are several characteristics of good testing:

• For every development activity there is a corresponding testing activity.
• Each test level has test objectives specific to that level.
• The analysis and design of tests for a given test level should begin during the corresponding development activity.
• Testers should be involved in reviewing documents as soon as drafts are available in the development life cycle.

Software Quality

What is Quality?

Quality is the totality of features and characteristics of a product or service that bear on its ability to satisfy stated and implied needs.

Software Quality means: Total conformance to user requirements and specifications. Absence of Defects Fitness of Use.

Other definitions

Errors: Mistakes we make.

Defects: Defects are the results of errors.

Failures: Software failures are the results of Defects - observed while running the software

Quality Assurance vs Quality Control

Quality Assurance

1.Ensures that the product is developed correctly

2.Prevention activity

3.Eg. Process definition, planning

4.Done at the beginning of project

Quality Control

1.Ensures that the product developed is correct

2.Detection and correction activity

3.Eg. Reviews and Testing

4.Carried out after initiation

Importance of QA/QC

“All QC/QA activities are important, because all lead to quality software, if practiced correctly. However, if you allow me to choose one only, my choice is Formal Technical Reviews. If conducted properly, they are the single-most effective ways to uncover and fix defects while they are still inexpensive to find and fix.”

Roger Pressman

What is V&V?

Verification. 

• Determine whether the artifacts of each phase of SDLC fulfill the requirements of the previous phase. 
• Are we building the product correctly? 
• Also called as static technique or Review

Validation.

• Determine whether the artifacts of each phase of the SDLC are in tune with the customer requirements. 
• Are we building the correct product? 
• Also called as dynamic technique or Testing

Static and Dynamic V&V

Static and Dynamic techniques.

Why V&V?

• V&V is required because:
• Software construction is a complex task.
• Software construction is a Human activity. Humans make mistakes.
• Discipline and Methodology for construction reduce mistakes but cannot eliminate mistakes.
• V&V is about evaluating the products and processes used for producing the products.
• V&V is NOT about evaluating the producers.

Types of V&V

Reviews: 

• Project Plans, Schedules, and Costs 
• Requirements, Functional Specifications, and Design 
• Test Plans, Test Specifications, Test Scripts, 
• Source Code

Testing of Software: 

• Unit
• Integration 
• System Customer Acceptance