Configuration and Change Management Managing the products of system change

Topics covered Configuration management fundamentals Software and documentation version control Configuration management planning (SCMP) Change management System building CASE tools for configuration management

Configuration Management New versions of software systems are created as they change For different machines/OS Offering different functionality Tailored for particular user requirements Configuration management is concerned with managing evolving software systems System change is a team activity CM aims to control the costs and effort involved in making changes to a system

Configuration Items (CI’s) Units tracked officially down to the smallest unit worth tracking includes most official documents Payroll v. 0.3.4.3 Payroll v. 0.4.1.0 Payroll v. 0.3.4.2 S6 A1 C4 D5 E3 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Configuration Items (CI’s) Units tracked officially down to the smallest unit worth tracking includes most official documents Module updated Payroll v. 0.3.4.2 Payroll v. 0.3.4.3 Payroll v. 0.4.1.0 S6 S7 A1 A1 C4 C4 D5 D5 E3 E3 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Configuration Items (CI’s) Units tracked officially down to the smallest unit worth tracking includes most official documents Module added Payroll v. 0.4.1.0 Payroll v. 0.3.4.2 Payroll v. 0.3.4.3 S6 S7 S7 A1 A1 A1 C4 C4 C4 D5 D5 D5 E3 E3 E3 F1 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Configuration Management Requirements Locking - to prevent more than one person working on a CI at one time Check out - authorization Check-in procedure Authorization May inforce testing Historical record of prior groupings of consistent CI’s For a list of CM tools: http://dmoz.org/Computers/Software/Configurati on_Management/Tools/ Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel.

System Families

CM Standards CM should always be based on a set of standards which are applied within an organisation Standards should define how items are identified, how changes are controlled and how new versions are managed Standards may be based on external CM standards (e.g. IEEE standard for CM) Existing standards are based on a waterfall process model - new standards are needed for evolutionary development For further info see http://www.rspa.com/spi/SCM.html

IEEE 828-1990 SCMP Table of Contents 3.2 Configuration control 3.2.1 Requesting changes 3.2.2 Evaluating changes 3.2.3 Approving or dis- approving changes 3.2.4 Implementing changes 3.3 Configuration status accounting 3.4 Configuration audits & reviews 3.5 Interface control 3.6 Subcontractor / vendor control 4. SCM schedules 5. SCM resources 6. SCM plan maintenance 1. Introduction 2. SCM management 2.1 Organization 2.2 SCM responsibilities 2.3 Applicable policies, directives & procedures 3. SCM activities 3.1 Configuration identification 3.1.1 Identifying configu- ration items 3.1.2 Naming configu- 3.1.3 Acquiring configu- Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Plan Configuration Management One way to ... 1. Roughly sketch out your SCMP Determine procedures for making changes Omit tool references unless already identified one See the case study for an example 2. Specify what you need from a CM tool For class use, maybe only locking and backup 3. Evaluate affordable tools against your needs and budget Commercial tools are in wide use (here is a list) For class use, try free document storage web sites; try simple method of checking out e.g. renaming 5. Finalize your SCMP Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Change Management Software systems are subject to continual change requests From users From developers From market forces Change management is concerned with keeping managing of these changes and ensuring that they are implemented in the most cost-effective way

The Change Management Process

The Change Management Process

The Change Management Process

The Change Management Process

Change Request Form CRF form layout is part of the CM planning process Records from the requestor: change requirement (description) requestor’s name reason for change Urgency Records from the development team: evaluation of change requirement assessment / impact analysis – technical/opertaional feasibility change cost estimate recommendation

Change Request Form

Assessment portion of Change Request Form Technical impact on design, code, testing, etc Risks associated with change External impact on users and operators Estimate Effort and resources Costs Schedule

Change Tracking Tools Differs from CM tools like CVS A major problem in change management is tracking change status Change tracking tools keep track of the status of each change request and automatically ensure that change requests are sent to the right people at the right time. Integrated with E-mail systems allowing electronic change request distribution

Change Control Board Changes should be reviewed by an external group who decide whether or not they are cost-effective from a strategic and organizational viewpoint rather than a technical viewpoint Should be independent of project responsible for system. The group is sometimes called a change control board May include representatives from client and contractor staff

Derivation History Record of changes applied to a document or code component Should record, in outline, the change made, the rationale for the change, who made the change and when it was implemented May be included as a comment in code. If a standard prologue style is used for the derivation history, tools can process this automatically

Component Header Information

Change Request Form - P1 Project: Registration System Number: 0023 Change requester: DLS Date: 3/28/2005 Description: We would like the system to be played by more than one user at a time over a network. Change priority: high

Project: Registration System Number: 0023 Change Assessment: Change Request Form - P2 Project: Registration System Number: 0023 Change Assessment: Analyst: Analysis Date: Technical impact on design, components, code, testing, etc Risks associated with change External impact on users and operators Effect on resources Effect on costs Effect on schedule

ONE WAY … Change Request Form - P2 Project: Registration System Number: 0023 Change Assessment: Analyst: Analysis Date: Technical impact on design, components, code, testing, etc Network centric change in architecture from single system arch Player against player Multi-tasking (threaded) code for concurrent execution of player paths Risks associated with change Delay in response time of game Currently lack human resources to affect change (can we get them) Server crash means everyone is down Potential for players cheating External impact on users and operators Will now need a network Will need an administration person Game is potentially more complex due to player-player interactions

ONE WAY … Change Request Form - P2 Project: Registration System Number: 0023 Change Assessment: Analyst: Analysis Date: Effect on develop resources Human A developer with network computing expertise Physical A server (for at least testing) A system for simulating multiple users A DBMS will be needed (for the game and for financial account) Network hardware / connection Addition infrastructure for added human and physical resources Effect on costs Hardware = $5000 Human = $60,000*1.30 / 220 * 10 mandays = $3500 Training/Travel = $2500 Infrastructure = $2000 Project management overhead ~ 10% of $13,000 = $1300 Effect on schedule Approximately 1 month