2.5.1 Systems Development

Manual Transmittal

May 22, 2020

Purpose

(1) This transmits revised IRM 2.5.1, Systems Development.

Background

In response to General Accounting Office (GAO) findings published since 2018, the Agency committed to improving its capability to 1) engineer, develop, or maintain enterprise software systems and 2) transition from current enterprise architecture to target enterprise architecture. Internal controls are established under:

  • IRM, Part 2, Chapter 5, during engineering, development, testing, delivery, and maintenance of Agency software systems

  • IRM 1.11.1 IRS Internal Management Documents System.

Material Changes

(1) Manual Transmittal - removed Gina Garza’s name as ACIO, and replaced with the current Acting Chief Information Officer Nancy Sieger

(2) 2.5.1.1, Program Scope and Objectives

(3) 2.5.1.1.1, Added Background

(4) 2.5.1.1.2, Added Authority

(5) 2.5.1.1.3, Added Roles and Responsibilities

(6) 2.5.1.1.4, Added Program Management and Review

(7) 2.5.1.1.5, Added Program Controls

(8) 2.5.1.1.6, Acronyms/Definitions/Terms

(9) 2.5.1.1 6.1, Constituent Internal Revenue Manuals

(10) 2.5.1.1.6.3, Other publications - removed title Managing the Software Process, Watts S. Humphrey, and replaced with IRS Enterprise Services Integrated Process Management (IPM) and included a weblink

(11) 2.5.1.2, Added System Development Quality Assurance

(12) 2.5.1.2.1, Updated Affected Personnel

(13) 2.5.1.2.2, Added Configuration Controls

(14) 2.5.1.2.2.1, Added Configuration Control Board

(15) 2.5.1.2.2.2, Added Government sponsor, Configuration Control Board

(16) 2.5.1.2.2.3, Added Chairperson, Configuration Control Board (CCB)

(17) 2.5.1.2.3, Added Work Requests

(18) 2.5.1.2.4, Update Quality Assurance (QA) Waivers

(19) 2.5.1.3, Added Configuration Management (CM)

(20) 2.5.1.3.1, Added Proposing a Change

(21) 2.5.1.3.2, Added Requesting a Work Request

(22) 2.5.1.3.11, Added Manage Software Contracts

(23) 2.5.1.3.12, Added Plan Applications Development projects

  1. Added a reference for IRM 2.16.1 Enterprise Life Cycle (ELC)

(24) 2.5.1.4, Updated Directives changed

(25) 2.5.1.4.1, Added Quality Assurance

(26) 2.5.1.4.4, Added Curtail Software Defects

(27) 2.5.1.4.4 (1), Curtail Software Defects - added the following steps for resolving defects alpha list a - f:

  1. Planning and coordination of requirements

  2. Peer review meetings must be planned

  3. Defects in software products must be identified by total number of major and minor defects found by all peer reviewers, and removed

  4. Rework must be performed to resolve issues found

  5. A follow-up peer review meeting must be performed for reworked requirements artifact

  6. Exit Criteria - All defects and issues have been identified, corrected, and the product is accepted

(28) The information in this manual was revised to reflect changes since its last publication. Editorial changes were made throughout for minor clarifications, corrected references, and links to resources.

  1. Changed IRM 2.5.11 title from Analysis and Design to correct title Analysis Techniques and Deliverables

  2. IRM 2.5.16 Use of Live Data in Testing is obsolete, changed to current title IRM 10.5.8.3.6.1 IT Security, Sensitive But Unclassified (SBU) Data Policy,

  3. Added link for reference IRM 10.5.8.3.6.1

  4. IRM 2.5.50 Enterprise Life Cycle Lite is obsolete, changed to current title IRM 2.16.1 Enterprise Life Cycle (ELC), added link to reference

(29) Added a reference for IRM 2.110.1 IT Requirements Engineering Program Office (REPO) directive

(30) Added a reference link for Enterprise Service Acquisition

(31) Added the Risk Management website link for IT Project Tracking Reporting and Control, https://program.ds.irsnet.gov/sites/ITSandPELC/RM/SitePages/Home.aspx

(32) 2.5.1.4.4, Added QA Waivers

(33) Other publications (2) removed Capability Maturity Model Integration (CMMI) guidelines for Process Integration and Product Improvement , MaryBeth Chrisis, and replaced with IRM 2.100.2 Integrated Process Management (IPM) , Integrated Process Management Standardized Process

(34) 2.5.1.11.1.2, Added Change Control Board

(35) 2.5.1.14, Added Define/Plan Organizational Process Training

(36) Exhibit 2.5.1-1 - Changed Terminology to Terms and Descriptions, and added more terms

(37) Exhibit 2.5.1-2 - For Change Control Coordinator - removed Gwendolyn Barnett's name IRS, changed title -to Delivery Management Quality Assurance (DMQA) Director

(38) Exhibit 2.5.1-3 - Added a row for Revision history with date September 2019

(39) Exhibit 2.5.1-4 - Removed IRM 2.6.1 Product Assurance Standards and Procedures, the IRM is obsolete; replaced with IRM 2.127.2 Testing Standards and Procedures, IT Policy

