You are on page 1of 99

Introduction to SDLC and SE Concepts

New hire orientation program

Deloitte Consulting LLP

Start time

End time

Session

9:00 AM

10:45 AM

Introduction and getting started

10:45 AM

11:00 AM

Tea break

11:00 AM

1:00 PM

System development life cycle

1:00 PM

2:00 PM

Lunch break

2:00 PM

3:45 PM

Requirement engineering

3:45 PM

4:00 PM

Tea break

4:00 PM

5:00 PM

Testing techniques

5:00 PM

6:00 PM

Configuration management

-2-

duction to SDLC and SE Concepts.pptx

Timelines

Introduction to SDLC and SE


Concepts
Introduction and getting started

Deloitte Consulting LLP


Date : 6th July 2009

Software
Software is the collection of.
Computer programs
Procedures
Rules
Data
Associated documentation

-4-

duction to SDLC and SE Concepts.pptx

A definition of process
A set of activities performed to achieve a given purpose. Any specific
combination of machines, tools, methods, materials, and/or people
employed to attain specific qualities in a product or service.
For organization to improve its business, following are three critical
dimensions:
Process is one of three quality leverage points
People

Outputs

Process

Technology

-5-

duction to SDLC and SE Concepts.pptx

Inputs

Software engineering
Establishment and use of sound engineering principles in order to
obtain economically a software that is reliable and works efficiently on
real machines (Bauer 69).
Application of science and mathematics by which capabilities of
computer equipment are made useful to man via computer programs,
procedures, and associated documentation (Boehm 81).
A systematic approach to the development, operation, maintenance,
and retirement of a software (IEEE 87).

-6-

duction to SDLC and SE Concepts.pptx

Application of a systematic, disciplined, and quantifiable approach to


the development, operation, and maintenance of a software(IEEE93).

Goals of software engineering


High-quality product

-7-

duction to SDLC and SE Concepts.pptx

At low cost

Software development models


Waterfall model
Prototyping model
Iterative enhancement model

-8-

duction to SDLC and SE Concepts.pptx

Spiral model

Waterfall model
Sequential
Enforces complete requirements specification
Cannot proceed to the next phase till the current phase is over
Does not model the reality

-9-

duction to SDLC and SE Concepts.pptx

Earliest availability of the working model Midway through the project

Prototyping model
Do not wait for requirements Freeze. Build a prototype to understand
requirements.
Prototype thrown away after requirements are understood.
Effective method to demonstrate the feasibility of a new concept.

- 10 -

duction to SDLC and SE Concepts.pptx

Danger of mistaking the prototype as the real software.

Iterative model
Software developed and delivered in increments.
Each increment adds some functionality.

- 11 -

duction to SDLC and SE Concepts.pptx

At each step, enhancements based on clients feedback analysis and


design are carried out.

Spiral model
Risk driven
Iterative steps

Planning
Risk analysis
Development
Customer evaluation

Provides early indication of risks

- 12 -

duction to SDLC and SE Concepts.pptx

Requires high management skills

Programmer versus software engineer


Individual with good skills

Part of a team

Programming-in-the-small

Programming-in-the-large

Knowledge on

Design approaches

Data structures
Algorithms

OO, modules, etc.


Top-down/bottom-up

Fluent in several programming


languages

Translates requirements into


specifications

May lack formal training

Familiarity in multiple application


areas
Converses with users
Sees big picture
Can model application
Good communication and
interpersonal skills
- 13 -

duction to SDLC and SE Concepts.pptx

Minimal exposure to CS

What are the key challenges facing software engineering?


Coping with legacy systems, coping with increasing diversity, and
coping with demands for reduced delivery times
Legacy systems
Old, valuable systems must be maintained and updated

Heterogeneity
Systems are distributed and include a mix of hardware and software

Delivery

- 14 -

duction to SDLC and SE Concepts.pptx

There is increasing pressure for faster delivery of software

Q and A

Introduction to SDLC and SE Concepts


SDLC Jargon made easy

Deloitte Consulting LLP


Date : 6th July 2009

Agenda
What is SDLC?
SDLC phases
SDLC models
SDLC key success factors
References
Summary
Q and A

What is SDLC?
An acronym for system development life cycle.
A set of stages/phases that all information systems go through in
their lifecycle.

- 18 -

duction to SDLC and SE Concepts.pptx

A conceptual model used in system development.

