A colleague who is a very good programmer produces software with a low number of

Crosby, P. 1979. Quality is Free. New York: McGraw-Hill. El-Amam, K. 2001. ‘Object-oriented Metrics: A Review of Theory and Practice’. National Research Council of Canada. http:seg.iit.nrc.caEnglishabstractsNRC44190.html . Endres, A. and Rombach, D. 2003. Empirical Software Engineering: A Handbook of Observations, Laws and Theories. Harlow, UK: Addison-Wesley. Fagan, M. E. 1976. ‘Design and code inspections to reduce errors in program development’. IBM Systems J., 15 3, 182–211. Fagan, M. E. 1986. ‘Advances in Software Inspections’. IEEE Trans. on Software Eng., SE-12 7, 744–51. Gilb, T. and Graham, D. 1993. Software Inspection. Wokingham: Addison-Wesley. Grady, R. B. 1993. ‘Practical Results from Measuring Software Quality’. Comm. ACM, 36 11, 62–8. Gunning, R. 1962. Techniques of Clear Writing. New York: McGraw-Hill. Hall, T. and Fenton, N. 1997. ‘Implementing Effective Software Metrics Programs’. IEEE Software, 14 2, 55–64. Humphrey, W. 1989. Managing the Software Process. Reading, Mass.: Addison-Wesley. IEC. 1998. ‘Standard IEC 61508: Functional safety of electricalelectronicprogrammable electronic safety-related systems’. International Electrotechnical Commission: Geneva. IEEE. 2003. IEEE Software Engineering Standards Collection on CD-ROM. Los Alamitos, Ca.: IEEE Computer Society Press. Ince, D. 1994. ISO 9001 and Software Quality Assurance. London: McGraw-Hill. Kilpi, T. 2001. ‘Implementing a Software Metrics Program at Nokia’. IEEE Software, 18 6, 72–7. Kitchenham, B. 1990. ‘Measuring Software Development’. In Software Reliability Handbook. Rook, P. ed.. Amsterdam: Elsevier, 303–31. McConnell, S. 2004. Code Complete: A Practical Handbook of Software Construction, 2nd edition. Seattle: Microsoft Press. Mills, H. D., Dyer, M. and Linger, R. 1987. ‘Cleanroom Software Engineering’. IEEE Software, 4 5, 19–25. Offen, R. J. and Jeffrey, R. 1997. ‘Establishing Software Measurement Programs’. IEEE Software, 14 2, 45–54. Stalhane, T. and Hanssen, G. K. 2008. ‘The application of ISO 9001 to agile software development’. 9th International Conference on Product Focused Software Process Improvement, PROFES 2008, Monte Porzio Catone, Italy: Springer. 680 Chapter 24 ■ Quality management Configuration management 25 Objectives The objective of this chapter is to introduce you to configuration management processes and tools. When you have read the chapter, you will: ■ understand the processes and procedures involved in software change management; ■ know the essential functionality that must be provided by a version management system, and the relationships between version management and system building; ■ understand the differences between a system version and a system release, and know the stages in the release management process. Contents 25.1 Change management 25.2 Version management 25.3 System building 25.4 Release management 682 Chapter 25 ■ Configuration management Software systems always change during development and use. Bugs are discovered and have to be fixed. System requirements change, and you have to implement these changes in a new version of the system. New versions of hardware and system plat- forms become available and you have to adapt your systems to work with them. Competitors introduce new features in their system that you have to match. As changes are made to the software, a new version of a system is created. Most sys- tems, therefore, can be thought of as a set of versions, each of which has to be main- tained and managed. Configuration management CM is concerned with the policies, processes, and tools for managing changing software systems. You need to manage evolving sys- tems because it is easy to lose track of what changes and component versions have been incorporated into each system version. Versions implement proposals for change, corrections of faults, and adaptations for different hardware and operating systems. There may be several versions under development and in use at the same time. If you don’t have effective configuration management procedures in place, you may waste effort modifying the wrong version of a system, deliver the wrong version of a system to customers, or forget where the software source code for a particular version of the system or component is stored. Configuration management is useful for individual projects as it is easy for one person to forget what changes have been made. It is essential for team projects where several developers are working at the same time on a software system. Sometimes these developers are all working in the same place but, increasingly, development teams are distributed with members in different locations across the world. The use of a configuration management system ensures that teams have access to infor- mation about a system that is under development and do not interfere with each other’s work. The configuration management of a software system product involves four closely related activities Figure 25.1: 1. Change management This involves keeping track of requests for changes to the software from customers and developers, working out the costs and impact of making these changes, and deciding if and when the changes should be implemented. 2. Version management This involves keeping track of the multiple versions of system components and ensuring that changes made to components by different developers do not interfere with each other. 3. System building This is the process of assembling program components, data, and libraries, and then compiling and linking these to create an executable system. 4. Release management This involves preparing software for external release and keeping track of the system versions that have been released for customer use. Configuration management involves dealing with a large volume of information and many configuration management tools have been developed to support CM Chapter 25 ■ Configuration management 683 Release Management Change Proposals Change Management System Releases Component Versions System Versions Version Management System Building Figure 25.1 Configuration management activities processes. These range from simple tools that support a single configuration man- agement task, such as bug tracking, to complex and expensive integrated toolsets that support all configuration management activities. Configuration management policies and processes define how to record and process proposed system changes, how to decide what system components to change, how to manage different versions of the system and its components, and how to distribute changes to customers. Configuration management tools are used to keep track of change proposals, store versions of system components, build systems from these components, and track the releases of system versions to customers. Configuration management is sometimes considered to be part of software quality management covered in Chapter 24, with the same manager having both quality management and configuration management responsibilities. When a new version of the software has been implemented, it is handed over by the development team to the quality assurance QA team. The QA team checks that the system quality is acceptable. If so, it then becomes a controlled system, which means that all changes to the system have to be agreed on and recorded before they are implemented. The definition and use of configuration management standards is essential for quality certification in both the ISO 9000 and the CMM and CMMI standards Ahern et al., 2001; Bamford and Deibler, 2003; Paulk et al., 1995; Peach, 1996. These CM standards can be based on generic CM standards that have been devel- oped by bodies such as the IEEE. For example, standard IEEE 828-1998 is a stan- dard for configuration management plans. These standards focus on CM processes and the documents produced during the CM process. Using the external standards as a starting point, companies then develop more detailed, company-specific stan- dards that are tailored to their specific needs. One of the problems of configuration management is that different compa- nies talk about the same concepts using different terms. There are historical 684 Chapter 25 ■ Configuration management reasons for this. Military software systems were probably the first systems in which configuration management was used and the terminology for these sys- tems reflected the processes and procedures already in place for hardware con- figuration management. Commercial systems developers were not familiar with the military procedures or terminology and so often invented their own terms. Agile methods also have devised new terminology, sometimes intro- duced deliberately to distinguish the agile approach from traditional CM meth- ods. Figure 25.2 defines the configuration management terminology that I use in this chapter. Figure 25.2 CM terminology Term Explanation Configuration item or software configuration item SCI Anything associated with a software project design, code, test data, document, etc. that has been placed under configuration control. There are often different versions of a configuration item. Configuration items have a unique name. Configuration control The process of ensuring that versions of systems and components are recorded and maintained so that changes are managed and all versions of components are identified and stored for the lifetime of the system. Version An instance of a configuration item that differs, in some way, from other instances of that item. Versions always have a unique identifier, which is often composed of the configuration item name plus a version number. Baseline A baseline is a collection of component versions that make up a system. Baselines are controlled, which means that the versions of the components making up the system cannot be changed. This means that it should always be possible to re-create a baseline from its constituent components. Codeline A codeline is a set of versions of a software component and other configuration items on which that component depends. Mainline A sequence of baselines representing different versions of a system. Release A version of a system that has been released to customers or other users in an organization for use. Workspace A private work area where software can be modified without affecting other developers who may be using or modifying that software. Branching The creation of a new codeline from a version in an existing codeline. The new codeline and the existing codeline may then develop independently. Merging The creation of a new version of a software component by merging separate versions in different codelines. These codelines may have been created by a previous branch of one of the codelines involved. System building The creation of an executable system version by compiling and linking the appropriate versions of the components and libraries making up the system. 25.1 ■ Change management 685 Figure 25.3 The change management process