(40) Exhibit 2.5.1-4 - Removed the comment ' To be determined' for Manage Software Changes; and added Software Change - IRM 2.150.1, Change Management

(41) Exhibit 2.5.1-4 - Removed the comment ' To be determined' for Manage Software Contracts, and added IRM 2.149.4, IT Asset Management

(42) Exhibit 2.5.1-4 - Removed the comment ' To be determined ' for Manage Requirements, and added IRM 2.110.1 Requirements Engineering

(43) Exhibit 2.5.1-4 - For Integrate Engineering and Managerial Activities, added IRM 2.120.1, Engineering Policy

(44) Exhibit 2.5.1-4 - For Plan Software Development Projects, removed ‘To be determined', and added IRM 2.15.1, Enterprise Architecture (EA)

(45) Exhibit 2.5.1-4 - For Track and Oversee Development Projects removed ‘To be determined', and added IRM 2.120.5, Engineering - Performance Engineering

Effect on Other Documents

IRM 2.5.1, dated September 01, 2006 is superseded.

Audience

The audience intended for this transmittal is personnel responsible for engineering, developing, testing, and maintaining Agency software systems identified in the Enterprise Architecture. This engineering, development, and maintenance include that performed by both government employees and contractors.

Effective Date

(05-22-2020)


Nancy Sieger
Acting Chief Information Officer

Program Scope and Objectives

  1. Purpose: This Internal Revenue Manual (IRM) and the other manuals that constitute IRM 2.5.1 Information Technology, Systems Development establishes the directives, procedures, standards, and other controls intended in the interest of the Government to:

    • Ensure Agency software systems are, in an efficient and effective manner, engineered, developed, and maintained

    • Improve the Agency’s capability to engineer, develop, and maintain software systems

    • Improve the Agency’s capability to transition from the current enterprise architecture to the target enterprise architecture

  2. Audience: This IRM 2.5.1 is the baseline guidance for all IRMs under IRM 2.5, and applies to all IRS Senior Leadership, Information technology (IT) managers at all levels. Also included are personnel responsible for: engineering, developing, or maintaining Agency software systems identified in the Enterprise Architecture. This engineering, development, and maintenance include services performed by both government employees and contracts.

  3. Policy Owner: Application Development (AD) Associate Chief Information Officer (ACIO)

  4. Program Owner: Director, Technical Integration Organization (TIO)

  5. Primary Stakeholders are as follows:

    1. IRS IT managers

    2. Quality Assurance (QA) managers and QA staff

    3. Application Development

    4. Engineers

    5. Developers - government and contractors

Background

  1. In response to Government Accountability Office GAO-18-298 Information Technology (IT): IRS Needs to Address Significant Risks to Tax Processing- Investments Performance and Risks, June 2018 report provided to Congressional Committees. IRS IT recognized the importance of continuously improving the performance of IRS Major IT Investments. IT IRS organizations’ Mainframe systems, using legacy programming languages: Common Business Oriented Language (COBOL), Assembler Language Code (ALC), Java programming; etc., IRS Application Development (AD) has established Risk Management strategies and guidance to identify, analyze, mitigate, and monitor risks and issues for system development standards.

Authority

  1. IRM 2.5.1 establishes the System Development program for the IRS

  2. Treasury Inspector General Tax Administration (TIGTA)

  3. Presidential American Technology Council, 2017

  4. Clinger-Cohen Act of 1996

  5. Director of Office of Management and Budget (OMB)

  6. Secretary of the Department of Homeland Security (DHS)

  7. Federal Information Security Modernization Act (FISMA) of 2014

  8. Secretary of Commerce for modernization of Federal IT

  9. 21st Century Integrated Digital Experience Act (IDEA), December 2018

