2.27.1  Configuration Management (Cont. 1)

2.27.1.6 
Configuration Control

2.27.1.6.3  (01-01-2010)
Configuration Control Board

  1. A CCB receives change packages from its ERB via its CM Rep or CCB Secretariat. Change packages are also received from lower-level CCBs when their thresholds are exceeded, conflicts need resolving, or authority issues exist.

  2. CCBs select a proposed solution, when applicable, and disposition the change package. Dispositions are defined in Table 2.27.1-9.

    Disposition Definition
    Approve Analysis is complete, and the proposed change is approved to implement.
    Conditionally Approve The proposed change is approved, but other actions must be completed before implementation proceeds.
    Defer The proposed change is put on hold. The analysis provided in the change package didn’t give enough information for the CCB to make a clear approve or disapprove decision.
    Disapprove The CCB determined that the proposed change was not required or the same problem is part of an existing change package.
    Elevate The proposed change package solutions exceed the CCB’s threshold limits.
    Remand The proposed change is within the authority of a lower-level CCB.

2.27.1.6.3.1  (01-01-2010)
Check CCB Authority

  1. Each CCB has a charter defining its authority levels and threshold criteria. The following activities ensure that the change package is processed by the appropriate CCB. Figure 2.27.1-11 presents an overview of this process. (file= "47349011" )

    Figure 2.27.1-11

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    Figure 2.27.1-11

  2. The CM Rep or CCB Secretariat reviews change packages against the ‘Change Package Checklist’:

    1. Incomplete change packages are returned to the sender (e.g., ERB, CM Rep, or CCB Secretariat) with an explanation of the deficiencies and this process ends (the sender shall update the change package and resubmit it).

    2. Complete change packages are forwarded to the CCB Chair.

  3. The CCB Chair reviews each change package to determine if the proposed change(s) is within this CCB’s authority level and threshold criteria.

  4. When the proposed solution(s) exceeds this CCB’s threshold limits, the CCB Chair dispositions it ‘Elevate.’

  5. If the change package should be managed at a lower-level or peer CCB, the CCB Chair dispositions it ‘Remand.

  6. The CM Rep or CCB Secretariat records each disposition on the Disposition Signature Sheet (DSS) and the CCB Chair authorizes the dispositions by signature.

  7. The CM Rep or CCB Secretariat sends an informational copy of the signed DSS to the distribution list,

    Items Distribution
    CCB Meeting Minutes Signed Disposition Signature Sheets CCB Permanent Members, CCB attendees Chairperson of the next higher level CCB, Other involved CCB Chairpersons, Engineering Review Board Members, CM Rep, Project/system CM repository
    Action Items from CCB CCB Permanent Members Review, Board Chairperson
       

    see Table 2.27.1-10.

  8. The CM Rep or CCB Secretariat forwards elevated and remanded change packages to the appropriate CCBs for further processing.

2.27.1.6.3.2  (01-01-2010)
CCB Members Review

  1. CCB meetings will be performed electronically or "face-to-face " and are scheduled periodically and/or at the Chair’s discretion. CCB review activities consist of CCB standing members reviewing and providing recommendations on change packages. The CCB Chair evaluates the recommendations and determines if a meeting is needed. Figure 2.27.1-12 depicts these activities at a high level. (file= "47349012" )

    Figure 2.27.1-12

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    Figure 2.27.1-12

  2. Change packages are collected until the next CCB meeting.

  3. The CCB process continues with the CM Rep:

    1. Preparing a change package Cover Page and adding it to the change package, then

    2. Sending a copy of the change package to each CCB Standing Member.

  4. CCB standing members evaluate the change packages, focusing on their area(s) of expertise.

  5. If a standing member has issues or suggestions, these are documented on the Cover Page or on attachments to the Cover Page.

  6. The CCB Standing Members mark their recommended disposition, sign, date, and return the Cover Page with attachments, if any, to the CM Rep.

  7. Once the Cover Pages are returned, they are compiled and forwarded to the CCB Chair.

  8. The CCB Chair considers the input from the standing members. After this review, the Chair will call a CCB meeting and/or disposition change packages. For change packages that are dispositioned, the CCB review is considered an electronic CCB meeting, with these follow-up activities:

    1. The dispositions are recorded on the Disposition Signature Sheet and the CCB Chair authorizes the dispositions by signature.

    2. An informational copy of the signed Disposition Signature Sheet is sent to the distribution list and the original is filed in the organization’s repository.

    3. The dispositioned change packages are processed as defined in IRM 2.27.1.6.3.4 Disposition Change Packages

    .

2.27.1.6.3.3  (01-01-2010)
Conduct the CCB Meeting

  1. Face-to-face CCB meetings are scheduled for change packages that the CCB Chair or a Standing Member wants to address in more detail. Figure 2.27.1-13 portrays a summary of this process.

    Figure 2.27.1-13

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    (file= "47349013" ) Figure 2.27.1-13

  2. The CM Rep or CCB secretariat:

    1. Reserves the conference room,

    2. Prepares the CCB meeting agenda, and

    3. Sends meeting notices, including the agenda, to the CCB Permanent Members.

  3. Permanent Members will invite Ad Hoc participants as required.

  4. The CCB Chair calls the CCB meeting to order and facilitates all discussions.

  5. The minutes from the previous CCB are reviewed. The minutes will be approved as is, conditionally approved (minor changes are needed), or not approved.

  6. For each change package the following activities are performed:

    1. The sponsor of the change or applicable CM Rep presents the change package, per the agenda.

    2. Standing Members, who have issues with a change package, present their concerns and recommendations with supporting information. Subject Matter Experts (SME), e.g., Ad Hoc participants, are included on an " as needed" basis.

    3. The CCB discusses the issues, then the Chair, with advice from the Standing Members, assigns a disposition to the change package.

    4. The CM Rep or CCB Secretariat records action items and dispositions.

  7. After all change packages have been dispositioned, the secretariat reviews any action items/dispositions for accuracy and concurrence. This review helps to keep the minutes complete and accurate.

  8. The Chair adjourns the meeting, and then signs the Disposition Signature Sheet. The DSS is retained by the CM Rep for the organization’s repository and a copy is retained for the CCB minutes.

  9. The CCB Secretariat drafts and distributes the meeting minutes to members and applicable stakeholders.

