2.27.1  Configuration Management

2.27.1.1  (01-01-2010)
Configuration Management (CM) Overview

  1. This IRM establishes the authority and responsibility for the performance of Configuration Management throughout MITS.

  2. This Internal Revenue Manual (IRM) provides the Configuration Management (CM) framework to be used enterprise wide. It describes the functions, planning and management requirements, and details the Configuration management four primary functions.

  3. Other MITS CM documents still in effect are:

    1. Modernization and Information Technology Services Configuration Management Plan and

    2. MITS CM Process Compliance Assessment Procedure.

2.27.1.1.1  (01-01-2010)
Benefits

  1. Benefits of Configuration Management (CM) are realized through the implementation of the four CM functions:

    1. Configuration Identification,

    2. Configuration Control,

    3. Configuration Status Accounting and

    4. Configuration Audits.

  2. Implementing CM will stabilize products at key points in the life cycle and then facilitate control of changes to those products. Controlling changes reduces costs by increasing productivity and customer satisfaction while minimizing rework.

  3. Effective Configuration Management is important to a project’s success. CM enables a team to work together in a stable environment and still have the flexibility to do creative work. CM reduces project risks by minimizing:

    1. Requirement scope creep,

    2. Unauthorized changes,

    3. Schedule slippage, and

    4. Cost overruns.

2.27.1.1.2  (01-01-2010)
Configuration Management Terms and Definitions

  1. The CM terms and definitions used in this IRM are defined in the MITS CM Plan, Appendix A. The URL to the CM Plan: http://paig.ds.irsnet.gov/Library/Plans/M-PLN-CM-V3%5b1%5d.1-05022003.DOC

  2. The term ‘organization’ is used in this IRM as a generic term for projects.

2.27.1.2  (01-01-2010)
Roles and Responsibilities

  1. This section describes the roles and responsibilities of the individuals that are involved in CM Planning and Management and the four primary CM functions.

2.27.1.2.1  (01-01-2010)
MITS Configuration Management Program

  1. The MITS Configuration Management Program responsibilities include, but are not limited to:

    1. Acting as the MITS-wide CM Program Office (MITS CM).

    2. Ensuring that all MITS Configuration Items (CI), their associated artifacts, and other products are configuration controlled in accordance with this IRM.

    3. Approving any tailoring of the processes defined in this IRM and any related resources of this IRM.

    4. The authority and responsibility for the integrity of the CM portion of the Enterprise Life Cycle (ELC) Process Asset Library (PAL).

    5. Establishing metrics to be collected and used to determine the status of organizational CM activities and resultant products.

    6. Performing process oversight through CM Process Compliance assessments.

    7. Training and mentoring organizations in CM Functions.

    8. Providing guidance in all CM matters.

2.27.1.2.2  (01-01-2010)
Acquisition Programs and Projects

  1. The responsibilities of organizations that acquire development and/or maintenance services for IRS CIs, include, but are not limited to:

    1. Approving the service provider’s CM Plan, and

    2. Verifying that the service provider’s CM activities are compliant with this IRM and the MITS CM Plan.

2.27.1.2.3  (01-01-2010)
Development / Maintenance Service Providers

  1. The responsibilities of organizations developing and/or maintaining IRS CIs include, but are not limited to:

    1. Carrying out CM activities in accordance with this IRM and the MITS CM Plan.

    2. Requiring their CM staff to be fully knowledgeable in all aspects of this IRM, MITS CM Plan, and the organizational CM plan, to maintain and upgrade their CM program, when necessary.

    3. Designating a person (or persons) to be responsible for performing CM activities, known as a CM Representative (CM Rep).

2.27.1.2.4  (01-01-2010)
CM Representative

  1. The CM Rep implements the CM processes defined in this IRM, MITS CM Plan, and the organization's CM Plan.

  2. The CM Rep refers to MITS CM for guidance on CM issues.

2.27.1.2.5  (01-01-2010)
Subject Matter Expert

  1. Subject Matter Experts (SME) provide technical expertise to MITS Organizations and CM Reps, as requested.

2.27.1.3  (01-01-2010)
Configuration Management Function

  1. The purpose of CM is to establish and maintain the integrity of work products throughout their life cycle.

  2. Configuration Management is a discipline applying technical and administrative direction and surveillance over the entire system life cycle. Configuration Management (CM) is applicable to the development of new systems and Configuration Items (CI), to the management of existing systems and CIs, and to CI-associated artifacts and organizational products.

  3. CM is applied through the systematic identification, control, status reporting, and audits of system CIs, CI-associated artifacts and organizational products.

    1. Identification detects and documents the CIs, CI-associated artifacts and organizational products owned by programs and projects.

    2. Control manages changes to the identified CIs, CI-associated artifacts and organizational products.

    3. Status reporting provides visibility into the current status of CIs, their associated artifacts and other controlled products.

    4. Audits verify that deliverables meet contract requirements.

  4. There are four primary functions of Configuration Management:

    • Configuration Identification

    • Configuration Control

    • Configuration Status Accounting

    • Configuration Audits

