1. Configuration Management How to keep from losing control of change

2. Reasons for Change Management Identify what has (is or will/won’t be or should/shouldn’t be) changed Control pace and timing of change Ensure change occurs where and as planned (i.e., proper implementation) Report change to constituents

3. Managed Components Software – Obviously! Data E.g, database versions, configuration files, numerical tables, user files Documents Requirements, Models and Design, User Manual, Installation Procedures Hardware Software – Again. Yes. System s/w, application packages, development tools, libraries

4. Layers of the SCM Process Identification: determining the SCIs, i.e., naming those things that you want controlled Change Control: instituting a process for change (see pg 596-597 7/e, pg 752-753 6/e) Version Control: part of your process for managing multiple (perhaps active) versions of the SCIs Configuration Auditing: making sure the change rules are being followed Reporting: Getting the word out about changes to those who care

5. Additional Points of Emphasis Why things change (pgs 585-586 7/e, pgs740- 741 6/e) New business conditions or requirements New customer needs Business re-organization or project priorities System redefinition Better understanding of system capability or application New context: H/W or S/W What it means for an object to become “baseline” (pg 588 7/e, pg 743 6/e)