2.27.1.6.3.4  (01-01-2010)
Disposition Change Packages

  1. The CM Rep or CCB Secretariat processes the change packages per the dispositions documented on the DSS. Figure 2.27.1-14 provides a summary of this process. (file= "47349014" )

    Figure 2.27.1-14

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    Figure 2.27.1-14

  2. The CM Rep or CCB Secretariat processes change packages per their dispositions on the DSS. Change packages with:

    • ‘Defer’ dispositions are held until a designated due date, or the CCB Chair directs resubmission to the CCB.

    • ‘Disapprove’ dispositions are marked closed in the tracking system, with no further processing.

    • ‘Approve’ or ‘Conditionally Approve’ dispositions are forwarded to the appropriate D/M organization for processing (see IRM 2.27.1.6.4.2 Change Implementation).

    • ‘Elevate’ dispositions are forwarded to a higher level or authority

    • ‘Remand’ dispositions are forwarded to a lower level of authority.

2.27.1.6.4  (01-01-2010)
Change Management

  1. Change management is the transition of a changed or new product through development to deployment into the CPE, with minimum disruption to users. This procedure is initiated when a change to the CPE is approved (after Enterprise Life Cycle (ELC) Milestone (MS) 4B exit). This can occur in a number of ways, including, but not limited to:

    • Implementation of a change to a Product Baseline, e.g.

      • Proposed upgrade to Infrastructure components,

      • Changes from vendors or contractors, or

      • A patch or an emergency fix in the CPE.

    • Establishing a new product baseline,

    • Change to Service Level Agreement,

  2. Upon successful completion of post installation testing, the release becomes fully operational (deployed).

2.27.1.6.4.1  (01-01-2010)
Emergency Change Processing

  1. An emergency change is a maintenance effort that must be executed immediately to avoid loss of service or severe usability problems to a large number of users, a mission-critical system, or some equally serious problem. In these situations, primary emphasis is on restoring the system as quickly as possible, temporarily bypassing the formal configuration control process. Consideration of documentation is typically delayed until after the system has been satisfactorily restored. Figure 2.27.1-15 illustrates this process. (file= " 47349015" )

    Figure 2.27.1-15

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    Figure 2.27.1-15

  2. The Operations and Maintenance (OM) manager receives notification that an emergency/critical problem has occurred.

  3. The OM manager determines if an emergency CCB and/or ChMB should be convened.

  4. If a CCB/ChMB is needed, the board holds an emergency meeting and the board becomes the CA. If a CCB/ChMB is not needed, the OM manager is the CA.

  5. The Subject Matter Expert (SME), assigned by the CA, investigates the problem and proposes a solution.

  6. The CA reviews the proposed solution. The CA approves the solution as a temporary change, or disapproves it and returns it to the SME for more analysis ((5) above).

  7. The D/M organization, designated by the CA, develops the solution.

  8. The CA ensures the solution is tested prior to installation into the Current Production Environment (CPE).

  9. The installation team installs the updated system/product into the CPE in accordance with the most recent transmittal notice and/or Version Description Document (VDD).

  10. If the installation is unsuccessful, the installation team backs the change out of the CPE and processing continues at (5) above.

  11. When the installation is successful, the installation team deploys the change into the CPE.

  12. The CA (or designee) documents the emergency change on the appropriate change form and submits it into the formal configuration control process for review and approval to accept the change as permanent.

2.27.1.6.4.2  (01-01-2010)
Change Implementation

  1. This section of the Change Management procedure is initiated when an approved change, other than an emergency change, to a Product Baseline is assigned to a D/M organization for development. Upon completion of this section, the changes have been developed and are ready for system testing. Figure 2.27.1-16 shows the activities to be performed. (file= "47349016 " )

    Figure 2.27.1-16

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    Figure 2.27.1-16

  2. The D/M organization receives the change package of an approved change to a Product Baseline.

  3. The D/M team develops the approved solution in accordance with the appropriate procedures (i.e., IRM, ELC, internal). These procedures include unit and integration testing.

  4. The CM Rep checks for any non-baselined products requiring modification. For impacted non-baselined products:

    1. The CM Rep uses the [CS] CM Worksheet to determine the CA and notifies the CA of the required updates.

    2. The CA (or designee) ensures the changes are made and advises the CM Rep when the changes are complete.

  5. The D/M CM Rep completes the transmittal documentation and, in accordance with the D/M’s documented procedure, moves the CI(s) and associated artifacts to the appropriate test repository.