2.27.1.3.1  (01-01-2010)
Configuration Identification

  1. The foundation needed to establish the other CM functions.

  2. Ascertains the products owned by the organization and how the products fit together.

  3. Assignment of a unique identifier to each artifact. This unique identifier (Configuration Identification Index) is used to correlate documentation to the appropriate CI and to distinguish between product versions.

2.27.1.3.2  (01-01-2010)
Configuration Control

  1. The systematic proposal, justification, evaluation, coordination, and disposition of proposed changes to controlled products.

  2. Benefits the organization by enabling change decisions to be based on knowledge of complete change impact, limiting changes to those deemed necessary or those offering significant value.

  3. Maintains the integrity of controlled products by ensuring that only authorized changes are incorporated.

2.27.1.3.3  (01-01-2010)
Configuration Status Accounting

  1. The recording and reporting of information needed to manage configuration items effectively, e.g., status of proposed and approved changes or the status of CI's in the operational inventory.

2.27.1.3.4  (01-01-2010)
Configuration Audits

  1. Are performed to provide objective data to support the decision to accept, or not accept, a new or changed product.

  2. There are two types of configuration audits, functional and physical.

    1. A Functional Configuration Audit evaluates a developed product to establish how well the requirements have been met.

    2. A Physical Configuration Audit appraises the technical documentation, against the as-built product, to confirm the documentation's effectiveness for maintenance, support and operation of the product.

2.27.1.3.5  (01-01-2010)
Integration of CM Functions

  1. Figure 2.27.1-1 provides a road map showing the relationship and data flow among the CM functions, which is also explained below.

    Figure 2.27.1-1

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

    1. The Configuration Identification function identifies CIs, CI-associated artifacts and organizational products, assigns each a Configuration Identification Index (CII) and documents the relevant data in the [Configuration System (CS)] CM Worksheet

    2. The artifacts identified and the products developed during Configuration Identification are placed into repositories for Configuration Control. Other artifacts will be input to or output from the Configuration Control function, e.g., proposed change packages, reports, minutes, etc.

    3. Configuration Audits require configuration controlled inputs and produce outputs that need to be configuration controlled. Inputs will be test documentation, previous audit reports, change packages; outputs are the audit plan, report, checklist, and minutes.

    4. Configuration Status Accounting (CSA) shares data with all the functions. Data input to CSA is processed and output in the form of CSA Reports (CSAR).

2.27.1.4  (01-01-2010)
Planning and Management

  1. The following policies establish the requirements for planning and managing CM:

    1. CM activities will be planned, funded, managed, implemented and controlled in accordance with all applicable laws, regulations, this IRM and the MITS CM Plan.

    2. A CM Plan that supports the implementation of this IRM and the MITS CM Plan will be developed and maintained for each program, project or operational system. Multiple projects or systems maybe combined in a higher-level CM plan.

    3. Responsibilities for organizational level CM activities will be explicitly assigned and outlined in the CM Plan

    4. CIs will be maintained in an approved CM Repository and CI information will be recorded as described in IRM 2.27.1.5.

    5. Personnel assigned to perform CM activities will be trained in the objectives, processes, procedures and methods for performing these activities. The MITS CM Training curriculum is available in the Enterprise Learning Management System (ELMS).

    6. CM information, such as acquisition documents or data and measurements, will be recorded and maintained in a CM Repository.

    7. CM activities will be reviewed by the managers of the acquiring organization and the service provider on a periodic and event driven basis. This is not a replacement for the program level CM process Assessment conducted by MITS CM .

  2. The first step in planning CM is to develop a CM Plan. A CM Plan Data Item Description (DID)/Template is available at the URL below: http://paig.ds.irsnet.gov/Library/DIDs/MITS_CM_Plan_DID%20(2).doc The CM Plan DID/Template is a valuable tool for developing a CM Plan

  3. Figure 2.27.1-2 is a process flow diagram designed to help organizations determine how to bring their CM processes into compliance with this IRM and the MITS CM Plan.

    Figure 2.27.1-2

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

    1. Programs and projects establishing CM (start-ups or organizations with no CM) follow the path across the top. This path identifies the processes required to establish CM activities. Each process box contains the IRM section number where a description of the process is found. Writing the CM Plan is accomplished in conjunction with establishing the CM functions.

    2. Organizations that are performing CM shall evaluate their CM processes for compliance following the path down the left side and across the bottom of the figure. In concert with this evaluation and improvement effort, CM activities will continue to be performed. The CM Plan will be updated to reflect the improvements.

    3. Organizations shall use this planning & management tool to prepare for an organization on systems CM process compliance assessments. These assessments are performed on organizations and project-level or operational systems by the MITS CM Program. The MITS CM Program will focus on major projects and systems with high risks and coordinate assessment schedules with applicable organizations.

  4. Once the CM Plan is completed or revised, it will be reviewed and approved by the applicable authority. The CM plan is the organization's foundation document and the "centerpiece" of a CM process compliance assessment.