Roles and Responsibilities

  1. Applications Development (AD): AD is responsible for building, testing, delivering, and maintaining integrated information applications systems, e.g. software solutions, to support modernized systems and production environment to achieve the mission and objectives of the Service. Additional, AD is responsible for the following:
    • AD works in partnership with customers to improve the quality of and deliver changes to IRS information systems products and services
    • Establishes and maintains rigorous contract and fiscal management, oversight, quality assurance, and program risk management processes to ensure that strategic plans and priorities are being met
    • Maintains the effectiveness and enhance the integration of IRS installed base production systems and infrastructure while modernizing core business systems and infrastructure
    • Provides quality assessment/assurance of deliverables and processes

  2. Application Development’s chain of command is the following:

    1. Commissioner: Oversees and provides overall strategic direction for the IRS. The Commissioner’s and Deputy Commissioner’s main focus is for the IRS’s services programs, enforcement, operations support, and organizations. Additionally, the Commissioner’s vision is to enhance services for the nation’s taxpayers, balancing appropriate enforcement of the nation’s tax laws while respecting taxpayers’ rights.

    2. Deputy Commissioner, Operation Support (DCOS): Oversees the operations of Agency-Wide Shared Services: Chief Financial Officer, Human Capital Office, Information Technology, Planning Programming and Audit Oversight and Privacy, and Governmental Liaison and Disclosure.

    3. Chief Information Officer (CIO): The CIO leads Information Technology, and advises the Commissioner on Information Technology matters, manages all IRS IT resources, and is responsible for delivering and maintaining modernized information systems throughout the IRS. Assisting the Chief Technology Office (CTO) is the Deputy Chief Information Officer for Operations.

    4. Application Development (AD) Associate Chief Information Officer (ACIO): The AD ACIO reports directly to the CIO; oversees and ensures the quality of: building, unit testing, delivering and maintaining integrated enterprise-wide applications systems to support modernized and legacy systems in the production environment to achieve the mission of the Service.

    5. Deputy AD Associate CIO (ACIO): The Deputy AD ACIO reports directly to the AD ACIO, and is responsible for:
      • Leading all strategic priorities to enable the AD Vision, IT Technology Roadmap and the IRS future state
      • Executive planning, and management of the development organization which ensures all filing season programs are developed, tested, and delivered on-time and within budget

  3. AD has the following Domains:

    1. Compliance Domain

    2. Corporate Data Domain

    3. Customer Service Domain

    4. Data Delivery Service (DDS) Domain

    5. Delivery Management; Quality Assurance (DMQA) Domain

    6. Identity & Access Management (IAM) Organization Domain

    7. Internal Management Domain

    8. Submission Processing Domain

    9. Technical Integration Organization (TIO) Domain

     

  4. Director, Compliance: Provides executive direction for a wide suite of Compliance domain focused applications and oversee the IT Software Development organization to ensure the quality of production ready applications.

    1. Directs and oversees an unified cross-divisional approach to compliance strategies needing collaboration pertaining for the following:

    • Abusive tax avoidance transactions needing a coordinated response

    • Cross-divisional technical issues

    • Emerging issues

    • Service-wide operational procedures

  5. Director, AD Corporate Data: Directs and oversees the provisioning of authoritative databases, refund identification, notice generation, and reporting.

  6. Director, Customer Service: Directs and oversees Customer Service Support for the IT Enterprise Service Desk ensuring quality customer to employee relationship.

  7. Director, Data Delivery Services: Oversees and ensures the quality of data with repeatable processes in a scalable environment. The Enterprise Data Strategy is to transform DDS into a data centric organization dedicated to deliver Data as a Service (DaaS) through:

    • Innovation - new methods, discoveries

    • Renovation - streamline or automate

    • Motivate - incent and enable individuals

  8. Director, Delivery Management & Quality Assurance (DMQA):

    • Executes the mission of DMQA by ensuring AD has a coordinated, cross-domain, and cross-organizational approach to delivering AD systems and software applications

    • Reports to the AD ACIO, and chairs the AD Risk Review Board

    • Chairperson, Configuration Control Board, see IRM 2.5.1.2.2.3

    • Government Sponsor, Configuration Control Board, see IRM 2.5.1.2.2.2

    • For additional information concerning AD roles, see Exhibit 2.5.1-2

  9. Director, Identity & Access Management (IAM) Organization: Provides oversight and direction for continual secure online interaction by verification and establishing an individual's identity before providing access to taxpayer information “identity proofing” while staying compliant within federal security requirements.

  10. Director, Internal Management: Provides oversight for the builds, tests, deliveries, refund identification, notice generation, and reporting.

  11. Director, Submission Processing: Provides oversight to an organization of over 17000 employees, comprised of: a headquarters staff responsible for developing program policies and procedures, five W&I processing centers, and seven commercially operated lockbox banks. Responsible for the processing of more than 202 million individual and business tax returns through both electronic and paper methods.

  12. Director, Technical Integration: Provides strategic technical organization oversight ensuring applicable guidance, collaboration, and consolidation of technical integration issues and quality assurance for the Applications Development portfolio.

Program Management and Review

  1. The Enterprise Program Management Office (EPMO) is responsible for the delivery of integrated solutions for several of the IRS’s large scaled programs. It plays a key role in establishing change, release plans, and implementing new information system functional capabilities.

  2. The EPMO is the primary partner with the business for programs under their purview and works with IT delivery partners (AD, ES, EOPS and the other ACIO areas) to deliver required capabilities. This structure positions each organization to maintain a strong core function to optimize their operations.

Program Controls

  1. The Enterprise Program Controls (EPC) Office will lead the EPMO in Information Technology Enterprise-wide program management functions, and will assist the Applications Development (AD) organization in cross domain support for a variety of program management disciplines. The EPC office is comprised of seven sections: Business Operations, Program Support Services, Investment & Contract Management, Program Oversight & Reporting, Communications & Organization Readiness, Enterprise Transition Management Office, and Technical Integration.

Acronyms/Definitions/Terms

  1. For terms and definitions see Exhibit 2.5.1-1

  2. For acronyms see Exhibit 2.5.1-4