2.27.1.6.4.3  (01-01-2010)
Test and ELC Milestone 4B Exit

  1. In this section, modified CIs and newly developed products are tested and configuration audits are performed. Upon completion of this section the CIs have been promoted to MS 5 System Deployment Phase. (file= " 47349017" )

    Figure 2.27.1-17

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    Figure 2.27.1-17

  2. Functional Configuration Audits (FCA) are most effective when combined with testing; this enables the FCA Team to witness product testing. Based on the criteria established for the FCA and procedures outlined in Section 8 of this IRM, the RM ensures the audit is accurately performed.

  3. The appropriate Test Organization or project personnel execute product testing.

  4. The Physical Configuration Audit (PCA) is performed by the PCA Team in accordance with IRM 2.27.1.7.

  5. The RM prepares for the Milestone Exit Review (MER) in accordance with the Milestone Readiness Review (MRR) Procedure [MITS-PR-MRR-V2.0-06232008].

  6. An MER is performed in accordance with the Enterprise Life Cycle Guide [MITS-GD-ELC_GUIDE-FINAL V3.0_12192007] and the product is promoted to MS 5 System Deployment Phase.

  7. The test organization completes the documentation and the CM Rep or the installation team moves the product baseline artifact into the production library.

2.27.1.6.4.4  (01-01-2010)
Prepare for Deployment

  1. The processing of new or modified products for deployment into the CPE requires ChMB approval. To obtain this approval, the RM (or designee) provides verification of the information required by the ChMB. This section describes the activities and documentation required to submit change package to the ChMB. Figure 2.27.1-18 shows the activities to be performed.

    Figure 2.27.1-18

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    (file= "47349018" ) Figure 2.27.1-18

  2. The RM prepares the verification readiness confirmation materials required by the ChMB for each proposed change. The RM downloads the ‘ChMB Verification Readiness Checklist’ to inventory the information as it is collected. The RM:

    1. Verifies the on-site lead or team has been identified.

    2. Identifies the System Administrator.

    3. Obtains the following information from the change package, or other documentation, as applicable:

      1. Change identifier,

      2. Change description,

      3. Approval authority and date of approval, as applicable,

      4. SME,

      5. Environment,

      6. Platform(s) affected, and

      7. Applications impacted, or potentially impacted,

      8. Origin of Change (ITAMS, CR, UWR)

      9. When (date, start time and end time)

      10. RM obtains concurrence from impacted business areas.

    4. Ascertains the applications on platform(s).

    5. Gets the Certification and Accreditation memos to confirm:

      1. Security requirements have been considered and coordinated, and

      2. Installation/deployment of the system has been authorized.

    6. Confirms that a back-out plan has been developed. If no back-out plan is needed, the reason is documented.

    7. Coordinates with projects and appropriate testing personnel to:

      1. Determine that pre-deployment testing was completed successfully, and

      2. Ensure post-deployment testing is planned for all impacted applications.

    8. Proposes the time window for deployment.

  3. Provides the CM Rep with copies of the verification documentation.

  4. Reviews verification documents to prepare for questions from the ChMB members during the meeting.

2.27.1.6.4.5  (01-01-2010)
The ChMB Meeting

  1. The ChMB authorizes the installation of new or modified products into the CPE. The ChMB meetings are conducted weekly or on an ad hoc basis when necessary. Figure 2.27.1-19 portrays a summary of this process. (file= "47349019" )

    Figure 2.27.1-19

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    Figure 2.27.1-19

  2. The CM Rep reviews the proposed changes submitted by the RM(s) and selects the application and infrastructure changes scheduled for deployment during the two week period that extents beyond the date of the ChMB meeting and adds these to the ChMB agenda.

  3. The CM Rep distributes the ChMB agenda and verification documents, via email to all members, Business Customers, and participants, one day before the weekly ChMB and two hours prior to an ad hoc ChMB.

  4. At the ChMB meeting, the Chair calls the meeting to order and facilitates all discussions.

  5. For each proposed change:

    1. The associated RM presents a change package.

    2. The board reviews any security issues or other concerns.

    3. Impacted, or potentially impacted, applications are identified and the impacted business area(s) provides concurrence.

    4. The Chair, with advice from the ChMB members, assigns a disposition (i.e., approve, defer, or approve with contingency changes) to the proposed change.

    5. The CM Rep records action items and dispositions.

  6. After all the proposed changes are dispositioned, the ChMB decides which changes will be deployed together, the priority, and schedule for release(s). The ChMB works with the Installation Team to schedule installation and deployment dates.

  7. Before the teleconference is adjourned, the CM Rep reviews with the ChMB, the action items/dispositions. This review helps to keep the minutes complete and accurate.

  8. The CM Rep compiles the meeting minutes and distributes them to the appropriate stakeholders.

2.27.1.6.4.6  (01-01-2010)
Disposition Proposed Changes

  1. The CM Rep processes proposed changes per the dispositions documented in the meeting minutes. Figure 2.27.1-20 provides a summary of this process. (file= "47349020" )

    Figure 2.27.1-20

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    Figure 2.27.1-20

  2. The CM Rep processes the proposed changes as defined below:

    1. Defer: Change goes back to Life Cycle Maintenance until tested and passed back to Change Management.

    2. Approve with Contingency:

      1. The RM assigns the contingency condition(s) to the appropriate D/M org for resolution.

      2. Once the contingency condition(s) are met, the change becomes approved.

    3. Approve:

      1. The Installation Team installs the release as specified in the Software Transmittal Notice (STN)/VDD).

      2. The Test Team, which typically includes end users, performs post-installation testing per the Deployment Site Readiness Test (DSRT) Plan or the Deployment Plan.

      3. When an installation is successful, the product is considered " deployed" and this process ends.

      4. When there is an unsuccessful installation, the product is backed out of the CPE.

      5. The CM Rep returns the change package to the ChMB for further action (see IRM 2.27.1.6.4.5 The ChMB Meeting).