2.27.1.5  (01-01-2010)
Configuration Identification Procedure

  1. Configuration Identification enables an organization to identify what products are owned by its organization and how they fit together.

  2. Configuration Identification also assigns a unique identifier to each of these products. This unique identifier (Configuration Identification Index) is used to correlate documentation to the appropriate CI and to distinguish among product versions.

  3. This section explains the activities related to performing Configuration Identification.

2.27.1.5.1  (01-01-2010)
[Configuration System] CM Worksheet

  1. The [CS] CM Worksheet is used to record data about the organization’s Configuration Items, CI-associated artifacts and/or the organizational products. The URL to the DID/template is provided below: http://op.ds.irsnet.gov/sites/MITS/ES/CM/CM%20Program%20Administration/Approved%20Program%20Versions/CM%20Worksheet%20Template.XLS The DID/template presents the format and data required of the [CS] CM Worksheet. Additional data shall also be recorded in the worksheet.

  2. Figure 2.27.1-3 is a process flow diagram describing the following instructions.

    Figure 2.27.1-3

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

  3. To initialize the [CS] CM Worksheet, the steps are:

    1. Download the [CS] CM Worksheet template from the MITS Configuration Management Website.

    2. Identify the System SME.

    3. Work with the SME to locate existing CIs, CI-associated artifacts and organizational documents. Table 2.27.1-2 provides examples.

      Table 2.27.1-2 Sample Artifacts
      ELC Milestones Documents
      1 IRS Organization Management Plans (Organization Management Plan, CM Plan, Quality Management Plan …)
        Tailoring Plan
        Project Charter
      2 Transition Management Plan
        Business System Concept Report
        Business System Architecture Report
        Business System Requirements Report
        Updated Milestone 1 Documents
      3 [Configuration System] CS Structure Chart
        Design Specification Report Part 1 - Logical
        Interface Control Documents
        Updated Milestone 2 Documents
        Requirements Traceability Matrix
      4A Design Specification Report Part 2 – Physical
        Updated Milestone 3 Documents
      4B Updated Milestone 4A Documents
        Functional Configuration and Physical Configuration Audit Plans
        Test Documentation
      N/A Product Specification Package
        Functional Specification Package

    4. Work with the Program/Project Manager (PM) to identify planned organizational documents (e.g., plans, meeting minutes,) and work products (see examples in Table 2.27.1-2).

    5. Document each existing and planned artifact in the [CS] CM Worksheet.

  4. Group artifacts with their associated CI (this shall require the use of the [CS] CI Structure Chart described in the next section). Enter available information for each artifact into the [CS] CM Worksheet (instructions are included with the worksheet).

2.27.1.5.2  (01-01-2010)
[Configuration System] CS Structure Chart

  1. A [CS] Structure Chart is the breakdown of the Configuration System to the lowest manageable levels (CIs), which depicts the:

    1. Size and complexity of the system, and

    2. Number of readily identifiable functions and modules within each function and whether each identifiable function is a manageable entity or should be broken down into smaller components.

  2. A [CS] Structure Chart is also used to diagram associated elements that comprise a run stream or thread.

  3. A [CS] Structure Chart is often developed as a hierarchical diagram, as shown in Figure 2.27.1-4; however, other representations are allowable. The representation must describe the breakdown of the Configuration System into subsystems and CIs (the lowest manageable level).

    Figure 2.27.1-4

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

  4. An accurate and complete [CS] Structure Chart is:

    1. Key to the determination of the configuration items, and

    2. A visual representation of the Configuration System and the internal interfaces among its CIs.

  5. During the Configuration Control process, the [CS] Structure Chart is used to identify CIs and their associated artifacts that a proposed change shall impact.

2.27.1.5.2.1  (01-01-2010)
Construct a [CS] Structure Chart

  1. Figure 2.27.1-5 is a process flow diagram describing the following instructions.

    Figure 2.27.1-5

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

  2. If a [CS] Structure Chart has been developed, the SME will be requested to review the [CS] Structure Chart to ensure it represents the current structure and update the chart where needed.

  3. If a [CS] Structure Chart is not available, the SME will be requested to create a [CS] Structure Chart.

    Construct a [CS] Structure Chart

    The SME will Explanation Action
    1. Analyze the Configuration System    
    2. Sub-divide the CS into:  
    1. Sub-systems (SS),

    2. Lower-level sub-systems (LSS), and

    3. CIs.

    3. Document the CS sub division as blocks in a hierarchical diagram    
    4. Analyze the items represented by blocks in the Structure Chart. The blocks denote sub-systems, lower-level sub-systems, and CIs.

    Note:

    The boxes labeled as CIs are at the lowest manageable level. CIs roll up into lower-level sub-systems and sub-systems, which are also CIs. These rolled-up CIs (sub-systems) must also be identified.

    a. Select the block.

  4. Once the SME selects the block, perform the following actions.

    If the item represented by the block Then
    has the following attributes,
    1. Treated as a single entity in the CM process,

    2. Has an end use function (i.e., documented requirements are associated with it; e.g., Functional Specification Package, Program Requirements Package, Hardware Requirements Specification or Computer Program Book) and

    3. Designated for separate configuration control.

    it is a CI:
    is a CI
    1. Block will be specified as a CI, and

    2. Available CI information will be documented in the [CS] CM Worksheet.

    is part of a CI it is a component and the:
    1. Block will be removed,

    2. Component title will remain, and

    3. Available information on the component will be documented in the [CS] CM Worksheet.

    is not a CI, or part of a CI the block will be removed from the [CS] Structure Chart

  5. Every item represented by a block on the [CS] Structure Chart must be evaluated. If there are more items (blocks) to evaluate, continue this activity from "select a block" above.