Resources

  1. This section describes the Internal Revenue Manual (IRM) that constitute IRM Part 2 (Information Technology), Chapter 5 (Applications Development). This section also identifies the Internal Revenue Service documents used with this IRM and any other documents associated with this IRM. The controls established in this IRM are based on concepts, principles, and theory expressed in the following references:

    1. IRM 2.5.3, Programming and Source Code Standards

    2. IRM 2.5.4, Document Standards

    3. IRM 2.5.10, Function Point Standards

    4. IRM 2.5.11, Analysis Techniques and Deliverables

    5. IRM 2.5.12, Design Techniques and Deliverables

    6. IRM 2.5.13, Database Design Techniques and Deliverables

    7. IRM 2.5.14, System Development, Quality Assurance

    8. IRM 10.5.8, Security Privacy and Assurance, Privacy and Information Protection, Sensitive But Unclassified (SBU) Data Policy: Protecting SBU in Non-Production Environments

    9. IRM 2.16, Enterprise Life Cycle (ELC) - Enterprise Life Cycle details the project life cycles for systems development

    10. IRM 2.100.2, Integrated Process Management (IPM), Integrated Process Management Standardized Process

    11. IRM 2.150.1, Information Technology (IT), Configuration Management, Configuration Management Policy

    12. IRM 2.150.2, IT Configuration and Change Management, Configuration Management

    13. ISO/IEC 20000-1:2011, Information Technology - Service Management - Part 1: System Requirements, 9.2 Change Management

    14. IT Infrastructure Library (ITIL) Service Transition, 2011 Ed., Chapter 4.2 Change Management

  2. Other publications in this Internal Revenue Manual (IRM) are based on decisions, direction, guidance, or recommendations expressed in the following documents:

    1. Capability Maturity Model Integration (CMMI) Version 2.0 for Development, CMMI institute released March 2018, website: https://cmmiinstitute.com

    2. Investment Performance and Risk Tax Processing (GAO-18-298T), June 2018)

System Development Quality Assurance

  1. The Quality Assurance Program Office supports the delivery of high-quality products and services by ensuring projects remain within quality standards as established by the IRS. Currently there are eight process areas and three types of audits currently covered by the AD QA. The process areas are:

    1. Project Planning

    2. Project Monitoring and Control

    3. Configuration Management

    4. Requirements Management

    5. Measurement and Analysis

    6. Software Development

    7. Testing

    8. Supplier Agreement Management

  2. QA audit types are:

    1. Process Audit - Evaluates a process area based on organizational standards and requirements

    2. Work Product Audit - Evaluates work products for conformance to the Enterprise Life Cycle (ELC), Data Item Descriptions (DID) and templates

    3. Release Review Audit - Evaluates a selection of processes used and work products created during a release

Affected Personnel

  1. The controls established in this Internal Revenue Manual (IRM) apply to Agency personnel responsible for engineering, developing, or maintaining Agency software systems identified in the Enterprise Architecture. Agency personnel who contract for development maintenance of these software systems must ensure contracts comply with these controls.

Configuration Controls

  1. A critical aspect of the Change Control process is documenting changes, the more information contained in the documentation, the easier it is to do an: assessment, development, maintenance, and improvement of the process controls established through Internal Revenue Manual (IRM) Part 2 Information Technology, Chapter 5 Systems Development.

  2. The Configuration Controls approves or controls changes to the design, structure, and format of IRMs that constitute IRM Part 2, Chapter 5.

Configuration Control Board
  1. The Configuration Control Board (CCB) must:

    1. Control the product and service baseline

    2. Evaluate and approve, or reject proposed changes to the Configuration Item number

  2. Any new CCBs, subordinate CCBs, or exceptions must obtain approval from the Configuration Management process owner, see IRM 2.150.1 Configuration Management Policy.

Government sponsor, Configuration Control Board
  1. The Configuration Control Board controls the product and service baseline, and concurs on the distribution of all Work Requests resulting in approvals on the CCB SharePoint site

  2. The Government Sponsor approves, or disapproves Work Requests (WR), or deviations from controls cited under IRM 2.150.2 Configuration Management Process.

Chairperson, Configuration Control Board (CCB)
  1. The Chairperson decides whether a Work Request (WR) will be presented to the Configuration Control Board and designates who will present the WR.

  2. The Configuration Control Board consist of the following:

    1. AD CCBs

    2. Domain CCBs

    3. Branch CCBs

    4. AD, Data Management Quality Assurance

    5. Enterprise Architecture (EA)

    6. Enterprise Operations, Investment Management and Change Control Board (IMCCB)

Work Requests

  1. Without approval from the Configuration Control Board (CCB), Work Requests or deviations from the process controls established under Internal Revenue Manual (IRM) Part 2 Information Technology, Chapter 5 Applications Development are not authorized.

Quality Assurance (QA) Waivers

  1. QA has established procedures for the waiver justification process. The purpose of the waiver is to uniformly track any project team’s deviation from published standards, and have a documented agreement between the process owner, AD QA and the project team on deviations from accepted standards. For additional information see IRM 2.5.14 IT System Development, Quality Assurance (QA).

Configuration Management (CM)

  1. Configuration Management (CM) is a critical control and discipline process for maintaining information about configuration items required to deliver an IT Service, and ensure the integrity, security, and reliability of information systems.

  2. CM’s purpose is to identify, control record, report, audit, and verify Configuration items and to manage deviations from these controls, IRM 2.150.1 Information Technology, Configuration Management, Configuration Management Policy, establishes the following procedures:

    • Proposing a Change

    • Requesting a Work Request