2.27.1.6.4.7  (01-01-2010)
Metrics

  1. The CM Rep collects the following metrics and provides a report to the applicable ChMB, as required:

    1. Number of successful, unsuccessful, and partial installations,

    2. Ad-hoc meetings by application or infrastructure, and

    3. Uncoordinated change/release by application or infrastructure.

2.27.1.6.4.8  (01-01-2010)
ChM Change/Release Waivers

  1. When a waiver to the release process is required, the following steps will be performed.

  2. The project manager submits a waiver request, with supporting rationale, in writing via email to the Enterprise Services’s Technology Release Management organization. The email will contain the following information:

    1. Project /Application Name / Title, and

    2. Descriptions of the:

      • Application change(s) for which the waiver is being requested.

      • System / applications that are interconnected or potentially impacted by the change(s) for which the waiver is being requested.

      • Risk(s) to those systems / applications that are interconnected or potentially impacted by the change(s) for which the wavier is being requested.

      • Actions taken or other considerations that minimize the risk to those systems / applications that are interconnected or potentially impacted by the change(s) for which the waiver is being requested.

  3. The Director, Technology Release Management, will approve or reject all waiver requests.

2.27.1.7  (01-01-2010)
Configuration Status Accounting

  1. Configuration Status Accounting (CSA) is the recording and reporting of information needed to manage configuration items effectively, including the status of proposed and approved changes. CSA provides a highly reliable source of configuration information to support program/project activities.

  2. MITS policy provides the direction to produce Configuration Status Accounting Reports that show the status of all Configuration Controlled products. The policy states:

    1. Using approved procedures, CIs and associated artifacts shall be identified and controlled, and proposed changes shall be tracked through closure.

    2. MITS CM shall determine the status of the CM activities and resultant products.

  3. This IRM provides instructions on how to develop Configuration Status Accounting Reports (CSAR) and, once developed, how to populate the reports. CSARs are intended to depict the actual status of certain aspects of a specific project or program.

  4. The reports from this activity provide visibility into current state, activity status, and configuration information of a product and its documentation.

  5. CSA tasks include, but are not limited to:

    1. Recording the current approved configuration documentation and configuration identifiers associated with each CI.

    2. Recording and reporting the status of proposed changes from initiation to closure.

    3. Recording and reporting the results of configuration audits to include the status and final disposition of identified discrepancies and action items.

    4. Providing the traceability of changes from the original released configuration documentation of each system/CI(s) to the current configuration documentation.

  6. The roles and responsibilities for CSA include:

    1. MITS CM: responsibilities include, but are not limited to:

      • Providing guidance, training, and assistance to projects and organizations so that CSARs are produced in accordance with this IRM.

      • Developing the form and format of MITS Standard CSARs

    2. ORGANIZATIONAL/PROGRAM/PROJECT MANAGERS: responsibilities include, but are not limited to:

      • Ensure that CSARs are produced and documented in accordance with this IRM

      • Ensure that Configuration Management Plans refer to this IRM to provide the details for the development, production, and distribution of CSARs.

      • Review CSARs for accuracy and take appropriate action to ensure that needed corrections or updates are submitted to the appropriate authority in a timely manner.

    3. CM REP: responsibilities include, but are not limited to:

      • Assists CSAR Requestors in developing and documenting the requirements for new or Ad Hoc CSARs .

      • Determines if the CSAR requirements are adequate.

      • Creates the CSAR(s), required by the requestor, by collecting data, formatting reports, and accomplishing the required analysis.

      • Assigns a Configuration Identification Index (CII) to the CSAR documentation.

      • Documents CSAR format and data sources.

      • Places the CSAR, including its documentation, under Configuration Control.

      • Distributes the CSAR in accordance with the documented distribution list.

      • Generates Standard CSARs when required (or on a timely basis).

    4. A CSAR REQUESTOR: responsibilities include, but are not limited to: .

    • Develops and documents the requirements for new or Ad Hoc project CSARs

    • Forwards request to appropriate CM Rep.

    • Validates the CSAR meets expectations.

    • Verifies the content and accuracy.

    • Determines and documents CSAR distribution.

    .

2.27.1.7.1  (01-01-2010)
Configuration Status Accounting Data

  1. CSA data is captured and supplied using automated tools, examples are:

    1. IBM® Rational®:

      • RequisitePro® (requirements),

      • ClearQuest® (Tracking System for Change Requests (CRTS) and Defect Reports (DRTS)), and

      • ClearCase® (source code, documents).

    2. Work Request Tracking System (WRTS), and

    3. Information Technology Asset Management System (ITAMS).

2.27.1.7.2  (01-01-2010)
Configuration Status Accounting Reports

  1. CSA data is communicated to managers and other stakeholders using Configuration Status Accounting Reports (CSAR).

  2. There are two types of CSARs, Standard and Ad Hoc.

    1. A Standard CSAR is produced and distributed on a regular basis, or is widely used and produced on an as needed basis.

    2. Ad Hoc CSARs are intended for limited usage and special purposes (e.g., a one-time report).

