Software Configuration Management Process

Wed, 29 Sep 2010 11:28:35 +0000

Identification of Configuration Controller: Configuration Controller (CC) can be identified for the project by PM during the Kick off meeting or while requesting for the resource allocation. CC along with PM / PL shall be responsible for maintaining the Process Database according to the library structure defined by SQA, Process Database Management Process for the Library Structure creation. The library structure created by CC shall be documented in the Project Library Structure and Access Control. CC of the project will update the Process Database after the approval of the work product.

Identification of Software Configuration Management Group: Project Manager identifies the SCMG. The PM, Configuration Controller (CC) for the Project, PL/ML (optional) will constitute the SCMG. Any member of the Project Team can prepare the Change control form for any change required. The SCMG will analyze the impact of change and it would be sent to software configuration control board for approval.

Identification Software Configuration Control Board (SCCB): Sr. Management, Customer, PM, On-site co-coordinator can be the members of this board. The SCCB will be responsible for authorizing the baselines for software work products. Change control form are approved by SCCB, the corrected CIs will also be authorized by SCCB for baselining. SCCB is also responsible for release.

Preparation of Software Configuration Management Plan: The PM / PL, prepares the Configuration Management Plan for the project. The SCMP will include the configuration items. The SCMP will include identification of naming convention for all documents.

SCMP Review: The SCMP is reviewed by SQA, and subsequently it is also reviewed and approved by the Delivery Head.

Handling the Changes: Any member of the project team can raise a Change Control Form (CCF) when any of the following situations arise:

Whenever a customer initiates a change. The change can be either an enhancement / bug.
Whenever a change calls for correcting CI
When a CI that needs to be changed is a work product of a completed phase of the project.
When CI/s need to be changed and the effort required will be more than one person day.
Whenever there is a change in the requirements/ architectural design document

The above conditions are a guideline for defining a major change, which need to be informed to the customer. Any change in a CI needs to be reviewed and approved by the appropriate authority as per the SCMP. After a CCF is raised with the changes required, it will put up to SCMG. SCMG will then evaluate CCF and SCCB will approve for Implementation.

Tracking and controlling versions of software items: The Change Control Form is used to track and control the changes and versions of software items. VSS / TFS can be used for Configuration Management. The Documents and Quality records in Projects are to be controlled and maintained.

Handling Customer Supplied test data: The test data that are supplied by the customer shall be protected with appropriate access rights in the projects. Restricted access shall be provided in the testing environment for those test data that are provided by the customer from the live environment.

Configuration Status Accounting: The numbers of changes made along with the revision numbers are recorded in MLPD. The Master list of Project Documents mentions list of all Technical document and project specific documents like PDSP, FSD, ADS, DDS, Test plan and test case document and also provides a reference to the release date, release number mentioned in the Software delivery note along with versions to identify the release it constituted.

Audit Base lining: The purpose of an audit is to find out the conformance to the customer requirements and to provide feedback to the management regarding any specific problem encountered. Audits are planned to track the operations starting from the receipt of the contract up to the delivery and installation through the various stages of development. The contract review will form the basis of recording the customer requirements.

Library Structure: The purpose to have a Library Structure defined for projects is to have proper documentation, knowledge & information sharing across all projects. At the start of any project, Library Structure is created by SQA and maintained by projects later. Initially the Library Structure will have its default folders.

SQA will facilitate the projects to store the relevant data of the latest versions. This will be the Process Database.

Configuration Audits: The schedule for FCA and PCA will be identified in the Project Schedule. The Audit Schedule will be approved by the PM. The schedule for both FCA and PCA will be available in the Project Schedule for the project. Also, these needs to be addressed in SCMP also.

FCA: The objective of this audit is to verify that the functional requirements have been fully addressed. This audit is to be conducted by project independent person. In case that is not feasible because of non-availability of project independent person, PM/PL/ML will conduct the audit. At the end of FCA, the auditor will hand over the Audit checklist and NCR to the SQA, who in turn would verify and hand over it to the concerned PM. Audit findings, will be tracked to closure by SQA at the time of PCA. FCA will be done at the end of design, coding and testing phases for development projects and for Maintenance Project on each release.
PCA: The objective of this audit is to verify correctness of the configuration management of the final version of the deliverable WP. This audit will be conducted by SQA after the FCA is over. PCA will be done at the start and phase end of the project for development projects and for maintenance project on each release.

Configuration Audit Checklist

Tue, 02 Jun 2009 16:31:49 +0000

Below is a sample configuration audit checklist (for FCA and PCA). The Project Managers can use the following checklist as a reference for the readiness of the audit or even for doing the audit.

Release audit:

Does the release documentation clearly define the scope of release, including the CRs that should be incorporated?
Are all dependencies / bugs been documented?
Is there adequate documentation that identifies the environment to recreate the release?
Is there adequate documentation that specifies the components and the versions of those components that comprise the release?
Are all the items of the release in sync with each other?
Has the release been created using the right versions of the right components from the right repositories?

Repository/Configuration item audit:

Are the repositories defined as per the SCM plan?
Have the items been put into the correct repositories?
Are the required items present in the repositories?
Have the items been named according to the conventions specified in the SCM plan?
Are the version numbers of items according to the SCM plan?
Have all items been put in the repositories according to the events defined in the SCM plan?
Do the items have required documentation to identify the item, version and the change history?

Change Implementation Audit:

Have all the required CRs been closed?
Do CRs identify all items to be changed?
Have all items identified for change in the CR been changed?
Is it possible to isolate the changes between any two versions of the items?
Is the documentation in the items adequate to trace the changes back to the appropriate CR?
Is there adequate means to go back to a previous means?
Are there any changes between two versions of an item that are not traceable to an approved CR?
Are the CRs documented before making changes in items?
Are CRs analysed, evaluated and approved prior to making of the change in items?

Other aspects to Audit:

Are appropriate back ups of repositories been taken?
Has the recovery from back up been tested?
Are there any unauthorized components available in the working directories of the team members?
Is there adequate security/authorization to ensure that only authorized team members perform the check-in and check-out?

Project Management Guide » Configuration Management

Software Configuration Management Process

Configuration Audit Checklist