Proposing a Change

  1. Personnel affected by controls cited under IRM, Part 2 Information Technology, Chapter 5 Applications Development may propose a change to controls.

  2. The types of process changes are the following:

    1. Emergency Change: A Request-For-Change (RFC) must be submitted for the change to occur as soon as possible as a (P1) or (P2) Incident Management ticket to the Change Analyst.

    2. Standard Change: A Request-For-Change (RFC) must be submitted when an accepted solution from authority was approved in advance. This process pertains to repetitive or reoccurring changes.

    3. Normal Change: A Request-For-Change (RFC) that requires a service change to a service or IT infrastructure. This is not an Emergency or Standard change, and is subject to a full change management review and Change Advisory Board review for authorization/rejection.

  3. To propose a change, the steps are:

    1. Proposer: The proposer must prepare a proposal and submit the proposal to the Change Analyst.

    2. Change Analyst (CA): A Change Analyst is delegated by the Change Coordinator, and must manage/support the: plan, design, and build/test tasks of an RFC within the Change Management Life Cycle.

    3. The CA must also perform the following:
      • The impacted projects must be submitted as comments for the proposal to the responsible Change Analyst.
      • The Change Analyst must review the proposal to determine the impacted projects.
      • The Change Analyst must route the proposal with impacted projects for review.
      • The Change Analyst must package the proposal as a Work Request (WR) and submit the WR to the Coordinator.
      • The Change Analyst’s Frontline Manger must review and authorize the RFC after it is submitted by the initiating Change Analyst.

    4. Change Manager (CM): The Change Manager must support the Technical Authorization and Schedule & Approve Phases by reviewing the submitted Request For Change (RFC). The CM must ensure the RFC follows the correct workflow.

    5. Change Coordinator (CC): The Change Coordinator must coordinate the RFC/WR assessment, planning, and performance of work completed by the technical team.

    6. Change Authority (CA): The Change Authority is the approval group that must accept or reject the RFC/WR during the presentation to the Configuration Control Board (CCB). If the CA accepts the RFC/WR, the Chairperson must present the RFC/WR to the Committee or schedule the Proposer, Analyst, or Coordinator to present the RFC/WR.

    7. Work Request (WR): The Committee must reject or accept the WR. If the Committee accepts the , the Analyst must package the signatures and WR, then submit the package to CCB SharePoint site.

    8. Change Approver/Change Advisory Board (CAB): The Change Approver or Change Advisory Board (CAB) consist of representatives from all IRS IT organizations/domains that must provide advice on the assessment, prioritization, scheduling of changes, and approval of releases.

  4. For additional information pertaining to Change Management, see IRM 2.125.2 Information Technology, Change Management, Change Management Process Description.

Requesting a Work Request

  1. Personnel affected by controls cited under Internal Revenue Manual (IRM), Part 2 (Information Technology), Chapter 5 (Applications Development) may request a Work Request from these controls. If conformance to a control is impossible, unreasonable, or otherwise not in the best interest of the Agency, then a Work Request from conformance may be requested.

  2. To request a Work Request, the steps are:

    1. The Requestor must prepare a memo requesting the Work Request

    2. The Requestor must submit the memo to the Configuration Controls

    3. The Coordinator must review the Work Request and submit the Work Request to the Sponsor, Configuration Control Board (CCB)for approval or denial

    4. The Government sponsor, CCB must either approve or deny the Work Request

    5. The Coordinator, within 15 working days, must notify the Requestor of a decision

  3. When preparing a memo to request a Work Request, at a minimum, the memo must:

    1. Identify the related standards document and, if applicable, the specific standard

    2. Explain and justify the request for a Work Request

    3. Identify any pertinent documentation

    4. Describe an alternative to the waived standard

    5. Identify a contact

  4. When notifying the Originator of a decision, at a minimum, the notification must:

    • State whether the request was approved or denied or state whether additional time is required for a decision

    • If additional time is required, then the notification must state the expected date of decision

    • State an explanation to the Originator when a request is denied

Directives

  1. This section establishes directives for applications development. Through internal controls and during the engineering, development, and maintenance of agency software systems, these directives must be satisfied. Exhibit 2.5.1-4, for each directive, lists the IRMs that support the directive.

  2. This IRM establishes the following directives:

    • Assurance of Quality Software

    • Coordinate Change and Maintenance of Applications Configuration Controls

    • Coordinate Change of Applications

    • Curtail Software Defects

    • Define Applications Configuration Controls

    • Engineer Software Products

    • Integrate Engineering and Managerial Activities

    • Manage Requirements

    • Manage Software Changes

    • Manage Software Contracts

    • Plan Applications Change Projects

    • Track and Oversee Applications Change Projects

    • Plan/Define Continuous Process Improvement

    • Manage security controls for system development based on NIST 800-37 Risk Management Framework and NIST 800-53 Revision 4: Security and Privacy Controls

    • Plan/Define Organizational Process Training

