Supplementary Slides for
Software Engineering:
A Practitioner's Approach, 5/e
copyright © 1996, 2001
R.S. Pressman & Associates, Inc.
For University Use Only
May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.
This presentation, slides, or hardcopy may NOT be used for
short courses, industry seminars, or consulting purposes.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
1
Chapter 9
Software Configuration Management
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
2
What is it?
A set of activities designed to control change by
identifying the work products that are likely to change,
establishing relationships among them,
defining mechanisms for managing different versions of
these work products,
Controlling the changes imposed, and
Auditing & reporting the changes made
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
3
The “First Law”
No matter where you are in the system
life cycle, the system will change, and the
desire to change it will persist throughout
the life cycle.
Bersoff, et al, 1980
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
4
What Are These Changes?
changes in
business requirements
changes in
technical requirements
changes in
user requirements
other
documents
software models
Project
Plan
data
Test
code
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
5
The Software
Configuration
The items that comprises all information produced as part of the
software process
programs
The pieces
– the output of SW process
documents
data
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
6
Change & SCM
Software Engineering
tools
methods
procedures
a TQM foundation
•
•
•
•
•
•
SCM
identification
version control
change control
auditing
reporting
construction
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
7
Baselines
A specification or product that has been
formally reviewed and agreed upon, that
thereafter serves as the basis for further
development, and that can be changed only
through formal change control procedures
Eg. System Specification, SW requirements,
design specification, source code, test plan,
operational system
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
8
SCI (Software Configuration Items)
Information that is created as part of the
software engineering process
eg,. A single section of a large specification, or one
test case in a large suite of tests
It is a document, an entire suite of test cases,
or a named program component (eg. C++
function)
Specific versions of editors, compilers, and
other CASE tools may be “frozen” as part of
the software configuration
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
9
Identification of Objects
Two types of objects:
1. Basic object: a “unit of text” that has been
created during analysis, design, code, or
test.
Eg. A section of requirement specification, a
source listing for a component, a suite of test
cases
2. Aggregate object is a collection of basic
objects and other aggregate objects
Eg. Design specification
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
10
Object Features
 Name: a character string
 Description: a list of data items that identify
the SCI type (document, program, data)
a project identifier
change/version information
 List of resources: entities that are provided, processed,
referenced or otherwise required by the object.
eg. Data types, specific functions, variable names
 “realization”: a pointer to the basic object
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
11
Version Control
Combines procedures and tools to manage
different versions of configuration objects
Eg. Evolution graph
each node is a complete version
each version is a collection of SCIs (source code,
documents, data)
Each version may be composed of different variants
eg. A version composed of entities: 1, 2, 3, 4, 5
Two variants (1) entities 1, 2, 3, 4 for color display (2)
entities 1, 2, 3, 5 for monochrome
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
12
Version Control (2)
Evolution graph
Obj
1.3
Obj
1.0
Obj
1.1
Obj
1.2
Obj
1.1.1
Obj
2.0
Obj
1.1.2
Eg. Version 1.1.2, 1.3 & 2.0 are currently supported
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
13
Change Control
STOP
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
14
Change Control Process—I
need for change is recognized
change request from user
developer evaluates
change report is generated
change control authority decides
request is queued for action
Engineering Change Order generated
change request is denied
user is informed
change control process—II
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
15
Change Control Process-II
assign people to SCIs
check-out SCIs
make the change
review/audit the change
establish a “baseline” for testing
change control process—III
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
16
Change Control Process-III
perform SQA and testing activities
check-in the changed SCIs
promote SCI for inclusion in next release
rebuild appropriate version
review/audit the change
include all changes in release
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
17
Elements of Change Control
Access Control: governs which software
engineers have the authority to access and
modify a particular configuration object
Synchronization control: helps to ensure that
parallel changes, performed by two different
people, don’t overwrite one another
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
18
Audit
 How do we ensure that the change has
properly implemented?
1. Formal Technical Reviews: focuses on the
technical correctness of the configuration object
that has been modified
2. Software Configuration Audit: complements
the Formal Technical Reviews by assessing for
a configuration object for characteristics that are
generally not considered during review
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
19
Auditing
Change
Requests
SCIs
SQA
Plan
SCM Audit
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
20
Status Accounting
Change Change
Requests Reports
ECOs
SCIs
Status Accounting
Reporting
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
21
Configuration Status Reporting (CSR)
 An SCM task that answer the following
questions
1.
2.
3.
4.
++
What happened?
Who did it?
When did it happen
What else will be affected?
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
22