Accessibility Skip to Top Navigation Skip to Main Content Home  |  Change Text Size  |  Contact IRS  |  About IRS  |  Site Map  |  Español  |  Help  

Part 2. Information Technology

Chapter 5. Systems Development

Section 1. Systems Development

2.5.1  Systems Development

2.5.1.1  (09-01-2006)
Introduction

  1. This manual is organized into the following subsections:

    1. Introduction

    2. Development Control

    3. Directives

  2. The subsection, "Introduction" introduces Internal Revenue Manual (IRM), Part 2 (Information Technology), Chapter 5 (Applications Development). This subsection addresses topics relevant throughout IRM, Part 2, Chapter 5.

  3. The subsection, "Development Control" cites the procedure for proposing changes to controls established under IRM, Part 2, Chapter 5. This subsection also cites the procedure for requesting a waiver to controls established under this chapter.

  4. The subsection, "Directives" cites the directives expected to be satisfied through internal management controls and during the engineering, delivery, and maintenance of Agency software systems.

2.5.1.1.1  (09-01-2004)
Purpose

  1. This Internal Revenue Manual (IRM) and the other manuals that constitute IRM Part 2 (Information Technology), Chapter 5 (Applications Development) establish 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.5.1.1.2  (09-01-2004)
Definitions

  1. Exhibit 2.5.1-1 defines terms and acronyms used in this Internal Revenue Manual (IRM) and terms that shall be consistently used among the IRMs under IRM Part 2, Chapter 5.

2.5.1.1.3  (09-01-2004)
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 or maintenance of these software systems shall ensure contracts comply with these controls.

2.5.1.1.4  (09-01-2004)
Roles

  1. Exhibit 2.5.1-2 identifies the personnel or organizational units assigned to the roles established through this Internal Revenue Manual (IRM). This IRM establishes the following roles:

    • Development Controls Coordinator

    • Software Quality Committee

    • Sponsor, Software Quality Committee

    • Chairperson, Software Quality Committee

2.5.1.1.4.1  (09-01-2004)
Development Controls Coordinator

  1. The Development Controls Coordinator coordinates the assessment, development, maintenance, and improvement of the controls established through Internal Revenue Manual (IRM) Part 2 (Information Technology), Chapter 5 (Applications Development).

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

  3. The Development Controls Coordinator ensures controls are published in a consistent manner.

2.5.1.1.4.2  (09-01-2004)
Software Quality Committee

  1. The Software Quality Committee accepts or rejects proposed changes to controls established under Internal Revenue Manual (IRM) Part 2 (Information Technology), Chapter 5 (Applications Development).

2.5.1.1.4.3  (09-01-2004)
Sponsor, Software Quality Committee

  1. The Sponsor, Software Quality Committee concurs on the distribution of a System Information Bulletin.

  2. The Sponsor approves or disapproves waivers or deviations from controls cited under Internal Revenue Manual (IRM) Part 2 (Information Technology), Chapter 5 (Applications Development).

2.5.1.1.4.4  (09-01-2004)
Chairperson, Software Quality Committee

  1. The Chairperson decides whether a System Information Bulletin (SIB) will be presented to the Software Quality Committee and designates who will present the SIB.

2.5.1.1.5  (09-01-2004)
Waivers

  1. Without approval from the Software Quality Committee, there shall be no waivers or deviations from the controls established under Internal Revenue Manual (IRM) Part 2 (Information Technology), Chapter 5 (Applications Development).

2.5.1.1.6  (09-01-2004)
References

  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.