SDLC phases
The generic phases of SDLC are:
Analysis
Design
Build/test
Deployment

- 19 -

duction to SDLC and SE Concepts.pptx

Maintenance

SDLC phases (cont.)

Design

Build/test

Design
Specification

Architecture

Scope

Deployment

Business

Requirement

Proof of

Master Test

Requirements

Specification

Concept

Strategy

Product

Cases

- 20 -

Build

Deployment

Design Test

Selection

Maintenance

Maintenance

Execute
Test

duction to SDLC and SE Concepts.pptx

Analysis

Analysis

Design

Build/test

Deployment

Maintenance

Analysis phase
The analysis phase involves:
Study the clients current business processes and information
systems.
Evaluate issues/problem areas that need to be addressed by the new
system.
Gather/determine and structure the requirements.
Prepare requirements specification document (RSD).
Review the RSD.

- 21 -

duction to SDLC and SE Concepts.pptx

Get sign-off from the authorized client personnel.

Analysis

Design

Build/test

Deployment

Maintenance

Design phase
The design phase involves:
Designing the physical construction, hardware, operating systems,
networking, communications, and security specifications.
Preparing the functional design document that focuses mainly on the
business processes/aspects of the system.
Preparing the technical design document that is based on the
functional design and provides detailed technical specifications that
should be followed during the construction phase.
Prepare unit test plans/scripts (UTPS).
Review the functional design and technical design documents.

- 22 -

duction to SDLC and SE Concepts.pptx

Get sign-off from the authorized client personnel.

Analysis

Design

Build/test

Deployment

Maintenance

Build/test phase
The build activities involve:
Installation of hardware, operating system, etc.
Develop code based on the technical design.
Perform unit testing of the code using the UTPS.
Closure of unit testing findings.

- 23 -

duction to SDLC and SE Concepts.pptx

The testing activities involve:


Prepare the system test plan/scripts for testing the new system.
Complete system testing and integration testing.
Close the findings from system testing and integration testing.
Complete user acceptance testing.
Close the findings from user acceptance testing.
Get sign-off on the system from authorized client personnel.

Analysis

Design

Build/test

Deployment

Maintenance

Deployment phase
The deployment phase involves:
Ensure the required hardware, software, network, etc., are setup.
Train the users on using the new system.
Deploy the newly developed system.
Release the new system to client users for use.
Monitor the performance of new system.

- 24 -

duction to SDLC and SE Concepts.pptx

Help the users to increase their comfort level in using the new system.

Analysis

Design

Build/test

Deployment

Maintenance

Maintenance phase
The maintenance phase involves:
Prepare and review the maintenance plan.
Get sign-off on the system from authorized client personnel.
Document the issues reported by users on the new system.
Design, build, test, and deploy the code changes for resolving these
issues.
Make changes to accommodate changes in operating system,
peripheral devices, etc.

- 25 -

duction to SDLC and SE Concepts.pptx

Make changes to accommodate customers functional or performance


enhancement requirements.

SDLC models
The more popular SDLC models are:
The linear sequential model.
The prototyping model.
The rapid application development (RAD) model.

- 26 -

duction to SDLC and SE Concepts.pptx

The following few slides explain each of these models.

Linear sequential model


The linear sequential model
Analysis

Design

Build/test

Deployment

Is also called the waterfall model or the classic life cycle model.
Is a sequential approach to system development.
Progresses from one phase to another.
Has analysis, design, build/test, and deployment as the phases.

- 27 -

duction to SDLC and SE Concepts.pptx

Is the oldest and most widely used model.

Linear sequential model (cont.)


Strengths
Oldest, widely used, and proven model.
More predictable and controllable project schedule.
Each phase proceeds in strict order and ensures all activities in
previous phase are completed before moving to next phase.
High probability of delivering the system on time.

- 28 -

duction to SDLC and SE Concepts.pptx

Weaknesses
Does not allow for revision or iteration. Not always feasible in real-time
projects.
Sometimes is difficult for customers to clearly state all requirements.
Demands more patience from customers.
Adds a lot of waiting time for team members as they have to wait for the
dependent tasks to be completed.

Prototyping model

Listen to customer

Customer
test-drives
prototype

- 29 -

duction to SDLC and SE Concepts.pptx

Build/revise
prototype

Prototyping model (cont.)


The prototyping model is adopted when
The customer has a generic set of objectives.
Detailed requirements are not identified.
Build a pilot system to give an idea to the customer.

