1. Configuration Management CS 415, Software Engineering I Mark Ardis, Rose-Hulman Institute February 4, 2003

2. 2 A Story of 3 Programmers (The following story is purely fictional. Any resemblance to real people or cartoon characters is entirely coincidental.)

3. 3 AliceDilbertWally were working on a college registration system. Once Upon a Time

4. 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. 5 System Architecture UIDBLC

6. 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. 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. 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. 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. 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. 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. 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. 13 All 3 Programmers Test None of the results are as they expected.

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

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

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

17. 17 What Went Wrong?

18. 18 Versions LC Alice DB Dilbert LC LC Dilbert DB LC Wally DB Wally UI Alice UI UI Dilbert

19. 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. 20 Version Control Tools Revision Control System (RCS) Concurrent Versions System (CVS) ClearCase from Rational SoftBench CM from Hewlett-Packard Many others

21. 21 Use of VC Tools Creation of initial baseline Check Out Check In Review Log Merging

22. 22 RCS Demo

23. 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. 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. 25 All 3 Programmers are Happy

26. 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. 27 Configuration Management All the technology and processes required to control changes to artifacts. Includes: –Configuration Items –Change Request Forms –Configuration Control Board

28. 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. 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. 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. 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. 32 Factors in Evaluating Change Requests Size of change Complexity Date needed Cost Resources available Impact on other work Politics …

33. 33 Summary Version control prevents conflicts between individuals Configuration control provides management and accountability for changes

34. 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