2.27.1.5.3  (01-01-2010)
Define Configuration Identification Index

  1. A Configuration Identification Index (CII) is a unique label used for filing and retrieval. A CII contains five fields: Configuration, Identification, Index, Version, and Date. Each CI, CI-associated artifact and organizational product is assigned a CII.

    1. The CII for CI-associated artifacts and organizational products contain data in each CII field.

    2. A CI is a collection of associated artifacts; therefore, the CII for a Configuration Item has data only in the Configuration Field. The Configuration Field is followed by four hyphens, indicating that the other four fields are empty.

  2. Figure 2.27.1-6 provides a pictorial representation of the CII.

    Figure 2.27.1-6

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

  3. General rules for CIIs are:

    1. Hyphens (dashes) will only be used as CII field separators. Hyphens will not be used within any of the five required fields, but must be used separate each of the five required fields, i.e., Configuration-Identification-Index-Version-Date.

    2. The CII is to appear on the label and, if possible, in the source code listing ( commented at the beginning of the software) of software artifacts, on the outside surface of hardware artifacts, and on every page of a document.

  4. General rules for documenting CIIs are:

    1. On each page of an electronic copy, the CII is:

    2. A smaller size than the document narrative font,

    3. The same font type as the document or any readable western font,

    4. Not bolded, and

    5. Centered at the bottom of each page.

    6. On each page of a hard copy, for which no electronic copy is available, the CII must be clearly labeled at the bottom of the page. Suggested methods are:

    7. Written in ink, or

    8. Affixed to the document by adding a permanent label.

  5. Using CIIs as filenames, which is not a requirement, could cause problems depending on the operating system. The use of underscore _ is recommended as a replacement for any character or special symbol that is objectionable to an operating system.

2.27.1.5.3.1  (01-01-2010)
Configuration Field

  1. For a CI and its associated artifacts, the Configuration Field identifies the system to which they belong. For organizational products, the Configuration Field identifies the owner organization.

  2. The Configuration Field is the first field in a CII.

  3. The Configuration Field could contain a maximum of 50 characters.

  4. Table 2.27.1-3 in IRM 2.27.1.5.3.1.2 shows examples of the different Configuration Fields defined in this section.

2.27.1.5.3.1.1  (01-01-2010)
Configuration Field for CIs and Associated Artifacts

  1. For a Configuration Item and its associated artifacts, the Configuration Field identifies the hierarchical path from its Configuration System through the applicable subsystems down to the CI.

  2. When creating a Configuration Field for a CI (i.e., software, hardware, databases) and its associated artifacts:

    1. The left-most entry is the Configuration System (CS) designation, i.e., ‘CS’

    2. The next entry is the first-level subsystem designator (SS1) beginning with a period (.). This type of entry is repeated for each lower-level subsystem (LSS), i.e., "SS1.LSS2 …"

    3. The right-most entry is the Configuration Item (CI) designation beginning with a period, i.e., ‘.CI’

    4. The complete configuration field would be formatted as " CS.SS1.SS2.LSS3 ….CI" . "CS.SS1.SS3.CI4" is an example of one of the CIs in Figure 2.27.1-4

2.27.1.5.3.1.2  (01-01-2010)
Configuration Field for Organizational Documents

  1. An organizational document is a controlled artifact that is not associated with a CI.

  2. The Configuration Field is the owner’s organization symbol.

  3. When creating a Configuration Field for organizational products (e.g., CM Plan or Configuration Control Board Charter), the organization’s symbol, complete with appropriate punctuation, becomes the Configuration Field.

    Table 2.27.1-3 Configuration Field Examples

    Product Format Example Definition
    Configuration
    Hardware (HW) CI - CI-associated artifacts CS.SS1.SS2.LSS3 ….CI IAP.MCC.PRIF.CNSL Integrated Collection System Automated Collection System Print (IAP) Enterprise Computing Center - Martinsburg (ECC -MTB) Local PeRIPHerals (PRIF) LPAR Consoles (CNSL)
    Software (SW) CI - CI-associated artifacts CS.SS1.SS2.SS3 ….CI IAP.MCC.SSW.LPR15 Integrated Collection System Automated Collection System Print (IAP) Eenterprise Computing Center - Martinsburg -(ECC-MTB) System SoftWare (SSW) LPAR 15 Sys SW LPR15)
    Organizational products Organization Symbol OS:CIO:ES:BI:TRM:CM Operations Support (OS) Chief Information Officer (CIO) Enterprise Services (ES) Business Integration (BI) Technology Release Management (TRM) Configuration Management (CM)

