© Mahindra Satyam 2009 Configuration Management QMS Training

2 © Mahindra Satyam 2009 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 © Mahindra Satyam 2009 Process Configuration Planning Configuration Control Configuration Status Reporting and Accounting Configuration Audits Mahindra Satyam Confidential

4 © Mahindra Satyam 2009 Configuration Planning Identify Resources for SCM Version Control of SCIs Identify SCIs Mahindra Satyam Confidential

5 © Mahindra Satyam 2009 Identify Resources for SCM  SCM group  SCM Tools  Specific Hardware Requirements for SCM Mahindra Satyam Confidential

6 © Mahindra Satyam 2009 Identify Resources 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 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 Mahindra Satyam Confidential

7 © Mahindra Satyam 2009 Identify Resources for SCM 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 Mahindra Satyam Confidential

8 © Mahindra Satyam 2009 Identify Resources for SCM Specific Hardware Requirements for SCM:  These requirements, if any, will be documented in the project plan Mahindra Satyam Confidential

9 © Mahindra Satyam 2009 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. Mahindra Satyam Confidential

10 © Mahindra Satyam 2009 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) Mahindra Satyam Confidential

11 © Mahindra Satyam 2009 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 Mahindra Satyam Confidential

12 © Mahindra Satyam 2009 Version Control of SCIs The SCM group manages the versions of  Documents  Customer Supplied /included software products Mahindra Satyam Confidential

13 © Mahindra Satyam 2009 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 Mahindra Satyam Confidential

14 © Mahindra Satyam 2009 Configuration Control Request Change Evaluate the Change Approve / Disapprove the Change Check out the SCIs Modify the SCIs Validate the SCIs Create Executables Mahindra Satyam Confidential

15 © Mahindra Satyam 2009 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 Mahindra Satyam Confidential

16 © Mahindra Satyam 2009 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 Mahindra Satyam Confidential

17 © Mahindra Satyam 2009 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 Mahindra Satyam Confidential

18 © Mahindra Satyam 2009 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 Mahindra Satyam Confidential

19 © Mahindra Satyam 2009 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 Mahindra Satyam Confidential

20 © Mahindra Satyam 2009 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 Mahindra Satyam Confidential

21 © Mahindra Satyam 2009 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 Mahindra Satyam Confidential

22 © Mahindra Satyam 2009 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 Mahindra Satyam Confidential

23 © Mahindra Satyam 2009 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) Mahindra Satyam Confidential

24 © Mahindra Satyam 2009 Configuration Audits  Physical configuration audit (PCA)  Functional Configuration audit (FCA) Mahindra Satyam Confidential

25 © Mahindra Satyam 2009 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 Mahindra Satyam Confidential

26 © Mahindra Satyam 2009 Configuration Audits 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) Mahindra Satyam Confidential

27 © Mahindra Satyam 2009 Configuration Audits 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 Mahindra Satyam Confidential

28 © Mahindra Satyam 2009 Configuration Audits 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 Mahindra Satyam Confidential

29 © Mahindra Satyam 2009 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 Mahindra Satyam Confidential