configuration management cs 415, software engineering i mark ardis, rose-hulman institute february...
Post on 19-Dec-2015
219 views
TRANSCRIPT
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