2.27.1.5.3.2  (01-01-2010)
Identification Field

  1. The Identification Field classifies the artifact by type. Some Identification Field examples are CKL (checklist), SYD (system document), SCH (schematic), SCHD (Schedule), PRP (Program Requirements Package), and SRC (source code). The actual entry for the Identification Field is taken from the Identification Field List maintained on the MITS CM web page. http://mits.web.irs.gov/ConfigurationManagement/archieve/Docs_Other/M-LST-ID_Field-V5_0-10292002.xls

  2. The Identification (ID) Field is the second field of the CII.

  3. The Identification Field could contain up to seven characters. If more than seven characters are needed for clarity, then additional identifiers could be requested from MITS CM.

  4. For CI-associated artifacts and organizational products, the Identification Field, preceded by a hyphen field separator, is appended to the Configuration Field, as shown in Table 2.27.1-4.

    Table 2.27.1-4 Identification Field Examples

    Product Format Example Definition
    Configuration-Identification
    HW CI CS.SS1.SS2.SS3.CI- IAP.MCC.PRIF.CNSL-  
    HW CI-associated Artifacts CS.SS1.SS2.SS3.CI-ID IAP.MCC.PRIF.CNSL-FSP Functional Specification Package (FSP)
    SW CI CS.SS1.SS2.SS3.CI- IAP.MCC.SSW.LPR15-  
    SW CI-associated Artifacts CS.SS1.SS2.SS3.CI-ID IAP.MCC.SSW.LPR15-SRR System Requirements Report
    Organizational Documents Org Symbol-ID OS:CIO:ES:BI:TRM:CM-CHT Charter (CHT)

