1. Configuration and Change Management
Managing the products of system change

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

3. 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

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

5. Configuration Items (CI’s)
Units tracked officially
down to the smallest unit worth tracking
includes most official documents
Module updated
Payroll v
Payroll v
Payroll v 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.

6. Configuration Items (CI’s)
Units tracked officially
down to the smallest unit worth tracking
includes most official documents
Module added
Payroll v
Payroll v
Payroll v 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.

7. 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:
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.

8. System Families

9. 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

10. IEEE 828-1990 SCMP Table of Contents
3.2 Configuration control
Requesting changes
Evaluating changes
Approving or dis-
approving changes
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
Identifying configu-
ration items
Naming configu-
Acquiring configu-
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

11. 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.

12. 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

13. The Change Management Process

14. The Change Management Process

15. The Change Management Process

16. The Change Management Process

17. 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

18. Change Request Form

19. 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

20. 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 systems allowing electronic change request distribution

21. 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

22. 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

23. Component Header Information

24. 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

25. 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

26. 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

27. 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