Configuration Management

1
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
Once Upon a Time

• Alice Dilbert Wally
• were working on a college registration system.

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
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 Changes

• Dilbert 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

1. Wally checks in his new versions.
2. Alice checks out and modifies UI and DB.
3. 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 Pages
• www.cmtoday.com/yp/configuration_management.html
  
• Newsgroup
• comp.software.config-mgmt
• www.daveeaton.com/scm/CMFAQ.html
• Component Software (RCS for Windows)
• www.ComponentSoftware.com