Configuration and Change Management

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. 0.4.1.0 Payroll v. 0.3.4.3 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.

5. Configuration Items (CI’s) Units tracked officially • down to the smallest unit worth tracking • includes most official documents Module updated Payroll v. 0.4.1.0 Payroll v. 0.3.4.3 Payroll v. 0.3.4.2 S7 S6 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. 0.4.1.0 Payroll v. 0.3.4.3 Payroll v. 0.3.4.2 S7 S7 S6 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: http://dmoz.org/Computers/Software/Configuration_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 http://www.rspa.com/spi/SCM.html

10. 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- ration items 3.1.3 Acquiring configu- ration items 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. ChangeRequestForm

19. Assessment portion of Change Request Form • Assessment • 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 E-mail 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. 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