Quality Assurance (QA)

  1. The purpose of this directive is to provide management with visibility into the processes being used by organizational units that develop, maintain, and manage software.

  2. The following requirements state what is expected to satisfy this directive:

    1. All activities for Quality Assurance (QA) must be planned.

    2. Quality Assurance must be applied to all Applications Change projects.

    3. Software product quality (the conformance of products with standards and requirements) must be objectively validated.

    4. Software service performance (the adherence of services with procedures and requirements) must be objectively verified.

    5. Organizational units affected by QA activities must be informed of these activities and the results.

    6. Noncompliance issues unresolved among organizational units must be organizationally elevated and resolved.

  3. The Delivery Management and Quality Assurance (DMQA) manager must request and initiate an appraisal of how AD is performing their process against the referenced process improvement model.

Audit Process Control
  1. AD Quality Assurance is responsible for seven process areas and three types of audits for process control.

  2. AD audit process controls are as follows:

    • Process Audit: Evaluates a process area, in depth, based on organizational standard and requirements, and are based on where a project is in the development lifecycle.

    • Work Product Audit: Reviews work products (all product and deliverables) for conformance to the Enterprise Life Cycle (ELC), Data Item Descriptions (DID) and templates. This audit is either performed as the project completes during the lifecycle, or in conjunction with the QA Release Review.

    • Release Review Audit: Evaluates the processes used and work products produced during a release, and is normally performed at the end of a scheduled release for projects that have an accelerated release schedule.

    • For additional information please see, IRM 2.5.14.

  3. The final Audit Findings report is issued and stored in the QA repository, and when audit findings need corrective action, a Corrective Action plan is requested from the auditor as a part of the Audit Findings report.

Change Control Board (CCB) Roles
  1. The Chief, IT Enterprise Operations, Demand Management & Project Governance (DMPG) Change Advisory Board (CAB) Application Development (AD), QA and Senior AD QA Management Analyst serve as the QA CCB and manage Change Control procedures when new QA documents are developed or Changes Request (CR) have been received:

    1. The Chief, AD QA and the Senior AD QA ensure the following tasks are accomplished:
      • Accurate sequential numbers are assigned to each CR received, and the request is recorded in the QA CR log
      • All updates to the AD QA database with results from the audit or other record of QA audit activities
      • Change Requests are forwarded to the Change Control Board for disposition
      • AD QA CCB meet monthly, and review any Change Request (CR) received, in accordance with the AD QA Change Control Procedures.

    2. For Process Asset Integration Group assets, the approval process starts with the CCB, but must be approved by the AD Program Management Office (PMO) and Associate CIO.

    3. For additional information see, IRM 2.5.14 System Development, Quality Assurance.

Coordinate Change and Maintenance of System Change Control

  1. The IT Enterprise Operations, Demand Management & Project Governance (DMPG) Change Advisory Board (CAB) is a community of IT executives and IT professionals that advise and collaborate with the Application Development domain for the assessment, prioritization, scheduling of changes, and the approval of releases.

  2. The purpose of this directive is to establish organizational responsibility for activities that improve the Agency’s capability to develop systems and software applications. The following requirements state what is expected to satisfy this directive:

    1. System Change and improvement activities must be coordinated across the organization.

    2. Strengths and weaknesses of the Change processes used must be identified relative to the standard processes.

    3. Organization-level Change processes, and improvement activities must be planned.

Coordinate Change of Software

  1. The purpose of this directive is to establish a means for the system development Change Management processes to participate with the other Change groups so that the project is better able to satisfy the customer’s needs. The Demand Management & Project Governance (DMPG) is responsible for the development, implementation, and maintenance of this process. The following requirements state what is expected to satisfy this directive:

    1. The customer’s business requirements must be agreed to and signed by all affected organizations.

    2. Commitments among the Change organizations must be agreed to by affected organizations.

    3. Development organizations must identify, track, and resolve issues.

Curtail Software Defects

  1. The purpose of this directive is, early and efficiently, to remove defects from software. The following requirements state what is expected to satisfy this directive:

    1. Planning and coordination of requirements

    2. Peer review meetings must be planned

    3. Defects in software products must be identified by total number of major and minor defects found by all peer reviewers, and removed

    4. Rework must be performed to resolve issues found

    5. A follow-up peer review meeting must be performed for reworked requirements artifact

    6. Exit Criteria - All defects and issues have been identified, corrected, and the product is accepted

Define System Configuration Controls

  1. The purpose of this directive is to develop and maintain a usable set of system Change process assets and controls that improve process performance across the organization and that provide a basis for cumulative, long-term benefits to the organization. The following requirements state what is expected to satisfy this directive:

    1. A standard Change and maintenance process for the organization must be developed and maintained.

    2. Information about the organization’s use of standard processes must be collected, organized, reviewed, and shared.

Engineer Software Products

  1. The purpose of this directive is to consistently perform a well-defined engineering process that integrates all software engineering activities, effectively and efficiently, to produce correct, consistent software products. The following paragraphs state what is required to satisfy this directive:

    1. Software engineering tasks/activities must be defined, integrated, and consistently performed to produce software.

    2. Software products must be kept consistent.