- 30 -

duction to SDLC and SE Concepts.pptx

Pilot system will further lead to detailed development life cycle.

Prototyping model (cont.)


Strengths
Serves as an effective mechanism for identifying requirements.
Iteration is possible and hence gives more flexibility.
Changing customer needs can be more effectively managed and hence
provides better customer experience.
Adds comfort level to the client as the progress of the product is visible
and they get a good idea of the final product.
Weaknesses
The initial prototype is not close to the final system. So, it may result in
lot of rework.

- 31 -

duction to SDLC and SE Concepts.pptx

Less/no focus on quality and hence may create more issues in the final
system.

RAD model
Modelling
(business,
data, and
process)

Application
generation

Testing and
turnover

Team 1

New
system

Team 2

- 32 -

duction to SDLC and SE Concepts.pptx

Team 3

RAD model (cont.)


The RAD model:
Is a linear sequential model that emphasizes extremely short
development cycle.
Is a high-speed adaptation of waterfall model.
Achieves rapid development by using component-based approach.
Each component/function is addressed by a separate team and all
components are quickly integrated to form a whole system.
Has modeling, application generation, and testing and turnover as the
phases.

- 33 -

duction to SDLC and SE Concepts.pptx

Demands well-understood requirements and highly scalable scope.

RAD model (cont.)


Strengths
Extremely short development lifecycles.
Embraces Object Oriented (OO) programming which inherently fosters
reusable software components.
Encourages use of readily available tools in the market to reduce the
lifecycles.
Results in highly maintainable and scalable system.
Lesser time spent on testing and review activities.

- 34 -

duction to SDLC and SE Concepts.pptx

Weaknesses
Very high resource requirements.
Demands full-time availability and high commitment from customers.
Not suitable for projects where the system cannot be properly
modularized.

SDLC key success factors


Planning and scheduling
Document reviews
Following development standards
Code reviews and walk-through
Configuration management (version control)
Issue tracking
Testing and defect prevention

- 35 -

duction to SDLC and SE Concepts.pptx

Change management process

References
Deloitte KX Portal https://kx.deloitteresources.com/default.aspx
Deloitte Learning Center https://www.deloittenet.com/dtlearning/default.asp
Books
Software Engineering A Practitioners Approach by Roger Pressman
Software Engineering Productivity Handbook by J. Kayes
Encyclopedia of Software Engineering by J. J. Marchiniak

Other Useful Links


http://www.lifecyclestep.com/0.0.0LifecycleStepHomepage.htm
http://scitec.uwichill.edu.bb/cmp/online/cs22l/waterfall_model.htm
http://courses.cs.vt.edu/csonline/SE/Lessons/Waterfall/
http://www.business-esolutions.com/islm.htm
http://searchvb.techtarget.com/sDefinition
http://searchsmallbizit.techtarget.com/sDefinition/0,,sid44_gci214246,00.html
http://www.cs.wm.edu/~coppit/csci780-fall2003/presentations/15-spiral-model.pdf
http://searchvb.techtarget.com/sDefinition/0,,sid8_gci755347,00.html
http://www.sei.cmu.edu/

- 36 -

duction to SDLC and SE Concepts.pptx

Summary
Define SDLC
SDLC phases
SDLC models
Key success factors

- 37 -

duction to SDLC and SE Concepts.pptx

References

Q and A

Introduction to SDLC and SE Concepts


Requirement engineering process

Deloitte Consulting LLP


Date : 6th July 2009

Topics
Requirement engineering
Why requirement engineering?
Types of requirement
Users of requirement
Requirement Measure
Guidelines for writing requirement document
Requirement management flow

Requirement engineering
The process of establishing the services that the customer requires
from a system and the constraints under which it operates and is
developed
The requirements themselves are the descriptions of the system
services and constraints that are generated during the requirements
engineering process
Phases of requirements in project life cycle
Obtain an understanding of requirements
Obtain commitment to requirements
Manage requirements changes
Maintain bidirectional traceability of requirements
Identify inconsistencies between project work and requirements

- 41 -

duction to SDLC and SE Concepts.pptx

Why requirement engineering

- 42 -

duction to SDLC and SE Concepts.pptx

Users perception of requirement

Why requirement engineering

- 43 -

duction to SDLC and SE Concepts.pptx

Designers perception of requirement

Why requirement engineering

