Download Chapter 11: Software Configuration Management

Chapter 11:
Software Configuration
Management
Asst. Prof. Dr. Duygu Çelik Ertuğrul
1
Configuration Management
• New versions of software systems are created as they change
• Configuration management is concerned with managing evolving
systems
• Involves the development of procedures and standards to manage
product evolution
• May be viewed as part of a more general quality management
process.
2
Software Configuration Management (SCM)
• A Software Configuration Management (SCM) Plan defines the
strategy to be used for change management.
3
Software Configuration Management
How to manage ‘change’ in software ?
SE Process produces three main categories of outputs:
1. Computer programs
• both source and executable
2. Documentation
• both technical and user
3. Data
• within a program or external to it
These items are called a ‘software configuration’.
4
Fundamental sources of change (in software configuration)
a) New business or market conditions may dictate changes in
requirements or business rules.
b) Customers may ask for modification of:
₋ Data produced
₋ Functionality delivered
₋ Services delivered by a computer program
c) Reorganization or change of business size (↗ or ↘) may cause
changes in project priorities.
d) Budgeting or scheduling constraints may cause a redefinition of the
system to be built
e) Errors detected in the software need to be corrected
5
Software Configuration Management?
• A set of activities that have been developed to manage change
throughout the life cycle of computer software.
• Change is a ‘fact of life’ in SE.
• Customers want to modify requirements,
• Developers want to modify technical approach,
• Managers want to modify project approach,
as they get more experienced, and collect additional info.
6
Configuration Management Standards
• CM should always be based on a set of standards which are applied
within an organization
• Should define how
• items are identified
• changes are controlled
• versions are managed
• Should be based on an evolutionary process model rather than
something like the waterfall model!!!
7
Baselines
• A work product becomes a
baseline only after it is
reviewed and approved.
• A baseline is a software
configuration
management
concept that helps us to
control
change
without
seriously
approaching
justifiable change.
• Once a baseline is established
each change request must be
evaluated and verified by a
formal procedure before it is
processed.
8
Fig 9.2. Baselined SCIs and Project Database (Software Repository or Project
Library)
9
SUMMARY: A Baseline: (IEEE Std. 610. 12_1990)
• 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.
• Before a software configuration item becomes a baseline, changes may be made quickly
and informally.
• Once a baseline is established, changes can only be made by applying formal procedures
• Milestones usually define baselines.
• The progress of events that lead to a baseline is illustrated in the previous slide
Purpose of creating Baseline?
• Creation of a baseline is usually a milestone in the schedule.
• The baseline is centrally controlled.
• Everyone uses the same current baselines.
• To change the baseline, a formal process is required.
10
Software Configuration Item (SCI)
• Definition: Information that is created as part of the software
engineering process.
• Examples:
• Software Project Plan
• Software Requirements Specification
• Models, Prototypes, Requirements
•
•
•
•
Design document
Source code
Test suite
Software tools (e.g., compilers)
11
The following SCI-Software Configuraion Items become the target for configuration
management techniques, and hence form a set of baselines:
1. System Specification
2. Software Project Plan
3. Software Requirement Specification
a) Graphical analysis model
b) Process specifications
c) Prototype(s)
d) Mathematical specification
4. Preliminary User Manual
5. Design specification
a) Data design description
b) Architectural design description
c) Module design descriptions
d) Interface design descriptions
e) Object descriptions
6. Source code listing
7. Test specification
a) Test plan and procedure
b) Test cases and recorded results
8. Operation and installation manuals
9. Executable program
a) Module executable codes
b) Linked modules executable codes
10. Database description
a) Scheme and file structure
b) Inıtıal content
12. User manual
13. Maintenance documents
a) Software problem reports
b) Maintenance requests
c) Engineering change orders
14. Standards and procedures for SE
A Software Configuration
Item ?
Information that is created as
a part of the SE process (a
document, an entire plan of
test cases, or a program
12
module)
• Many companies also place specific versions of editors, compilers,
and other CASE tools under configuration control.
• A configuration object has a name, attributes and connections to
other configuration objects.
13
14
Elements of SCM
There are four elements of SCM:
1.
2.
3.
4.
Software Configuration Identification
Software Configuration Control
Software Configuration Auditing
Software Configuration Status Accounting
15
Configuration Management Cycle
Customer
Customer generates
a change request
Project Manager
Dev Team
Configuration
Manager*
Customer
approves
changes
Manager
assigns change
request to
software
engineer
Software
engineer checks
out necessary
configuration
objects
SE
completes
necessary
changes
SE checks in
modified
configuration
objects and
notifies CM
CM creates
new system
baseline
CM prepares
new system
release for
operation if
necessary
*In charge of administering project database and providing access control to engineers
16
Software Configuration Management Tasks





Identification (tracking multiple versions to enable efficient changes)
Version control (control changes before and after release to customer)
Change control (authority to approve and prioritize changes)
Configuration auditing (ensure changes made properly)
Reporting (tell others about changes made)
17
Requirements for SCM
• Repository: shared DB for artifacts (eserler) with controlled access to
prevent overwrites.
• Version management: Preserve history of changes made to each artifact;
provide ability to see how version was created.
• Workspace control: Private work space with ability to check out from
repository and check in with new version number.
• Product modeling and building: Procedure to build the product from
artifacts in repository.
18
Version Terminology
• Version
• instance of system that is functionally different
from other system instances
Version Numbering Derivation Structure
from Sommerville
• Variant
• instance of system that is functionally identical
but non-functionally different from other system
instances.
• Release
• system instance distributed to users outside the
development team.
V1.0
V1.1b
V1.1.1
V1.1
V1.2
V2.0
V2.1
V2.2
V1.1a
19
Change Tracking Tools
• Major problem in change management is tracking the change status
• Change tracking tools help track the status of each change request
• Ensures that change requests are sent to the right people at the right
time
• Can be integrated with e-mail systems to allow electronic
distributions of change requests
20
CM Plan - Format
According to
IEEE Standard 828 - standard for
Software Configuration Management Plans
1. Introduction
a) purpose b) scope c) definitions and acronyms d) references
2. Management
a) organization
b) SCM responsibilities
c) interface control
d) SCMP implementation
e) policies, directives, procedures (naming conventions, version designations,
problem report process)
3. SCM Activities
a) configuration identification
b) configuration control (change history, review authority, read/write control,
member identification)
c) configuration status accounting (status of requests, status of approved changes, …)
d) audits and reviews
4. Tools, Techniques, and Methodologies
5. Supplier Control
6. Records Collection and Retention
21
IEEE 1042
Guide to Software Configuration Management
• Defines terms, such as baseline and version
• Discusses configuration management as a management discipline and
its role in the engineering process
• Includes checklists of issues for sections of the SCMP (IEEE Std 828)
• Includes four complete examples of SCMPs
22
CM Tools - Necessary Features
 Dependency Tracking!!!
 Audit Trails!!!
 Reporting of Changes
 Supports the Change Rules
 Versioning
 Requirements Tracing
 Repository arranged as "basic objects" and "aggregate objects"
 Supports both Linear evolution and Trees
23