Configuration Management How to keep from losing control of change

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

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

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 /e, pg /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

Additional Points of Emphasis Why things change (pgs /e, pgs /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)