- 44 -

duction to SDLC and SE Concepts.pptx

Developers perception of requirement

Types of requirements 1
User requirements
Statements in natural language, plus diagrams of the services the system
provides and its operational constraints. Written for customers

System requirements
A structured document setting out detailed descriptions of the system
services. Written as a contract between client and contractor

Software specification

- 45 -

duction to SDLC and SE Concepts.pptx

A detailed software description, which can serve as a basis for a design or


implementation. Written for developers

Types of requirements 1 (cont.)


Client managers
User requirements

System end users


Client engineers
Contractor managers
System architects

System requirements

System end users


Client engineers
System architects
Software developers
Client engineers (perhaps)
System architects
Software developers

- 46 -

duction to SDLC and SE Concepts.pptx

Software design
specification

Types of requirements 2
Functional requirements
Statements of services the system should provide, how the system should
react to particular inputs, and how the system should behave in particular
situations

Nonfunctional requirements
constraints on the services or functions offered by the system, such as timing
constraints, constraints on the development process, standards, etc.

Domain requirements

- 47 -

duction to SDLC and SE Concepts.pptx

Requirements that come from the application domain of the system and that
reflect characteristics of that domain

Different users of requirement document


System customers

Specify the requirements and read them to check that they meet their needs.
They specify changes to the requirements

Managers

Use the requirements document to plan a bid for the system and to plan the
system development process

System test engineers

System maintenance
engineers

Use the requirement to understand what system is to be developed

Use the requirement to develop validation tests for the system

Use the requirements to help understand the system and the relationships
between its parts

- 48 -

duction to SDLC and SE Concepts.pptx

System engineers

Requirements measures
Property
Speed

Measure
Processed transactions/second
User/even response time
Screen refresh time

Size

Kilo bytes
Number of RAM chips

Ease of use

Training time
Number of help frames

Reliability

Meantime to failure
Probability of unavailability
Rate of failure occurrence
Availability

Robustness

Time to restart after failure


Percentage of events causing failure
Probability of data corruption on failure
Percentage of target dependent statements
Number of target systems

- 49 -

duction to SDLC and SE Concepts.pptx

Portability

Guidelines for writing requirements


Invent a standard format and use it for all requirements
Use language in a consistent way. Use shall for mandatory
requirements, should for desirable requirements
Use text highlighting to identify key parts of the requirement
Avoid the use of computer jargon
Specify external system behavior
Specify implementation constraints
Easy to change
Serve as reference tool for maintenance
Record forethought about the life cycle of the system i.e. predict
changes

- 50 -

duction to SDLC and SE Concepts.pptx

Characterize responses to unexpected events

Guidelines for writing requirements (cont.)


Requirements document structure.
Introduction
Glossary
User requirements definition
System architecture
System requirements specification
System models
System evolution
Appendices
Index

- 51 -

duction to SDLC and SE Concepts.pptx

RM process Functional spec (FS) preparation


Alternative solutions
(for decision making)

Input
Business
requirement

Review
requirements

Create FS

Output
Baseline
functional specs

Sign off FS

Review FS

- 52 -

duction to SDLC and SE Concepts.pptx

For changes, refer to change control procedure

RM process Technical spec (TS) preparation


Input
Functional spec
Tech spec
review checklist

Initial object
review/
requirements
understanding

Output
Baseline
technical spec
Baseline test
cases

Sign off TS and


test cases

Alternative solutions
(for decision making)
Create TS and
test cases

Review TS and
test cases

- 53 -

duction to SDLC and SE Concepts.pptx

For changes, refer to change control procedure

Requirements management
Input
Requirement
document
(FS/TS)

Requirements
allocation and
understanding

Alternative solutions
(for decision making)

Maintain
configuration
status report

Revised FS/TS
Receive
clarifications
Prepare
communication
log/issue log

Receive
response

For changes, refer to change control procedure

- 54 -

duction to SDLC and SE Concepts.pptx

Output
Reviewed FS/TS

Software requirements in a nutshell


Software requirements
Vision and
scope

User
requirements

User cases

Functional
requirements

System
requirements
Software
requirements
specification

Quality
attributes
Other
nonfunctional
requirements

Constraints

- 55 -

duction to SDLC and SE Concepts.pptx

Business
requirements

