Software Development Life Cycle.

Day 2-Session 1
Lavanya.M
 Software Process
Coherent sets of activities for specifying, designing, implementing and
testing software systems

Objectives

To introduce software lifecycle models

To describe a number of different lifecycle models and when they
may be used
To describe outline process models for requirements engineering,
software development, testing and evolution
 SDLC

Business Functional
Req. Spec. Design Code/Build
Spec

Requirements Analysis Development Testing Implementation Maintenance

Unit System
Performance
Testing Testing
 Life Cycle Models

There are several models for such processes, each describing approaches to a
variety of tasks or activities that take place during the process. Some are listed
below.

V- Model

Water Falls Model

Extreme Programming

Spiral Model
 V - Model

User Acceptance
Requirements Corrective testing
Preventive

System
Analysis Testing

High Level Integration

Design Testing

Low Level Unit Testing

Design

Code V- MODEL
 V- Model Development
It is the model what is using by most of the companies.
V model is model in which testing is done parallel with
development. left side of v model ,reflect development input for
the corresponding testing activities.

It is a parallel activity which would give the tester the domain

knowledge and perform more value added,high quality testing
with greater efficiency. Also it reduces time since the test
plans,test cases.test strategy are prepared during the
development stage itself.
Waterfalls Model.
 Disadvantage of Water falls
Model.

Disadvantages :
More rework and changes will be more, if any error occurs,
Time frame will be more, More people will be idle during the initial time
Inflexible partitioning of the project into distinct stages makes it difficult to
respond to changing customer requirements.
 Extreme Programming.

New approach to development based on the development and

delivery of very small increments of functionality

Relies on constant code improvement, user involvement in the

development team and pair wise programming
 Spiral Model.
Determine objectives
Evaluate alternatives
alternatives and
identify, resolve risks
constraints Risk
analysis
Risk
analysis
Risk
analysis Opera-
Prototype 3 tional
Prototype 2 protoype
Risk
REVIEW analysis Proto-
type 1
Requirements plan Simulations, models, benchmarks
Life-cycle plan Concept of
Operation S/W
requirements Product
design Detailed
Requirement design
Development
plan validation Code
Design Unit test
Integration
and test plan V&V Integration
Plan next phase test
Acceptance
Service test Develop, verify
next-level product
 Spiral Development
Process is represented as a spiral rather than as a
sequence of activities with backtracking

Each loop in the spiral represents a phase in the

process.

No fixed phases such as specification or design - loops

in the spiral are chosen depending on what is required

Risks are explicitly assessed and resolved throughout

the process
 Key Points
Software processes are the activities involved in producing and
evolving a software system. They are represented in a software
process model

General activities are specification, design and implementation,

validation and evolution

Lifecycle models describe the organisation of software processes.

Iterative process models describe the software process as a cycle of

activities
 Project Management.
Project Initiation:
Map Activities to Software Life Cycle Model
Allocate Project Resources
Establish Project Environment
Plan Project Management
Project Monitoring and Control
Analyze Risks
Perform Contingency Planning
Manage the Project
Retain Records
Implement Problem Reporting Model
 Project Management.

Software Quality Management

• Plan Software Quality Management

• Define Metrics

• Manage Software Quality

• Identify Quality Improvement Needs

Requirement Management.
Requirement Management is to gather and manage user,
business, technical, and functional requirements within a
product development project.

• Frequency of change in the total requirements set

• Rate of introduction of new requirements

• Number of requirements changes to a requirements

baseline

• Percentage of defects with requirement errors

as the root cause

• Number of requirements-related change requests

(as opposed to defects found in
 Risk Management.
Risk Management is the process of measuring, or assessing risk and
developing strategies to manage it. Strategies include transferring the risk to
another party, avoiding the risk, reducing the negative effect of the risk, and
accepting some or all of the consequences of a particular risk. Traditional
risk management focuses on risks stemming from physical or legal causes
(e.g. natural disasters or fires, accidents, death, and lawsuits). Financial risk
management, on the other hand, focuses on risks that can be managed
using traded financial instruments.

Software Risk Evaluation (SRE)

Continuous Risk Management (CRM)
Team Risk Management (TRM)
 Configuration
Management.
Software Configuration management is an umbrella activity that is applied
throughout the software process. SCM identifies controls, audits and reports
modifications that invariably occur while software is being developed and after it has
been released to a customer. All information produced as part of software
engineering becomes of software configuration. The configuration is organized in a
manner that enables orderly control of change.

The following is a sample list of Software Configuration Items:

Management plans (Project Plan, Test Plan, etc.)

Specifications (Requirements, Design, Test Case, etc.)

Customer Documentation (Implementation Manuals, User Manuals, Operations
Manuals, On-line help Files)

Source Code (PL/1 Fortran, COBOL, Visual Basic, Visual C, etc.)

Executable Code (Machine readable object code, exe's, etc.)

Libraries (Runtime Libraries, Procedures, %include Files, API's, DLL's, etc.)

Databases (Data being Processed, Data a program requires, test data, Regression
test data, etc.)

Production Documentation