2.5.1.1.6.1  (05-26-2006)
Constituent Internal Revenue Manuals

  1. Internal Revenue Manual (IRM) 2.5.1, Systems Development introduces IRM Part 2 (Information Technology), Chapter 5 (Applications Development). The following IRMs constitute this chapter:

    • IRM 2.5.2, Software Systems Testing

    • IRM 2.5.3, Programming and Source Code Standards

    • IRM 2.5.4, Document Standards

    • IRM 2.5.7, Data Naming Standards

    • IRM 2.5.10, Function Point Standards

    • IRM 2.5.11, Analysis and Design

    • IRM 2.5.13, Database Design

    • IRM 2.5.14, Quality Assurance

    • IRM 2.5.16, Use of Live Data in Testing

    • IRM 2.5.50, Enterprise Life Cycle Lite

  2. IRM 2.5.2, Software Systems Testing defines the testing procedure for developers who must provide software that adheres to standards for systems development, complies with approved processing requirements, and meets the needs of customers.

  3. IRM 2.5.3, Programming and Source Code Standards establishes standards and guidelines to promote the development of maintainable, portable, reliable software applications in all Service used/approved languages.

  4. IRM 2.5.4, Document Standards provides preparation standards and guidelines for documents that constitute deliverables.

  5. IRM 2.5.7, Data Name Standards provides the standards and methods to be used when developing data names throughout development life cycles.

  6. IRM 2.5.10, Function Point Standards describes function point standards and how it will be used. These standards explain the use of function points for software sizing, resource estimation, cost of software development and forecasting.

  7. IRM 2.5.11, Analysis and Design establishes standards, techniques, and other controls for documenting analysis results and documenting software designs. This IRM was developed to describe techniques for analyzing business processes, designing and modeling software designs.

  8. IRM 2.5.13, Database Design establishes standards, guidelines and other controls for documenting database systems. It describes techniques for analyzing, designing, and modeling databases.

  9. IRM 2.5.14, Quality Assurance provides audit guidelines and procedures. These guidelines and procedures establish how to determine the level of compliance with agency directives, procedures, and standards for systems development.

  10. IRM 2.5.16, Use of Live Data in Testing cites procedures for using live data in testing software.

  11. IRM 2.5.50, Enterprise Life Cycle Lite details 1) the project management methodology for non-Tier A projects and 2) cites the policies, procedures, and guidelines for chartering and managing system development projects.

2.5.1.1.6.2  (09-01-2004)
Internal Revenue Service Documents

  1. The following Internal Revenue Service Document (IRSD) supplements this Internal Revenue Manual (IRM):

    • IRSD 12136, Enterprise Life Cycle Lite

  2. IRSD 12136, Enterprise Life Cycle Lite details the project life cycles for systems development.

2.5.1.1.6.3  (05-26-2006)
Other Publications

  1. The controls established in this Internal Revenue Manual (IRM) are based on decisions, direction, guidance, or recommendations expressed in the following documents:

    • Tax Systems Modernization: Blueprint is a good start but not yet sufficiently complete to build or acquire systems (GAO/AIMD/GGD-98-54, February 1998)

    • Clinger-Cohen Act of 1996

  2. The controls established in this IRM are based on concepts, principles, and theory expressed in the following documents:

    • The Capability Maturity Model: Guidelines for Improving the Software Process, Carnegie Mellon University/Software Engineering Institute, ISBN 0-201-54664-7

    • Managing the Software Process, Watts S Humphrey, ISBN 0-201-18095-2

    • Capability Maturity Model Integration (CMMI): Guidelines for Process Integration and Product Improvement, Mary Beth Chrissis, Mike Konrad and Sandy Shrum, ISBN 0-321-15496-7

2.5.1.1.7  (06-07-2006)
Revision History

  1. Internal Revenue Manual (IRM) 2.5.1, Applications Development constitutes a new IRM. Exhibit 2.5.1-3 records the revision history for this IRM.

2.5.1.2  (09-01-2004)
Development Control

  1. To coordinate the assessment, development, maintenance, and improvement of development controls and to manage deviations from these controls, Internal Revenue Manual (IRM) 2.5.1, Applications Development establishes the following procedures:

    • Proposing a Change

    • Requesting a Waiver

2.5.1.2.1  (09-01-2004)
Proposing a Change

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

  2. To propose a change, the steps are:

    1. The Proposer shall prepare a proposal and submit the proposal to the Development Controls Coordinator.

    2. The Coordinator shall route the proposal to an analyst.

    3. The Analyst should review the proposal to determine impacted projects.

    4. The Analyst shall route the proposal to the impacted projects for review.

    5. The impacted projects should submitted comments to proposal to the Analyst who would incorporate into proposal.

    6. The Analyst shall package the proposal as a System Information Bulletin (SIB) and submit the SIB to the Coordinator.

    7. The Coordinator shall review the SIB and submit the SIB to the Chairperson, Software Quality Committee.

    8. The Chairperson shall reject or accept the SIB for presentation to the Software Quality Committee (SQC). If the Chairperson accepts the SIB, the Chairperson shall present the SIB to the Committee or schedule the Proposer, Analyst, or Coordinator to present the SIB.

    9. The Committee shall reject or accept the SIB. If the Committee accepts the SIB, the Analyst shall package the signatures and SIB, then submit the package to the Sponsor, SQC for concurrence.

    10. If the Sponsor approves the SIB, then the Analyst shall distribute the SIB, revise the appropriate IRM, clear the IRM, and submit the IRM for republication.