Key points
User requirements should be written in natural language, tables and
diagrams
System requirements are intended to communicate the functions that
the system should provide
System requirements may be written in structured natural language, or
in a formal language
A software requirements document is an agreed statement of the
system requirements
Requirements set out what the system should do and define constraints
on its operation and implementation
Functional requirements set out services the system should provide

User requirements are high-level statements of what the system


should do
- 56 -

duction to SDLC and SE Concepts.pptx

Nonfunctional requirements constrain the system being developed or


the development process

Q and A

Introduction to SDLC and SE Concepts


Software testing techniques

Deloitte Consulting LLP


Date : 6th July 2009

Software testing
Dijkstra Testing can show the presence of bugs, but not their absence!
Independent testing is a necessary, but not sufficient condition for
trustworthiness.
Good testing is hard and occupies 20% of the schedule.
Poor testing can dominate 40% of the schedule.

- 59 -

duction to SDLC and SE Concepts.pptx

Test to assure confidence in operation; not to find bugs.

Ad-hoc Test

Error Scenario Test

Shakeout Test

Regression Test

Deployment Test

Seven formal test phases

duction to SDLC and SE Concepts.pptx

- 60 -

User Acceptance Test

Operational Test

Performance Test

Development
test phases

Integration Test

System Test

Packaged Validation/
String Test

Unit Test

Various types of tests


Test phases
Supplementary
test phases

Testing phases
System
specification

Acceptance test
plan

Service

System design

System
integration test
plan

Acceptance test

Subsystem
integration test
plan

System
integration test

- 61 -

Detailed design

Module and unit


code and tess

Subsystem
integration test

duction to SDLC and SE Concepts.pptx

Requirements
specification

Testing approaches
Coverage based All statements must be executed at least once
Fault based Detect faults, artificially seed, and determine whether
tests get at least X% of the faults
Error based Focus on typical errors, such as boundary values
(off by 1) or max elements in list
Black box Function, specification based, test cases derived from
specification
White box Structure, program based, testing considering internal
logical structure of the software

- 62 -

duction to SDLC and SE Concepts.pptx

Stress based No load, impulse, uniform, linear growth, exponential


growth by 2s

Testing approaches (cont.)


Error Human action producing incorrect result
Fault is a manifestation of an error in the code
Failure A system anomaly, executing a fault induces a failure
Validation The process of evaluating a system or component during or
at the end of development process to determine whether it satisfies
specified requirements

- 63 -

duction to SDLC and SE Concepts.pptx

Certification The process of assuring that the solution solves the


problem

Test process
Program or doc
Prototype
or model
Subset of input

Expected output

Test
strategy

Subset of input

Compare

Execute

Actual output

Test
results

Execute

- 64 -

duction to SDLC and SE Concepts.pptx

Input

Fault detection versus confidence building


Testing provokes failure behavior A good strategy for fault detection,
but does not inspire confidence
User wants failure free behavior High reliability
Automatic recovery minimizes user doubts
Test team results can demoralize end users, so report only those
impacting them

- 65 -

duction to SDLC and SE Concepts.pptx

A project with no problems is in deep trouble

Testing requirements
Review or inspection to check that all aspects of the system have been
described
Scenarios with prospective users resulting in functional tests

Common errors in a specification:

- 66 -

duction to SDLC and SE Concepts.pptx

Missing information
Wrong information
Extra information

Traceability tables
Features Requirements relate to observable system/product features
Source Source for each requirement
Dependency Relation of requirements to each other
Subsystem Requirements by subsystem

- 67 -

duction to SDLC and SE Concepts.pptx

Interface requirements relation to internal and external interfaces

Traceability table: Pressman


Subsystem

R01

R02

R03

S02

S03

- 68 -

duction to SDLC and SE Concepts.pptx

Requirement

S01

Test documentation
Test design document specifies for each software feature the details of
the test approach and lists the associated tests.
Test case document lists inputs, expected outputs, and execution
conditions.
Test procedure document lists the sequence of action in the testing
process.
Test report states what happened for each test case. Sometimes, these
are required as part of the contract for the system delivery.

- 69 -

duction to SDLC and SE Concepts.pptx

In small projects many of these can be combined.

Human static testing


Reading Peer reviews (best and worst technique)
Walk-through and inspections
Correctness proofs

- 70 -

duction to SDLC and SE Concepts.pptx

Stepwise abstraction from code to specification

Inspections
Sometimes referred to as Fagan inspections
Basically a team of about four folks examines code, statement by
statement

