Change and Configuration Management Standards

Business Solutions Center of Excellence Change and Configuration Management Standards Version 1.1 Change and Configuration Management Standards OA/OIT Page 3 1 Change and Configuration Management Standards 1. Introduction 1.1 Purpose This document details the Change and Configuration Management standards for the Business Solutions Center of Excellence. The focus of this document is to clearly communicate and explain the criteria for implementing effective and efficient change and configuration management in an environment that supports shared documentation, code, and executable components across the enterprise. 1.2 Scope The scope of this document is for Change and Configuration Management practices for the operation of the Business Solutions Center of Excellence as well as organizations contributing to the Business Solutions Center of Excellence enterprise repository. 1.3 References G001 – Glossary IEEE 828 Software Configuration Management Plans IEEE 1042 Software Configuration Management ANSI/EIA -649 National Consensus Standard for Configuration Management MIL-STD-973 (1992) Configuration Management DOE-STD-1073-93 Guide for Operational CM IEEE-STD-610 IEEE Computer Dictionary -Compilation of IEEE Standard Computer Glossaries 1.4 Overview This document begins with a broad definition of a Change and Configuration Management (CCM) process for the Business Solutions Center of Excellence. The definition includes best practices for both the enterprise as well as project level change and configuration management. The remainder of the document details CCM in terms of roles and responsibilities; tasks and activities; and artifacts. Lastly, this document addresses CCM software tools to be used in an overall process. Change and Configuration Management Standards OA/OIT Page 4 2. Configuration and Change Management (CCM) Process Definition CCM is the discipline of applying technical and administrative direction to identify and document functional and physical characteristics of a particular hardware configuration item, software configuration item; control changes to such characteristics; record and report change processing and implementation status; and verify compliance with specified requirements (per IEEE-STD-610). CCM is an integral part of any software development process. CCM can be viewed as part of an overall software development process or as standalone process that works within a software development process. Certain aspects of CCM also go towards meeting the goals of a quality assurance process. 2.1 Enterprise and Project CCM In the context of the Business Solutions Center of Excellence, CCM plays a vital role of insuring reusable application components are managed for change across the enterprise. Change to enterprise application components left unmanaged will promulgate defects to potentially many applications. This is a risk that is inherent in the use of any shared component, but is a significantly greater risk when components are shared widely. A CCM process in conjunction with a Quality Assurance process mitigates these risks. A CCM process manages and communicates change. More importantly, when quality is built into the process, change is tested and verified thus insuring the robustness and stability of applications across the enterprise. However, quality does not begin at the enterprise. Quality begins at the individual project level where components are first built. Without quality at the project level, reusable aspects of the project can not be promulgated to the enterprise. A CCM process is thus equally important at project level as it is at the enterprise level. This document defines a standard for CCM that works equally well for enterprise as well as projects. One way of viewing the CCM process defined in this document is that it is a model way of performing CMM. As a model, it gives a standard to concretely implement a CCM process for the enterprise or a project. Models are inherently abstractions of concrete implementation. Given this, the best practice is to implement a CCM process that is tailored to the specific requirements of enterprise and to the specific requirements on individual projects. This best practice means that a CCM process implemented at the project level will vary from project to project and from the enterprise implementation of the CCM process. The size of a project and number of developers has the most significant impact on an implementation of the CCM process. Smaller projects have fewer resources but concurrently have less CCM work to be performed. Certain roles and responsibilities that would be allocated to number of people on a large project can be combined to fewer people on a smaller project. This idea holds true for the activities performed by people on projects. Smaller projects tend to have less formalism and ceremony than larger projects. For instance, a large project consisting of many developers may implement a Change Control Board to handle change requests, while a small project a project manger can approve, postpone, and reject changes. 2.2 Enterprise and Project Repositories Central to the CCM process is a repository for shared artifacts. The term artifact is used to describe any work product that is shared in a software development effort, including source code, executable code, documentation, help files, etc. An enterprise (centralized) repository is required for artifacts shared across the enterprise. At the project level there will be artifacts that are shared within project but not the enterprise. Commingling of project level and enterprise level artifacts in the same repository must be avoided to effectively and efficiently manage change to shared artifacts. This brings about the necessity of project repositories. Repositories require a combination of hardware and software; however the idea of enterprise and project repositories is a logical one. Physically, multiple repositories may coexist on the same hardware and software platform. The important aspect of separate enterprise and project repositories is that repository becomes a unit of decomposition for managing change. Change and Configuration Management Standards OA/OIT Page 5 2.3 Best Practices for a CCM Process Effective CCM can be achieved through a business process that manages change. This business process can be automated by software. Software for CCM typically has two major features. 1.) The ability to manage change requests, including defects, enhancements, issues and documentation changes. 2.) The ability to manage software assets in a software development process including design models, documentation, code and tests. The automation of the CCM business process reduces defects in the CCM process execution. It is inherently a best practice to automate as much of CCM process as possible, however there still remains a significant manual aspect to any CCM process. Sections 2.3.1 through 2.3.6 provide an overview of the best practices for the high-level manual processes associated with a CCM process. 2.3.1 Planning Planning is the first step to implementing effective and efficient Configuration and Change Management. A plan establishes appropriate activities to manage and control change to artifacts that are developed in a software development process. Artifacts consist of documents, models, code and any other item that can change during the development process that may affect a software build. The planning activity establishes policies to be used to monitor and safeguard project assets, and to enforce software development practices. CCM policies should facilitate communication and optimize the process of integrating work from multiple sources. The other primary aspect of planning is to establish a change control process. A change control process ensures that changes are made in a consistent manner. A Configuration Management Plan serves as a primary vehicle to communicate the change control process. 2.3.2 Create Configuration Management Environment A CM environment is where an overall deliverable, for instance, an application executable can be developed, built, and deployed. When establishing a CM Environment a repository is used. A repository can be as simple as a shared directory on a file server to the use of CM software. The key to establishing a CM environment is to insure that essential artifacts are obtainable when developers require them and the artifacts are versioned and stored for future use. 2.3.3 Managing Change Requests Change requests are documents that track defects, enhancements and any other of change for a deliverable. Change requests can be paper-based or computer-based as part of CM software. Change requests are important because they provide the mechanism to track and communicate change. Managing change requests begins with the submission of a change request. Change requests are reviewed, accepted, postponed, or rejected. Actions made to a change request need to be communicated to appropriate stakeholders and ultimately approved change requests need to be verified against changes made in the build of software. 2.3.4 Monitoring and Reporting Information needs vary based on size of projects with larger projects consisting of more team members requiring greater reporting needs. Monitoring goes hand-in-hand with reporting. Consistent monitoring and/or automated monitoring of configuration artifacts allows for more frequent and timely reporting. Reporting aids in tracking change and facilitating the communication of the progress in implementing change. Change and Configuration Management Standards OA/OIT Page 6 2.3.5 Managing the CM Environment Once a CM environment (repository) is established and work commences on a project, new development and changes will occur. The process of managing the CM environment coordinates the introduction of new and change development artifacts so that they may be integrated with existing development artifacts. The CM environment needs to be updated with correct baselines and versions of development artifacts throughout the life of a project. 2.3.6 Deploying Releases The process of deploying releases coordinates the building of release candidates and production versions of software. Deploying releases is also important in terms of promoting a project level component to an enterprise level shared component. In this case, a project level component is moved from a project repository to an enterprise repository. Change and Configuration Management Standards OA/OIT Page 7 3. Roles and Responsibilities Roles and responsibilities provide a mechanism to understand the CCM process from people-centric point of view. The following are the key roles and responsibilities in the CCM process. Several roles may be performed by one individual on smaller projects. Alternatively, several people could fulfill one role on very large projects. 3.1 Configuration Manager The Configuration Manager supports the overall CM environment so that developers have an appropriate environment to build and test their work, and so that all artifacts are available for deployment as required. The Configuration Manager role also has to ensure that the CM environment facilitates product review, and change and defect tracking activities. This role is responsible for writing the CM Plan and reporting progress statistics based on change requests. 3.1.1 Configuration Manager Responsibilities -Setup and maintain the CM Environment -Perform Configuration Audits -Reports on Configuration Status 3.2 Change Control Manager The Change Control Manager manages the CCM process for all changes to a project. The Change Control Manager decides on a case-by-case basis whether a change request warrants the advisory consultation of the Change Control Board, project Stakeholders or additional Approvers. If the change request is simple, routine, or clearly unacceptable, the Change Control Manager may use discretion to approve or deny the request without additional consultation in order to expedite decision making. 3.2.1 Change Control Manager Responsibilities Management Responsibilities include: -Coordinate the movement of Change Requests through Change Management Process -Manage the change approval process in conjunction with the Change Control Board -Convene the Change Control Board meetings as required -Produce minutes of Change Control Board meetings including current status of all open Change Requests. Make minute available to Change Control Board and appropriate Stakeholders -Advise appropriate parties of status of changes. -Verify closure of change. Change Tracking Responsibilities include: -Maintain change log with the status of Change Requests from inception through closure. -Verify the Change Requests are correctly completed -Ensure all signoffs are obtained in accordance with change management procedure -Notify appropriate parties of Change Request status -Create Change Management Reports as necessary 3.3 Change Control Board The Change Control Board consists of representatives from all interested parties, including customers, developers, and users of a project. In a small project, a single team member, such as the project manger or Change Control Manager may play this role. The CCB provides a forum to review Change Requests on a regular basis. The Change Control Manager convenes the CCB. Change and Configuration Management Standards OA/OIT Page 8 3.3.1 Change Control Board Responsibilities -Assess and prioritize Change Requests -Approve or secure approvals for Change Requests 3.4 Change Approver The Change Approver reviews and approves Change Requests. One or more people may play this role on a project, however it is imperative that there is one individual that is identified and has the authority to make final decisions on Change Requests. 3.4.1 Change Approver Responsibilities -Assess the benefit of the change in relation to cost -Assess the business risk and impact of change -Ensure that the technical feasibility, risk and effect of the change have been adequately assessed -Approve or reject Change Requests 3.5 Change Requestor The Change Requestor is a stakeholder on the project that initiates the change process through the creation of a Change Request. 3.5.1 Change Requestor Responsibilities -Identify the business, service or technical need for the change -Define the success criteria for the change -Categorize the change -Propose the change solution in business or technical terms as appropriate -Propose a date by which the change will be implemented -Identify the affected parties -Submit the Change Request for approval -Attend Change Control Board meetings as required 3.6 Change Stakeholder Different parties have a stake in the quality of the outcome and the impact of changes on a project. Parties that have an interest in a particular project are generically referred to as the Change Stakeholder for that project. For specific changes the Change Requestor may nominate particular end users as a Change Stakeholder. 3.6.1 Change Stakeholder Responsibilities -Provide input on impacts of changes to project -For changes to other projects, consult on possible impacts on the project of interest -Attend Change Control Board meetings as required -For changes to the project of interest, the Change Stakeholder will need to approve the results at various stages of the change development, i.e., functional specification, implementation planning and acceptance testing. Change and Configuration Management Standards OA/OIT Page 9 3.7 Change Developer The Change Developer is the person responsible for scheduling, building and testing the solution that will satisfy a change request. 3.7.1 Change Developer Responsibilities -Accept approved Changes Requests for solution development 3.8 Change Implementer The Change Implementer is responsible for placing the solution to a Change Request into practice. In a technical environment, this would include the activities that promote the change to the production environment. For a functional change, this could include imp lementing changes in workflow. The Change Implementer is responsible for all testing in a parallel environment prior to making the change into the production system. Such testing must include assurances that implementation of the change does not cause any malfunctions to occur in other operations. The final step also includes verification of the proper functioning of the change solution after it is in use. 3.8.1 Change Implementer Responsibilities -Advise the Change Control Manager of the operational status of the change Change and Configuration Management Standards OA/OIT Page 10 4. Tasks and Activities Tasks and activities describe the CCM process from a functional point of view. Important things to note are the roles assigned to the activities, the timing and frequency of activities, and the optionality of activities. Optionality of activities pertains primarily to the size of a project. 4.1 Create Configuration Management Plan The Configuration Management (CM) Plan is created by the configuration manager and change control manager roles. Often these roles are assigned to one individual on smaller projects. Creating a CM Plan is not optional; however the detail the plan varies from project to project based on size of project. At the enterprise level, the CM Plan specifies significantly greater detail than at the project level given the risks associated with maintaining an enterprise repository. CM Plans are to be viewed as living documents that are modified as needed to adapt to environmental changes. CM Plans are typically created in the first iteration of a development cycle and are fine-tuned as the number of artifacts increase in a repository. Creating a CM Plan consists of identifying and establishing CM policies used to identify, safeguard and report on artifacts. Additionally policies and processes associated with change control are identified and established. 4.1.1 Identify and Establish CM Policies 4.1.1.1 Configuration Identification Configuration identification provides the ability to quickly and easily find specific versions of artifacts. In establishing a configuration identification policy, a labeling and versioning scheme is created to identify artifacts. 4.1.1.2 Baselining A baseline is a stable point or snapshot of an artifact in the life of an artifact. A baselining policy specifies when and the types of artifacts are baselined. In a project setting, baselining usually occurs at predefined specific milestones specified in the project plan. 4.1.1.3 Backup and Recovery The CM plan specifies policies associated with backup and recovery procedures for a repository. This often corresponds to the same procedures used for other servers in the enterprise. 4.1.1.4 Reporting Reporting configuration information is an excellent tool for project managers to gauge the progress and the amount of change made on project. Reporting also aids inspection and auditing to be performed on repository. A CM plan defines what CM data is captured for reporting purposes and who is responsible for generating the reports as well as how often the reports are generated. 4.1.2 Identify and Establish Change Control Process The change control process is one particular aspect of overall CCM process. Change Control refers to the specific procedures used to implement and communicate change. Change and Configuration Management Standards OA/OIT Page 11 4.1.2.1 Create Change Request Form A Change Request (CR) form is the primary communication mechanism for change in a CCM process. A CR identifies who, what, when, where and why of changes. The information on a CR is often the primary input into reporting (see section 4.1.1.4). CR can be paper based or electronically based if use CM software. Creating a CR in CM software requires configuration of the software. From the standpoint of the CM Plan, creating a CR means identifying what information is to be collect to support the surrounding change control process. 4.1.2.2 Create Change Control Process The CM Plan defines the change control process from the standpoint of people and activities in the process. Change Control Processes do not vary significantly from one project to another or from one organization to other. The overall process defines: 1. How a change request is submitted 2. How a change request is analyzed 3. How to approve/reject/postpone a change request 4. How to implement the changes of an approved change request 5. How postponed change request reenter the approval process 6. How change requests are retained for reporting and other purposes 4.1.3 Establish Change Control Board (CCB) A Change Control Board approves/rejects/postpones changes made to artifacts. At the project level, there may or may not be a CCB depending on the size of the project. One way of thinking of a CCB is that it is the approval mechanism of change. This may be the project manager or a board that consists of stakeholders for a project. The most important aspect of the CCB is that it has the authority to approve/reject/postpone change. The CM Plan specifies who will be on the CCB and how the CCB operates. Often a CCB will have one member appointed as a chair to arbitrate conflicts and to enforce decision of the board. The CM Plan needs to specify the frequency and where the CCB will meet as well as how decisions of the board are communicated. 4.2 Create CM Environment Creating a CM environment occurs once for the enterprise and once for each project. The purpose of creating the CM environment is the setup the hardware and software required to run a repository. This includes configuring the repository for first use. Over-time the CM environment needs to be maintained as part of the on-going activities of a CCM process. (See Section 4.5) The configuration manager is the role that works with a system administrator create CM environment. 4.2.1 CM Environment Considerations There are two primary considerations in creating and using a CM environment across an enterprise; containment of change and proliferation of stable work product. Containment of change physically controls work products as they are under development so that change to the work product can be management. It is imperative that work product undergoing change does not reach a production environment or other active projects while in a not stable state. The CM environment facilitates containment. Once work products have been stabilized, tested and rolled out to production there is also a need to share the stable work products across the enterprise. The process of sharing and using work product is facilitated by the CM environment. Change and Configuration Management Standards OA/OIT Page 12 The following diagram provides an example of four CM environments; an Enterprise Repository and three project repositories. The box labeled “Production” represents the production environment and is not a repository. The repository for Project A is shown in a pre-deployment state. Within Project A’s repository there are many components, documents, source code, etc. (not shown), but there is one component, shown as Component A, that has been identified for enterprise reuse. The notion of enterprise reuse for Component A is that Component A can be used in a number of development projects across the enterprise. The dashed lines on the diagram represent directional flow between repositories and the production environment for this example. Component A, is going to be copied into the Enterprise Repository, and thus the directional flow is from the Project A Repository to the Enterprise Repository. An important qualification for copying Component A into the Enterprise Repository is that Component A must have been tested and is in a state that precludes change. It would seem on the surface that if Component A is fully tested as part of Project A and that Component A has zero defects for Project A, that the component would be ready for use in other projects as well. History has shown that this assumption is downfall of component reuse. While Component A has been fully tested for Project A, it has not necessarily been tested for enterprise use. Testing for enterpris e use is substantially more rigorous than for a single application. For a component to work in a single application, the component needs to meet the needs of the application, which are fully known while developing the application. However, all of the ways that the component will be used across the enterprise are not known. If fact, how a component will be used across the enterprise will not be known until there is perfect knowledge of each project that will use the component. The solution to this unknown is for the component to undergo rigorous enterprise verification prior to the component to be deployed for any project. This needs to occur in a stable CM environment separate from any other CM environment. This is known as the Verification Workspace in the diagram that follows. Change and Configuration Management Standards OA/OIT Page 13 The Verification Workspace is a subsection of the Enterprise Repository where components undergo rigorous verification for enterprise use. (Testing and verification are detailed in the Rational Unified Process and Microsoft Solutions Framework.) When a component is moved from a project into the Verification Workspace, the component in the project must be locked to changes at the project level. This may seem trivial since in the example above, Component A was already tested. However, locking the component ensures that no changes are made at the project level to the component and that the component remains synchronized with the component in the Verification Workspace. Assuming that Component A passes enterprise verification without change, the component can be moved into a Shared Workspace for reuse on other projects and deployed into Production. Change and Configuration Management Standards OA/OIT Page 14 Once Component A has been verified and moved into the Shared Workspace and copied into production, Component A remains locked in the Project A Repository. Changes to Component A within Project A at this point would require the production component to change, and there would also be a difference between Component A in Project A and Component A in the Shared Workspace in the Enterpris e Repository. There are two strategies to synchronize different versions of Component A. The first is not to synchronize. Typically in component technologies, a change to a published or deployed component is treated as creating an entirely new component. This especially true if the interface of the component has changed. A second strategy can be used when a defect has been found in a component that does not affect the interface of the component. This second strategy would fix the defect in the component with an entire new round of testing and verification which would lead a stable state for the component in the production environment, enterprise repository, and all project repositories using the component. This last strategy is not ideal and should only be employed for critical defects. In sense, this example shows an overwhelming reason for proper CCM and testing practices. Suppose that a component was deployed to production for one project, and then reused on several other projects. Then a critical defect is found in the component. CCM allows for the change to be managed across all projects and the production environment. The next diagram assumes success in verification and the deployment of Component A. Component A resides in the Shared Workspace in the Enterprise Repository and is locked to changes. This keeps it synchronized with Project A and the production environment. The diagram above also shows the scenario of another project, Project B, reusing Component A. Project B is going to reuse Component A without any changes to the component. Component A is locked in Project B’s repository so change cannot occur. If fact, the safest method of using Component A in Project B is in binary form so no change to Component A’s code can occur. This keeps all copies of Component A synchronized across the enterprise. In the next diagram, a new project, Project C wants to reuse Component A from the Enterprise Repository; however Component A does will not work for Project C without change. This is a typical scenario in component reuse. An existing component may include 100% of the functionality required for one project but only 90% of the functionality for another. Change and Configuration Management Standards OA/OIT Page 15 If Project C cannot use Component A since it does not have 100% of the correct functionality Project C requires. However, Component A represents sizable work that would become rework on Project C if Project C did not reuse Component A in some way. The way to handle this scenario is to copy and rename Component A for use in Project C. Thus Component B in Project C is a renamed Component A. The source code for Component A becomes the starting point for Component B. From this point on, Component B is treated as a distinctly new component separate and apart from Component A. The following diagram shows the final states of the components Change and Configuration Management Standards OA/OIT Page 16 and repositories. If Component B is deemed to be an enterprise component, the component would go though project level testing and then to Verification Workspace in the Enterprise Repository for enterprise verification as discussed at the beginning of Section 4.2.1. 4.2.2 CM Environment Installation CM environment installation allocates hardware resources and installs the CM software. The primary considerations for hardware resource allocation are memory requirements to cache the repository, disk I/O throughput and network bandwidth for access to the repository, and disk space to house the repository. The primary activity of installing the CM software is configuring the repository. The initial steps in configuring the repository is organize the repository in a fashion to meet a project’s requirements. Repositories are generally implemented using hierarchical directory structures. The directory structure needs to match the logical organization of project artifacts. Overtime the structure of the repository will expand and change to facility build, test, and deployment activities of a project. At the enterprise level, the repository needs to be configured to handle the verification tasks discussed in section 4.2.1. At a very minimum the enterprise repository needs a Verification Workspace and Shared Workspace. A finer level of granularity is required when there are multiple components undergoing verification, with a Verification Workspace for each component. There may also be a need for preproduuctio and testing workspaces prior to deployment into production. 4.3 Manage Change Requests The core on-going activity of a CCM process is managing change requests. Change requests are the formal mechanism for communication and tracking change to development artifacts. The following state-chart diagram illustrates the change control process. The diagram depicts the state of a change request. A change request is created and submitted to the Change Control Board (CCB) for review. There are four basic courses of actions that CCB can take. The CCB can reject the CR, in which case the CR is closed. The CCB can postpone the CR to later in the development cycle, and the CCB can accept the CR. If a CR is postponed, it can be resubmitted at a later date for CCB review. The CCB may also request more information to be added to the CR. In this situation, the CR is appended with the additional information and resubmitted. Change and Configuration Management Standards OA/OIT Page 17 When a CR is accepted, the CR is assigned to a developer to make changes. When the changes are complete, the changes are verified. If the verification tests pass, the CR is closed. Otherwise, changes continue until the verification tests pass. 4.4 Monitoring and Reporting Monitoring of the CCM process allows reporting of significant information to manage the repository, application build, and the overall software development process. Best practices in monitoring consist of physical and functional audits. The results of audits form the basis of reports. A physical audit identifies the artifacts to be used to deploy an application from the repository. In a physical audit the files associated with a build are checked for correct baselines and versions. A physical audit includes source files, executable components, and optionally can include help files, documentation and other user files. A functional audit ensures that the functionality of build meets the requirements for a baseline. This includes auditing the CR submitted and approved for a given baseline build. The results of physical and functional audits lead to reports used by project management to assess the progress of change as well as stability of work products. 4.5 Manage CM Environment As artifacts are added to the repository, the CM Environment needs to be managed. Section 4.2 establishes the base configuration of the CM Environment. In this section, the on-going management details are explained. The CM Environment needs to support development, test, and deployment activities. A development workspace is created in the repository to separate development work from other on-going activities. The development workspace is populated with a project baseline which forms the basis to proceed with development activities. Separate workspaces are created for integration, test, and deployment activities. The complexity of maintaining the repository is directly proportionate to the complexity of the application architecture. Excellent architectures have the quality of simplicity, which is mirrored in the management of the repository. As changes are made to artifacts in the repository a number of CM operations are performed by developers. These logical (CM software may use slightly different terminology) operations include: -Check Out – allows access to change an artifact -Check In – stores a new version of an existing artifact with changes since last check out. -Add – stores a new artifact in the repository -Remove – removes an artifact from the repository -Move – moves an artifact from one repository or workspace to another -Copy – copies an artifact from one repository or workspace to another -Lock – insures no changes occur to an artifact in a repository Complexities arise when two developers check out the same artifact for development work. This is not necessarily a negative activity. Doing so allows parallel development on the same artifact, but changes need to be merged. The repository needs to be managed for merging purposes, particularly when source code artifacts need to be merged. In this case, a private integration workspace is created allowing the merger to be tested. After successful testing, a new baseline is established in the repository for the merged work. Change and Configuration Management Standards OA/OIT Page 18 4.6 Deploy Releases The process of deploying releases coordinates the building of release candidates and production versions of software. Deploying releases is also important in terms of promoting a project level component to an enterprise level shared component. In this case, a project level component is copied from a project repository to an enterprise repository into a verification workspace. Once enterprise verification has successfully occurred, the component is moved to a shared workspace for reuse and is deployed into production Change and Configuration Management Standards OA/OIT Page 19 5. Artifacts 5.1 Configuration Management Plan The Configuration Management (CM) Plan describes all Configuration and Change Control Management (CCM) activities you will perform during the course of the product or project lifecycle. It details the schedule of activities, the assigned responsibilities, and the required resources, including staff, tools, and computer facilities. 5.2 Project Repository The project repository stores all versions of project files and directories. It also stores all the derived data and metadata associated with the files and directories. 5.3 Change Request Change Requests are the primary artifact of a CCM process. Change Requests provide the audit trail of all changes that occur to a work product. The documentation of a Change Request allows project management to understand that state of change, the amount of change, and the progress of change on projects. This feedback allows more effective management of the overall development process. 5.4 Configuration Audit Findings A Configuration Audit Finding is a report from the process of performing a configuration audit. A configuration audit insures that there are no missing artifacts, and incompletely tested or failed requirements for a build coming out of a repository. 5.5 Test Results A Test Result is a report that provides summary information and analysis from the testing of a work product that resulted from the normal testing as part of the overall software development process or as a result of tests performed confirming changes made due to Change Requests. Change and Configuration Management Standards OA/OIT Page 20 6. CCM Software Tools 6.1 Need for CCM Software Tools A CCM process while not a very complicated process is very time consuming. The artifacts produced as part of a CCM process are fairly simple, but very time dependent. The tasks associated with a CCM process are also fairly simple, but as the number of artifacts increase the tasks associated with a CCM process take longer to perform. The automation of the CCM process allows tasks to be performed much faster and with greater precision. It is the precision and timeliness that insures that change is managed effectively. Software automation will be used as extensively as possible in maintaining the enterprise repository of the Business Solutions Center of Excellence as well as at the project level. There interdependence between enterprise and project repository requires all repositories to be compatible. Without compatible enterprise and project repositories, manual processes must be induced at one of the most critical aspects of the CCM process – managing change between the enterprise and projects. Section 6.2 details the requirements for CCM software, often called SCM (Software Configuration Management) software. 6.2 CCM Software Requirements 6.2.1 Data Storage Components must be stored in a repository. (This does not imply a single physical repository, or even a single logical repository, perhaps no more than an interface to a virtual repository.) Components must be versionable. Components must be uniquely identified across the virtual repository. This implies an identifier that is separate from the component name, since the name has no guarantee of uniqueness. Components must be searchable and retrievable. It must be possible to store metadata for components. It must be possible to store both black box (binary) components and source components. It must be possible to store and version all types of artifacts, including requirements, models, designs, specifications, source code, graphics, sound documents, test cases and results, etc. The repository must support arbitrarily defined relationships between artifacts. For example, if should be possible to relate a component to a requirement, a test cast, and a test result. 6.2.2 Composition and Configuration The system must have the ability to compose components with multiple levels of abstraction, and to version and reuse components at any level of abstraction. (For example, it must be possible to version an entire system comprising specific versions of individual components.) It must be possible to decompose artifacts into constituent parts, to allow versioning, parallel development, and ultimately reuse of the parts as well as the whole. The system must provide the ability to select specific versions of components to be included in a configuration, or to define rules that can select appropriate compatible members. The system must provide the ability to analyze systems and detect conflicts before build/test/deployment. The system must be able to support a variety of variants for each component. For example, components may have variants for different platforms and operating systems. The system must enable developers to compose systems from a combination of components and “glue code”. Change and Configuration Management Standards OA/OIT Page 21 The system must support different degrees of customization. For example, components may be delivered as source; therefore the system must enable local customization as well as integration. The system must provide the ability to assemble arbitrary groupings of data, simply file hierarchies. The system must provide namespace management such that the correct object is bound when the system is configured. (Namespace management is especially important in component-based systems because it is possible and even probably to have a variety of object with the same name and even type. These objects must be uniquely identified and bound such that they are never confused by mistake.) The system must present an object in proper location and context such that tools and other components can find it during construction, testing and runtime. 6.2.3 Distribution Supporting distribution of components through a variety of techniques including LAN or WAN, internet, ftp, mail and in a variety of granularities such as a single binary or source file to a grouping of files to grouping of versions across product boundaries. Support distribution of either binaries or code. Ability to automate software supply chain needs. Support vendor code management: easily receive updates and merge custom versions with the latest vendor code. 6.2.4 Process and Environment Supporting a variety development processes including publish/subscribe. Provide insulated environments for development and testing. Open systems to work with a variety of development/design/composition tools. Ability to manage changes (a level above versioning: change request tracking). Ability to track defect reports and enhancement requests in vendor-provided components or code. Ability to generate reports based on current configuration and changes to configuration. 6.3 Hardware Requirements Hardware Requirements are dictated by the CCM software manufacturer. This invariably consists of a dedicated server for the software. The enterprise repository for the Business Solutions Center of Excellence must be housed on dedicated server that has fully automated backup and recovery procedures. Project repositories should be housed on dedicated servers separate from the enterprise repository. This autonomy of project repositories allows the hardware environment to be managed at finer level or granularity and also eliminates the risk of one shared server failing and taking down all enterprise projects within the Commonwealth. See the Software Plan (SWP001) for the CCM software selection and the Hardware Plan (HP001) for server specifications.