## 4.12 Software Configuration Management When developing a solution, hundreds of artefacts like documents, code files, scripts, deliverables, etc, are created and need to be managed. In PM2-Agile, Software Configuration Management provides key activities that will consistently control the changes to the configuration and maintain its integrity and traceability. Software Configuration Management has four primary objectives. - **Identify and manage all items that are part of configuration management** – The Agile Project Core Team (A-PCT) must identify all the items (classes, libraries, test scripts, deployment files, etc) they need to keep track of and manage them with the help of specific tools. - **Simplify the build of different versions of the solution** – Solution development is an incremental process where different versions are regularly being demonstrated and delivered. As such, it’s of paramount importance to easily build and deliver a specific version of the solution. - **Ensure quality is maintained as configuration evolves** – As the configuration continuously evolves, it’s important to ensure that the quality of the solution is maintained. This is done by keeping track of the configuration items, their history of changes and the ability to see the impact of those changes. - **Increase Productivity by reducing mistakes** – Using the right set of tools, Software Configuration Management can be automated to the point where human intervention becomes residual. By dramatically reducing human intervention and consequently, mistakes, productivity will increase. As a process, Software Configuration Management has a set of steps that PM2-Agile acknowledges as key enablers of the objectives aforementioned. - **Identification** – Uniquely identify each configuration item to be added to the configuration management repository. Using an object oriented approach is usually a good practice, since this will also facilitate aggregation in similar types of objects (documents, scripts, etc). Properties like name, version, type of item, resources needed, etc are some of the most commonly used. - **Change Control** – The Change Control is already foreseen as a PM2 process that defines several activities related to project changes, including documenting, assessing, approving, - **Version Control** – setup a set of procedures and tools to enable the creation and management of the multiple occurrences of each object in the configuration management repository. For software development, it should be possible for an Agile Team Member (ATeM) to collect all relevant configuration objects and build a specific version of the solution. - **Configuration Auditing** – This is clearly a quality assurance activity. The goal is to ensure that quality is maintained as changes are made. The extent of this activity will depend on the context of the project. Typically, it addresses questions like verifying if the change was properly highlighted and documented and the author identified or if the configuration management procedures for noting, recording and reporting the change have been properly followed. Configuration Auditing will help ensuring that the correct configuration objects have been incorporated on a specific build. - **Reporting** – Provides information to anyone within the project (and organisation) who requires information regarding the changes occurred. Reporting should detail the change initiator, the time/date of the change, the scope of the change and other relevant information. Triggered when a configuration audit is conducted or when new or updated information is assigned to a configuration object, reporting should be aligned with the PM2 Communications Management Plan. As a configuration item moves through the process, the actions implied in one of the steps may not be applicable. As an example, a change in a configuration script may not need the actions involved in the Change Control step, as a change request is probably not needed. ![[4.10 Steps for Software Configuration Management.png]] Any relevant development-specific considerations regarding the software Configuration Management (e.g. tools to use, templates to apply), should be documented in alignment with the PM2 Quality Management Plan. The following are typical activities and key considerations when tailoring the Configuration Management process. - Assign each Configuration Item to a specific version of the solution. - Maintain a record of each Configuration Item (name, creation date, last update, version, etc) for audit purposes. - Describe conventions for naming and versioning project and product work products in compliance with corporate regulations, if applicable. - Adopt a standard product directory structure to place artefacts under version control. - Synchronisation control ensures parallel changes will not override each other. - Analyse issues involved in setting up the Configuration Management environment, which include: - Anticipated size of product data. - Distribution of the product team. - Physical location of servers and client machines. Adopt a standard template for the project’s Configuration Management system that establishes appropriate streams, roles and responsibilities. Ensure a Configuration Management capability for managing change requests, including enhancements and defects generated by the team and external stakeholders. Be aware and comply with policies for project media storage and release. Document how software developed by vendors and subcontractors is incorporated into version control.