Page 264 -

CHAPTER 9 SOFTWARE CONFIGURATION MANAGEMENT 235

FIGURE 9.5 Need for change is recognized
The change
control process
Change request from user

Developer evaluates

Change report is generated

Change control authority decides

Request is queued for action, ECO generated Change request is denied

Assign individuals to configuration objects User is informed

“Check out” configuration objects (items)

Make the change

Review (audit) the change

“Check in” the configuration items that have been changed

Establish a baseline for testing

Perform quality assurance and testing activities

“Promote” changes for inclusion in next release (revision)

Rebuild appropriate version of software

Review (audit) the change to all configuration items

Include changes in new version

Distribute the new version

is modified by the software engineer. After appropriate SQA and testing, the modi-
fied version of the object is checked in and the new baseline object is unlocked.
Some readers may begin to feel uncomfortable with the level of bureaucracy implied
by the change control process description. This feeling is not uncommon. Without
proper safeguards, change control can retard progress and create unnecessary red
tape. Most software developers who have change control mechanisms (unfortunately,