2.27.1.5.3.3  (01-01-2010)
Index Field

  1. The Index Field is a recognizable abbreviation of an artifact’s actual title. In this abbreviation:

    1. Underscores "_" or spaces should be used for clarity.

    2. Special characters will not be used. (CM uses CIIs as filenames and some operating systems do not recognize special characters, e.g., &, #, etc. Using the CII as a filename is not required by other organizations.)

  2. The Index Field is the third field of the CII.

  3. The Index Field should be as short as possible while still providing recognition of the artifact. The number of characters could be as many as 50.

  4. For CI-associated artifacts and organizational products, the Index Field, preceded by a hyphen, is appended to the Identification Field. The formats for the CII at this point are shown in Table 2.27.1-5.

    Table 2.27.1-5 Index Field Examples

    Product Format Example Definition
    Configuration-Identifier-Index
    HW CI CS.SS1.SS2.SS3.CI-- IAP.MCC.PRIF.CNSL--  
    HW CI-associated Artifacts CS.SS1.SS2.SS3.CI-ID-Index IAP.MCC.PRIF.CNSL-FSP-LPR15 Console LPAR 15 HW Dev
    SW CI CS.SS1.SS2.SS3.CI-- IAP.MCC.SSW.LPR15--  
    SW CI-associated Artifacts CS.SS1.SS2.SS3.CI-ID-Index IAP.MCC.SSW.LPR15-SRR-LPR15 LPAR 15 SW Sys
    Organizational Documents Org Symbol-ID-Index OS:CIO:ES:BI:TRM:CM-CHT-MITS CM WG MITS CM Working Group Charter

2.27.1.5.3.4  (01-01-2010)
Version Field

  1. The Version Field indicates the initial or subsequent release of a product.

  2. The Version Field is the fourth field of the CII.

  3. The Version Field contains the "V" prefix, the major version number, a period, and then the minor revision number

  4. For CI-associated artifacts and organizational products, the Version Field, preceded by a hyphen field separator, is appended to the Index Field. The formats for the CII at this point are shown in Table 2.27.1-6.

    Table 2.27.1-6 Version Field Examples

    Product Format Example Definition
    Configuration-Identifier-Index-Version
    HW CI CS.SS1.SS2.SS3.CI--- IAP.MCC.PRIF.CNSL---  
    HW CI-associated Artifacts CS.SS1.SS2.SS3.CI-ID-Index-Version IAP.MCC.PRIF.CNSL-FSP-LPR15 Console-V1.3 1st release with 3 minor changes
    SW CI CS.SS1.SS2.SS3.CI--- IAP.MCC.SSW.LPR15---  
    SW CI-associated Artifacts CS.SS1.SS2.SS3.CI-ID-Index-Version IAP.MCC.SSW.LPR15-SRR-LPR15-V3.1 3rd release with 1 minor change
    Organizational Documents Org Symbol-ID-Index-Version OS:CIO:ES:BI:TRM:CM-CHT-MITS CM WG-V2.0 2nd release

    Note:

    An organizations symbol change will not reset the version of organizational products to 1.0 and will not require an immediate update. The Configuration Field will be updated as part of the next scheduled product revision.

  5. The versioning of an artifact is ascending

  6. The first character of the Version Field is "V" followed by the version number.

  7. The version number is in the form "x.y.z" and is structured as follows:

    a. The ‘x’ indicates an initial (x=1) or subsequent release (a major revision). 1. A major revision is when full, or many, pages are changed.
    2. For a major revision, ‘x’ would increase by 1 and ‘y’ would be reset to zero.
    b. The ‘y’ signifies a minor change has been made. 1. A minor change is when wording is changed at the sentence level.
    2. When minor updates are made, ‘x’ is not changed, but ‘y’ will increase by one.
    c. The ‘z’ specifies an internal draft. 1. While the draft is in internal review, the ‘z’ is incremented for each update made as a result of the internal review.
    2. When the artifact is ready for the approving organizations sign-off, the ‘z’ position is eliminated and the version updated as necessary.

  8. Table 2.27.1-7 shows examples and provides descriptions for various versions.

    Table 2.27.1-7 Examples of the Version Field

    Example Definition
    V0.0.1 Initial version of a draft document
    V0.1 Initial version of a draft that has been approved by the sponsor’s representative, but not by the approving authority
    V1.0 Initial version of a document that has been approved by the approving authority
    V2.0 Second major revision that has been approved by the approving authority
    V2.5 Second major revision, fifth minor revision against version 2, approved by the approving authority
    V2.5.2 Second major revision, fifth minor revision, second internal draft against version 2.5

2.27.1.5.3.5  (01-01-2010)
Date Field

  1. The Date Field is the date of the current version.

  2. The Date Field is the fifth and last field of the CII.

  3. The Date Field is eight numbers and is formatted MMDDYYYY (MM= month number, DD=day of the month, YYYY=year). Examples of the Date Field are:

    Example:

    • May 21, 2007 would be 05212007

    • 12/25/06 would be 12252006

  4. For CI-associated artifacts and organizational products, the Date Field, preceded by a hyphen, is appended to the Version Field. The CII is complete at this point. Examples are shown in Table 2.27.1-8.

    Table 2.27.1-8

    Product Format Example Definition
    Configuration-Identifier-Index-Version-Date
    HW CI CS.SS1.SS2.SS3.CI---- IAP.MCC.PRIF.CNSL----  
    HW CI-associated Artifacts CS.SS1.SS2.SS3.CI-ID-Index-Version-Date IAP.MCC.PRIF.CNSL-FSP-LPR15 Console-V1.3-10242003 October 24, 2003
    SW CI CS.SS1.SS2.SS3.CI---- IAP.MCC.SSW.LPR15----  
    SW CI-associated Artifacts CS.SS1.SS2.SS3.CI-ID-Index-Version-Date IAP.MCC.SSW.LPR15-SRR-LPR15-V3.1-04152007 April 15, 2007
    Organizational Documents Org Symbol-ID-Index-Version-Date OS:CIO:ES:BI:TRM:CM-CHT-MITS CM WG-V2.0-12252007 December 25, 2007

2.27.1.5.4  (01-01-2010)
Identify Baselines

  1. There are three baselines in Configuration Management: functional, allocated and product.

    1. The functional baseline contains documents defining business and/or system functional requirements (typically will or must statements).

    2. The allocated baseline contains documents describing the functional, inter operability, and interface characteristics allocated from the business and/or system functional requirements. Allocated baseline products, for example are Interface Control Documents, Requirements Traceability Matrix, Functional Specification Packages, Design Specification Report Part 1, etc.

    3. The product baseline contains the as-built product and the as-built documentation (e.g., as-built design documents, source code listings, blueprints, hardware drawings, and system schematics).

  2. Development organizations will establish three baselines (Functional, Allocated, and Product) for each CI. Existing operational organizations that own one or more legacy CIs will establish, at a minimum, the Product baseline for each CI.

  3. The [CS] CM Worksheet will be updated to include baseline information. Each worksheet entry will be reviewed against the definitions above to determine if it is a baselined product. From this decision, ‘functional,’ ‘allocated,’ ‘product,’ or ‘none’ will be entered in the Baseline_Type column. Figure 2.27.1-7 details this procedure.

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

2.27.1.6  (01-01-2010)
Configuration Control

  1. Configuration Control is the Configuration Management (CM) primary function required for maintaining the integrity of IRS Configuration Items (CI) and other IRS configuration-controlled products. Configuration Control continues throughout an artifact’s life cycle. Configuration Control provides for the evaluation, coordination, disposition, and tracking of changes to:

    • Baselined products, by ensuring that Configuration Control Board (CCB) or Change Management Board (ChMB) approval is received before implementing proposed changes, and

    • Non-baselined products and organizational documents by ensuring that the owner approves proposed changes prior to implementation.

  2. The roles and responsibilities for Configuration Control are:

    1. CHANGE AUTHORITY (CA): The owner of a product is responsible for the product’s development and maintenance, although the actual work shall be delegated or contracted. The owner is also the product’s Change Authority. The role of CA shall be assigned to another person at the owner’s discretion. The CA dispositions proposed changes to configuration controlled products. The CA must have the authority to assign the resources required to implement approved changes. The CA is: .

      • The CCB (chairperson) for baselined products,

      • The ChMB (chairperson) for products to be installed in the Current Production Environment (CPE), and

      • The owner or designee for non-baselined products•

    2. CHANGE MANAGEMENT BOARD (ChMB): The approval authority for installation of changes to the IRS CPE that have an impact on applications or the infrastructure.

    3. CM REPRESENTATIVE (CM Rep): Every program, project, and operational system will have someone assigned to perform CM activities, i.e., the CM Rep. The CM Rep responsibilities are, but not limited to:

      • Identifying baselined and non-baselined products,

      • Updating and tracking change forms,

      • Supporting Configuration Control and Change Management Boards, and

      • Updating [Configuration System (CS)] CM Worksheets..

    4. CONFIGURATION CONTROL BOARD (CCB): A group of technical experts and managers with the assigned authority and responsibility to make decisions on the configuration of a baselined product, Configuration System, or CI.

    5. CCB SECRETARIAT: The secretariat functions consist of configuration management and administrative activities. These activities may be assigned to different staff members or to the CM Representative. The CM activities include:

      • Review Change Packages for completeness,

      • Coordinate the movement of Change Packages,

      • Compile Standing Members responses and review for consensus,

      • Present Change Packages at CCB meetings, and

      • Log Change Package information into the tracking system(s).

      The CCB administrative activities include:

      • Scheduling the meeting,

      • Inviting members,

      • Distributing meeting agenda,

      • Recording CCB dispositions in the minutes,

      • Getting the minutes approved, and

      • Distributing the minutes.

    6. DEVELOPMENT/MAINTENANCE (D/M): the organization or group that is actually performing the development or maintenance of a product.

    7. ENGINEERING REVIEW BOARD (ERB): A group of subject matter experts composed of technical and administrative representatives who perform analyses of proposed changes, including, but not limited to, impact and alternative analysis as well as cost/benefit analysis results, and recommend solutions. The ERB provides the analyses and proposed solutions to the CCB.

    8. MODERNIZATION AND INFORMATION TECHNOLOGY SERVICES (MITS): The Chief Information Officer has the overall responsibility and authority for ensuring that all MITS CIs, their associated artifacts, and all other controlled products are configuration-controlled in accordance with this IRM. However, in accordance with the implementation strategy of the MITS CM Plan, this authority is delegated down to the lowest practical level.

    9. RELEASE MANAGER (RM): Responsible for planning and sponsoring the release of new or modified systems (i.e., CCB/ChMB approved change(s)) into the CPE.

  3. Changes are needed for a variety of reasons, such as:

    • Error,

    • Problem,

    • Omission,

    • New business need,

    • Additional functionality,

    • Change to the development environment, or

    • Change to the operating environment.

  4. Listed below are several (not all inclusive) change tracking systems available at the IRS.

    1. AUTOMATED WORKFLOW MANAGEMENT (AutoWM): an IRS developed system that documents issues, requirements, change requests, and break-fixes to EUES-owned and managed systems. More information is available at the AutoWM Home Page.

    2. IBM RATIONAL® CLEARQUEST®: a database tool used to document Change Requests (CR) and Defect Reports (DR) track CR activities using the CR Tracking System (CRTS) and DR activities using the DR Tracking System (DRTS). More information on ClearQuest is available at the The DITE Rational Tools Site.

    3. INTEGRATED TECHNOLOGIES & ACCOUNT MANAGEMENT SERVICES (ITAMS): an automated trouble-ticketing tool capable of supporting all types of system, network, and operational problems. More information is available at the ITAMS Home Page.

    4. WORK REQUEST TRACKING SYSTEM (WRTS): an IRS web-based application, documents and tracks Work Requests (WR) in accordance with IRM 2.22.1, Work Request Process. More information is available at the WRTS Home (URL provided below). NOTE: Throughout the Configuration Control process, the appropriate tracking systems are kept current. To accomplish this, the tracking system is updated every time an action occurs on an associated change form, e.g., the CM Rep sends a change form to the Engineering Review Board (ERB) for analysis, or the CCB Chair dispositions a change package. Actions on change forms occur frequently; therefore, the task of updating the tracking systems will be assumed, but not listed in the following activities. WRTS Home

  5. Configuration Control is comprised of four sub-functions:

    1. Change Control

    2. Engineering Review Board

    3. Configuration Control Board

    4. Change Management

2.27.1.6.1  (01-01-2010)
Change Control

  1. Change control involves product retention, preservation, retrieval, and disposal. All controlled products are required to be retained, subject to archiving guidelines (reference IRM 1.15 Records Management).

  2. Version control is a subset of change control, and is used to manage and maintain different versions of a product. Version identifiers record each revision of a product.

  3. Version control is also the management and maintenance of a system running different versions of various applications or the same application modified to run on different brands of computers. Each will have a different version identifier for each different modification.

  4. During the development of a new document or product, changes may be made to successive iterations (i.e., versions) without undergoing the rigor of the Configuration Control process. These are draft products and version control is used to document the history of development. Once a product is reviewed and approved for use, all subsequent proposed changes must be processed through the Configuration Control process and approved by the designated approval authority.

2.27.1.6.1.1  (01-01-2010)
Initial Change Processing

  1. This activity includes the submission of a change form and, when required, a manager’s review. Figure 2.27.1-8 is a process flow diagram of this process.

    Figure 2.27.1-8

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

    (file= "47349008" ) Figure 2.27.1-8

  2. When a condition, such as those listed above, occurs, a change form is initiated.

  3. If the organization’s change process requires the change form to be reviewed by a manager prior to submission, then

    1. The originator’s manager reviews the change form to ensure the:

      1. Issue is valid, and

      2. Mandatory information is provided.

    2. From this review, the manager decides the next step for the proposed change: .

      1. Update: return the change form to the originator, noting the discrepancies, and the originator updates the change form and returns it to the manager ((3) a) above).

      2. Reject: the change form is not submitted and the process ends.

      3. Approve: continue at (4) below.

  4. Submit the change form in accordance with the associated change tracking system procedure.