2.27.1.7.2.1  (01-01-2010)
Develop a Configuration Status Accounting Report

  1. In the procedural steps below, a CSAR template, that satisfies a specific set of user requirements, is developed and documented. The CSAR template is used as input to the CSAR Operations. Figure 2.27.1-21 provides an overview of this process. (file= "47349021" )

    Figure 2.27.1-21

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    Figure 2.27.1-21

  2. A Requestor defines the CSAR requirements by completing a CSAR Requirement Form. Upon completion, the Requestor forwards the CSAR Requirement Form to the CM Rep. The requirements for a CSAR should include, but not be limited to, answering the questions on the CSAR Requirement Form.

  3. The CM Rep reviews the CSAR Requirement Form to determine if a CSAR can be created from the information supplied.

  4. If CSAR Requirement information is insufficient, the CM Rep returns the form, with comments or obtains the necessary information from the Requestor; otherwise, processing continues below.

  5. The CM Rep creates a draft format from the CSAR Requirement Form information.

  6. The CM Rep then collects the required data and generates a draft CSAR.

  7. The CM Rep reviews the draft CSAR with the Requestor to determine if the CSAR meets the Requestor’s expectations.

  8. If the CSAR does not meet expectations, the Requestor and CM Rep re-evaluate the requirements, update the CSAR Requirement Form, and processing returns to (5) above .

  9. The CM Rep updates the instructions and data sources as required. The CSAR Requirement Form must include the sources and instructions to satisfy each of the requirements.

  10. The CM Rep finalizes the CSAR format template. The template supports the repeatability of CSAR generation.

  11. The Requestor finalizes the distribution list and provides the list to the CM Rep.

  12. The CM Rep files the CSAR documentation (CSAR Requirement Form, distribution list, instructions, and format template) in the appropriate CM Repository.

2.27.1.7.2.2  (01-01-2010)
CSAR Operations

  1. CSAR Operations consists of generating previously defined CSARs (see ‘Develop a Configuration Status Accounting Report’ above). CSARs are produced on a periodic and as-needed basis. Figure 2.27.1-22 provides an overview of this procedure.

    Figure 2.27.1-22

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    (file= "47349022 " ) Figure 2.27.1-22

  2. This process is triggered when:

    1. It is time to produce a periodic standard CSAR, or

    2. A specific CSAR is requested, either an out-of-cycle or ad-hoc report.

  3. The CM Rep checks the CM Repository for the CSAR documentation.

  4. If the CSAR documentation is not on file, the CM Rep advises the Requestor to follow the instructions in IRM 2.27.1.8.2.1.

  5. When the CSAR information is on file, the CM Rep retrieves the documentation from the CM Repository.

  6. In accordance with the instructions, the CM Rep:

    1. Collects the data, and,

    2. Produces the CSAR.

  7. The Requestor verifies the accuracy of the CSAR .

  8. The CM Rep distributes the CSAR in accordance with the Distribution List on file.

  9. Recipients verify accuracy and report discrepancies or updates to the appropriate authority in a timely manner.

2.27.1.7.3  (01-01-2010)
Standard Configuration Status Accounting Reports

  1. A brief description and the intended purpose of each of the five required MITS Standard CSARs are included in the following sub-sections .

2.27.1.7.3.1  (01-01-2010)
[Configuration System] Configuration Management Worksheet

  1. This report records data on the organization’s Configuration Items (CIs), CI-associated artifacts and/or organizational products.

  2. The [CS] CM Worksheet template is in Microsoft® Excel® 2003 and can be downloaded from the MITS CM Website. The downloaded template contains detailed instructions for completing this CSAR.

  3. The [CS] CM Worksheet documents an artifact’s (or product’s) Configuration Identification Index (CII), Point of Contact (POC), Change Authority, Repository, etc.

  4. From this [CS] CM Worksheet, the Organization Manager can ascertain:

    1. The size (i.e., number of CIs and components) of the project,

    2. The artifacts/products as they relate to each other, and

    3. The location of the artifacts

  5. Figure 2.27.1-23 below presents the format and data required of the [Configuration System (CS)] CM Worksheet ./products.

    Figure 2.27.1-23

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    (file= "47349023 " ) Figure 2.27.1-23

2.27.1.7.3.2  (01-01-2010)
[Project] Baseline Deliverables Configuration Status Accounting Report

  1. This report records, in one place, all the baseline deliverables a project has developed, or expects to develop during the life cycle.

  2. The baseline deliverable data required in this report will be extracted from contract/Task Order/Enterprise Life Cycle (ELC) information and other documents.

  3. Managers and SMEs use this CSAR to determine the status of each baseline deliverable.

  4. This CSAR contains only those deliverables that will be placed into a Configuration Baseline. Figure 2.27.1-24 below presents the format and data required for this CSAR

    Figure 2.27.1-24

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    (file= "47349024" ) Figure 2.27.1-24

2.27.1.7.3.3  (01-01-2010)
[Project] WR Status Configuration Status Accounting Report

  1. This report lists the status of a project’s Work Requests (WRs). The WR Status CSAR is the "Project Impact Report" , a WRTS Standard Report, with the addition of optional costing information.

  2. The WR Status CSAR is in tabular format and includes: each WR Number, Title, Status, effort required, and cost, as shown in Figure 2.27.1-25. The project manager discerns the number of WRs in his/her area and the total effort required to complete individual items or the total effort. The figure below illustrates the report format. See the following URL for information and instructions on the Work Request Tracking System.

  3. There are three report types to display Project Impact Statement & Cost Document data for Logged Responses. One groups the data by Project. The second groups by WR Reference Number. The third groups by Cost Center. A number of user entered criteria are provided to customize the report.

    Figure 2.27.1-25

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    (file= "47349025 " ) Figure 2.27.1-25

