© mahindra satyam 2009 configuration management qms training

© Mahindra Satyam 2009

Configuration Management

QMS Training

2


Objective

To establish and maintain the integrity of the configuration items throughout the lifecycle of the project or process

To ensure that all concerned groups are kept informed about the status of software configuration

Mahindra Satyam Confidential

3


Process

Configuration Planning

Configuration Control

Configuration Status Reporting and Accounting

Configuration Audits


4


Configuration Planning

Identify Resources for SCM

Version Control of SCIs

Identify SCIs


5



SCM group

SCM Tools

Specific Hardware Requirements for SCM


6



SCM group:

During the project planning stage, the PL and PM identify a group for performing SCM activities. Depending on the project's SCM requirements, this group consists of:

– The PL only, with additional responsibility for SCM, or

– One resource from the project team, with a part time or full time responsibility for SCM, or

– More than one resource from the project team, with part time or full time responsibility for SCM. In this case, one of these resources will be identified as the head of the group


7



SCM Tools:

Microsoft VSS is the default tool for SCM

– In case the customer requires that a different tool be used, this will be documented in the project plan

PL specifies the access requirements for VSS to SCM group

SCM group gives the required access

Project server VSS where source code will be controlled will be administered by the project team itself


8



Specific Hardware Requirements for SCM:

These requirements, if any, will be documented in the project plan


9


Identify SCIs

PL identifies all SCIs for the project as a part of the project plan

This includes, the naming convention storage location, and when the baseline is acquiredThis also includes information on how traceability is maintained across SCIs

Definitions:Managed and controlled Documents Change control process (impact analysis, approval etc.,) needn’t be done to

change the baselined documents. Examples of Managed & Controlled documents are estimation sheets, project

plan, work request plan.Documents under configuration management A rigorous change control process is applied to baselined items. Some software

work products, e.g., the software design and the code, should have baselines established at predetermined points. These baselines are formally reviewed and agreed on and serve as the basis for further development. A rigorous change control process is applied to baselined items.


10



The SCM group controls and manages the versions of SCIs using VSS

Following information is recorded in VSS as a version history while checking in each version of an SCI:

SCI Version No.

Date

Description of Change

Change Request Id

Change implemented by (Name)


11



The SCM group controls and manages the versions of source code in the project using VSS

The SCM group maintains a copy of VSS on the respective project volume allocated to the project and maintains the source code


12



The SCM group manages the versions of

Documents

Customer Supplied /included software products


13



Each project maintains a Change Request Log with high level information on all change requests

This is used for broad tracking and status monitoring of change requests

A Change Request Form is used for recording and tracking activities for each Change Request in detail


14



Request Change

Evaluate the Change

Approve / Disapprove the Change

Check out the SCIs

Modify the SCIs

Validate the SCIs

Create Executables


15


Request Change

The customer or member(s) of the project team may raise change requests

The change request is recorded on a Change Request Form by the requester of the change

If the change request is by phone, e mail , fax, etc.. then it will be recorded in a Change Request Form by the SCM group

The SCM group assigns a unique Change Request ID for the request at this stage

The Change Request Log will also be updated by the SCM group with details of the new change request


16


Evaluate the Change

PL evaluates the change requestsThe evaluation has the following steps: Identify the SCIs that need to be changed

Estimate the change impact in terms of time and effort

Identify the impact on statutory and regulatory requirements if applicable

Identify the impact on Integrity and Security features if applicable


17


Approve / Disapprove the Change

If the change impact is

small and can be absorbed in the existing schedules for the project, PL may approve the change request

– PM may be consulted at this stage, if required

large, the PL decides if it needs approval from the customer

– If yes, then it shall be forwarded to the customer for approval

The decision for approval / disapproval is to be recorded in change request form and change request log


18


Check out the SCIs

PL plans the schedule and resources for implementing the change

This is updated in the MS Project file

The SCM group checks out the identified SCI(s) and informs the concerned project team member(s)

These activities will be recorded with proper justification in change request form and change request log


19


Modify the SCIs

The SCI(s) will be changed by the concerned team members as per the change request

These activities are recorded in Change Request Form and Change Request Log

Traceability matrix is updated wherever necessary to reflect the changes


20


Validate the SCIs

The updated SCI(s) will be validated by the concerned project team member(s) to ensure proper implementation of the change

Validation consists of :

For document changes: An inspection/review

For source code changes: A code inspection/review of the impacted programs and testing of the change, including regression testing.

These activities will be recorded Change Request Form and Change Request Log


21


Check in the SCIs

Once the changes are validated, the concerned project team member(s) inform the SCM group about the readiness of the SCI(s) to be checked in

The SCM group then checks in the SCI(s) into VSS

Following information is recorded in VSS as a version history while checking in the SCI into VSS:

SCI Version No. and Date

Description of Change

Change Request Id

Change implemented by (Name)

These activities are recorded in Change Request Form and Change Request Log


22


Create Executables

After source code changes, the new version of the software product will be built by the concerned project team member(s) using relevant versions of SCIs

This will be then delivered to the customer


23


Configuration Status Reporting and AccountingSCM group sends configuration status reports to the affected groups as identified in the project plan

The inputs for these reports are :

Change Request Log for the project

SCI Status (a print out from VSS giving the current status of all SCIs)


24



Physical configuration audit (PCA)

Functional Configuration audit (FCA)


25



PL plans for these audits to coincide with the delivery of the project documents in the project plan

SCM Group conducts these audits

It is recommended that the audit team includes system testers and other project team members

Audit Team

Records the audit results in the configuration audit reports

Submits the report to the PM


26



PCA

is an audit of the SCI(s) and Quality records

has to be carried out for completeness and compliance verification usually during the following baselines:

Functional baseline (established by requirements)

Allocated baseline (established by high level design)

Product baseline (established by finished code)


27



FCA

ensures that the work products

accurately reflect the functional characteristics as expected

conform to the necessary interface characteristics

verifies that the work product has achieved the expected performance by examining the test data


28



FCA

has to be performed progressively throughout the development of the product and finalized when testing is complete

In some cases FCA has to be done during integrated system testing, in which case FCA will be delayed until that time

is conducted on the first baseline of the product, which is a representative of the final deliverable


29


Objective Met

The integrity of the configuration items is established and maintained throughout the lifecycle of the project or process

All concerned groups are kept informed about the status of software configuration