Code is read before meeting


Meeting is run by a moderator
Two inspectors or readers paraphrase code
Author is silent observer
Code analyzed using checklist of faults: wrongful use of data, declaration,
computation, relational expressions, control flow, and interfaces

Results in problems identified that author corrects and moderator


re-inspects

- 71 -

duction to SDLC and SE Concepts.pptx

Constructive attitude essential; do not use for programmers


performance reviews

Walk- through
Guided reading of code using test data to run a simulation
Generally less formal
Learning situation for new developers
Parnas advocates a review with specialized roles where the roles define
questions asked - proven to be very effective reviews

- 72 -

duction to SDLC and SE Concepts.pptx

Nondirective listening

The value of inspections/walk-through (Humphrey 1989)


Inspections can be 20 times more efficient than testing.
Code reading detects twice as many defects/hour as testing.
80% of development errors were found by inspections.

- 73 -

duction to SDLC and SE Concepts.pptx

Inspections resulted in a 10 times reduction in cost of finding errors.

Top-down and Bottom-up (Humphrey 1989)


Bottom-up
Major features

Advantages

Top-down

Allows early testing


Modules can be integrated in various
clusters as desired
Major emphasis is on module
functionality and performance

The control program is tested first


Modules are integrated one at a
time
Major emphasis is on interface
testing

No test stubs are needed


It is easier to adjust staffing needs

No test drivers are needed


The control program, plus a few
modules forms a basic early
prototype

Errors in critical modules are found early

Interface errors are discovered


early

Disadvantages

Test drivers and harness are needed

Test stubs are needed

Many modules must be integrated before


a working program is available

The extended early phases dictate


a slow staff buildup

Interface errors are discovered late

Errors in critical modules at low


levels are found late

- 74 -

duction to SDLC and SE Concepts.pptx

Modular features aid debugging

Some specialized tests


Testing GUIs
Testing with client/server architectures
Testing documentation and help facilities
Testing real-time systems
Acceptance test

- 75 -

duction to SDLC and SE Concepts.pptx

Conformance test

Lessons learned
Before you reuse software look below the surface.
Lack of functionality
No support
Hidden costs
Poor documentation
Poor performance

- 76 -

duction to SDLC and SE Concepts.pptx

Vendor instability

Customer interests

Price
Schedule

- 77 -

Reliability
Response time
Throughput

duction to SDLC and SE Concepts.pptx

Features

After
Installation

Before

Why bad things happen to good systems


Customer buys off-the-shelf

Customer refuses critical billing


module

with enhancements

Customer demands 33
enhancements and tinkers with
database
Unintended system
consequences

- 78 -

duction to SDLC and SE Concepts.pptx

Developers complies

But

System works with 40%-60%


flow- through

Q and A

Introduction to SDLC and SE Concepts


Software configuration management

- 80 -

duction to SDLC and SE Concepts.pptx

Deloitte Consulting LLP


Date : 6th July 2009

What is software configuration management?


Definition:
A set of management disciplines within the software engineering process
to develop a baseline.
Description:

- 81 -

duction to SDLC and SE Concepts.pptx

Software configuration management encompasses the disciplines and


techniques of initiating, evaluating, and controlling change to software
products during and after the software engineering process.

Why configuration management ?

How do I make
sure that the right
changes go into
the release?

Problems

Multiple developers
are working at the
same time...

What happened to
the fix I added to
this code last
week?

How can I authorize


access to the work
products?

Configuraiton management

- 82 -

duction to SDLC and SE Concepts.pptx

What happened to
this piece of code?
It worked
yesterday!

A bug, I cannot
reproduce it.

Functions in configuration management

Scoping
Procedure definition
Roles and responsibility
Directory structure and
access definition

Planning

Verification

Configuration
management
process

Status
accounting

Identification

CI identification
Base lining

Control

CI status update
CI status tracking
CI status reporting

Adding of new CI's


Update CI attributes
Control changes

- 83 -

duction to SDLC and SE Concepts.pptx

Plan and perform for


configuration audit
Verify with physical CI's
Report and closure of
audit

Basic definitions
Configurable Item (CI) An aggregation of work products that is
designated for configuration management and treated as a single entity
in the configuration management process. Common CIs:
Process-related documentation (plans, standards, and procedures)
Engineering documents and work products (requirements, design, code units,
and test cases)
Tools (compilers and other support tools)
Receivables (customer- supplied items)
System build for the software test activity or delivery