2.5.1.2.2  (09-01-2004)
Requesting a Waiver

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

  2. To request a waiver, the steps are:

    1. The Requestor shall prepare a memo requesting the waiver.

    2. The Requestor shall submit the memo to the Development Controls Coordinator.

    3. The Coordinator shall review the waiver and submit the waiver to the Sponsor, Software Quality Committee (SQC) for approval or denial.

    4. The Sponsor, SQC shall either approve or deny the waiver.

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

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

    • identify the related standards document and, if applicable, the specific standard;

    • explain and justify the request for a waiver;

    • identify any pertinent documentation;

    • describe an alternative to the waived standard; and

    • 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 and

    • if additional time is required, then the notification shall state the expected date of decision.

    • a explanation will be provided to the Originator when a request is denied.

2.5.1.3  (06-07-2006)
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 shall be satisfied. Exhibit 2.5.1-4, for each directive, lists the IRMs that support the directive.

  2. This IRM establishes the following directives:

    • Assure Software Quality

    • Coordinate Development and Maintenance of Applications Development Controls

    • Coordinate Development of Applications

    • Curtail Software Defects

    • Define Applications Development Controls

    • Engineer Software Products

    • Integrate Engineering and Managerial Activities

    • Manage Requirements

    • Manage Software Configurations

    • Manage Software Contracts

    • Plan Applications Development Projects

    • Track and Oversee Applications Development Projects

    • Plan/Define Continuous Process Improvement

    • Plan/Define Organizational Process Training

2.5.1.3.1  (06-07-2006)
Assure Quality Assurance

  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. The following requirements state what is expected to satisfy this directive:

    1. Activities for Quality Assurance (QA) shall be planned.

    2. Quality Assurance shall be applied to all Applications Development Projects.

    3. Software product quality (the conformance of products with standards and requirements) shall be objectively validated; software service performance (the adherence of services with procedures and requirements) shall be objectively verified.

    4. Organizational units affected by QA activities shall be informed of these activities and the results.

    5. Noncompliance issues unresolved among organizational units shall be organizationally elevated and resolved.

  2. The Business Process Improvement (BPI) Program Manager can request and initiate an appraisal of how AD is performing their process against the referenced process improvement model.

2.5.1.3.2  (06-07-2006)
Coordinate Development and Maintenance of System Development Controls

  1. 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 development and improvement activities shall be coordinated across the organization.

    2. Strengths and weaknesses of the development processes used shall be identified relative to the standard processes.

    3. Organization-level process development and improvement activities shall be planned.

2.5.1.3.3  (06-07-2006)
Coordinate Development of Software

  1. The purpose of this directive is to establish a means for the applications development project to participate with the other development groups so that the project is better able to satisfy the customer’s needs. The following requirements state what is expected to satisfy this directive:

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

    2. Commitments among the development organizations shall be agreed to by affected organizations.

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

2.5.1.3.4  (09-01-2004)
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. Peer reviews shall be planned.

    2. Defects in software products shall be identified and removed.

2.5.1.3.5  (09-01-2004)
Define System Development Controls

  1. The purpose of this directive is to develop and maintain a usable set of system development 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 development and maintenance process for the organization shall be developed and maintained.

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

2.5.1.3.6  (09-01-2004)
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 shall be defined, integrated, and consistently performed to produce software.

    2. Software products shall be kept consistent.

2.5.1.3.7  (09-01-2004)
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 development controls. The following requirements state what is expected to satisfy this directive:

    1. Project plans shall be tailored from the Agency’s standard development processes.

    2. Projects shall be planned and managed according to the Agency’s standard development processes.

2.5.1.3.8  (06-01-2006)
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 development and improvement activities across the organization;

    5. Develop new and update processes and process assets.

2.5.1.3.9  (09-01-2004)
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 shall 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 shall be accordingly changed.

2.5.1.3.10  (09-01-2004)
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 configuration management activities shall be planned;

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

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

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