2.27.1.7.3.4  (01-01-2010)
Open Change Requests Configuration Status Accounting Report

  1. This report records the status of Change Requests (CRs) being processed within the IRS. Sub-reports can be generated for specific projects. The Change Request Tracking System (CRTS) generates this CSAR, which includes information about each CR as shown in Figure 2.27.1-26 below. The project manager can identify the number of open CRs in his/her area.

  2. Other reports (e.g., one with fewer fields) can be obtained from CRTS following the procedures specified in the user’s guide. The user’s guide for CRTS is available in CRTS User Guide the MITS CCB Meeting SharePoint Document Library under " CRTS Documents" .

    Figure 2.27.1-26

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    (file= "47349026 " ) Figure 2.27.1-26

2.27.1.7.3.5  (01-01-2010)
Action Items Configuration Status Accounting Report

  1. This CSAR shows the status of Action Items being processed within a program or project. This CSAR is for internal organizational use and supplements the ITRAC system used to keep executives informed of Action Items that require higher level attention (reference the Risk, Issue, and Action Item Management Directive).

  2. An action item is defined as a short-duration, minimal resources activity assigned to a member or stakeholder within the organization. An action item must be within the scope of the duties currently assigned to that person.

  3. Figure 2.27.1-27 below shows the report format and instructions, respectively.

    Figure 2.27.1-27

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    (file= "47349027 " ) Figure 2.27.1-27

2.27.1.8  (01-01-2010)
Configuration Audits

  1. There are two types of Configuration Management (CM) configuration audits:

    1. The Functional Configuration Audit (FCA) evaluates a developed or changed product to establish how well the requirements have been met.

    2. The Physical Configuration Audit (PCA) appraises the technical documentation against the product, as built, to confirm the documentation effectiveness for maintenance, support, and operation of the product.

  2. Audit results provide the Acquiring Organization’s (AO) Release Manager (RM) with objective evidence to consider when making the decision to accept, or not accept, ownership of the product.

  3. FCAs and PCAs are required for Enterprise Life Cycle (ELC) Milestone 4B exit. Operational systems following planned Maintenance path of ELC are required to perform both on FCA and PCA. These audits shall be involved in the project ELC tailoring plan.

  4. The FCA checklist with recommended tailoring is provided for the ELC Planned Maintenance Path. All other paths use the complete FCA Checklist.

2.27.1.8.1  (01-01-2010)
Roles and Responsibilities

  1. The Audit Team composition for both the Functional and Physical Configuration Audits are very similar. The Audit Team consists of a group of individuals, which includes one or more CM Representatives (CM Reps), who are experienced and skilled in performing configuration audits.

  2. Configuration audits are performed by personnel who are not responsible for, or are not performing, the actual Development or Maintenance (D/M) activities, i.e., the auditors must be independent from the D/M organization. The composition of the Audit Team will vary depending on the D/M organization. See Table 2.27.1-11 below.

    When D/M is performed by: The Audit Team Members are:
    A Contractor : A MITS organization that is not the AO From the AO: - Release Manager (RM) - CM Rep(s) - Subject Matter Experts (SME) From the D/M Organization: - Project Manager (PM) - CM Rep - SMEs
    The AO From the AO which is the D/M Organization: - RM (Audit Sponsor), also assumes the D/M PM responsibilities. - AO CM Rep, performs the D/M CM Rep responsibilities - AO SME(s), performs the D/M SME(s) responsibilities Independent Members: - CM Rep to perform the AO CM Rep tasks - SME(s) to perform the AO SME activities

  3. Other personnel that will assist the Audit Team are:

    1. Modernization and Information Technology Services (MITS) CM staff,

    2. SMEs, for example:

      • Architecture,

      • Requirements,

      • Software,

      • Hardware,

      • Test, and

      • Others as required (e.g., Quality Assurance, Security …).

2.27.1.8.1.1  (01-01-2010)
Modernization and Information Technology Services (MITS)

  1. The Release Manager’s activities include, but are not limited to:

    • Serving as audit chair,

    • With D/M PM input, determining scope and schedule for the audit,

    • Reviewing audit plans and reports,

    • Approving audit plans and reports

    • Attending audit meetings,

    • Obtaining appropriate SME support,

    • Approving Action Item (AI) resolutions, when appropriate, and

    • Accepting the Audit as approved or not approved. Note: When the RM is the D/M PM, then the RM’s manager is the approval authority for the Audit Report and must determine whether to approve or not approve the Audit and sign the Audit Report.

  2. AO or Independent CM Representative: Depending upon the size and complexity of the product being audited, more than one CM Rep will be required. An AO or independent (not from the D/M organization) CM Rep, who is experienced and skilled in managing and performing Audits, is required. If such an individual is not readily available, the RM must find a qualified CM Rep from the MITS CM Branch, another MITS organization, or a contractor. AO CM Rep activities include, but are not limited to:

    • Developing Audit Plan,

    • Preparing initial Audit Checklist,

    • Providing meeting agendas and minutes,

    • Participating in Audit Meetings,

    • Performing Audit checklist activities,

    • Developing Audit Report,

    • Obtaining approval signature for the plan and report, and

    • Distributing Audit documents.

  3. An AO or independent (i.e., not from the D/M organization) SME(s) is required (e.g., Product, Test, and others). If such individuals are not readily available, the RM must find qualified SMEs from another MITS organization or a contractor.

    1. An FCA requires both a Product SME and a Test SME.

      1. The Product SME activities include, but are not limited to:

        • Witnessing test execution, or examining the test report, to ensure the product’s functionality matches its requirements,

        • Witnessing test execution, or examining the test report, to ensure the product’s functionality matches its requirements,

        • Verifying the Requirements Traceability Matrix (RTM), and

        • Baselined requirements trace to test cases

      2. The Test SME activities include, but are not limited to, reviewing test cases, scripts, and procedures to ensure they are "good enough " , i.e.:

      • Baselined requirements trace to test cases

      • Test cases trace to baselined requirements,

      • Official input test data is specified,

      • Expected results are identified, and

      • A sufficient number of test cases that validate error handling and recovery are included in the test suite.

      • Witnessing test execution, or examining the test report, to ensure the product’s functionality matches its requirements,

      • Verifying the Requirements Traceability Matrix (RTM), and

      • Performing and supporting technical checklist activities. 2. The Test SME activities include, but are not limited to, reviewing test cases, scripts, and procedures to ensure they are "good enough" , i.e.:

      • Baselined requirements trace to test cases

      • Test cases trace to baselined requirements,

      • Official input test data is specified,

      • Expected results are identified, and

      • A sufficient number of test cases that validate error handling and recovery are included in the test suite.

    2. A PCA requires a Product SME to perform and support technical checklist activities.

