340 likes | 355 Views
Configuration Management. CS 415, Software Engineering I Mark Ardis, Rose-Hulman Institute February 4, 2003. A Story of 3 Programmers. (The following story is purely fictional. Any resemblance to real people or cartoon characters is entirely coincidental.). Once Upon a Time.
E N D
Configuration Management CS 415, Software Engineering I Mark Ardis, Rose-Hulman Institute February 4, 2003
A Story of 3 Programmers (The following story is purely fictional. Any resemblance to real people or cartoon characters is entirely coincidental.)
Once Upon a Time Alice Dilbert Wally were working on a college registration system.
Division of Labor Alice worked on the User Interface (UI) Dilbert worked on the Database (DB) Wally worked on the Limits Checker (LC)
UI DB LC System Architecture
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.
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
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.
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.
Wally -- New Version Wally wanted to modify the system so that the LC module was called before attempting to process an Add/Drop transaction.
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
Rebuilds • Wally recompiles and rebuilds the system with his changes. • Dilbert recompiles and rebuilds the system with his changes. • Alice recompiles and rebuilds the system with her changes.
All 3 Programmers Test None of the results are as they expected.
Alice's Tests • Although Alice's changes to the UI and LC modules were made, the DB module reflects Dilbert's changes.
Dilbert's Tests • Dilbert's changes to the DB module were made, but the LC reflects Alice's changes.
Wally's Tests • Wally's changes have all been overridden by changes made by Alice and Dilbert.
Versions LCAlice DBDilbert LC LCDilbert DB LCWally DBWally UIAlice UI UIDilbert
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
Version Control Tools • Revision Control System (RCS) • Concurrent Versions System (CVS) • ClearCase from Rational • SoftBench CM from Hewlett-Packard • Many others
Use of VC Tools • Creation of initial baseline • Check Out • Check In • Review Log • Merging
New Scenario for the 3 Programmers • Wally checks out all 3 modules (UI, DB, LC) and starts modifying his local copies. • Alice tries to check out UI and DB, but sees that Wally has a lock on each. • Dilbert tries to check out DB and LC, but sees that Wally has a lock on each.
Scenario Continued • Wally checks in his new versions. • Alice checks out and modifies UI and DB. • Dilbert checks out and modifies DB and LC.
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
Configuration Management • All the technology and processes required to control changes to artifacts. • Includes: • Configuration Items • Change Request Forms • Configuration Control Board
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
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)
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
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
Factors in EvaluatingChange Requests • Size of change • Complexity • Date needed • Cost • Resources available • Impact on other work • Politics …
Summary • Version control prevents conflicts between individuals • Configuration control provides management and accountability for changes
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