2.27.1.6.1.2  (01-01-2010)
Changing Non-Baselined Products

  1. Requests for change to non-baselined products are submitted to the product owner. If the change is required as part of a CCB or ChMB approved change package, the product will be updated. If the requested change only impacts the non-baselined product, the CA will or will not approve the request. If the CA approves the request, the change is implemented. If disapproved, the Request for Change is returned to the originator, noting the reason for disapproval. If the originator does not accept the Change Authority’s decision, the matter is elevated for management resolution. Figure 2.27.1-9 provides an overview of this process.

    Figure 2.27.1-9

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

    (file= "47349009" ) Figure 2.27.1-9

  2. The CA reviews and analyzes the proposed change. When the CA disapproves a requested change, processing continues at (7) below. When the change is part of a CCB/ChMB approved change package or the CA approves the change, the change is implemented as described below.

  3. The CA or designee makes the change using the applicable procedures. Upon completion, the change package is updated and returned to the appropriate CM Rep.

  4. When a change package is returned, the CM Rep reviews the package for:

    1. compliance with the CA’s instructions,

    2. a completeness check (performed and documented), and

    3. the required information.

  5. When the CM Rep accepts a change package as complete, the Configuration Identification Index (CII) version and date fields are updated on the product and in the CS CM Worksheet, the product is put under configuration control, the appropriate stakeholders are notified, and this procedure is complete.

  6. When a change package is incomplete, the CM Rep returns it to the sender, noting the item(s) that is missing, and processing continues at (3) above.

  7. The CA documents the reason(s) for rejecting the proposed change on the Request for Change and returns the request to the CM Rep.

  8. The CM Rep returns the Request for Change to the originator. The originator reviews the Change Authority’s decision, annotates acceptance or rejection of the decision, and returns the updated Request for Change to the CM Rep.

  9. If the originator accepts the CA’s decision, then this procedure ends. If the originator does not accept the decision, the CM Rep elevates the Request for Change to a higher authority for resolution. The higher authority(ies) resolves the issue in accordance with management procedures, and then returns the change package, with the decision, to the CM Rep.

  10. If the resolution is to implement the proposed change, processing continues at (3) above. If the decision is to not implement the change, the appropriate stakeholders are notified and this procedure ends