2.27.1.8.1.2  (01-01-2010)
D/M Organization

  1. The D/M Project Manager activities include, but are not limited to:

    • Assisting the RM with scope and schedule of the audit activities,

    • Reviewing the audit plan and report,

    • Making personnel available to support the audit team, when necessary,

    • Attending the audit meetings, and

    • Resolving audit discrepancies and providing a schedule for completing action items, when applicable.

  2. The D/M CM Rep functions include, but not limited to:

    • Ensuring work facilities are available for the audit team,

    • Helping the AO CM Rep obtain access to audit inputs,

    • Identifying and preparing facilitation tools, and

    • Coordinating the audit logistics.

  3. D/M SMEs (e.g., Product (i.e., Architecture, Requirements, Software, and Hardware), Test, and others as required) will be available to assist with technical issues, as needed.

2.27.1.8.2  (01-01-2010)
Configuration Audit Process

  1. Configuration Audits consist of four stages: planning, preparation, conduct, and closure. The following sub-sections describe the activities for each.

2.27.1.8.2.1  (01-01-2010)
Audit Planning

  1. Figure 2.27.1-15 illustrates the activities performed during audit planning. The Release Manager (RM) makes planning decisions, such as scope and schedule. The AO CM Rep incorporates these decisions into the draft audit plan, prepares the initial checklist, completes the draft plan, and sends the draft to the audit team for review. (file= "47349028" ) Figure 2.27.1-28

    Figure 2.27.1-28

    This image is too large to be displayed in the current screen. Please click the link to view the image.

  2. The RM makes the decisions needed for the planning the audit. Two examples are:

    • Scope: Operations and Maintenance (O&M) or development system, release number of the product/system to be audited, number of builds/drops, etc. and

    • Schedule: availability of staff, tools, and facilities; if an FCA, will it be conducted concurrently with System Acceptance Test / Final Integration Test or after testing is complete; FCA and PCA will run concurrently or consecutively, etc.

  3. The AO CM Rep drafts the audit plan, using the audit plan template (template on Process Asset Library (PAL)). The RM’s decisions are incorporated and the draft plan is completed (e.g., tools, resources, inputs, and audit acceptance criteria) based on experience.

  4. The AO CM Rep prepares the appropriate (FCA or PCA) checklist (templates on PAL). Checklist activities, which are not applicable to this audit, are shaded out; deletions will not be made to the checklist. Additions to the checklist are made as needed. The initial checklist is added to the audit plan as an appendix.

  5. The AO CM Rep distributes the draft Audit Plan to the Audit Team members for review.

  6. The Audit Team members independently evaluate the draft Audit Plan for accuracy and completeness and provide recommendations and feedback at the Opening Meeting.

2.27.1.8.2.2  (01-01-2010)
Audit Preparation

  1. In this section, preparations for the audit are made, as shown in Figure 2.27.1-16. The Opening Meeting is held. The Audit Plan is approved. The D/M CM Rep arranges for, and schedules, the use of tools needed during the conduct of the audit. (file= "47349029" ) Figure 2.27.1-29

    Figure 2.27.1-29

    This image is too large to be displayed in the current screen. Please click the link to view the image.

  2. The AO CM Rep, with input from the RM, identifies the personnel to invite to the Opening Meeting. The AO CM Rep develops the meeting agenda, arranges for a conference room, and sends meeting invitations attaching the agenda and draft Audit Plan.

  3. The AO CM Rep facilitates the opening meeting per the agenda. As part of this meeting, the RM will approve the Audit Plan.

  4. If the Audit Plan requires updating, then the AO CM Rep updates the plan per the recommendations and feedback, and returns the plan to the RM for approval.

  5. The D/M CM Rep, with input from D/M Engineering, schedules and arranges for the necessary access and availability of the tools needed to facilitate and support the audit. Tasks will include scheduling computer time, arranging for SME support, and coordinating product documentation.