Integrate Engineering and Managerial Activities

  1. The purpose of this directive is to integrate the software engineering and management activities into a coherent, defined process that is tailored from the organization’s Configuration Controls. The following requirements state what is expected to satisfy this directive:

    1. Project plans must be tailored from the Agency’s standard Change processes.

    2. Projects must be planned and managed according to the Agency’s standard Change processes.

Improve Processes and Maintain Process Assets

  1. The purpose of this directive is to receive, evaluate, review and implement new, improved or enhanced processes and /or implement best practices. The following requirements state what is expected to satisfy this directive for Continuous Process Improvement (CPI):

    1. Establish the framework for organizations to make incremental process improvements

    2. Establish and maintain a set of organizational process assets

    3. Plan, implement, and communicate improvements

    4. Coordinate and deploy process Change and improvement activities across the organization

    5. Develop new and update processes and process assets

Manage Requirements

  1. The purpose of this directive is to establish a common understanding (understanding of the requirements allocated to the software) between an organizational unit that is acquiring software and an organizational unit that is developing or maintaining the software. The following requirements state what is expected to satisfy this directive:

    1. System requirements allocated to software must be controlled to establish a baseline for software engineering and management.

    2. When allocated requirements are changed, the plans, products, and activities associated with the software must be accordingly changed.

Manage Software Configurations

  1. The purpose of this directive is to establish and maintain the integrity of the product, throughout the life of the corporate software product. The following requirements state what is expected to satisfy this directive:

    1. Software configurations management activities must be planned.

    2. Corporate software products, identified as software configuration items, must be cataloged, controlled, and inventoried.

    3. Access to, changes to, and distribution of configuration items must be controlled.

    4. Organizational units involved in software configuration management activities must to be informed of the status and content of software baselines.

Manage Software Contracts

  1. The purpose of this directive is to select qualified software contractors and effectively manage them. The following requirements state what is expected to satisfy this directive:

    1. Documented standards and procedures must be used in selecting software subcontractors and managing the subcontract.

    2. Project managers and subcontractors must agree to their commitments to each other.

    3. Project managers and subcontractors must maintain ongoing communication.

    4. Project managers must track contractor’s actual results and performance against commitments.

Plan Applications Development Projects

  1. The purpose of this directive is to establish reasonable plans for managing Change projects and performing engineering tasks. The following paragraphs state what is required to satisfy this directive:

    1. Estimates must be documented and used in project planning and tracking.

    2. Project activities and commitments must be planned and documented.

    3. Project commitments must be negotiated between all managers involved in a project and the results of this negotiation must be documented.

Track and Oversee Applications Development Projects

  1. The purpose of this directive is to provide adequate visibility into the actual development progress so that management can take effective actions when the project’s performance deviates significantly from the plan (project plan or applications Change plan). The following paragraphs state what is required to satisfy this directive:

    1. Actual results and performance must be tracked against the project plan.

    2. When actual results and performance significantly deviate from the plan, corrective actions must be taken and managed to closure.

    3. Changes to project commitments must be agreed to by managers in affected organizational units.

Define/Plan Organizational Process Training

  1. The purpose of this directive is to develop the skills and knowledge of employees to perform their role effectively and efficiently. The following paragraphs state the requirements to satisfy this directive:

    1. Training activities are planned.

    2. Identify training needed by the organization.

    3. Obtain and provide training to address those needs.

    4. Establish and maintain training records.

    5. Assess training effectiveness.

Terms and Descriptions