2.27.1.6.2  (01-01-2010)
Engineering Review Board

  1. During this activity, the CM Rep accepts new requests for change, sends the request to the appropriate ERB for analysis, and then forwards the change packages to the appropriate change authority(s). Figure 2.27.1-10 illustrates this process. (file= "47349010" )

    Figure 2.27.1-10

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

    Figure 2.27.1-10

  2. The CM Rep monitors the tracking system(s) for new proposed changes against their organization’s products or systems.

  3. When a new request is received, the CM Rep determines the appropriate ERB (defined in Configuration System (CS) CM Worksheet) and forwards the requests for change to that ERB. The ERB provides technical support to the organization’s CCB.

  4. When the ERB receives a requests for change, a technical analysis is performed, which includes, but is not limited to:

    • Identifying products and systems that will be modified if the request is approved,

    • Performing impact and other analyses of the proposed change,

    • Proposing technical solutions, with supporting information, for the proposed change,

    • Recommending a disposition and one of the proposed solutions as optimum,

    • Documenting:

      • Analyses results

      • Proposed technical solutions

      • Recommended disposition

    • Combining this documentation with the request to make a change package, and

    • Returning the change package to the associated CM Rep.

  5. For each impacted product identified in the change package, the CM Rep ensures that the product’s Configuration Identification Index (CII) and Change Authority are documented. The Configuration System (CS) CM Worksheet is used in accomplishing this activity.

  6. Change packages that affect only non-baselined products are forwarded to the product owner and are processed as defined in IRM 2.27.1.6.1.2 Changing Non-Baselined Products. Change packages with baselined products are forwarded to the CCB (IRM 2.27.1.6.3).


More Internal Revenue Manual