25.1 Change management

Change is a fact of life for large software systems. Organizational needs and require- ments change during the lifetime of a system, bugs have to be repaired, and systems have to adapt to changes in their environment. To ensure that the changes are applied to the system in a controlled way, you need a set of tool-supported, change management processes. Change management is intended to ensure that the evolution of the system is a managed process and that priority is given to the most urgent and cost-effective changes. The change management process is concerned with analyzing the costs and bene- fits of proposed changes, approving those changes that are worthwhile, and tracking which components in the system have been changed. Figure 25.3 is a model of a change management process that shows the principal change management activities. There are many variants of this process in use but, to be effective, change manage- ment processes should always have a means of checking, costing, and approving changes. This process should come into effect when the software is handed over for release to customers or for deployment within an organization. The change management process is initiated when a ‘customer’ completes and submits a change request describing the change required to the system. This could Customer Support Development Submit CR Customer Product DevelopmentCCB Change Requests Select CRs Close CRs Assess CRs Valid Invalid Register CR Close CR Check CR Pass Fail Close CR Implementation Analysis CostImpact Analysis Modify Software Test Software 686 Chapter 25 ■ Configuration management Figure 25.4 A partially completed change request form be a bug report, where the symptoms of the bug are described, or a request for additional functionality to be added to the system. Some companies handle bug reports and new requirements separately but, in principle, these are both simply change requests. Change requests may be submitted using a change request form CRF. I use the term ‘customer’ here to include any stakeholder who is not part of the development team, so changes may be suggested, for example, by the market- ing department in a company. Electronic change request forms record information that is shared between all groups involved in change management. As the change request is processed, infor- mation is added to the CRF to record decisions made at each stage of the process. At any time, it therefore represents a snapshot of the state of the change request. As well as recording the change required, the CRF records the recommendations regarding the change; the estimated costs of the change; and the dates when the change was requested, approved, implemented, and validated. The CRF may also include a sec- tion where a developer outlines how the change may be implemented. An example of a partially completed change request form is shown in Figure 25.4. This is an example of a type of CRF that might be used in a large complex systems engineering project. For smaller projects, I recommend that change requests should be formally recorded and the CRF should focus on describing the change required, with less emphasis on implementation issues. As a system developer, you decide how to implement that change and estimate the time required for this. Change Request Form Project: SICSAAppProcessing Number: 2302 Change requester: I. Sommerville Date: 200109 Requested change: The status of applicants rejected, accepted, etc. should be shown visually in the displayed list of applicants. Change analyzer: R. Looek Analysis date: 250109 Components affected: ApplicantListDisplay, StatusUpdater Associated components: StudentDatabase Change assessment: Relatively simple to implement by changing the display color according to status. A table must be added to relate status to colors. No changes to associated components are required. Change priority: Medium Change implementation: Estimated effort: 2 hours Date to SGA app. team: 280109 CCB decision date: 300109 Decision: Accept change. Change to be implemented in Release 1.2 Change implementor: Date of change: Date submitted to QA: QA decision: Date submitted to CM: Comments: