From MIKE2 Methodology
| This deliverable template is used to describe a sample of the MIKE2.0 Methodology (typically at a task level). More templates are now being added to MIKE2.0 as this has been a frequently requested aspect of the methodology. Contributors are strongly encouraged to assist in this effort.
|
| Deliverable templates are illustrative as opposed to fully representative. Please help add examples to this template that are representative of the proposed output.
|
The Configuration Management Baseline includes ensuring the development team has the correct versions of source code, vendor products, files for compilation and linkage, procedures for check-in, check-out and the capability to conduct development in a fashion that won’t impact others.
Example for a sample Configuration Management Baseline
Introduction
This document defines and establishes the overall Configuration Management strategy for the project. The scope of this plan includes tools, resources, techniques and the CM environments. This plan provides the means by which the integrity of the design and content of the projects can be maintained during the Project and Development lifecycle, and provides for the delivery into XYZ’s operational environment and lifecycle.
Purpose
The purpose of the CM Strategy is to define the overall process and environment in which CM occurs for the X project. In addition, this plan is an attempt to establish and define common terms used in a structured CM environment. A common language, as well as an understanding of what CM does, provides the means to deliver this service to all members of the project in a consistent and meaningful way.
The CM Organization will use this plan for configuration identification, configuration control, and configuration reviews as described in this plan to ensure the ability to manage each Configuration Item (CI) (e.g. design document, srf, report, etc.) identified for this project.
This strategy provides the mechanism by which the system's configuration is documented and changes are identified, evaluated, implemented and tracked.
The purpose of implementing a robust CM process, with associated plans and procedures, is to position XYZ, throughout all phases of the system's lifecycle with the capability to carry out disaster recovery and rollbacks, and provide traceability and audit capabilities to the system and its changes..
Scope
The scope of this Strategy is to identify and define CM activities, including Configuration Identification (baseline identifiers and documentation) and Configuration Control (procedures and release of CIs). These activities provide traceability from approved requirements through acceptance test and deployment and delivery into XYZ’s Operational phase by performing a series of audits.
This process allows formal controls to be put in place to manage change to the products CIs, to maintain traceability and integrity throughout the product’s lifecycle.
While this is the overall configuration management strategy for CRP, exceptions may occur for individual CRP phases. These exceptions will be noted, reviewed and approved in the phase specific test and configuration management deliverables.
Configuration Management Overview
Configuration Management is the process that manages the changes to and releases of systems into environments. It ensures the system built and deployed conforms to the system designed and delivered.
CM provides traceability into and through the development and support lifecycles, and enables controlled and verifiable delivery of system components from development to test to production and support, via Release Management
Roles and Responsibilities
Test/CM Track Lead
The Test/CM Track Lead is responsible for the management of the Test/CM Track and for setting the strategic direction of CM during the CRP Project.
CM Lead
The CM Lead is responsible for:
- Configuration Identification
- Baseline Control
- Release Management including Release Notes
- Change control for all forms of system changes
- Coordinating software package builds and deployments with appropriate Project members.
- Reporting/Communication for all the CIs
- Administrator of CM tools
- Management of CM Libraries.
CM Analyst
The CM Analyst is responsible for executing the move and rebuild of the applications files from one environment to another. The primary environments are:
CI Owner
The CI owner is the team member that is responsible for delivering the CI. The CI owner's responsibility as it relates to CM is to use the version control process to configure any of the CI's artifacts that have been developed. They are responsible for escalating any issues to the PMO and any defects to the Test Lead. They are also responsible for using the standard tools set up for the project responsibly in order to ensure the integrity of the application.
Test Team
The Test Team is responsible for initiating any change requests or defects. For more details of the Test Team’s responsibilities see the CRP Test Strategy.
Project Management Office (PMO)
The PMO's primary responsibility as it relates to CM is to manage the project’s change requests and to work with the CM Lead to release any baselines.
Technical Track Leads/Technical Track Members
The Technical Track Leads/Technical Track Members responsibility as it relates to CM is to put all CIs in version control, complete all required release forms, and provide the information required to close any change requests or defects as applicable. They are also responsible for initiating any change requests or defect corrections that are needed and obtaining approval for any change requests or defects that they have been assigned.
Configuration Identification
Configuration Identification is one of the main aspects of CM, which is related to the identification and control of the project’s artifacts required to re-create and maintain the product.2
Identification Methods
The top level Configuration Item (CI) is the X project. The decomposition of the system into lower level CIs will be based on the design and schedule of the project such that each separately delivered entity will be identified as a CI. The Project is the process, organization, and artifacts put together to build a product that will be deployed in a production environment. The product is a collection of the baseline artifacts that can be built and rebuilt throughout the project’s life cycle and into Production Support.
The project’s CIs that are identified by CM will represent the final delivered system and supporting documentation (as defined in the Deliverable Acceptance Document (DAD)
Configuration Identification
Configuration Identification is one of the main aspects of CM, which is related to the identification and control of the project’s artifacts required to re-create and maintain the product.
Identification Methods
The top level Configuration Item (CI) covers the overall project. The decomposition of the system into lower level CIs will be based on the design and schedule of the project such that each separately delivered entity will be identified as a CI. The Project is the process, organization, and artifacts put together to build a product that will be deployed in a production environment. The product is a collection of the baseline artifacts that can be built and rebuilt throughout the projects life cycle and into Production Support.
The project’s CIs that are identified by CM will represent the final delivered system and supporting documentation (as defined in the Deliverable Acceptance Document (DAD)). After Post Implementation when the project ends some of the project CIs will be retired while others will live on to support the product that is being maintained by XYZ's IR Department.
All of the CIs for CRP will be detailed in CRP’s Configuration Identification Index.
CI Baselines
Baselines will be established and documented for the delivery of each CI in order to ensure that the product that is integrated meets the requirements and passes test. The CI’s documentation artifacts will be baselined after they pass through the initial review gate, as established in the DAD, when the deliverables are signed off and approved. For each review gate that the deliverable passes through a new baseline will be established. All other CIs will initially be baselined after the build/development milestone of the project is reached. For each milestone that follows, a new baseline of the CI’s non-documentation artifacts will be established including any reiterations of a milestone, such as when defects are regression tested.
CRP Logical and Physical Environments
Throughout the development and support lifecycle, both physical and logical system environments need to be established and managed. The environment itself is a Configuration Item, and as such, needs to be managed like any other CI described previously.
Environments are part of describing release migration paths. The logical environment may mirror the physical environment. Alternatively, many logical environments may have only one physical environment.
For complete reliability of builds, for both testing and production, it is imperative that secure logically distinct environments be created. The Technical Track members should maintain the development and unit test environments. Test/CM Track members should maintain test and training environments. CM and the Technical Operations members of the Infrastructure Track should maintain any of the production environments. While there may be some exceptions, the product’s environments will usually be on a server (i.e. not on any team member's local machine). These environments may not be accessible to all team members.
All team members will have full access to the development and unit test environments.
All of the Test/CM Track members will have full access to all other test and training environments. All other project members will only have read access to the test environments.
All of the Track members will have read access to the training environment. All other project members will only have read access to the training environment.
Only the CM and the Technical Operations members of the Infrastructure Track will have full access to the Production environment. All other project members will only have read access to the production environment.
Logical Environments & Release Migration Path
Revision & Version Management
Version Management is the set of processes by which the artifacts are revisioned and baselined, at a specific point in time.
Version Documentation
Version Management is facilitated by using version labels and Promotion Groups in Version Control Software. These labels and groups are applied to the appropriate revisions of theartifacts that are contained in the CML.
Product Documentation
Product documentation deliverables will be managed in the knowledge repository. Once a deliverable is approved it will be locked down in Intraspect by the PMO. Once the deliverable passes successfully through the audit gate it will be baselined in the CML established by CM and labeled as released. Once they are baselined any change to the documentation requires a project change request. This change request would have to be approved by the PMO Project Directors before any changes are made to the document. For approved changes the PSST will facilitate the checkout of the baselined document, the distribution of the document to the appropriate change owner, and the checking in of the updated approved version of the document.
Version Control Software
CM Technology
The team will make use of a the organistion's standard technology. It is used to record and track any test defects that are found by the Test/CM Track during all of the project's test phases. The disposition codes of these defects is detailed in the Test Strategy.
Update Process
For any approved changes to a Change Request the affected artifact(s) should be checked out of the project database in Version Control Software by the project team member that is responsible for that CI, the CI Owner. The change record must be referenced in the description when the artifact(s) are checked out. When the CI owner checks out any artifact(s) they are put into the defined work area for the project. Once the CI Owner has finished making the changes then the artifact(s) should be checked back in. If a user needs to check out an artifact that is already locked by another user then they should coordinate with that user on making their changes or request that CM establish a branch (when applicable).
Build/Release Management
Release Management Process
This is the process that enables the control and approval of what is delivered into the development and test environments during the lifecycle of the project. It ensures that what is required is actually delivered and that the proper documentation accompanies it. It also provides the traceability needed to know what requirements or defects were satisfied and what artifacts were effected by the release. A release is a CM action in which a particular version of a product's baselined artifacts is made available for a specific purpose (e.g. released to test). A release is made according the project plan (e.g. System Test, UAT, etc.) and also at the discretion of the project management team and CM.
Technical Track members will be allowed to perform their own releases to the development environment. CM will perform all updates to all test environments as well as the training and the production environments.
Once the test environments are established the baselined artifacts will be released as scheduled to the appropriate test environments. A detailed release schedule for the test environment will be defined in the Test Plan for each test phase of the project. Before any updates that are released to either the test or the production environments the entrance criteria in the CRP Test Strategy must be met. Authorization from the Test/CM Track Lead must also be received via email before performing any release to these environments.
Releases of the baseline artifacts to the training environment will occur after all phases of test have been completed and the ABC Track authorizes the release. The release schedule for the training environment will be defined by the ABC Tracks.
Release/Migration Path
CM is responsible for ensuring the successful release of any baseline to any of the testing environments.
Once the developer has completed the build phase and all unit testing has been done and delivered the Test/CM Track Lead will verify that all entrance criteria for the System Test environment has been satisfied and will request the release of the current baseline to the appropriate test environment.
Once system and performance testing has been done and delivered the Test/CM Track Lead will verify that all entrance criteria for the User Acceptance Test (UAT) environment has been satisfied and will request the release of the current baseline to the UAT environment.
Migrations to the Training environment will be according to the criteria defined by the ABC Track and coordinated between the ABC and Test/CM Track Leads.
Once a baseline has passed all testing then the Test/CM Track Lead will verify that all exit criteria for the User Acceptance Test (UAT) environment has been satisfied and that all entrance criteria for the Production environment has been met then the CM Lead will communicate with the PMO that the baseline is ready to be released to the production environment..
Entrance/Exit Criteria
For the entrance and exit criteria for all environments through production please see the CRP Test Strategy.
For the entrance and exit criteria for production please see XYZ's ETCM CM Guidelines.
Fast tracked defects will only be used for critical defects for the details of fast tracked defects and for their entrance and exit criteria to any of CRP's test or training environments see the CRP Test Strategy. For the entrance and exit criteria for fast tracked system changes to Production see XYZ's ETCM CM Guidelines.
Release/Migration Request
Releases will usually be done as requested as long as all exit criteria from the current environment and all entrance criteria to the next environment have been met. Releases will be authorized by the Test/CM Track Lead (test environments) or the ABC (training environment) or the PMO (production environment) and coordinated with CM.
Requested releases will be tracked by using a migration request form that will be established by CM.
Configuration Change Control
Configuration Change Control is the process by which the integrity of and the changes to a baselined CI are ensured and is the mechanism by which all changes are strictly controlled.
A change request is required for any CI that has been baselined by CM. For the change control process to be used for defects found during testing see the Change Control Process for defects in the CRP Test Strategy. For all other change requests see the Change Control Process defined by the PMO.
At the end of the CRP project all change records shall be delivered to CM in order to provide a full and accurate change history for all of the project's CIs.
CM Standards and Naming Conventions
One of the important aspects of any system for naming products is that the name be specific as well as unambiguous.
Documentation files should be named to reflect the deliverables purpose. The filename should never contain the version of the document. The version should be tracked in the CML and in the revision history inside the document.
Any emails pertaining to any change record should reference the change record number in the subject line of the email.
The following rules should be followed throughout the CRP project:
- Work only in the appropriate CRP environment
- Follow the procedures for migrating artifacts among environments
- Never delete a delivered CRP artifact
- Never rename a delivered CRP artifact. If modifications/additions are necessary, they should be commented and named with a prefix so that they can be clearly identified during future upgrades.
- Use standard naming conventions.
- CM or the PMO must approve any deviation from the standards established in this document.
- As a general rule all programs will be written to be platform independent (e.g., no Oracle, Informix, etc. specific commands). The Technical Track Team Leads should review all programming to ensure that independence is achieved.
Vendor/Contractor Software Control
All software developed by an outside vendor/contractor will be subject to the strategy implemented by Configuration Management, as appropriate. Once a CI is delivered to XYZ it must follow the CM strategy for version control and change control.
BlogMarks
del.icio.us
digg
Furl
Simpy
smarking