2.5.1.3.11  (09-01-2004)
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 shall be used in selecting software subcontractors and managing the subcontract.

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

    3. Project managers and subcontractors shall maintain ongoing communication.

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

2.5.1.3.12  (09-01-2004)
Plan Applications Development Projects

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

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

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

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

2.5.1.3.13  (06-07-2006)
Track and Oversee Applications Development Projects

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

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

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

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

2.5.1.3.14  (06-07-2006)
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 what is required 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.

Exhibit 2.5.1-1  (06-07-2006)
Definitions

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

CMM:An acronym for Capability Maturity Model.

CMMI:An acronym for Capability Maturity Model Integration.

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 or 2) establish limits, alternatives, and guidelines for personnel who exercise discretion in applying their authority or fulfilling their duties and responsibilities.

CPI:An acronym for Continuous Process Improvement.

Customer: A person or organizational unit that is responsible for accepting a product or service and for authorizing payment to the provider.

Development Control:A control used to influence or determine decisions regarding the engineering, development, or maintenance of systems. In a managerial context, a development control may constitute a policy, directive, standard, or procedure. In a technical context, a development control 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 1) is not monitored for compliance or 2) compliance is not mandatory.

IRM:An acronym for Internal Revenue Manual.

IRSD:An acronym for Internal Revenue Service Document.

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:1) A control that specifies actions or steps to be taken to perform a given activity or service. 2) A control used and enforced to establish uniform performance of some activity or service.

Process improvement:The application of the plan-do-study-act (PDSA) philosophy to processes to produce positive improvement and better meet the needs and expectations of customers (see " plan-do-check-act cycle" ).

Process improvement team: A structured environment often made up of cross functional members who work together to improve a process or processes.

SIB:An acronym for System Information Bulletin.

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:1) A control that specifies a mandatory characteristic for some product or other result. 2) A control used and 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 Information Bulletin:A bulletin that announces a change in development 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.

System Requirement:A condition or capability that a system or system component must meet.

Tailor:To modify a process, standard, or procedure.

Exhibit 2.5.1-2  (09-01-2004)
Roles

This exhibit identifies the organizational units assigned to the roles established through this Internal Revenue Manual (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 Assigned Personnel or Organizational Unit
Development Controls Coordinator Gwendolyn Barnett
    BPI Program Manager
    OS:CIO:AD:CE:B
Software Quality Committee Corporate Data
    OS:CIO:AD:CP
  Compliance Systems
    OS:CIO:AD:C
  Internal Management Systems
    OS:CIO:AD:IM
  Submission Processing
    OS:CIO:AD:SP
  Customer Service
    OS:CIO:AD:CS
  Test, Assurance & Documentation
    OS:CIO:AD:TAD
  Program Management
    OS:CIO:AD:PM
Sponsor, Software Quality Committee Applications Development
    OS:CIO:AD
Chairperson, Software Quality Committee Applications Development
    OS:CIO :AD

Exhibit 2.5.1-3  (09-01-2004)
Revision History

Date Change and Purpose for Change
September 2004 This manual was published as a new Internal Revenue Manual.
July 2006 This manual is being updated to incorporate the emphasis that has been placed on organizational improvements.
   

Exhibit 2.5.1-4  (06-01-2002)
Directives and Supporting Internal Revenue Manuals

Directive IRM that supports Directive
Assure Software Quality IRM 2.5.14, Quality Assurance
  IRM 2.6.1, Product Assurance Standards and Procedures
Coordinate Development and Maintenance of System Development Controls IRM 2.5.1, Systems Development
Coordinate Development of Software IRM 2.15.1, Enterprise Architecture
Curtail Software Defects IRM 2.5.2, Software Systems Testing
  IRM 2.6.1, Product Assurance Standards and Procedures
Define System Development Controls IRM 2.5.1, Systems Development
Engineer Software Products IRM 2.5.3, Programming and Source Code Standards
  IRM 2.5.4, Document Standards
  IRM 2.5.7, Data Naming Standards
  IRM 2.5.11, Analysis and Design
Integrate Engineering and Managerial Activities To be determined.
Manage Requirements IRM 2.5.11, Analysis and Design
Manage Software Configurations To be determined.
Manage Software Contracts To be determined.
Plan Software Development Projects To be determined.
Track and Oversee Development Projects To be determined.

More Internal Revenue Manual