Software Configuration Management

1
Software Configuration Management
2
Overview

• To frame our discussion, consider
• What is a software configuration?
• Why does a configuration require management?
• How do we control and coordinate changes in the
  software configuration?

3
Outline

• First Law of Software Engineering
• SCM Activities
• Software Configuration
• Baseline
• Change Control
• Version Control

4
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
5
What Are These Changes?
changes in
business requirements
changes in
technical requirements
changes in
other documents
user requirements
software models
Project
Plan
data
Test
code
6
The Software Configuration
programs
documents
The pieces
data
7

• Configuration management is the art of
  identifying, organizing, and controlling
  modifications to the software being built by a
  programming team. The goal is to maximize
  productivity by minimizing mistakes.

8
Goals

• Provide a defined and controlled configuration of
  the software throughout the lifecycle.

9
Goals

• Provide the ability to consistently replicate the
  executable object code for software manufacture
  or to regenerate it in case an investigation or
  modification is needed.

10
Goals

• Provide control over process inputs and outputs
  during the lifecycle to insure consistency and
  repeatability of process activities.

11
Goals

• Provide a known point for review, status
  assessment, and change control.

12
Goals

• Provide controls to insure that problems receive
  attention and that changes are recorded, approved
  and implemented.

13
Goals

• Provide evidence of approval of the software by
  controlling the outputs of the software process.

Adapted from Pfleeger, Hatton, Howell (2002)
Solid Software. Prentice-Hall.
14
Goals

• Aid in assessing the software products
  compliance with requirements.

Adapted from Pfleeger, Hatton, Howell (2002)
Solid Software. Prentice-Hall.
15
Goals

• Insure that secure physical archiving, recovery,
  and control are maintained for configuration
  items.

Adapted from Pfleeger, Hatton, Howell (2002)
Solid Software. Prentice-Hall.
16
Activities

• Software configuration management is a set of
  tracking and control activities that begin when a
  software development project begins and
  terminates when the software is taken out of
  operation.

17
Four Facets of SCM

• Configuration Identification
• Configuration Control and Change Management
• Configuration Auditing
• Status Accounting

18
Configuration Identification

• The process of establishing a baseline from which
  changes are made.

19
Software Configuration

• The items that comprise all information produced
  as part of the software engineering process are
  called a software configuration.
• Artifacts produced during the process are called
  software configuration items (SCI).

20
Baselines

• The IEEE (IEEE Std. No. 610.12-1990) defines a
  baseline as
• 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.
• a baseline is a milestone in the development of
  software that is marked by the delivery of one or
  more software configuration items and the
  approval of these SCIs that is obtained through a
  formal technical review

21
Baseline

• It is an SCM task to maintain the integrity of
  the set of artifacts. An approach to the
  integrity issue is to require approval for adding
  items to the baseline. A second part to
  maintaining integrity is dealing with
  modifications to items in the database.

22
Change Management

• SCM provides the opportunity to review the
  history of the development activity by
  highlighting what has changed and with what
  frequency.

23
Change Control

• Change control involves procedures and tools to
  bring order to the change process. Larger
  projects have a formal Change Control Board whose
  responsibility it is to review and approve or
  disapprove change. It is the CCB responsibility
  to provide the mechanism to maintain orderly
  change processes.

24
Change Control
STOP
25
Change Control ProcessI
need for change is recognized
change request from user
developer evaluates
change report is generated
change control authority decides
request is queued for action
change request is denied
user is informed
change control processII
26
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 processIII
27
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
28
Change Control Process
29
Baselines
30
Terminology

• A configuration for a particular system is called
  a version.
• A system is typically assembled and tested in
  stages called builds.

31
Version Control

• Version control works to help manage the
  configuration items needed for particular
  versions during the development process.

32
Version Control Methods

• Separate Files
• Deltas
• Conditional Compilation

33
Configuration Audit

• This is a process to verify that the baseline is
  complete and accurate, that changes made are
  recorded, that recorded changes are made, and
  that the configuration items used in a version or
  build are documented in the configuration
  correctly.

34
Status Accounting

• Simply the maintenance of records of all baseline
  components where they come from, the current
  version, the history of changes, and pending
  changes.