Configuration Management QMS Training. Objective To – Establish and maintain the integrity of the...

Configuration Management

QMS Training

Objective

• To – Establish and maintain the integrity of the

configuration items throughout the lifecycle of the project or process

– Ensure that all concerned groups are kept informed about the status of software configuration

Mahindra Satyam ConfidentialMahindra Satyam Confidential 22

Process


Configuration Planning

Configuration Control

Configuration Status Reporting and Accounting

Configuration Audits

Configuration Planning


Identify Resources for SCM

Version Control of SCIs

Identify SCIs

Identify Resources for SCM• SCM group • SCM Tools• Specific Hardware Requirements

for SCM



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 partti me or full time responsibility for SCM, or

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



• 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



• Specific Hardware Requirements for SCM: – These requirements, if any, will be documented in

the project plan


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 acquired

This 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.


Version Control of SCIs• 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)


Version Control of SCIs• 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


Version Control of SCIs• The SCM group manages the versions of– Documents– Customer Supplied /included software

products


Configuration Control• 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


Configuration Control


Request Change

Evaluate the Change

Approve / Disapprove the Change

Check out the SCIs

Modify the SCIs

Validate the SCIs

Create Executables

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


Evaluate the Change• PL evaluates the change requests• The 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


Approve / Disapprove the ChangeIf 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


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


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


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


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


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


Configuration Status Reporting and Accounting

• SCM 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)


Configuration Audits

• Physical configuration audit (PCA) • Functional Configuration audit (FCA)


Configuration Audits• 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


Configuration AuditsPCA• 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)


Configuration AuditsFCA• 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


Configuration AuditsFCA• 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


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


Configuration Management QMS Training. Objective To – Establish and maintain the integrity of the...

Documents

Transcript of Configuration Management QMS Training. Objective To – Establish and maintain the integrity of the...