2.16.1  ELC Guidance

Manual Transmittal

April 25, 2012

Purpose

(1) This transmits revised IRM 2.16.1, Enterprise Life Cycle (ELC) - Enterprise Life Cycle Guidance.

Material Changes

(1) This is a revised IRM providing an overview and detailed description of the ELC, and guidelines for using the ELC in a practical and effective manner.

(2) The information in IRM 2.16.1, Enterprise Life Cycle (ELC) Guidance, has been updated to reflect changes instituted since its previous publication. Editorial changes were made throughout the document, certain material was rearranged, website addresses were updated where applicable, and the following list of changes were also made:

Subsection Changed Description of Change
2.16.1 Where a change occurred to a subsection, the sub section is dated 12-15-2011. The following changes applied to various subsections throughout the manual:
  • Definitions and explanations for various terms were revised; especially terms and definitions that pertain to the iterative path were changed to address recent iterative development approaches;

  • Hypertext links and organizational references were updated;

  • Details pertaining to reviews were revised;

  • References to programs were removed; and

  • Figures were updated;


The following subsections were added:
  • A subsection to address obtaining development tools; and

  • A subsection to elaborate ELC path selection.

Effect on Other Documents

This IRM supersedes IRM 2.16.1, Enterprise Life Cycle (ELC) Guidance, dated September 4, 2010.

Audience

This IRM establishes the directive for implementing and complying with the ELC requirements. This IRM applies to IRS managers, personnel, and executives who manage, directly support, or provide oversight to projects that effect business change. This IRM also applies to contractors who conduct projects on behalf of the IRS that effect business change.

Effective Date

(04-25-2012)

Terence V Milholland
Chief Technology Officer

2.16.1.1  (06-16-2008)
ELC Overview

  1. This subsection provides an overview of the Enterprise Life Cycle (ELC). This includes what the ELC is (characteristics and structure) and why the ELC is used (purpose and objectives).

2.16.1.1.1  (08-03-2009)
What is the ELC?

  1. The ELC is the approach used by IRS to manage and implement business change through information systems initiatives.

  2. The ELC is appropriate for use by all (major, non-major, small-other) projects.

  3. Please see IRM 2.16.1.3.4.2 for the definitions of the three types of projects.

2.16.1.1.2  (06-16-2008)
Purpose of the ELC

  1. The ELC provides the direction, processes, tools, and assets necessary to accomplish business change in a consistent and repeatable manner.

2.16.1.1.3  (04-25-2012)
Objectives of the ELC

  1. The objectives of the ELC are to:

    1. Enhance chances for successfully achieving the desired business change

    2. Standardize the approach for managing and governing business change, and supporting information system projects throughout IRS; and

    3. Help ensure project success by reducing risk and ensuring compliance with applicable internal and external standards and mandates.

2.16.1.1.4  (09-04-2010)
Why Use the ELC?

  1. There are several reasons that IRS uses the ELC. First, the ELC is based on best practices of both government and industry. Using a documented life cycle based on these best practices enables IRS to follow repeatable processes that yield better results over the long run.

  2. Second, by using the ELC, IRS can more easily comply with external requirements such as the Clinger-Cohen Act, the Government Performance and Results Act (GPRA), the Federal Records Act (FRA), and the Federal Information Security Management Act (FISMA).

  3. Third, the IRS is implementing the recommendation made by the Treasury Inspector General for Tax Administration (TIGTA) to move to one life cycle that will accommodate all projects regardless of which IRS organization manages the project.

  4. Fourth, by using the ELC, the IRS is focused on designing and implementing technologies that meet business objectives, such as availability and sustainability.

2.16.1.1.5  (09-04-2010)
ELC Approval Authority for Artifacts

  1. This document supports roles that enable the IRS to engineer and integrate systems; transition from the current Architecture to the target Enterprise Architecture (EA); and otherwise manage changes to the enterprise.

  2. The approval authorities for major, non-major and small other projects are defined by the Process Owners to assist the Program/Project Manager concerning the appropriate approval(s) necessary for the artifacts produced by the project.

2.16.1.1.6  (08-03-2009)
ELC Training

  1. Project personnel are responsible for coordinating with their managers to ensure they receive appropriate training to implement the guidelines in this IRM. Contact the ELC Office training coordinator for current training information.

  2. Upcoming ELC Training is published on the ELC website. Please see the ELC website at http://elc.nc.no.irs.gov/.

