©ian sommerville 2006software engineering, 8th edition. chapter 29 slide 1 configuration management
TRANSCRIPT
©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 29 Slide 1
Configuration management
©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 29 Slide 2
Software Configuration Management
Art of coordinating SW development to minimize confusion
Software quality assurance (umbrella) activity
Set of tracking and control activities beginning to end
©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 29 Slide 3
Why Software Configuration Mgmt?
Change increases confusion
CM necessary when a software system has
Many developers Many versions
CM aims to control the costs and effort involved in making changes to a system
©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 29 Slide 4
Software Configuration Mgmt Activities
Identifying change
Controlling change
Ensuring change is properly implemented
Reporting changes to interested others
©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 29 Slide 5
Identifying Changes: Origin of changes
New business or market conditions New customer needs Reorganization or business
growth/downsizing Budgetary or scheduling constraints Most changes are justified
©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 29 Slide 6
Baselines Concept that helps us control change
without seriously impeding justifiable change
Before baseline: changes made quickly and informally
Once baseline established: changes can be made, but a formal procedure must be applied to evaluate and verify each change
©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 29 Slide 7
Identifying Changes
SW Configuration Items (SCIs) are identified• Document, suite of test cases, program
component, software tools• Identify relationships among SCIs (part-
of, interrelated, dependencies)
©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 29 Slide 8
Controlling Changes
Version control • manage many existing versions of SCIs• Use evolution graph or object pool
representation
©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 29 Slide 9
Controlling Changes
• before and after release• Authority (access control and synchronization
control)• Change requests submitted and evaluated• Change report (results of evaluation)• Change order (for approved change)• Check out SCI, make change, apply SQA activities• Check in SCI to database and version control
mechanisms• Before baseline, informal change control• Once baseline est. project level change control• After release, formal change control
©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 29 Slide 10
Ensure change properly implemented
aka Configuration auditing• Formal technical reviews• Software configuration audit
• Change made? Additional modifications?
• Formal technical review conducted?
• Software process followed/standards applied?
• Change “highlighted” in SCI? change date/author noted?
• SCM procedures followed?
• Related SCIs updated?
©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 29 Slide 11
Reporting Changes
• What happened?• Who did it?• When?• What else will be affected?
• Keep management and practitioners appraised of important changes.