Terms Descriptions
Audit An independent examination of deliverables, products, or services performed to assess compliance with established policies, procedures, standards, processes or other controls.
Agency Software System A software system developed by or for an agency.
Capability Maturity Model A description of the stages through which an organization or organizational unit evolves as it defines, implements, measures, controls, and improves its Change processes. By facilitating the determination of current capabilities and the identification of issues most critical to product quality and service performance, this model provides a guide for selecting improvement strategies.
CCB SharePoint A SharePoint site that displays a change in Configuration Controls. The bulletin describes the change, justifies the change, states the benefits of implementing the change, identifies the affected Internal Revenue Manual, lists the organizational units/personnel that are affected and targeted for IRM document clearance, and identifies a contact for responses to the change.
Continuous Improvement Sometimes called continual improvement. The ongoing improvement of products, services or processes through incremental and breakthrough improvements.
Continuous Process Improvement Provides a framework for organizations to make incremental process improvements, even in those processes that are considered to be in good operating condition. It is based on the philosophy that organizations can always make improvements.
Control A statement published to either
1) Determine or influence decisions
2) Establish limits, alternatives, and guidelines for personnel who exercise discretion in applying their authority or fulfilling their duties and responsibilities.
Customer A person or organizational unit that is responsible for accepting a product or service and for authorizing payment to the provider.
Configuration Controls Controls used to influence or determine decisions regarding the engineering, development, or maintenance of systems. In a managerial context, a Configuration Controls may constitute a policy, directive, standard, or procedure. In a technical context, a Configuration Controls may address a deliverable, method, process, technique, task, or tool.
Directive A control that expresses executive commitment, direction, or leadership.
End User When a product or service is deployed in its operational environment, an end user refers to the person or organizational unit that will use the product or service for its intended operational use.
Findings The conclusions of an assessment, evaluation, audit, or review that identify issues, problems, or opportunities within the area of investigation.
Focus group A group, usually of 8 to 10 persons, that is invited to discuss an existing or planned product, service or process.
Guideline A control that is not monitored for compliance, or compliance is not mandatory.
Method A set of criteria and rules that establishes a consistent, predictable, or repeatable way to perform a task or produce a result.
Methodology A synthesis of controls, methods, plans, or principles that constitutes an approach for accomplishing something.
Organization An organizational unit that comprises other organizational units.
Organizational Unit A group of people acknowledged as a unit within an organization.
Peer Review A review of a deliverable/product performed by peers of the producers of the deliverable/product and performed to identify defects and improvements.
Project An organizational unit chartered to accomplish one or more goals within a scheduled timeframe, within an allocated budget, and according to a documented plan.
Project Manager A role assigned to a person who is expected to manage a project and manage according to a budget, schedule, defined scope, and documented plan.
Procedure A control used and enforced to establish uniform performance of some activity or service
Process Improvement An application of the plan-do-study-act (PDSA) philosophy to processes to produce positive improvement and better meet the needs and expectations of customers
Process Improvement team A structured environment often made up of cross functional members who work together to improve a process or processes.
Software Application A software product applied in some discipline or field (e.g., accounting, purchasing, project management) to accomplish work.
Software Product The complete set or any of the individual items of the set, of computer programs, procedures, and associated documentation and data designated for delivery to a customer or end user.
Software System A collection of software components organized to accomplish a function
Standard A control that specifies a mandatory characteristic for some product or other result, and is enforced to prescribe a uniform quality for a product or other result
Subproject A component of a larger project.
System A collection of components organized to accomplish a specific function or set of functions.
System Requirement A condition or capability that a system or system component must meet
Tailor To modify a process, standard, or procedure.
Work Product All products and deliverables including the standards/procedures used to produce them.

Roles By Organizational Unit

This exhibit identifies the organizational units assigned to the roles established through this IRM. Where a role is assigned to an organizational unit, the assignment means the role is assigned to the manager of the unit, or person delegated by the manager.

Role Organizational Unit
Change Control Board Director, Delivery Management and Quality Assurance
    OS:IT:AD:DMQA
Configuration Control Board Director, Corporate Data
    OS:CIO:AD:CP
  Director, Compliance Systems
    OS:CIO:AD:C
  Director, Internal Management Systems
    OS:CIO:AD:IM
  Director, Submission Processing
    OS:CIO:AD:SP
  Director, Customer Service
    OS:CIO:AD:CS
Sponsor, Configuration Control Board Director, Technical Integration Organization
    OS:CIO:TIO
Chairperson, Configuration Control Board Application Development
    OS:CIO:AD

Directives and Supporting Internal Revenue Manuals

Directive IRM that supports Directive
Assure Software Quality IRM 2.5.14 , Quality Assurance
Mitigate Software Defects IRM 2.127.1 Information Technology, Testing Standards and Procedures Testing Policy and IRM 2.127.2 , Testing Standards and Procedures
Coordinate development Change, and Maintenance of System Configuration Controls IRM 2.5.1, Systems Development
Coordinate Change of Software IRM 2.15.1 , Enterprise Architecture
Define System Development Configuration Controls IRM 2.150.1, Information Technology, Configuration Management Policy, and IRM 2.150.2 , Information Technology, Configuration Management, Configuration Management Process
Change Management Process Description IRM 2.125.2 IT Change Management, Change Management Process Description
Engineer Software Products IRM 2.5.3, System Development Programming and Source Code Standards
Guidelines on the preparation of Enterprise Life Cycle deliverables that create documents IRM 2.5.4 , Document Standards
Standard to use when creating data names and eliminating data redundancies IRM 2.152.3, Information Technology, Data Engineering, Naming Data Element(s)/Object(s)
Integrate Engineering and Managerial Activities IRM 2.120.1, Information Technology, Engineering, Engineering Policy
Manage Requirements IRM 2.110.1, Information Technology, Requirements Engineering, Requirements Engineering Directive
Manage Software Changes IRM 2.150.1, Information Technology, Change Management
Manage Software Contracts IRM 2.149.4, Information Technology, Asset Management, Asset Management Procedures
Plan Software Development Change Projects IRM 2.15.1, Enterprise Architecture (EA)
Track and Oversee Development Change Projects IRM 2.120.5, Information Technology, Engineering - Performance Engineering

Acronyms and Definition

Acronym Definition
ACIO Assistant Chief Information Officer
AD Application Development
CCB Change Control Board
CCB Configuration Control Board
CIO Chief Information Officer
CMM Capability Maturity Model
CR Change Request
CMMI Capability Maturity Model Integration.
CPI Continuous Process Improvement
DCOS Deputy Commissioner for Operations Support
ELC Enterprise Life Cycle
EPMO Enterprise Program Management Office
IRM Internal Revenue Manual
IRSD Internal Revenue Service Document.
PDCA Plan-Do-Check-Act
QA Quality Assurance
QC Quality Control
WR Work Request.