2.16.1.1.7  (04-25-2012)
Structure of the ELC

  1. The ELC has two structural pieces:

    • Process Assets

    • ELC Framework

  2. Process Assets - A Process Asset provides guidance, support, direction or assistance for how to accomplish the work. Examples of process assets include:

    • Directives

    • Procedures

    • Document Standards

    • Data Item Descriptions (DIDs) and Templates

    • Handbooks, Guides, and manuals

    • Methodologies

    • Processes

    • Examples

    Process assets are available on the Information Technology (IT) Process Asset Library (PAL) ((http://paig.ds.irsnet.gov)).

  3. ELC Framework - ELC features are organized in a pictorial representation called the ELC Framework. This framework illustrates how various ELC features relate to each other and where they come into play at various points in the life cycle of a project.

2.16.1.1.8  (04-25-2012)
Standard Development Tools

  1. The IRS Enterprise Standards Profile (ESP) (http://ea.web.irs.gov/ESP/default.aspx) lists standards and approved products applicable to IRS target architecture as described in the Enterprise Architecture. Development teams should refer to the ESP to determine which standards and approved products apply to their areas of responsibility. Listings in the ESP include guidance for usage that should be reviewed for useful relevant information.

  2. Also refer to the Common Operating Environment (COE) (http://coe.enterprise.irs.gov/softwareOrdering/include/default.asp) website for additional software information and standards.

2.16.1.1.9  (04-25-2012)
Tools Request

  1. OS GetServices(http://itams.enterprise.irs.gov:11160/oaa/login.jsp) is a source for acquiring project resources such as software tools, for instance, once a project identifies required tools, requests may be submitted via OS GetServices for project members. The On-Line 5081 (https://ol5081.enterprise.irs.gov) System is the source for acquiring access to data repositories.

2.16.1.2  (04-25-2012)
ELC Framework

  1. The ELC Framework is the structure for organizing and applying the processes used to manage business change. The ELC Framework is composed of numerous structural elements; each serves a particular purpose and is implemented by one or more processes. The framework organizes the elements into six layers:

    • Management Layer

    • Governance Layer

    • System Life Cycle Layer

    • Solution Layer

    • Methodology Layer

    • Specialty Areas Layer

2.16.1.2.1  (04-25-2012)
Management Layer

  1. The purpose of the Management Layer is to plan, monitor, and control the work specified by the system life cycle. The assets associated with this layer address management functions performed by personnel who are part of or directly associated with the team or operational organization on a day-to-day basis. It includes the formation and management of projects to support the life cycle, and, if necessary, the acquisition of outside services to perform the work.

  2. Various types of projects are addressed and managed through the ELC. These basic types of projects are defined in the Management Layer.

  3. These features constitute this layer:

    • Project Types

    • Program Management

    • Project Management

    • Service Management

2.16.1.2.1.1  (08-03-2009)
Project Types

  1. A project is a group of tasks to accomplish a specific objective; with a beginning and ending date; that is planned, monitored, and measured; that follows a specific life cycle process; and that results in deliverables or end products. The ELC Framework addresses management of these types of projects:

    • Solution Development Projects

    • Solution Maintenance Projects

  2. Solution Development Projects - Solution development projects involve the design, development and/or acquisition, and deployment of solutions that support the enterprise vision and architecture. In the system life cycle, this type of project usually is initiated in the Project Initiation Phase and concluded in the System Deployment Phase. Note that a project with multiple releases may have one or more releases that are operational while development of the current release is in progress.

  3. Solution Maintenance Projects - Solution maintenance projects maintain, enhance, or otherwise change an operational solution or solution component that is part of the Current Production Environment (CPE). The maintenance type is addressed below:

    1. Planned Maintenance: a maintenance effort that is formally planned in advance as a project and executed with an appropriate degree of management and governance controls. A Planned Maintenance project may address multiple maintenance actions at the same time, will often originate from the Operations & Maintenance Phase, and may not need to execute all ELC stages

2.16.1.2.1.2  (04-25-2012)
Program Management

  1. A program is a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually. Programs may include elements of related work outside the scope of the discrete projects in a program. Because most business change initiatives are broad and complex, they are often structured as a set of related projects that are implemented over a period of time. Program management involves planning, directing, controlling, and administering these initiatives throughout the life cycle as a program. This focuses on management of the coordination between individual projects as well as guidance and direction for common aspects among the individual projects. The ELC does not provide directives, guidelines, or procedures for managing programs.

  2. The Program Management feature spans the portion of the life cycle from program initiation through systems deployment. However, there may be periods in which some projects have been delivered and others are in-process or have not yet begun. As a result, Program Management does not terminate after systems deployment but partially overlaps Service Management.

2.16.1.2.1.3  (08-03-2009)
Project Management

  1. Project management is the discipline applied to ensure orderly and controlled initiation, planning, execution, and close-out of a project.

  2. Project management functions according to a Project Management Plan (PMP) in conjunction with the closely related disciplines of requirements management, quality management, configuration management, risk management, issue and action item management, and others to ensure project success.

  3. The Project Management feature of the ELC Framework spans the portion of the life cycle that may be addressed by a formal project. This may include solution development projects and/or solution maintenance projects.

2.16.1.2.1.3.1  (09-04-2010)
Project Management Plan (PMP)

  1. The Project Management Plan (PMP) is a requirement for all IRS Information Technology (IT) projects and is a key project planning document.

  2. The PMP defines the project's scope of work and its approach to managing all project activities. It provides a framework for managing project activities and for completing the project successfully.

  3. The PMP consists of several subsidiary plans. These include:

    • Quality Management Plan (QMP)

    • Configuration Management Plan (CMP)

    • Requirements Plan (RP)

    • Risk Management Plan (RMP)

    • Contingency Management Plan (COMP)

  4. Work on the PMP begins in the Project Initiation Stage. IRM 2.16.1.2.3.3.3 for additional information about this stage.

  5. For detailed information on the PMP, refer to the Project Management Plan Template maintained on the ELC website (http://elc.nc.no.irs.gov/).

2.16.1.2.1.4  (06-16-2008)
Service Management

  1. Service Management involves planning, directing, controlling, and administering the support of a solution from the time it is deployed through the time it is retired. This includes management of services related to:

    • Operating and maintaining the technical infrastructure and automated solutions

    • Maintaining and enhancing the solutions

    • Helping users of the solutions

  2. Simultaneously, within the time span of any system life cycle, there may be some portions of the solution that are operational and managed by Service Management, while other portions of the same initiative are in development and managed by Program/Project Management. In some cases, the Service Management role may be performed by an outside contractor for interim project releases and turned over to the IRS only after deployment of the final release.

2.16.1.2.2  (08-03-2009)
Governance Layer

  1. Process assets associated with the Governance Layer address interventions by personnel or organizations that are not directly associated with the team performing the work on a day-to-day basis. These may include:

    1. Executive interventions (e.g., to determine if a project still meets IRS objectives),

    2. Specialty group interventions (e.g., System Engineering, Security, Privacy, Strategy and Capital Planning, Records Management, and Disaster Recovery and Contingency Planning) to ensure conformance to certain requirements or standards,

    3. Outside organization interventions (e.g., Office of Management and Budget (OMB), Government Accountability Office (GAO) for purposes such as funding and auditing.

  2. Governance activities are periodic and occur at specific points in the life cycle. These activities often take the form of reviews performed throughout the life cycle. The following features make up this layer:

    • Unified Work Request (UWR)

    • Project Charter

    • OMB Compliance

    • Milestones

    • Milestone Reviews (including Milestone Readiness (MRR) and Exit Reviews (MER))

    • Certifications

2.16.1.2.2.1  (09-04-2010)
Unified Work Request

  1. The Unified Work Request (UWR) process initiative is to provide a single system to request products and services from the IRS MITS organizations, except for those services that are requested through the OS GetIT services. Requests are referred to as Work Requests (WR). The WR is a required document that provides notification to MITS that a service or support is needed. As the project is implemented WRs will be used to document all of the requests for MITS services. The number and timing of these WRs will vary from project to project. For further information about the UWR process, please see the Requirements and Demand Management (RADM) web site (http://mits.web.irs.gov/ES/DM/).

2.16.1.2.2.2  (09-04-2010)
Project Charter

  1. The project charter is required for all new IRS projects. It formally introduces the scope of work to be accomplished by a project and assigns management responsibility for the project at a high level.

  2. The charter lists the business processes, key stakeholders, locations, requirements, systems, interfaces, business and technical scope, tools, and target releases that the project must address, as derived from the IRS Enterprise Architecture (EA), which includes the information systems and business architectures.

  3. Once approved, changes to the project charter are controlled through a formal change control process.

  4. The project charter is included in the Governance Layer to illustrate and highlight its specific life cycle location. Information about chartering a project is also found in the subsection on EA-related activities in the Enterprise Architecture Specialty Area. IRM 2.16.1.2.6.3

  5. For detailed information on the Project Charter, refer to the Project Charter Template maintained on the ELC website (http://elc.nc.no.irs.gov/).

2.16.1.2.2.3  (04-25-2012)
OMB Compliance

  1. OMB Compliance entails satisfying OMB requirements for planning, budgeting, acquiring, and managing federal capital assets. Two primary submissions must be made to OMB:

    • OMB Circular No. A-11, Part 2, Exhibit 53 (E53)

    • OMB Circular No. A-11, Part 7, Exhibit 300 (E300)

  2. OMB Circular No. A-11, Part 2, Exhibit 53 - The E53 is the Agency IT Investment Portfolio. It is submitted to identify requested funds from OMB as part of the normal budgeting cycle and updated as required. All investments requiring OMB IT funding are listed on the E53.

  3. OMB Circular No. A-11, Part 7, Exhibit 300 - The E300 is a subset of the E53, Capital Asset Plan, that summarizes the Business Case and outlines the benefits, costs, risks, and other OMB/Treasury requested data. It demonstrates an alignment with organizational objectives. It is used to determine if the effort should receive funding. The IRS submits the E300 to OMB to obtain funding approval for new major and existing major projects (IRM 2.16.1.3.4.2). The E300 is updated during the life of the project based on the annual budget cycle.

  4. OMB Circular No. A-130 (5) (k)- This states that agencies shall incorporate records management and archival functions into the design, development, and implementation of information systems.

  5. OMB Compliance is included in the Governance Layer to illustrate and highlight the specific life cycle location for this governance item. Information about E300s and E53s is also found in the Strategy and Capital Planning Specialty Area subsection. IRM 2.16.1.2.6.8

2.16.1.2.2.4  (08-03-2009)
Milestones

  1. A milestone is an investment management decision point placed at a natural breakpoint in the life cycle which allows the project to proceed to the next phase. Phases are broad sections of work that encompass activities of similar scope, nature, and detail, and that provides natural breakpoints in the life cycle. Milestones are points at which management requires updated cost, progress, and risk information to make project funding and decisions for project continuation.

    Milestone Occurs at the End of:
    MS 0 Vision & Strategy/Enterprise Architecture Phase
    MS 1 Project Initiation Phase
    MS 2 Domain Architecture Phase
    MS 3 Preliminary Design Phase
    MS 4A Detailed Design Phase
    MS 4B System Development Phase
    MS 5 System Deployment Phase

    Note:

    For MS 0, no formal MRR is required.

  2. Note that through tailoring, phases may be modified and combined depending on the nature of the life cycle path used. In these cases, there is a single milestone at the end of the combined phase. For example, a single Milestone 3/4A instead of Milestone 3 and Milestone 4A.

2.16.1.2.2.5  (09-04-2010)
Milestone Reviews

  1. There are three types of reviews that are related to milestones:

    • Pre-Milestone Readiness Review

    • Milestone Readiness Review

    • Milestone Exit Review

2.16.1.2.2.5.1  (04-25-2012)
Milestone Readiness Reviews

  1. A MRR is a project review performed by the reviewing organization to determine if the project is in compliance with ELC requirements and is ready to begin the milestone exit process. Depending on the project category, the reviewing organization may be the ELC Office, Business System Planning (BSP), or Program Management Office (PMO).

  2. It is recommended that the project complete a pre-MRR which is a dress rehearsal for the MRR. The pre-MRR is an opportunity to identify issues and/or risks that may impact the outcome of the MRR as well as resolve any issues and/or project conditions of the previous phases or phase being exited.

  3. As stated, the purpose of the MRR is to determine if the project is ready to exit a milestone and move on to the next phase. The MRR may help to minimize last minute project delays and help streamline MER decisions made by the project's governance organization. The MRR looks for the process artifacts that were identified for that phase of development in the Project Tailoring Plan.

  4. Existing information is gathered for the MRR. This includes project status, lessons learned, risk identification, technical decision criteria from Life Cycle Stage Review (LCSR) and/or End of Sprint Checkpoint (EoSC) summary of results. Validate that ELC required reviews have been conducted. Check CTR and LCSR Reviewer Comment Forms (or EOSC summary of results), consolidated comments, attendance lists and actions items, as appropriate. Ensure stakeholders/Process Owners participated in the LCSR by examining attendance lists and/or reviewer comment forms for each LCSR. Check that reviewer comments have been resolved satisfactorily. Ensure the appropriate LCSR checklists for the current phase have been completed and approved. Provide evidence that the project has completed review of all lessons learned from previous phases or releases, and that the risk identification was performed using the Risk Identification Procedures; and check that baseline ELC artifacts have been established or updated. This information is used to determine if the project has satisfied conditions outlined in the ELC Artifacts by Phase Checklist found on the ELC website. If all conditions are satisfied, the reviewing BSP or PMO will make a formal recommendation to the office providing support to the owning governance board that the project is ready to begin the milestone exit process. If the conditions are not met or fully satisfied, the reviewing organization may recommend a conditional exit and document the outstanding conditions (i.e., risks and issues) in the formal memorandum. If the conditions are not fully satisfied, the project may receive a conditional recommendation.

  5. Examine the status of risks, issues, action items and prior and/or current project conditions, if applicable. Status of these items will be noted in the MRR Report. Ensure projects have documentation supporting MS exit conditions. Update ELC Artifacts by Phase Checklist comment column with status or impediments for each required artifact.

  6. The following table depicts where MRRs are usually performed during the life cycle:

    MRR for: Monitors Readiness to Exit:
    Project Initiation Phase MS 1
    Domain Architecture Phase MS 2
    Preliminary Design Phase MS 3
    Detailed Design Phase MS 4A
    System Development Phase MS 4B
    System Deployment Phase MS 5

    Note:

    Planned Maintenance Path projects do not require MRRs for MS 5.

  7. IRM 2.16.1.3.5 Conducting Effective Reviews for further guidance on MRRs.

2.16.1.2.2.5.1.1  (04-25-2012)
Milestone Readiness Review Activities

  1. Activities for MRRs can be grouped into three areas:

    1. Plan and schedule the MRR;

    2. Conduct the MRR; and

    3. Prepare the MRR package.

  2. Plan and schedule the MRR - Activities included in planning are working with the ELC Coach to develop a tailoring plan, advising the stakeholders and process owners about the review schedule, and establishing a detailed schedule of review activities. The Project Manager or Release Manager should schedule the MRR ten business days prior to the scheduled milestone exit. To plan for the MRR, the Project Manager or Release Manager should:

    1. Confirm all ELC required artifacts, as specified in the Project Tailoring Plan (PTP), for the MS exit have been reviewed and approved (i.e., signed) by the relevant Process Owners. Ensure documentation is on file for any deferrals, waivers, etc.

    2. Assemble the project documentation to be reviewed at the MRR.

    3. Distribute project documentation, either electronically or hard copy, to the MRR team prior to the scheduled MRR.

    4. Schedule the MRR meeting according to the required timeframe discussed above. Ensure all CTRs or EOSCs and the LCSR have been completed and procedures followed; see CTR and LCSR procedures located on the PAL for guidance.

    5. Send a calendar invite for MRR meeting to the relevant Stakeholders and Process Owners, ELC Coach and MRR team.

  3. Conduct the MRR - Activities in the Conduct MRR area are intended to describe how the MRR is conducted. This activity is performed by the ELC Coach or designee assigned to the project. The ELC coach or designee is required to verify the relevant Process Owner approval signatures on all ELC required artifacts as documented in the PTP, as well as collect status on all prior and current project conditions, risks and issues. The ELC Coach or designee provides this information to the appropriate Governance Board as input into the decision making process, as well as ensure tracking is done, using the applicable IRS item tracking system. At each MRR, the ELC Coach or designee shall:

    1. Create an attendance list of MRR attendees and develop meeting minutes or notes from the discussion.

    2. Validate that the ELC artifacts listed on the ELC Artifacts by Phase Checklist, have been approved (signed) by relevant Process Owners, for the phase being exited. Any missing ELC required artifacts, such as no Cybersecurity certification, may become "conditions" (i.e., missing requirements which introduce risks to the project outcomes) to exiting the MS. These conditions are recorded as requirements based on the risks identified during a phase. The risks are entered into the MITS Enterprise Risk Tracking database (i.e., ITRACS or successor database) and are carried over to the next phase until resolved.

    3. Validate that ELC required reviews (CTRs or EOSCs, and LCSR) have been conducted. Check CTR or EOSC, and LCSR Review Comment Forms, Consolidated Comments, attendance lists and actions items, as appropriate. Ensure stakeholders/Process Owners participated in the LCSR by examining attendance lists and/or reviewer comment forms for each LCSR. Check that reviewer comments have been resolved satisfactorily. Ensure the appropriate LCSR checklists for the current phase have been completed and approved. Check that baseline ELC artifacts have been established or updated.

    4. Examine the status of risks, issues, action items and prior and/or current project conditions, if applicable. Status of these items will be noted in the MRR Mitigation Report. Ensure projects have appropriate documentation supporting MS exit conditions.

    5. Update ELC Artifacts by Phase Checklist comment column with status or impediments for each required artifact. Record the risks that are being carried over as conditional into the next phase and develop a mitigation plan for reporting to the Board.

    6. Validate MRR work checklist.

  4. Prepare the MRR package - Activities in the Prepare the MRR package is intended to describe how a MRR package is prepared. The MRR package will include a recommendation to the appropriate Governance Board for the project Milestone Exit Request (MER). This activity is led by the ELC Coach or designee with input from the Project Manager/Release Manager, project team members and relevant Process Owners. The ELC Coach or designee performs the following:

    1. Prepare the MRR Package. The package consists of the MRR Report Template, ELC Artifacts by Phase Checklist, MRR Work Checklist and MRR Attendees.

    2. Examine the impact of all risks, issues, project conditions and action items on the MS Exit as input into the MRR recommendation. Verify that all project conditions have mitigation plans in place.

    3. Submit a draft MRR package to the Project Manager or Release Manager (and affected Process Owners/Stakeholders, if applicable) for review and comment to obtain concurrence and/or discuss status at the MRR. The MS readiness recommendation will include one of three options: “Conditional, Unconditional, or Not to Proceed.”

    4. Once concurrence is obtained on the MRR package, finalize and route the package to the appropriate Executives for approval.

    5. Obtain executive approval. Send approved MRR package to the governance office (e.g., Program Governance Office (PGO), project Program Management Office (PMO), Business System Planner (BSP)) for submission to the appropriate Governance Board in support of the project MER.

    6. ELC coaches enter risks and issues associated with the exit recommendation into the MITS Enterprise Risk Tracking database (i.e., ITRACS or successor database).

    Governance Boards, of projects reporting to Executive Steering Committees (ESCs), require the MRR Package no later than four business days prior to the scheduled MER.

2.16.1.2.2.5.2  (04-25-2012)
Milestone Exit Reviews

  1. A Milestone Exit Review is a project review conducted at the end of a life cycle phase by the project's governance organization in compliance with IRS governance procedures. The purpose of the MER is to obtain Board approval for the project to continue on to the next phase, and if necessary, approve required funding.

  2. The MER does not begin until the project's governance organization receives a formal recommendation from the reviewing organization that the MRR was successfully completed. IRM 2.16.1.2.2.5.1 Note that the MER is not meant to be a detailed or extensive technical review. It is a governance board decision review based primarily on previously conducted reviews and recommendations

  3. IRM 2.16.1.3.5 Conducting Effective Reviews for further guidance on MERs.

  4. The following table shows the MERs usually conducted during the life cycle:

    MER Approves Exit of Phase: Approves Progression to Phase:
    MS 1 Project Initiation Domain Architecture
    MS 2 Domain Architecture Preliminary Design
    MS 3 Preliminary Design Detailed Design
    MS 4A Detailed Design System Development
    MS 4B System Development System Deployment
    MS 5 System Deployment Operations & Maintenance

    Note:

    Planned Maintenance Path projects do not require MERs for MS 5.

2.16.1.2.2.6  (09-04-2010)
Certifications

  1. Certifications occur at key points in the life cycle. They are technical evaluations resulting in a formal judgment as to whether the solution meets certain conditions. Certifications are included in the Governance Layer to illustrate and highlight the specific life cycle location of these important governance actions. Certifications are also discussed in the ELC Specialty Areas. IRM 2.16.1.2.6 The following certifications and related evaluations are included in the Governance Layer:

    • Security Assessment and Authorization

    • Privacy Package/Privacy Impact Assessment

2.16.1.2.2.6.1  (09-04-2010)
Security and Privacy Certifications

  1. Security and Privacy Certification and Accreditation ensures that a solution properly addresses security and privacy considerations and requirements and is authorized to operate with live data. The Department of the Treasury Directive, TD P 71-10, establishes Security Assessment and Authorization policy requiring a formal review and issuance of official declarations that all Sensitive But Unclassified (SBU) information systems or networks are approved to operate.

  2. Certification is a technical evaluation process. It results in a judgement stating if a particular information system design or implementation (e.g., computer system, application or network design, and implementation) meets a pre-specified set of security and contingency planning requirements. Security Control Assessment (SCA) of the system's security features determines if the required safeguards are in place and functioning as intended. To perform a more objective judgement, an independent reviewer (rather than a system developer) performs the certification.

  3. Accreditation is the official management authorization for an information system/application to process SBU data in an operational environment. Accreditation is based on a comprehensive security evaluation of the information system's security documentation, addressing all aspects of security and privacy, including:

    • Administrative/Management Security

    • Communications Security

    • Information Security

    • Computer Security

    • Personnel Security

    • Physical Security

    • Contingency (Disaster Recovery)

    • Privacy

    • Compliance with federal laws and regulations

  4. Accreditation is granted on the basis of recommendations made by the IRS's security office, and means that the IRS explicitly accepts the associated risks of system/application operation.

  5. Security and Privacy Certification and Accreditation occurs during the Certification Stage of the System Development Phase prior to MS 4B exit with the system installed at all target sites, and is required before the system is allowed to process live data.

2.16.1.2.3  (06-16-2008)
System Life Cycle Layer

  1. The System Life Cycle Layer is the core of the ELC Framework. All other layers are structured to support the System Life Cycle Layer. Process assets associated with this layer specify a standard progression and cycle of work performed over the life of a business change solution. This includes all work required to specify and develop and/or acquire the solution as well as work associated with operating and maintaining the completed solution until it is retired.

  2. This layer does not include work involved with managing programs or projects that produce the solution.

  3. This layer specifies what kind of work is performed but not how to do the work.

  4. The following features are associated with this layer:

    • Perspectives

    • Phases

    • Stages

    • ELC Paths

2.16.1.2.3.1  (06-16-2008)
Perspectives

  1. A perspective is a distinct dimension from which all life cycle work must be considered. Perspectives ensure that work performed and solutions produced reflect a holistic approach. The ELC Framework addresses the following perspectives:

    • Business Process

    • Organization

    • Location

    • Data

    • Application

    • Technology

  2. Business Process Perspective - The business process perspective addresses what the enterprise does, how it does it, in what sequence, what rules it follows, and what results it obtains. Changes in the business perspective usually drive changes in all other perspectives. This ensures that the solution supports and enables the business.

  3. Organization Perspective - The organization perspective deals with the people in the enterprise: their culture, their capabilities, their team structures, and their organizational units. It also addresses the support systems that make organizational change possible.

  4. Location Perspective - The location perspective addresses where the enterprise does business in terms of both location types and specific physical facilities at a specific location. Locations may include customer and vendor sites as well as internal enterprise sites.

  5. Data Perspective - The data perspective addresses the content, structure, relationships, and business data rules surrounding the information that the enterprise uses.

  6. Application Perspective - The application perspective deals with the capabilities, structure, and user interface of software provided for the business users. Applications may be specific to the business of the enterprise, such as an order entry application, or general in nature, such as a word-processing program or an electronic spreadsheet.

  7. Technology Perspective - The technology perspective addresses the hardware, system software, and communications components used to support the enterprise.

  8. Perspectives have important uses throughout the life cycle. For example, they are used in initial project planning to help focus tailoring and to assess risk, during Domain Architecture to identify all relevant solution components, and during solution design to ensure that all aspects of the solutions are addressed. Additional guidance on Perspectives is found in the subsection on Using Perspectives. IRM 2.16.1.3.2

2.16.1.2.3.2  (09-04-2010)
Phases

  1. Phases are aggregations of one or more stages (IRM 2.16.1.2.3.3). These aggregations result in broad segments of work that encompass activities of similar scope, nature, and detail, and that provide natural breakpoints in the life cycle. Projects are managed within the bounds of phases. Each phase begins with a kickoff meeting and concludes with a milestone. This means that as the project is developing the solution, it should be stated that the project is in a phase, not in a milestone. For example, the project is "in the Domain Architecture Phase" not "in Milestone 2" .

  2. The following table identifies the phases of the system life cycle:

    Phase General Nature of Work Stages Included Prior Milestone Concluding Milestone
    Vision & Strategy/ Enterprise Architecture High level direction setting for the enterprise. (This is the only phase for enterprise planning projects.)
    • Investment Decision Support

    • Enterprise Architecture

    N/A MS 0
    Project Initiation Startup of development projects.
    • Project Initiation

    MS 0 MS 1
    Domain Architecture Specification of the operating concept, requirements, and structure of the solution.
    • Business Solution Concept

    • Business Solution Architecture

    MS 1 MS 2
    Preliminary Design Preliminary design of all solution components.
    • Application Requirements

    • Logical Design

    MS 2 MS 3
    Detailed Design Detailed design of solution components to a state from which they can be developed.
    • Physical Design

    MS 3 MS 4A
    System Development Coding, integration, testing, and certification of solutions.
    • Development

    • Integration, Test and Evaluation

    • Certification

    MS 4A MS 4B
    System Deployment Expanding availability of the solution to all target users. (Usually the last phase for development projects.)
    • Deployment

    MS 4B MS 5
    Operations & Maintenance Ongoing management of operational systems.
    • Operations & Maintenance

    MS 5 System Retirement

2.16.1.2.3.3  (09-04-2010)
Stages

  1. Stages represent the fundamental segments of work that define the system life cycle. The purpose of each stage is to evolve the solution to a new state or level of development. Stages account for the transformation of a high-level concept at the beginning of the life cycle into an operational solution at the end of the life cycle. Because solutions are managed within the bounds of stages, formal reviews of the solution occur at the end of many stages.

  2. The main focus of each stage is to complete a particular objective and get it approved. As each objective is approved, it forms the basis for the project to move onto the next stage/phase in the process. The following lists the stage and the primary objectives of each stage.

    Stage Objective
    Investment Decision Support Stage To define the organizational needs to implement and sustain and get authorization for the funds needed in the next stage
    Enterprise Architecture Stage To identify IT concept of operations, identify costs, define needed resources, and prioritize the needs of approved projects
    Project Initiation Stage To authorize the project to begin, and to define the scope
    Business Solution Concept Stage To define the business requirements needed to satisfy the organizational needs identified in the project scope
    Business Solution Architecture Stage To identify the Enterprise Architectural requirements for the solution
    Application Requirements Stage To identify the IT requirements for the solution
    Logical Design Stage To define the logical design that will provide the best solution to fulfill the documented requirements
    Physical Design Stage To define the physical design that will provide the best solution for the approved logical design
    Development Stage To develop the best components for the documented physical design
    Integration, Test and Evaluation (IT&E) Stage To integrate and test the developed components and to determine whether they meet the documented requirements
    Certification Stage To certify that integrated system of components meet security and privacy standards
    Deployment Stage To deploy the certified system
    Operations and Maintenance Stage To operate and maintain the deployed system
  3. One or more related stages comprise a phase (IRM 2.16.1.2.3.2 for discussion on phases).

2.16.1.2.3.3.1  (09-04-2010)
Investment Decision Support Stage

  1. The Investment Decision Support Stage is the first of two stages in the Vision & Strategy/Enterprise Architecture Phase. It is an enterprise-level stage that is performed, when needed, to set the direction for business change by developing future vision for a broad organizational area or by significantly updating an existing vision. State of the solution at the end of the Investment Decision Support Stage includes:

    1. Scope of the enterprise defined in terms of business areas and/or systems to be addressed

    2. Enterprise mission developed or clarified to include a statement of general purpose for why the organization exists

    3. Future vision for the enterprise described from the perspective of business processes, organizations, locations, data, applications, and technology

    4. Directional principles for each perspective; and

    5. Future role of information technology in the business aligned with the new vision.

  2. As an enterprise-level stage, Investment Decision Support Stage addresses many business areas and/or systems, and is run as an enterprise planning project.

2.16.1.2.3.3.2  (08-03-2009)
Enterprise Architecture Stage

  1. The Enterprise Architecture Stage is the second of two stages in the Vision & Strategy/Enterprise Architecture Phase. It is an enterprise-level stage that is performed, when needed, to provide the guiding structure for achieving the enterprise vision. This may entail developing a new architecture or making major revisions to current architecture. State of the solution at the end of the Enterprise Architecture Stage includes:

    1. Target architecture specifying solution components and component relationships

    2. Enterprise-level requirements

    3. Intermediate architectures for incrementally achieving the target architecture and providing envisioned functionality over time

    4. Identification of solution development projects for implementing the architecture; and

    5. Enterprise standards to be observed by all projects.

  2. As an enterprise-level stage, EA addresses many business areas and/or systems, and is run as an enterprise planning project.

    Note:

    The target IRS EA has already been defined. Any additional efforts occurring within this stage are to update and revise this architecture.

2.16.1.2.3.3.3  (09-04-2010)
Project Initiation Stage

  1. The Project Initiation Stage is the only stage in the Project Initiation Phase. Its purpose is to complete planning and preparation for a new solution development project. State of the solution at the end of the Project Initiation Stage includes:

    1. Technical and business features of the EA allocated to the project

    2. Completion of initial project planning; and

    3. Assembly and orientation of the project team.

  2. The scope of the overall project and the authorization to proceed are defined in this stage through the Project Charter.

  3. The ELC Office has developed the Project Initiation (PI) Guide to assist PMs of non-major (new development) projects. This guide focuses on the processes to be followed and artifacts to be developed during the ELC Project Initiation Stage of a project. The guide provides detailed guidance for each artifact and activity involved as well as process owner contact information. It also addresses those phase 0 activities that should take place. The guide is posted on the ELC office website and can be accessed at the following link: (http://elc.nc.no.irs.gov/Library/Guides/ELC%20Project%20Initiation%20Guide%20V2%200_8-30-10.doc)

2.16.1.2.3.3.3.1  (08-03-2009)
Project Kickoff Meetings

  1. Project Kickoff Meetings are required for development projects.

  2. In addition to the project team, all stakeholders, process owners, executive owners, and Subject Matter Experts (SMEs) representing the various process areas (e.g., Configuration Management, Requirements and Demand Management (RADM), Information Resources Accessibility Program (IRAP), ELC) should be invited to the project kickoff meeting.

  3. Meeting minutes of the project kickoff meeting are required and provide verification that the meeting was conducted.

2.16.1.2.3.3.4  (06-16-2008)
Business Solution Concept Stage

  1. The Business Solution Concept Stage is the first of two stages in the Domain Architecture Phase. Its purpose is to describe the vision for the solution to be built. State of the solution at the end of the Business Solution Concept Stage includes:

    1. Current state in terms of all ELC perspectives

    2. Future direction for the business area specified

    3. Conceptual specification of the solution selected to implement future direction; and

    4. Development infrastructure sufficient to build the solution specified to a logical level.

  2. To clarify state of solution, documentation of the current state should only have enough detail to understand the current state, improve it, and plan for transition.

  3. Future direction for the business area includes:

    1. Specification of objectives and goals

    2. User needs to be satisfied

    3. Policies, principles, constraints, assumptions, and strategies

    4. Description of the desired end state

    5. Critical success factors; and

    6. Critical business issues.

  4. Conceptual specification of the solution selected to implement the future direction includes:

    1. Pictures, narratives, and scenarios describing a system concept inclusive of all applicable ELC perspectives (i.e., process, organization, location, data, application, and technology)

    2. Identification of potential current or commercially available assets that could be used as part of the solution

    3. Identification of impacts on the current environment; and

    4. Verification that the conceptual solution is consistent with and supports the high-level project solution concept.

2.16.1.2.3.3.5  (09-04-2010)
Business Solution Architecture Stage

  1. The Business Solution Architecture Stage is the second of two stages in the Domain Architecture Phase. Its purpose is to specify the business system requirements and structure for a complete solution that implements the system concept and enables subsequent development of detailed software requirements. State of the solution at the end of the Business Solution Architecture Stage includes:

    1. Specification of a complete set of business system requirements in conjunction with a set of detailed models that depict design of the future business system from all solution perspectives

    2. System architecture structured to show all subsystem levels

    3. Business scenarios illustrating how business will be conducted using all relevant aspects of the architecture

    4. Initial definition of external interfaces

    5. Selection of a commercial software package, if applicable

    6. Functionality packaged into time-phased releases

    7. Technical infrastructure for development specified to the physical level; and

    8. Initial performance engineering model.

  2. To further clarify state of solution at the end of BSA stage, a complete set of business system requirements includes:

    1. Capability requirements

    2. Business requirements including process, organization, location, and business performance requirements that included sustainability and resilience

    3. Regulatory, contractual, and other programmatic requirements

    4. Requirements for implementation of identified business rule sets

    5. Information system requirements including functional, data, interface, information system and performance requirements

    6. Operational requirements including information system management, and procedural requirements

    7. Appropriate security control requirements, derived from controls defined in NIST 800-53A (NIST 800-53A is a companion document to 800-53 and is to be used in conjunction with 800-53, and not as a stand alone document)

    8. Privacy requirements derived from the Federal Enterprise Architecture (FEA) Security and Privacy Profile (SPP) and documented in the Privacy section of the Business Reusable Requirements Management repository and detailed in the Enterprise Architecture.

    9. Technical infrastructure requirements

    10. Establishment of requirements traceability to customer needs and the enterprise architecture; and

    11. Plans completed for requirements validation and verification.

    12. Records management requirements derived from the Federal Enterprise Architecture (FEA) Profile and documented in Process 3.2 Asset Management of the IRS Enterprise Architecture.

  3. Designs of the future business system from all solution perspectives include:

    1. Logical level business process model. These are definitions for external events and results that delimit process flows; major processes that are modeled from external events to results, that are decomposed to the lowest level of interest and relevance from a business perspective, and that are sufficient to accurately estimate scope and complexity of associated rule sets; subsequent rule harvesting, and any subsequent business process model refinement; identification of decision points and business rule sets associated with these business processes; and identification of system management and support processes.

    2. Logical level organization model. This is a definition of roles, competencies, and work groups; organizational impact; specification of organizational interactions in terms of organization and decision-making structures; and staff planning.

    3. Logical level location model. This is an identification of locations by type and geographic area; impact by location; assignment of processes to the locations where they will be performed; logical location specifications (i.e., facility requirements) created for each location.

    4. Logical level technology model. This is an overview of technology types at all sites, including diagrams of site interconnections; detailed diagrams of individual pieces of technology and their interconnections at each site; detailed descriptions of each technology component, including requirements for capacity and reliability, service capabilities, and applicable standards; and detailed descriptions of each technical infrastructure interface.

    5. Conceptual level data model. This is a definition of business entities and entity subtypes; specification of relationships between data entities including cardinality (or equivalent level of definition for object-oriented or other approaches); and distribution of data entities to processing sites (i.e., location and type of infrastructure component).

    6. Conceptual level application model. This is an identification and definition of applications; definition and illustration of the relationship between applications; assignment of business processes to the applications that support them; and distribution of applications to processing sites (i.e., location and type of infrastructure component).

    7. Security model. This is a high level explanation of the NIST SP 800-53A (NIST 800-53A is a companion document to 800-53 and is to be used in conjunction with 800-53, and not as a stand alone document) Controls applied to the application and description of the integration of security controls within the domain architecture. Drawings that describe the relationship of control mechanisms to the business system architecture are recommended.

  4. A system architecture structured to show all subsystem levels includes:

    1. System structure decomposed into identified subsystems and sub-subsystems

    2. Business system requirements and business rules decomposed and unambiguously allocated to each defined level of the system structure

    3. Identification and description of solution components

    4. Interaction model that specifies interrelationships between components in all perspectives; and

    5. Components allocated to the lowest levels of the architecture.

  5. An initial performance engineering model includes:

    1. Identification of time-critical functions

    2. Identification of security-critical functions

    3. Performance requirements

    4. Workload estimates; and

    5. Measurement objectives.

  6. Initial definition of external interfaces includes:

    1. Interface overview

    2. Responsibilities for participating organizations

    3. Interface requirements; and

    4. Data structures transferred.

  7. Physical level technical infrastructure for development and unit test includes:

    1. Specific brands and model numbers to be acquired or used

    2. Actual features and capacities

    3. Physical layouts of all equipment, system software, and networks; and

    4. Preparation of a Government Equipment List (GEL) for development and for unit testing.

2.16.1.2.3.3.6  (09-04-2010)
Application Requirements Stage

  1. The Application Requirements Stage is the first of two stages in the Preliminary Design Phase, except in the Commercial-Off-the-Shelf (COTS) and JAD/RAD paths. Each project release (if more than one) will have a separate Application Requirements Stage. Its purpose is to develop a set of software requirements that enables the system architecture and to evolve the solution to a level allowing commencement of logical application (i.e., software) design. For clarity, completeness and specificity, application requirements may be fully represented as combinations of graphical and textual models linked to summary textual statements. State of the solution at the end of the Application Requirements Stage includes:

    1. Domain architecture verified and updated, if necessary, to reflect any changes required due to implementation of the previous release (if not the first project release)

    2. Logical design of business processes completed

    3. Major functions performed by the application defined to a level sufficient to account for transformation of all data features processed by the function

    4. Automated portions of each application function, business process, and business rule set identified

    5. Data designed to a logical level

    6. A database management system (DBMS) and Records Management Application (RMA) identified and, if applicable, selected

    7. Application interface definitions for both external and internal interfaces developed to the conceptual level

    8. Business rules harvested from all applicable sources

    9. Application (i.e., software) requirements developed

    10. Security, privacy, and records management concerns adequately addressed

    11. Performance analyzed and updated, as necessary to reflect the impact of software requirements and the current state of the logical design

    12. Technical infrastructure for development and testing on order; and

    13. Technical infrastructure for the Enterprise Integration and Test Environment (EITE) specified to the physical level (if necessary).

  2. To further clarify state of solution at the end of the AR stage, complete logical design of business processes includes:

    1. Refinement and optimization of major business processes

    2. Design of minor business processes to the logical level

    3. Design of system management and support processes to the logical level

    4. Identification of lowest-level decision points and rule sets; and

    5. Analysis and definition of software parameter settings (if using packaged software).

  3. Logical design of data includes:

    1. Data analyzed and designed to a level sufficient to support business processes

    2. Fully attributed and normalized data structure

    3. Development of a data conversion strategy

    4. Development of a data integration strategy; and

    5. Development of a data disposition strategy.

  4. Conceptual definition of application interface definitions includes:

    1. Context diagrams developed for each application

    2. Definition of external entities

    3. Definition of interface boundary conditions

    4. Data mapped from source system to target system; and

    5. Interface requirements developed to the software level.

  5. Harvested business rules include:

    1. Identification of individual rules associated with each business rule set; and

    2. Specification of business rules in conformance with defined terms and a fact model.

  6. Application software requirements include:

    1. Requirements statements reflecting the automated portions of the process design

    2. Requirements that are consistent with and supportive of the business system requirements

    3. User System Interface (USI) requirements and standards; and

    4. Establishment of traceability of software requirements to business system requirements and to features of the logical process and data design.

  7. Adequate consideration of security and privacy includes Security and Privacy packages updated (as necessary) to reflect the impact of software requirements and the current state of the logical design.

  8. Performance analysis includes:

    1. Updated business volumes, service levels, and process performance; and

    2. Updated predictive models and benchmarks.

  9. Physical level technical infrastructure for EITE includes:

    1. Specific brands and model numbers to be acquired or used

    2. Actual features and capacities

    3. Physical layouts of all equipment, system software, and networks; and

    4. Preparation of a Government Equipment List for EITE.

2.16.1.2.3.3.7  (09-04-2010)
Logical Design Stage

  1. The Logical Design Stage is the second of two stages in the Preliminary Design Phase, except in the COTS and JAD/RAD paths. Each project release (if more than one) will have a separate Logical Design Stage. Its purpose is to complete the solution design to a level sufficient to enable the software requirements and allow physical solution design to begin. State of the solution at the end of the Logical Design Stage includes:

    1. Applications designed to the logical level

    2. The user-system interface designed to the logical level

    3. Interfaces designed to the logical level

    4. Requirements managed to the logical level

    5. Business rules model completed, including detailed specification of all business rules

    6. Common services identified

    7. Software architecture issues addressed

    8. Logical design consistent with and in conformance with higher-level designs

    9. Technical infrastructure for EITE on order (if necessary)

    10. Security, privacy, and records management concerns adequately addressed and including contingency planning

    11. Performance analyzed and updated, as necessary, to reflect the impact of the current state of the logical design; and

    12. Logical design parceled into increments or sub-releases, if appropriate. IRM 2.16.1.3.3.1.2

  2. To further clarify state of solution at the end of the LD stage, logical design of applications includes:

    1. Applications decomposed to the next level of modular structure (e.g., application subsystems)

    2. Automated functionality assigned to each substructure

    3. Definition of flow between application substructures; and

    4. Development of preliminary application unit test plans.

  3. Logical USI design includes:

    1. An outline of User System Interface menu structure; and

    2. Optional verification of USI design with a simulation prototype.

  4. Logical interface design includes:

    1. Identification and design of interfaces from application subsystems to external systems and IT services; and

    2. Identification and design of interfaces between application subsystems and IT services.

  5. Requirements managed to the logical level include:

    1. Requirements allocated to appropriate components of the logical design, including all identified configuration items (CIs); and

    2. Updated requirements traceability to the features of logical design.

  6. Regarding completion of the business rules model: It is possible that application-level analysis in this stage will uncover further details associated with related business processes and rules, and provide further specificity to the business requirements to which they relate. However, discovery of new business requirements should be the exception.

  7. Identification of common services includes:

    1. IT services beyond those currently provided have been identified and defined

    2. Identification and definition of system-wide common services beyond those currently provided; and

    3. Identification and definition of application-level common services.

  8. Addressing software architecture issues includes development of strategies and approaches for areas such as:

    1. Proposed hardware and any constraints imposed

    2. Proposed COTS and any constraints imposed

    3. Operating system constraints

    4. Multi-processing approach

    5. Multi-programming approach

    6. Data transmission approach (messaging or data interface)

    7. Initialization

    8. Resource monitoring/action

    9. Recovery

    10. Error processing

    11. System records management; and

    12. Hours of operation (e.g., continuous operation or planned restarts).

  9. Logical design consistency and conformance entails:

    1. Logical design that is in compliance with the EA; and

    2. Logical design that is consistent with and supportive of conceptual design of the data, application, technical infrastructure, business process, organizational, and location aspects of the solution.

  10. Adequate consideration of security, privacy, and records management includes:

    1. Appropriate security. privacy, and records management mechanisms derived from pre-specified requirements and incorporated in the logical design

    2. Logical design mitigates risk in accordance with control guidance specified in NIST SP 800-53A (NIST 800-53A is a companion document to 800-53 and is to be used in conjunction with 800-53, and not as a stand alone document)

    3. Logical design identifies all interfaces to common security and audit services used by the application

    4. Logical design represents audit services in accordance with enterprise audit requirements

    5. Development of Interconnection Security Agreements (ISA), as necessary

    6. Development of Records Control Schedule (RCA), in accordance with Federal Records Act requirements (36 Code of Federal Regulations, 44 U.S. Code

    7. Development of a draft Information Technology Contingency Plan (ITCP), including disaster plans (IRM 10.8.60, Information Technology (IT) Disaster Recovery Policy and Guidelines)

    8. Remaining security risks are entered into the Item Tracking System (ITRAC) for tracking purposes; and

    9. Security and Privacy Packages updated, as necessary, to reflect changes from the logical application design.

  11. Performance analysis includes:

    1. Updated business volumes and service levels

    2. Updated predictive models; and

    3. Updated benchmarks.

2.16.1.2.3.3.8  (09-04-2010)
Physical Design Stage

  1. The Physical Design Stage is the only stage in the Detailed Design Phase, except in the COTS and JAD/RAD paths, and is performed for a functionality increment or for each component of a release. Its purpose is to complete solution design to its lowest level in a manner that implements the logical design and is sufficient to allow application programming and testing to begin. State of the solution at the end of the Physical Design Stage includes:

    1. Requirements managed to the physical level

    2. Relationships of physical-level applications, databases, and infrastructure relationships illustrated, and individual physical solution components appropriately designed to the most detailed level

    3. Data designed to the physical level

    4. Applications designed to the physical level

    5. Production infrastructure designed to the physical level

    6. External interfaces defined to the physical level and approved by all parties responsible for the interface

    7. Physical design consistent with and in conformance with higher-level designs

    8. Security, privacy, and records management concerns adequately addressed

    9. Preliminary documentation and training needs addressed

    10. Technical infrastructure for development and unit testing installed

    11. Performance analyzed and updated to obtain required performance

    12. Preparations made for database conversion and population

    13. Test planning updated to reflect physical design; and

    14. Physical design parceled into builds or drops, if appropriate (IRM 2.16.1.3.3.1.1 for additional information on builds and drops).

  2. To further clarify state of solution at the end of the PD stage, requirements managed to a physical level include:

    1. Requirements allocated to appropriate components of the physical design, including all identified configuration items; and

    2. Updated requirements traceability.

  3. Physical data design includes:

    1. Physical database, sequential file, and object specifications showing exact data structure, layout, data relationships; and

    2. Data dictionary.

  4. Physical application design includes:

    1. Definition of transactions and related processing

    2. Decomposition of application subsystems into programs and IT services

    3. Design of program flows and/or object structures

    4. Detailed specifications sufficient to support coding and testing of all batch and interactive programs, application-level common services, IT services, and objects for all business and system management and support applications

    5. Actual layouts for all USI windows; and

    6. Actual layouts for all reports.

  5. Physical production infrastructure design includes:

    1. Overview diagram of the physical infrastructure showing the location of physical components by site and the interconnection of sites

    2. Detailed physical infrastructure diagram for each site showing the location and interconnection of all infrastructure components

    3. Detailed physical specifications for each component of the infrastructure, as installed

    4. Preparation of a Production Government Equipment List (including extra units to be used as spares); and

    5. Long lead time production infrastructure on order or in development.

  6. Physical design consistency and conformance entails:

    1. Physical design that complies with the EA; and

    2. Physical design consistent with and supportive of logical design of the data, application, technical infrastructure, business process, organizational, and location aspects of the solution.

  7. Adequate consideration of security, privacy, and records management includes:

    1. Appropriate security, privacy, and records management mechanisms are derived from pre-specified requirements and are incorporated in the physical design

    2. Security mechanisms are implemented using common services when feasible and local security mechanisms conform to approved standards

    3. Physical design mitigates risk in accordance with control guidance specified in NIST SP 800-53A

    4. Interconnection Security Agreements have been negotiated and approved

    5. System audit plan maps audit functions to appropriate enterprise audit services

    6. Remaining security risks are entered into ITRAC for tracking purposes

    7. Security and Privacy Packages updated (as necessary) to reflect changes from the physical design.

  8. Preliminary documentation and training needs include:

    1. Identification of required documentation; and

    2. Definition of learning modules for use in user training.

  9. Installation of technical infrastructure for development and unit testing includes:

    1. Installation, integration, and testing of technical infrastructure for development, for unit testing, and for a proof-of-technical-concept prototype.

  10. Performance analysis includes:

    1. Development of proof-of-technical concept prototype to validate technical performance and design feasibility

    2. Updated business volumes and service levels

    3. Updated predictive models; and

    4. Updated benchmarks.

  11. Preparation for database conversion and population includes:

    1. Plan for data conversion developed

    2. Plan for conversion testing developed

    3. Conversion test materials prepared; and

    4. Conversion software developed and tested.

  12. Updated test planning includes:

    1. Application unit test plans and related materials updated to reflect physical design

    2. Integration test plans updated with integration strategies, test designs, and traceability of requirements to test sets and test cases

    3. Security test plans updated with strategies, test designs, and traceability of requirements to test sets and test cases; and

    4. Deployment tests updated to reflect management procedures, planned test composition, and requirements traceability verification.

2.16.1.2.3.3.9  (08-03-2009)
Development Stage

  1. The Development Stage is the first of three stages in the System Development Phase, except in the COTS and JAD/RAD paths. It is performed for each solution component or for a functionality increment. Its purpose is to implement the physical design through actual construction and/or acquisition of all solution components. State of the solution at the end of the Development Stage includes:

    1. Process perspective components of the solution developed

    2. Organization perspective components of the solution developed

    3. Location perspective components of the solution developed

    4. Data perspective components of the solution developed

    5. Application perspective components of the solution developed

    6. Each component of the solution unit tested

    7. Developed components consistent with design

    8. Documentation completed

    9. Planning for integration and system testing completed

    10. Technical infrastructure for EITE installed (if necessary); and

    11. All production technical infrastructure on order.

  2. To further clarify state of solution at the end of the Development stage, process perspective components include:

    1. Business processes documented in terms of pertinent directives and process descriptions

    2. Work flow established and/or configured (if applicable); and

    3. Manual procedures.

  3. Organization perspective components include:

    1. New roles and organization structures

    2. Organizational change interventions; and

    3. Training modules, including both instructor and student materials for user and operator training.

  4. Location perspective components include locations constructed or retrofitted, as required to support the solution. If facility construction or remodeling is required, it may be necessary to accelerate this activity to an earlier portion of the life cycle to accommodate long lead times.

  5. Data perspectives include:

    1. Installed and configured (test) databases, files, and queues; and

    2. Test data loaded in test databases.

  6. Application perspective components include:

    1. Installed and configured commercial software (if any)

    2. All programs of the applications developed and unit tested (if applicable); and

    3. Individual programs integrated into complete applications.

  7. Components consistent with design include:

    1. Developed components implement the approved physical design; and

    2. Components remain compliant with the EA.

  8. Documentation includes:

    1. Initial user documentation; and

    2. Initial operations documentation.

  9. Unit testing includes:

    1. Unit test materials, including test plans, test scripts and test data

    2. Successfully executed unit tests; and

    3. Test reports showing correction of all major defects.

2.16.1.2.3.3.10  (09-04-2010)
Integration, Test and Evaluation Stage

  1. The Integration, Test and Evaluation is the second of three stages in the System Development Phase, except in the COTS and JAD/RAD paths. Each project release (if more than one) will have a separate Integration, Test and Evaluation Stage. Its purpose is to combine all individually developed components into a fully tested release. State of the solution at the end of the Integration, Test and Evaluation Stage includes:

    1. All individually developed solution components integrated into a functionally complete project release

    2. Security, privacy, and records management concerns adequately addressed and including contingency planning

    3. All applicable system tests successfully completed

    4. System performance assessed and fine-tuned to optimize results; and

    5. System ready for production site installation.

  2. To further clarify state of solution at the end of Integration, Test, and Evaluation stage, a functionally complete release includes:

    1. All components developed by the project integrated into a project release

    2. Project release integrated with prior project releases, if necessary,

    3. Project release integrated with legacy systems, as needed,

    4. Project release integrated with systems external to the IRS, if necessary; and

    5. Project release integrated with releases of other projects to form a program release, if necessary.

  3. Adequate consideration of security, privacy, and records management includes:

    1. Security, privacy, and records management requirements have been met by appropriate control mechanisms in the solution

    2. System implements security via common services and approved mechanisms

    3. System security functions according to the latest security design

    4. Residual system risk is documented in the Security Risk Assessment; and

    5. Security and Privacy Packages are updated (as necessary) to reflect the development

    6. Contingency Planning to ensure resilience and sustainability commensurate with business objectives for recovery time and recovery point.

  4. Successful completion of system tests described in the System Test Plan includes some or all of the following tests along with test completion reports, as tailored for the project:

    1. System Integration Test (SIT)

    2. System Acceptability Test (SAT)

    3. Government Acceptance Test (GAT); and

    4. Final Integration Test (FIT).

  5. System ready for production site installation includes:

    1. Functional Configuration Audit (FCA) of the solution.

2.16.1.2.3.3.11  (09-04-2010)
Certification Stage

  1. The Certification Stage is the final stage in the System Development Phase. Each project release (if more than one) will have a separate Certification Stage. Its purpose is to obtain certification of the release to process live data in the target environment. State of the solution at the end of the Certification Stage includes:

    1. Solution installed at production sites; and

    2. Solution certified for use with live data.

  2. To further clarify state of solution state at the end of the Certification stage, a solution installed at production sites includes:

    1. Production hardware, software, and infrastructure installed at all target sites

    2. Databases installed, configured, and initialized

    3. Release integrated at target sites

    4. Transition gaps closed at target sites: and

    5. Completion of a Physical Configuration Audit (PCA) of the solution.

  3. A solution certified for use with live data includes:

    1. Successful completion of Security Control Assessment

    2. Security Assessment and Authorization completed and the Security Assessment Report (SAR) which accurately documents residual risk; and

    3. Security and privacy risks to the application have been resolved or documented with approved Plan of Actions and Milestones in the Security Assessment and Authorization.

2.16.1.2.3.3.12  (08-03-2008)
Deployment Stage

  1. The Deployment Stage is the only stage in the System Deployment Phase. It is performed for each project release and is the last stage of a project. Its purpose is to put the solution into use by all users for the conduct of business.

    Note:

    Deployment may occur to all targeted users at once or may occur in stages.

  2. State of the solution at the end of the Deployment Stage includes:

    1. The business system is integral to conduct IRS business; and

    2. The project or release has concluded.

  3. To further clarify state of solution at the end of the Deployment stage, (i.e., the system is the method to conduct IRS business):

    1. Users trained

    2. All transition gaps at user sites closed

    3. Operations and Maintenance Personnel trained (as needed)

    4. Operations and Maintenance transition gaps closed

    5. Production database initialized with live data

    6. Final performance evaluations completed

    7. Initial Operational Capability (IOC) obtained

    8. Operations and maintenance of the system commenced (if necessary) to support live operations

    9. All target users using the system

    10. Full Operational Capability (FOC) obtained; and

    11. Measurement system to support assessment of functional performance.

  4. Conclusion of the project or release includes:

    1. All pertinent project materials turned over to users and operations

    2. Old system deactivated (if existing and appropriate)

    3. Pertinent project materials archived

    4. Project personnel reassigned (if necessary)

    5. Contracts concluded (if any)

    6. Project space reallocated (if needed); and

    7. Team ready to take over Operations and Maintenance (O&M).

2.16.1.2.3.3.13  (06-16-2008)
Operations and Maintenance Stage

  1. The Operations and Maintenance Stage is the only stage in the Operations and Maintenance Phase, and is not a part of the ELC process. Its purpose is to operate and maintain completed solutions or solution releases as part of ongoing business. State of the solution during the Operations and Maintenance Stage includes:

    1. Systems and solutions operated to support daily business

    2. Call center, help desk, or similar assistance provided

    3. Fixes and modifications to operational solutions or releases made, as required

    4. Disaster recovery implemented (exercise and maintenance of contingency and disaster recovery plans with fully documented after action reports generating plans of actions and timetables to remedy and mitigate identified vulnerabilities to resiliency); and

    5. Solution retired at end of life.

  2. To further clarify state of solution at the end of Operations and Maintenance Stage, making fixes and modifications to operational solutions includes:

    1. Immediate changes to fix critical problems made via Emergency Maintenance (when needed); and

    2. Multiple non-critical changes accumulated and implemented as a new release of the solution via Planned Maintenance.

2.16.1.2.3.3.13.1  (09-04-2010)
ELC Termination/Retirement

  1. Termination/Retirement represents the end of the project or system's life cycle. It provides for the systematic termination of a project or system to ensure that vital information is preserved for potential future access and/or reactivation. The project or system, when placed in the Termination/Retirement status, has been declared surplus and/or obsolete and has been scheduled for termination, and/or retired. The emphasis of this status is to ensure that the project or system (e.g., equipment, parts, software, data, procedures, and documentation) is packaged and disposed of in accordance with appropriate regulations and requirements. ELC recommends that the following process owners listed in the ELC Termination/Retirement Checklist (on the ELC website) be contacted during the termination/retirement of projects and/or systems.

2.16.1.2.3.4  (08-03-2009)
ELC Paths

  1. The ELC recognizes there are multiple ways to approach the solution to achieve the states defined by the ELC stages. To provide flexibility, the ELC supports multiple approaches called paths. A path is represented by a version of the ELC Framework that supports a unique technical or system engineering approach to accomplish life cycle work. Paths are like alternate roads; each cross different terrain, but all lead to the same destination. Projects may select one or more appropriate paths that provide the best fit for developing the solution.

  2. The ELC Framework supports multiple paths that address various portions of the life cycle:

    1. Five paths address new solution projects, covering all phases, from Project Initiation through System Deployment; and

    2. One maintenance path addresses solution planned maintenance for solutions in the Operations and Maintenance Phase.

  3. The following subsections provide complete descriptions and explanations of all ELC Paths. However, for any user who wishes to access graphical representations of these paths, they are available via the ELC website:http://elc.nc.no.irs.gov/

2.16.1.2.3.4.1  (06-16-2008)
Waterfall Path

  1. A waterfall development approach is distinguished by sequential development of a solution with planned reviews and formal approvals required before continuation of work. These reviews occur within each of the six ELC phases and approvals must occur at the end of each phase in order to allow project work to continue in the subsequent phase. The following are characteristics of a waterfall development approach:

    • Sequential Development

    • Evolving Teams

    • Formal Documentation

    • Formal Approvals

  2. Sequential Development - A waterfall approach provides for serial solution design and development. Solution design evolves through a planned progression of successive levels from logical design to development. Solution components are then developed.

  3. Evolving Teams - As the project life cycle progresses, the nature of the project team evolves to match the nature of activities performed. Early in the life cycle, architects have a prominent role. As the life cycle progresses into design, various types of analyst and designer roles dominate the activities. After physical design, programmer or developer roles dominate, followed by the testers.

  4. Formal Documentation - At each stage of the solution, formal documentation is prepared and the solution may undergo formal review (i.e., in an LCSR). Detailed documentation provides evidence of completion during reviews and supports transition from one role to another as they evolve from phase to phase.

  5. Formal Approvals - After each review, the work completed is approved. Subsequent work does not continue until the work done in the prior phase(s) is approved.

  6. The IRS Solutions Engineering (SE) organization is responsible for planning, engineering, and assisting in the deployment and monitoring of an effective, efficient and secure IT infrastructure, in support of the business needs of the IRS. For additional pertinent information, contact IA&E or visit the IA&E website http://mits.web.irs.gov/ES/SI/IA%26E.

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

2.16.1.2.3.4.1.1  (08-03-2009)
Commercial-Off-the-Shelf (COTS) Solution Path

  1. The COTS path is designed to capitalize on the benefits of a pre-existing Commercially-produced solution. This may be a software package, a suite of integrated packages, or infrastructure components (e.g., servers, workstations). Activities in the COTS Path differ from the waterfall path. COTS is oriented toward selection and configuration of the pre-existing solution. The following are characteristics of a COTS development approach:

    • Solution Selection

    • Solution Configuration

    • Solution Lab

    • Identification of Solution Extensions

  2. Solution Selection - Solution selection involves a full acquisition process. This includes activities to identify and pre-screen software packages or infrastructure components, conduct a formal Request for Proposal (RFP) or Request for Solution (RFS) process, document selection results in a Product Evaluation and Selection (PES) Report, and completion of contracting and legal requirements for obtaining the selected solution.

  3. Solution Configuration - After acquisition, the solution is brought in-house and configured. Solution configuration involves choosing desired settings for each of the provided software options. Similar configuration may be needed for infrastructure components.

  4. Solution Lab - For large, integrated suites of software, configuration is often conducted in a solution lab in order to get the package to function as desired. The solution lab is a team of users, process analysts, and technical personnel who work together to determine how best to configure the package to support the business processes and related business rules and requirements. Since a software package developed for commercial use seldom conforms completely to IRS operations, implementation of a COTS package generally requires changing business processes and rules to conform to package-imposed restrictions or the adoption of package-provided processes or business rules. A lab environment may also be used to conduct proof-of-technical concept prototype for infrastructure components.

  5. Identification of Solution Extensions - The lab process identifies the need for extensions to standard solution functionality. Note that actual development of extensions may be handled as separate solution components and may follow separate paths. As a general practice, to protect warranties and ensure the ability to implement upgrades, invasive modification of COTS solutions should be avoided.

  6. Management and governance considerations for this path include:

    1. Application Requirements, Logical Design and Physical Design Stages are combined to reflect that work performed is oriented toward configuration and parameter setting for pre-existing software as opposed to software design. Therefore, separate LCSRs for preliminary and detailed design are not needed.

    2. Preliminary and Detailed Design Phases are combined into a single phase concluding with a combined milestone: MS3/4A. Because logical and physical design are not separated, separate phases and milestone exits are not needed.

    3. Modification of requirements for and placement of EA Compliance may be required since the software application and its database already exist and have an inherent logical and physical design. These designs are not changeable, however, it may be necessary to modify the EA to reflect the application and data structure of the COTS package.

    4. Documentation requirements may be modified to incorporate pre-existing vendor documentation.

  7. If customization is incorporated into the COTS path, it may be necessary to split the Preliminary Design Phase and the Detailed Design Phase to accommodate this custom development work.

  8. The IRS Solutions Engineering (SE) organization is responsible for planning, engineering, and assisting in the deployment and monitoring of an effective, efficient and secure IT infrastructure, in support of the business needs of the IRS. For additional pertinent information, contact IA&E or visit the IA&E website (http://mits.web.irs.gov/ES/SI/IA%26E/).

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

2.16.1.2.3.4.1.2  (08-03-2009)
Joint Application Design (JAD)/Rapid Application Development (RAD) Path

  1. The JAD/RAD path is an iterative prototype-based approach for developing small and standalone solutions or solution components. This path is recommended in instances when no clear set of business and technical requirements exists.

  2. The first component, JAD, is a design process that brings together, in one physical location representatives from the users, sponsors, analysts, designers and developers. The goal is to create an acceptable design in a format defined upfront. For the JAD session to be successful, a strong independent facilitator should be nominated.

  3. The second component, RAD, is an iterative development process at the end of which a prototype is built. The goal is to expose part of the solution to the end user as early in the development cycle as possible so that critical feedback can be given and reacted to.

  4. The JAD/RAD Path is not recommended when business and technical requirements are well defined. The following are the characteristics of a Joint Application Development:

    • High-level architectural guidance

    • Full-time stakeholder involvement

    • Facilitated sessions

    • Iterative architecture design

    • Time-boxing

  5. High-level Architectural Guidance - Only high-level representations are developed. These are meant to provide guidance and expectations so that the development team proceeds in the correct direction.

  6. Full-time Stakeholder Involvement - Key system stakeholders representing both business and technical functions fully participate in the architecture development effort to ensure that directional guidance is both accurate and sufficient. These stakeholders are empowered to make project and architectural decisions.

  7. Facilitated Sessions - Development of architecture occurs in one or more facilitated, interactive sessions with all stakeholders in the room to foster consensus and common understanding.

  8. Iterative Architecture Design - The concept, requirements, and architecture are developed simultaneously and in multiple iterations as opposed to sequentially.

  9. Time-Boxing - Architecture development is often time-boxed with an agreement to pass the architecture to the development team after a set period of time as opposed to leaving completion unbounded. This helps avoid analysis-paralysis as well as situations where there is not common agreement as to what should be done.

  10. Management and governance considerations for this phase include the combination of the Business Solution Concept, Business Solution Architecture, and Application Requirements stages, since concept, requirements, and architecture are highly simplified and directional in nature. JAD also capitalizes on the fact that these aspects of Domain Architecture are developed quickly in a workshop setting. Therefore, a single life cycle stage review at the end of the combined Business Solution Concept and Business Solution Architecture Stage is sufficient.

  11. The RAD component consists of a highly accelerated spiral development approach used to produce small, standalone solutions or solution components on existing infrastructure in a short time frame. Spiral development is a "try and see" approach that employs prototyping with successive rounds of requirements discovery, design, and development until the solution is complete. Prototyping produces a model version of the system that is quickly developed and successively modified. Rapid Application Development capitalizes on the small, primarily stand-alone nature of the solution and a high performance team working in a high productivity environment.

  12. The following are characteristics of the RAD approach:

    • High-Level Direction

    • Requirements Discovery

    • Prototyping

    • Spiral Development

    • High Performance Teams

    • Limited Documentation

    • Time-box Management

  13. High-Level Direction - With the JAD/RAD Path, activities in Domain Architecture are only meant to produce high-level guiding direction for the team. This is the JAD process. During JAD, a team representing all key stakeholders works together in facilitated sessions to produce a guiding concept and directional requirements. This provides bounds for the development effort, identifies objectives and constraints, and gets the team started in the right direction.

  14. Requirements Discovery - Sometimes users do not know what they want until they see it and their concept of what they want may evolve as the solution evolves. Requirements discovery is part of the spiral development and accommodates a "moving target" approach by allowing requirements to emerge and evolve as the solution is built iteratively.

  15. Prototyping - Prototyping is the process of developing an early version of a solution. Prototypes allow users to see the solution early and determine if it meets their needs. Prototypes also help technical personnel analyze solution feasibility. RAD primarily employs limited function prototypes. A limited function prototype provides an early subset of the actual solution. It is a persistent piece of code that evolves into the final solution. Limited function prototyping is the key enabler of spiral development and must be supported by advanced prototyping tools. These tools can assist in rapidly designing solutions and may automatically convert designs to code.

  16. Spiral Development - This is a "try and see" approach to design and development. A trial solution is quickly designed and developed based on known (but not necessarily finalized) requirements and direction. The result is provided to users for their review and feedback, which may result in changed or additional requirements - this is the requirements discovery process. Based on the refined set of requirements, the prototype design is updated. The process of rapid design, prototyping, solution analysis, and requirements discovery repeats, each time coming closer to the final solution - hence the term "spiral development. "

  17. High Performance Teams - High performance teams are static and consist of a combination of full time users and technical case workers, and they use a "case worker" approach to increase productivity. Case workers are individuals who fill many of the functions required during the life cycle. For example, instead of having multiple teams members, one case worker may help discover requirements, design the solution, develop the prototype, and test the results. This approach eliminates handoffs and reduces the need for formal documentation.

  18. Limited Documentation - Only minimal formal documentation is produced during the JAD/RAD process; there are several reasons. First, the accelerated nature of this path does not allow for creation of formal documentation during the design and development process. Further, the use of case workers reduces the need for formal documentation. And, due to the spiral development process, design is not complete until the solution is developed so there is little to document. Finally, because there are not interim stage reviews, there is no need to document for approval purposes. As-built documentation may be produced after the fact to support ongoing operations.

  19. Time-box Management - A time-box is a set period of time in which an activity is performed; it concludes at the deadline even if it is not completed. Time-box management achieves accelerated results, however, functionality may be sacrificed in the interest of time. When the time-box period is over for JAD, the decision to deploy the latest RAD solution is made based on whatever functionality is completed. (Any foregone functionality may be developed and deployed in a later release.)

  20. Management and governance considerations for this path include:

    1. Logical Design, Physical Design, and Development stages are combined into a single phase. This reflects the spiral development approach performed by a high performance team. Since there is no distinct separation of design, and development, only a single Life Cycle Stage Review is possible.

    2. Logical Design, Physical Design and Development stages are merged into one phase, Preliminary and Detailed Design/RAD, concluding with a combined milestone: MS3/4A. Note that logical and physical design stages are part of the same phase, and that the Development Stage is accelerated.

    3. Logical design must wait until physical design is complete. A single certification jointly addressing logical and physical design must suffice. In addition, this single certification cannot occur until development is complete.

    4. JAD/RAD may be performed under a fixed-price contract, but it is not possible to issue the contract only for development based on an approved physical design. Because all design and development work are concurrent, a fixed-price contract would need to cover all design and development work.

  21. The IRS Solutions Engineering (SE) organization is responsible for planning, engineering, and assisting in the deployment and monitoring of an effective, efficient and secure IT Infrastructure, in support of the business need of the IRS. For additional pertinent, contact IA&E or visit the IA&E website (http://mits.web.irs.gov/ES/SI/IA%26E/).

    Figure 2.16.1-3

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

2.16.1.2.3.4.1.3  (04-25-2012)
Iterative Path

  1. The Iterative Path is an adaptive development approach in which projects start with initial planning and end with deployment, with repeated cycles of requirement discovery, development, and testing in between. It is a more flexible and adaptable process than traditional sequential development approaches.

  2. The Iterative Path is very well suited to projects and environments that change rapidly, because each iteration presents new opportunities for the project to adapt to change. It is also well suited to projects with a high-level of user interaction, because at the end of Iterations, user will have an opportunity to test and try the developed functionality.

  3. Iterative development is fundamentally different from sequential development approaches, such as Waterfall. The following are characteristics of an Iterative development approach:

    • Iterative and incremental development

    • Streamlined development phases and milestone exits

    • Integrated teams

    • Sprint planning and creation of functionality backlog

    • Development sprints with “End of Sprint Checkpoint reviews”

    • Informal interim and “as-built” final documentation

    • Close involvement of business stakeholders and process owners

    • Requirement discovery

    • Prototyping

    • Rigorous tracking of performance metrics

    • Use of Iterative ready tools

    • Reliance on automated testing

  4. Sprint and incremental development - Development of a system through repeated cycles and in small increments, allowing the developer to take advantage of learning from the development and testing of earlier portions or versions of the system. The development process starts with a simple implementation of a subset of the software requirements and iteratively builds upon the evolving versions until the completion of the full system.

  5. Streamlined development phases and milestone exits – The Iterative path streamlines the number of development phases. The Project Initiation and Domain Architecture phases are combined into one Project Planning and Initiation phase. The Preliminary Design, Detailed Design, and System Development phases are combined into one Design, Coding, Testing, and Integration phase. Corresponding to the changes in development phases, an Iterative project will only have MS2, MS4B, and MS5 milestone exits.

  6. Integrated teams - Projects using the Iterative path will form integrated project teams, consisting of business analysts, solution engineers, developers, testers, and any other relevant functional or domain experts. Members of an integrated project team would join the team from the very start of the project and work closely and contribute throughout the entire project, which is different from the “evolving team” concept of Waterfall, where different members join or leave the team at different stages of the project.

  7. Sprint planning and creation of functionality backlog – In the early stages [or in the first phase] of an Iterative project, the project team would define high-level requirements and architecture to set project boundaries. Requirements become a “backlog” of functionality that will be tracked and addressed throughout the project. The team would also conduct detailed iteration planning for the next phase, including grouping and allocation of requirements into specific iterations. The team groups requirements based on requirement priority and criticality, project delivery schedule, and integration resource planning.

  8. Development Sprints with “End of Sprint Checkpoint Reviews” – Projects using the Iterative path will undertake development Sprints in the new Design, Coding, Testing, and Integration phase, between MS2 and MS4B. The development Sprints would typically last between 1-4 months and can run sequentially or in parallel. At the end of each sprint, there will be an “End of Sprint Checkpoint” that includes a functionality demonstration and feedback from stakeholders.

  9. Informal interim and “as-built” final documentation – Because portions of the requirements, architecture, design, and test cases are developed incrementally, projects using the Iterative path would generate less interim documentation and require fewer interim approvals, compared to the Waterfall process. However, all documentation would be updated to an “as-built” state and formally reviewed prior to the release of functionality into production (i.e., before a 4B exit).

  10. Close involvement of business stakeholders and process owners – Iterative projects rely on the close involvement of process owners and business stakeholder to continuously provide feedback, so that requirements can be clarified and the design can be improved continuously. Typically, business representatives and members of key process owner groups would be embedded (either full- or part-time) in the team for the duration of the project.

  11. Requirements discovery – Sometimes users do not know what they need until they see it, and their concept of what they need may evolve as the solution evolves. Requirements discovery is part of the Iterative development and accommodates a “moving target” approach by allowing requirements to emerge and evolve as the solution is built iteratively. High level requirements are designed before MS2, and then detailed requirements are defined and updated in each Iteration.

  12. Prototyping – Prototyping is the process of developing an early version of a solution and is closely associated with the requirements discovery aspect of the Iterative development. Prototypes allow users to see the solution early and determine if it meets their needs. Prototypes also help technical personnel analyze solution feasibility.

  13. Rigorous tracking of performance metrics – Due to the flexible nature of the Iterative Path, it is very important to have rigorous tracking of performance metrics, to ensure that the project is on track to be delivered on time and with good quality. Iterative metrics may include velocity (i.e., functionality backlog per iteration), defects per Iteration (i.e., defects found during testing done within the iteration), and burndown rate (i.e., functionality backlog completed vs. remaining in iteration). Traditional metrics such as man-days or recorded defects should also be tracked.

  14. Use of Iterative ready tools – Iterative projects require a different set of tools than traditional projects. These Iterative ready tools will help in areas such as project management, solution design, automated testing, configuration management, bug tracking, and other aspects of the project.

  15. Reliance on automated testing – Because testing is an integral part of each integration and code will be added incrementally, automated testing is very important. It is important to use automated testing to ensure that new code does not break functionality developed in previous iterations and that testing is conducted in an efficient manner.

  16. Management and governance considerations for this path include:

    1. End of Sprint Checkpoints will replace Customer Technical Reviews and Life Cycle Stage Reviews for milestone MS 4B exit. The project will still go through the formal MRR and MER for MS 2 and MS 4B.

    2. Functionality developed in sprints can go into production, only if the documentation for the functionality is reviewed and approved in a formal MS 4B exit.

    3. Formal EA compliance is postponed until development is complete since physical design and development are concurrent; however, EA compliance should be checked throughout sprints to avoid “surprises” near the MS 4B MRR.

  17. The IRS Solutions Engineering (SE) organization is responsible for planning, engineering, and assisting in the deployment and monitoring of an effective, efficient and secure IT infrastructure, in support of the business needs of the IRS. For additional pertinent information, contact IA&E or visit the IA&E website (http://mits.web.irs.gov/ES/SI/IA%26E/).

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

2.16.1.2.3.4.1.4  (08-03-2009)
Managed Services Path

  1. The Managed Services Path is designed to capitalize on the benefits of Managed Services provided by either an outside service (3rd party); internal intra-business processes; and/or existing infrastructure (operational) service provider. This could include software package(s), integrated software packages, shared-services and/or infrastructure components (assets) e.g., servers, web hosting, network centric, workstations, support services and/or web hosting. The first two phases of the Managed Services Path are identical to the phases of the Waterfall and COTS path. Subsequent to the Domain Architecture phase (MS 2), activities in the Managed Services Path will differ from the other ELC models (Waterfall and COTS). The differences occur because the managed service is: (a) proprietary; and/or, (b) not maintained by the IRS. The standard detailed reviews required in the development of new solutions or the purchase of a service is not required when the solution is being provided and maintained by a service provider. The Managed Services Path is oriented toward selection and acceptance of the managed services solution, i.e., outside source (3rd party), intra-business processes, and/or infrastructure (operational) service provider. The following are characteristics of a Managed Services approach:

    • Identification of Service Requirements

    • Service Selection

    • Service Deployment

  2. Identification of Service Requirements - The Domain Architecture phase identifies the requirements to provide the desired service functionality. These may include software package(s), integrated software packages, shared-services and/or infrastructure (operational) components (assets) e.g., servers, web hosting, network centric, workstations, and/or web hosting.

  3. Service Selection – Service selection involves a full acquisition process. This includes activities to identify and pre-screen services or infrastructure (operational) components, conduct a formal Request for Proposal (RFP) or Request for Service Solution (RFSS) process, document selection, and completion of contracting and legal requirements for obtaining the selected service solution.

  4. Service Deployment - After acquisition, the service solution is installed/configured. Service provisioning involves choosing desired settings for each of the service options and possible installation of equipment required to access the service. Configurations may be needed for infrastructure (operational) components (assets). Acceptance of the service is achieved when the vendor’s Service reaches the agreed upon levels for a period of time defined in the acquisition process.

  5. Management and governance considerations for this path include: (a) the Application Requirements Stage is combined with the Business Systems Requirements and the Business System Requirements Stages into the Domain Architecture Phase. In this manner, all of the requirements are defined and documented before the Service Selection Phase. (b) the Preliminary Design and Detailed Design Phases have been replaced with the Service Selection Phase. The Service Selection Phase encompasses the full acquisition process. This includes activities to identify and pre-screen services or infrastructure components, conduct a formal Request for Proposal (RFP) or Request for Solution (RFS) process, document selection, and complete contracting and legal requirements for obtaining the selected solution. Because logical and physical designs are not part of the Managed Services Path, the normal artifacts and reviews by Enterprise Architecture (EA) are not needed. (c) the System Development Phase is replaced by the Service Deployment Phase. In this phase, the method of accessing the external service is established. This may involve choosing desired settings for each of the service options and possible installation of equipment. Configurations may be needed for additional/special infrastructure components. Acceptance of the service is achieved when the vendor’s Service reaches the agreed upon service levels for a period of time defined in the acquisition process. Privacy Impact Assessment artifacts are not required since the vendor solution/service already exists and will not reside on IRS equipment.

  6. If customization is incorporated into the Managed Services path, it may be necessary to assess the need for EA, Cybersecurity, Privacy, and Records Management reviews.

  7. The System Deployment Phase is not required in the Managed Services Path because the activities normally associated with this artifact are a repeat of the activities performed in the Service Deployment Phase.

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

2.16.1.2.3.4.2  (08-03-2009)
Maintenance Path

  1. Solution maintenance involves making changes to an existing, operational solution or release of a system. The ELC Framework addresses this as the Planned Maintenance path.

2.16.1.2.3.4.2.1  (08-03-2009)
Planned Maintenance Path

  1. The Planned Maintenance Path is a path for planned system maintenance of a non-emergency nature. This path manages change in an organized manner, minimizes the disruption caused by frequent system changes, and increases the efficiency and effectiveness of the system change process.

  2. Service Management originates Planned Maintenance projects under the guidance of Operations and Maintenance Methodology or processes. Note that the maintenance project is managed under control of the Project Management component, while the existing system release is simultaneously managed under Service Management. When the project concludes, the new maintenance release transitions to the Operations and Maintenance Stage under control of Service Management. The following approaches characterize this path:

    • Concurrent maintenance actions

    • Technical development approach basis

    • Selected stages and phases

    • Modification of existing documentation

  3. Concurrent Maintenance Actions - Planned Maintenance typically addresses numerous system changes and simultaneously implements all of the changes as a new version (or release) of the system. This approach has advantages including improved management of the maintenance function, reduced amount of retraining, and potential improvement of coding efficiency and effectiveness. Under Planned Maintenance, changes may include combinations of different types of maintenance, including:

    • Corrective maintenance (e.g., fix errors, bugs, defects; replace equipment)

    • Adaptive maintenance (e.g., conform to changed environment -- for example, an operating system upgrade or change of database management system)

    • Preventive maintenance (prevent a problem before it occurs)

    • Perfective maintenance (e.g., upgrades or enhancements to system functionality and/or performance). Changes under Planned Maintenance include permanent repairs to replace temporary patches implemented by Emergency Maintenance.

  4. Technical Development Approach Basis - Planned Maintenance is not a single, unique path (as are the development paths). Work performed in the Planned Maintenance Path is similar to work performed in development paths. Due to this similarity, Planned Maintenance projects may follow the most appropriate technical development approach given the nature of the changes being made. For example, a project making changes to custom code might select the Waterfall Path as the primary basis for proceeding. Or a project that needs to reconfigure a software package may select the COTS path. Criteria for choosing an appropriate development approach for Planned Maintenance are the same as for selecting a development path. Because of these similarities, the Planned Maintenance path selected for a project should be referred to as "Waterfall-Based Planned Maintenance" or "COTS-Based Planned Maintenance" .

  5. Selected Stages and Phases - The Planned Maintenance Path is illustrated as a feedback loop that has multiple potential entry points into the life cycle. During the planning process, the appropriate entry point is determined based upon the earliest baseline that will be affected by the maintenance. For example, if the logical design portion of the Allocated Baseline will be affected, the Planned Maintenance project should begin in the Preliminary Design Phase. If the physical design portion of the Allocated Baseline will be affected, the Planned Maintenance project should begin in the Detailed Design Phase. If the Product Baseline will be altered by making changes directly to code but neither the logical or physical design are affected, the Planned Maintenance project may begin in the System Development Phase.

  6. Modification of Existing Documentation - Planned Maintenance modifies an existing system. Unlike a new development project that must create new documentation, Planned Maintenance projects may update documentation that already exists to reflect the maintenance changes. If existing documentation is inadequate or non-existent, new documentation will be created in the currently approved ELC format

  7. Management and governance considerations for this path include:

    1. Planned Maintenance is managed as a formal project even though a formal Project Initiation and Domain Architecture Phase are not required. Appropriate project planning must be performed at the outset regardless of where the project commences the life cycle.

    2. Reviews and other governance considerations are determined based on the nature of the maintenance performed and the technical development approach followed. As with new development, reviews and governance should be implemented in a manner that is workable given the size, cost, schedule, and risk of the project. For example, a Planned Maintenance project that must enter the life cycle during Preliminary Design may not need to have a separate MS 3 exit.

  8. The IRS Solutions Engineering (SE) organization is responsible for planning, engineering, and assisting in the deployment and monitoring of an effective, efficient and secure IT infrastructure, in support of the business needs of the IRS. For additional pertinent information, contact IA&E or visit the IA&E website (http://mits.web.irs.gov/ES/SI/IA%26E/).

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

2.16.1.2.3.5  (06-16-2008)
Operational Capability

  1. Achievement of operational capability marks the passage of a system from a solution in development to a solution used by the IRS to conduct business. Two levels of operational capability are recognized:

    1. Initial Operational Capability, and

    2. Full Operational Capability.

  2. Initial Operational Capability (IOC) - IOC occurs in the System Development Phase and marks the first live usage of the system by the first group of users to receive the system.

  3. Full Operational Capability (FOC) - FOC marks complete usage of the system by all targeted users. This occurs in Milestone 5 and signals the end of deployment activities.

  4. Prior to IOC, project activities are primarily development and test-related. Beginning with IOC, operations and maintenance activities must commence to support the first group of system users (even though the Operations and Maintenance Phase has not started). Between IOC and FOC, project activities include a mix of deployment and operations and maintenance activities. Subsequent to FOC, project activities are solely operations and maintenance. Finally, if the system is deployed to all target users simultaneously instead of incrementally, IOC and FOC may be concurrent.

2.16.1.2.4  (08-03-2009)
Solution Layer

  1. The solution is the embodiment and end result of all the changes made to the business and related technology. It comprises a set of artifacts that satisfy the goals of the business change initiative. The purpose of assets associated with the Solution Layer is to manage the solution as it is produced. This includes providing standards for consistent solution specification, formal review of solution content, testing the solution, and establishing configuration management baselines for control of change. This layer provides control over artifacts and may be produced by multiple internal and external developers using different methodologies.

  2. The following elements constitute this layer:

    • Artifacts

    • Data Item Descriptions

    • Customer Technical Reviews

    • Life Cycle Stage Reviews

    • Configuration Management Baselines

    • Tests

    • Configuration Management Audits

2.16.1.2.4.1  (04-25-2012)
Artifacts

  1. An artifact is the tangible result of an activity or task performed during the life cycle of a project. There are different categories of artifacts: solution artifacts and management artifacts.

  2. Solution artifacts are the embodiment of the solution as it is produced. They include design documents, application software, and documentation.

  3. Management artifacts result from the management of a program or project. They include plans, meeting minutes and task orders.

  4. Artifacts may be designated as work products or deliverables (deliverables are artifacts that are contractually required and must be formally accepted by the IRS).

  5. The ELC identifies artifacts that are expected to be produced at various points in the life cycle. Exhibit 2.16.1-3 for ELC artifact descriptions as well as where in the life cycle they are produced. As necessary, projects may produce artifacts that are not part of the ELC but are project related.

  6. Formats for artifacts may vary, except where specific formats are required such as by DIDs or other IRS templates or standards.

  7. The ELC also recognizes functionally equivalent artifacts . These are artifacts that may not match the standard ELC artifacts exactly but which adequately serve the same purpose. In certain situations, and with proper approvals, functionally equivalent artifacts may be substituted for standard ELC artifacts. An example would be maintenance or pre-existing artifacts that were created using an old methodology. Use of functionally equivalent artifacts must be justified in the Tailoring Plan.


More Internal Revenue Manual