Configuration Management

CS 415, Software Engineering I

Mark Ardis, Rose-Hulman Institute

February 4, 2003

2

A Story of 3 Programmers

(The following story is purely fictional. Any resemblance to real people or cartoon characters is entirely

coincidental.)

3

Alice Dilbert Wally

were working on a college registration system.

Once Upon a Time

4

Division of Labor

Alice worked on the User Interface (UI)

Dilbert worked on the Database (DB)

Wally worked on the Limits Checker (LC)

5

System Architecture

UI DB LC

6

Alice -- Change Request

One day Alice received a request from a user:

Process multiple Add/Drop requests all at once, instead of one-at-a-time.

7

Alice Made Some Changes

Alice needed to make some changes in order to support the new version:– The UI module was changed to allow

multiple Add/Drops– Each Add/Drop was processed as before,

but limits checking was suppressed until the last transaction

8

Dilbert -- Finds a Bug

Dilbert noticed that CreditHours was an attribute of a Course, when it should really be an attribute of a CourseSection.

This would allow honors sections to earn more credit hours.

9

Dilbert Made Some ChangesDilbert needed to make some changes in

order to fix the bug:– The DB module was changed to reflect the

new relationship between CreditHours and CourseSections

– The LC module was changed to pick up the CreditHours attribute from the proper table.

10

Wally -- New Version

Wally wanted to modify the system so that the LC module was called before attempting to process an Add/Drop transaction.

11

Wally Made Some Changes

Wally needed to make some changes:– The UI module was changed to call the LC

module– The DB module was changed so that it no

longer called the LC module– The LC module was changed to report

back to the UI module

12

Rebuilds

1. Wally recompiles and rebuilds the system with his changes.

2. Dilbert recompiles and rebuilds the system with his changes.

3. Alice recompiles and rebuilds the system with her changes.

13

All 3 Programmers Test

None of the results are as they expected.

14

Alice's Tests

• Although Alice's changes to the UI and LC modules were made, the DB module reflects Dilbert's changes.

15

Dilbert's Tests

• Dilbert's changes to the DB module were made, but the LC reflects Alice's changes.

16

Wally's Tests

• Wally's changes have all been overridden by changes made by Alice and Dilbert.

17

What Went Wrong?

18

Versions

LCAlice DBDilbert

LC LCDilbert DB

LCWally DBWally

UIAlice

UI

UIDilbert

19

Version Control (VC)

• Keep copy of each version of an artifact

• Restrict access to artifacts (read-only, read-write)

• Locking to prevent simultaneous updates

• Record who makes changes and who has a lock to make a change

20

Version Control Tools

• Revision Control System (RCS)

• Concurrent Versions System (CVS)

• ClearCase from Rational

• SoftBench CM from Hewlett-Packard

• Many others

21

Use of VC Tools

• Creation of initial baseline

• Check Out

• Check In

• Review Log

• Merging

22

RCS Demo

23

New Scenario for the 3 Programmers

1. Wally checks out all 3 modules (UI, DB, LC) and starts modifying his local copies.

2. Alice tries to check out UI and DB, but sees that Wally has a lock on each.

3. Dilbert tries to check out DB and LC, but sees that Wally has a lock on each.

24

Scenario Continued

4. Wally checks in his new versions.

5. Alice checks out and modifies UI and DB.

6. Dilbert checks out and modifies DB and LC.

25

All 3 Programmers are Happy

26

Baseline

• An artifact that has been formally reviewed and agreed upon

• Serves as the basis for further development

• Can be changed only through formal procedures

27

Configuration Management

• All the technology and processes required to control changes to artifacts.

• Includes:– Configuration Items– Change Request Forms– Configuration Control Board

28

Configuration Items

• Artifact placed under configuration control

• May include:– requirements, designs, code, tests,

documents– tools (e.g., version of compiler)– hardware as well as software

29

Reasons for Change

• Request, usually from a customer

• Defect repair (corrective maintenance)

• Enhancement (perfective maintenance)

• Needed to accommodate some other change (adaptive maintenance)

• Improvement (preventive maintenance)

30

Change Requests

• Use a standard form

• Have unique Ids

• Usually contain:– name of proposer– object to be changed– reason for change– short description of intended change

31

Change Control Board

• May be hierarchically organized

• Evaluate change requests and decide:– which requests to grant– who will perform them

• Monitor progress– tracking system– regular reports

32

Factors in EvaluatingChange Requests

• Size of change• Complexity• Date needed• Cost• Resources available• Impact on other work• Politics

…

33

Summary

• Version control prevents conflicts between individuals

• Configuration control provides management and accountability for changes

34

References

Configuration Management Yellow Pageswww.cmtoday.com/yp/configuration_management.html

Newsgroupcomp.software.config-mgmtwww.daveeaton.com/scm/CMFAQ.html

Component Software (RCS for Windows)www.ComponentSoftware.com