- 84 -

duction to SDLC and SE Concepts.pptx

Baseline Set of specifications or work product that has been formally


reviewed and agreed upon. Baselines thereafter serve as the basis for
further development and can be changed only through formal change
control procedures.

Basic definitions (cont.)


Naming convention A unique identification given to each
configuration item. Example <project name>_<doc name>
Version Version defines unique number and status of the document.

- 85 -

duction to SDLC and SE Concepts.pptx

All the document shall be versioned as m.n. where m is the numeric starting
with 1, indicating release version numbers. n is numeric, starting with 0,
indicating the minor version number.
Once document gets released,versioning will be done on the basis of defined
changes (major/minor).

- 86 duction to SDLC and SE Concepts.pptx

CI identification

Functions in configuration management (cont.)


CI identification
Configuration identification step involves identification of:
CI to be controlled
Categorization of CI
Identification of controls for selected CI's
Baseline of CI's if available
Preparation of configuration register with CI details

- 87 -

duction to SDLC and SE Concepts.pptx

- 88 duction to SDLC and SE Concepts.pptx

Configuration control

Functions in configuration management (cont.)


Configuration change control change management
Changes can be triggered by any one of the following:
Requirement change request
Problem report
Defect(s)

All change requests are logged in XD portal in case of EA projects. TI


projects uses CR log for the same.

- 89 -

duction to SDLC and SE Concepts.pptx

Impact analysis will be done using XD portal for EA projects and CR log
for TI projects.

Functions in configuration management (cont.)


Configuration change control change management (flow)
Receive change
Request
(PM)

Yes

No
Conduct impact
analysis (TL/PM)

Approve CR
(SCCB)

Rejected?
No

Yes
Update configuration
status report/XD
portal

Open deferred
CR (TL/PM)

Send CR back to
initiator (TL/PM)

Assign responsibilities to
change the items affected
(PM)

Verify change and


update baseline
library (PM)

Review/
test the change
implementation

Close CR (TL/PM)

Monitor change
Implementation
(TL/PM)

No

Item
already
configured?

Plan for change


Implementation
(PM)

Label/version the
artifact to be
delivered

Retrieve items (CM)

- 90 -

duction to SDLC and SE Concepts.pptx

Yes

Functions in configuration management (cont.)


Configuration change control version control
Version number should reflect the impact of changes. There can be major
or minor changes.
Major change
Change of complete text or major part of the text.
Defining new responsibilities and activities.

Minor changes
Typographical errors.
Incorrect reference to related documents.
Addition/deletion of references.
Change of sequence of activities, etc.

- 91 -

duction to SDLC and SE Concepts.pptx

Managing software configurations


Software configuration management can be staffed in several ways:
A single team performs all software configuration management activities
for the whole organization.
A separate configuration management team is set up for each project.
All the software configuration management activities are performed by
the developers themselves.

- 92 -

duction to SDLC and SE Concepts.pptx

Mixture of all of the above.

Symptoms of poor configuration management


Bugs that have been corrected reappear.
Previous releases of software cannot be rebuilt.
Previous releases of software cannot be found.
Files get lost.
Files are mysteriously changed.
The same or similar code exists multiple times in different projects.

- 93 -

duction to SDLC and SE Concepts.pptx

Two developers accidentally change the same file concurrently.

Why configuration management ? (cont.)


Benefits
Prevent unauthorized access to project work products
Coordinate, track, and manage change activities
Ability to deliver revisions, updates, and cross-platform versions faster
Less time wasted fixing old code
Confidence that each release addresses all the requested changes

- 94 -

duction to SDLC and SE Concepts.pptx

Do configuration right, or forget about improving


development process.

Questions?
What is a baseline?

- 95 -

duction to SDLC and SE Concepts.pptx

Baseline Set of specifications or work product that has been formally


reviewed and agreed upon. Baselines thereafter serve as the basis for
further development, and can be changed only through formal change
control procedures.

Questions?
List 5 examples of CI from software project?
PMP
TD
UTP
FSD

- 96 -

duction to SDLC and SE Concepts.pptx

SRS

Questions?
What is SCCB?

- 97 -

duction to SDLC and SE Concepts.pptx

Software change/configuration control board

Q and A

- 99 -

duction to SDLC and SE Concepts.pptx

Copyright 2008 Deloitte Development LLC. All rights reserved.