2.27.1.8.2.3  (01-01-2010)
Audit Conduct

  1. This section defines the tasks required to complete the Audit Checklist activities. At the conclusion of this section the checklist activities will be complete, a checklist walkthrough will have been accomplished, and the draft Audit Report will have been prepared. Figure 2.27.1-17 provides the process flow for these activities. (file= "47349030" ) Figure 2.27.1-30

    Figure 2.27.1-30

    This image is too large to be displayed in the current screen. Please click the link to view the image.

  2. The AO CM Rep, in consultation with the other CM Reps (when applicable) and SME(s), assigns responsibility for specific checklist activities. Changes to the work assignments will be made as the audit progresses to ensure achievement of the audit objectives. Checklist activities cover several areas, e.g.:

    1. For an FCA:

      • Requirements Traceability

      • Tracking Changes

      • Test Documentation

      • Test Witnessing, when applicable

    2. For a PCA:

      • FCA has been performed

      • FCA has not been performed

      • Transmittals

      • Verifying technical documentation

  3. The AO CM Rep(s) / SME(s) will review the assigned checklist activities and begin collecting the artifacts needed to complete the activities. The artifacts are, but not limited to, the inputs described in the Audit Plan. During the audit, relevant information shall be collected by sampling. The sample size depends on the complexity of the product/system audited and on the quality of information received. NOTE: The artifacts reviewed to support the findings are objective evidence. Only information that is verifiable will be used as objective evidence. The objective evidence shall be recorded on the Checklist in sufficient detail (e.g., include the Configuration Identification Index (CII)) to allow validation.

  4. While completing checklist activities, the AO CM Rep(s) and SME(s) analyze the evidence and record the results on the checklist. In the ‘P/F’ column of the checklist, the auditors log ‘P’ (pass) or ‘F’ (fail) based on their interpretation of the findings.

    • When performing an FCA, there are two activities that use separate checklists, which are included in the FCA Checklist.

      1. ‘Individual Change Form Data Sheets’. Each change record reviewed is recorded on an ‘Individual Change Form Data Sheet’. Prior to the checklist walkthrough, the data from these checklists is summarized and recorded in the Audit Checklist, item 5. The individual checklists are concatenated and attached to the Audit Checklist.

      2. ‘Test Witness Data Sheets’. The results of each test witnessed are recorded on an individual ‘Test Witness Data Sheet’. Prior to the checklist walkthrough, the data from these checklists is summarized and recorded in the Audit Checklist, item 9. The individual checklists are concatenated and attached to the Audit Checklist.

  5. Once the checklist activities are complete and all data is entered in the checklist, the AO CM Rep forwards a draft copy to the RM for review. The AO CM Rep then meets with the RM to walkthrough the audit results. The RM will invite others to this walkthrough. This is an informal meeting providing an opportunity to raise and discuss issues. Unresolved issues are recorded as AIs.

  6. AIs resulting from the Checklist Walkthrough are resolved by repeating activities (3) – (5) above, as needed. The RM reviews the resolutions and either closes the AI or requests further action.

  7. The AO CM Rep prepares the draft Audit Report in accordance with the audit report template (found on PAL). Once the AIs, if any, are closed, the Checklist(s) is updated and included as an appendix to the report

2.27.1.8.2.4  (01-01-2010)
Audit Closure

  1. This section completes the Audit. The activities are shown in Figure 2.27.1-31. The Out-Briefing will be held, and the Audit Report approved and distributed. (file= "47349031" ) Figure 2.27.1-31

    Figure 2.27.1-31

    This image is too large to be displayed in the current screen. Please click the link to view the image.

  2. The AO CM Rep, with input from the RM and D/M PM, identifies the personnel needed at the audit Out-Briefing. The AO CM Rep develops the meeting agenda, arranges for a conference room, and sends out meeting invitations attaching the agenda and draft report.

  3. The AO CM Rep facilitates the audit Out-Briefing per the agenda. The results of the audit activities are discussed. Any discrepancies are reviewed, and action items assigned by the RM, as appropriate. The RM determines the outcome of the audit, and will approve (by signing) the audit report at this meeting.

  4. If the Audit Report requires changes, then the AO CM Rep updates the Report per the recommendations and feedback, and returns the report to the RM for review and approval.

  5. The AO CM Rep prepares and distributes the approved Audit Report, which includes the audit outcome and the completed audit checklist.

  6. The three possible audit outcomes are:

    1. Not Approved. Discrepancies exist which must be resolved. The RM will not accept the risks these discrepancies pose. A new audit must be performed before approval can be attained. The RM schedules a follow-up audit. This closes the audit.

    2. Approved. No major non-compliances exist; therefore, the audit is complete. (This does not constitute the acceptance of the Configuration Item(s) (CI), nor does this establish the product baseline.) This closes the audit.

    3. Conditionally Approved. Actions items exist which will impact the production system if not fixed (determined by the RM). Once resolved, the audit outcome is reevaluated. Unless new problems arise as a result of an AI resolution, a re-audit is not required.

  7. The D/M PM reviews the action items, ensuring that the descriptions include the specific tasks to be completed. The D/M PM then assigns responsibility for each action item and the expected completion date to the D/M team.

  8. The D/M CM Rep will:

    • Distribute the audit action items,

    • Configuration Control the action items,

    • Track the status of action items,

    • Provide to the RM Configuration Status Accounting Reports on AI status.

  9. The RM reviews each AI resolution. This review provides the RM the opportunity to verify that the AI has been resolved satisfactorily. If the solution is unacceptable, or if the AI resolution uncovers another discrepancy, the RM evaluates the risk and its possible effect on the Current Production Environment (CPE) if deployed. After this review the audit outcome is re-evaluated as described in (6) above.


More Internal Revenue Manual