2.16.1  ELC Guidance (Cont. 1)

2.16.1.2 
ELC Framework

2.16.1.2.4 
Solution Layer

2.16.1.2.4.1 
Artifacts

2.16.1.2.4.1.1  (04-25-2012)
Artifact Minor Revisions

  1. An errata sheet is an optional mechanism in the ELC process used to make minor revisions to a published document to correct spelling and/or typing mistakes or to make minor updates to an ELC approved artifact.

  2. The errata sheet can be used to notify those who originally approved/concurred an ELC artifact by signing it, that minor changes have been made to the document/artifact. Unless those who originally signed the document felt like the changes were significant, the changes described in the Errata sheet would be accepted and no new approval/concurrence signature would be required. If the signees feel that the changes are significant and notifies the originator of such in writing, the whole ELC artifact must be re-published and re-approved/concurred by all who originally approved/concurred on the artifact.

  3. This optional procedure has been implemented to reduce the paperwork involved in the approval process of ELC artifacts. A minor change includes any change which is:

    • non-technical

    • non-architectural

    • to correct spelling and/or typing mistakes.

  4. The Project Manager initially decides if a change is minor. The ultimate decision makers are the people who originally approved the ELC artifact (by signing it). If after reviewing the Errata sheet they feel that the changes are significant, they can withdraw their approval by notifying the Project Manager in writing of their decision. In this case, the Project Manager should meet with the PO to discuss concerns in order to get buy in for Errata usage, if discussions with the PO fail the PM must re-publish the whole artifact and obtain all new approvals.

  5. Errata sheets are associated with the artifacts they are altering through their files names. The Errata sheet filename should begin using the same title name as the final signed artifact; adding the suffix "-errata_sheet 1" . If more than one errata sheet is needed, the number increased for each additional errata sheet.

  6. The addition of the Errata sheet should be listed in the Revision History of the baseline (final) version of the document. The errata sheet will be distributed to those who originally approved/concurred to the ELC artifact. An Errata sheet must specify the:

    1. name of the project associated with the sheet;

    2. date upon which the sheet was issued;

    3. name of the artifact associated with the project;

    4. original date of the artifact;

    5. original version number of the artifact;

    6. configuration identification item (CII) number of the artifact;

    7. name of the person who prepared the sheet;

    8. names of those who originally signed the artifact;

    9. reason the artifact was changed; and

    10. the sections that were changed and what was changed in the section.

2.16.1.2.4.2  (08-03-2009)
Data Item Descriptions

  1. A Data Item Description (DID) outlines the standard content and format for major artifacts (e.g., reports, plans, documentation) produced during the life cycle. DIDs ensure consistency regardless of which organization produces an artifact or what methodology is used. All organizations producing business change and information systems solutions for the IRS are required to provide artifacts that conform to specified DIDs unless deviations are authorized and approved by a Task Order or Project Tailoring Plan. Artifacts produced using alternate formats must include a mapping of all sections in the alternate format back to the sections of the standard DID.

  2. DIDs supporting ELC can be found on the PAL (http://paig.ds.irsnet.gov).

    Note:

    Some artifacts may be described in terms of a standard IRS ELC template as opposed to a complete DID.

2.16.1.2.4.3  (09-04-2010)
Customer Technical Reviews

  1. A Customer Technical Review (CTR) is performed by IRS stakeholders to provide a vertical, in-depth review of selected technical and business artifacts produced by a project. CTRs facilitate approval of artifacts by:

    • Ensuring early and continuous stakeholder feedback

    • Identifying and resolving issues and actions required to gain approval

    • Providing a forum to resolve conflicting comments

  2. Not all artifacts require a CTR. Required CTRs are specified in the negotiated Task Order. Any requests for MITS services should be documented in a WR.

2.16.1.2.4.3.1  (09-04-2010)
CTR Activities

  1. Activities necessary to perform a successful CTR are organized into three groups: planning, preparation, and completion.

  2. Planning - Activities associated with planning include supporting the provider organization (the organization responsible for developing the artifact and conducting the CTR), confirming the reviewers, and distributing the product to be reviewed.

  3. Preparation - Activities associated with preparation include conducting a kickoff session to orient and prepare reviewers, actual review of the material, and comment compilation.

  4. Completion - Activities associated with completion include achieving consensus on the disposition of comments, recording all modifications to the artifact in a change history section of the artifact, and updating the version of the product.

  5. For information specific to planning for CTRs, IRM 2.16.1.3.5.7 Plan Early CTRs for Major Artifacts.

2.16.1.2.4.4  (09-04-2010)
Life Cycle Stage Reviews

  1. A Life Cycle Stage Review (LCSR) is performed by IRS stakeholders to verify the solution for its completeness, correctness, and consistency given its point in the life cycle. An LCSR deals with all artifacts that comprise the solution.

  2. The LCSR is the venue for reviewing security and privacy, as well as contingency planning, throughout the life cycle.

  3. In addition, each LCSR specifies a set of solution criteria for review. These criteria may not be eliminated unless they are not applicable to the work performed by the project.

  4. LCSRs usually occur at the conclusion of a phase prior to the MRR. However, all phases do not have a standard LCSR. A successful LCSR results in approving the solution; subsequently, the appropriate baseline may be established or updated. The following table lists standard LCSRs in the ELC:

    ELC Phase ELC Stage Life Cycle Stage Review
    Vision & Strategy/Enterprise Architecture Investment Decision Support None specified
    Enterprise Architecture None specified
    Project Initiation Project Initiation None specified
    Domain Architecture Business Solution Concept None specified
    Business Solution Architecture Business System Requirements and Architecture LCSR
    Preliminary Design Application Requirements None specified
    Logical Design Logical Design LCSR
    Detailed Design Physical Design Physical Design LCSR
    System Development Development None specified
    Integration, Test and Evaluation Development LCSR
    Certifications None specified
    System Deployment Deployment None specified
    Operations and Maintenance Operations and Maintenance None specified

  5. For detailed information on the LCSR, refer to the Life Cycle Stage Reviews Procedure maintained on the ELC website (http://elc.nc.no.irs.gov/).

2.16.1.2.4.4.1  (09-04-2010)
LCSR Activities

  1. Activities for Life Cycle Stage Review activities are grouped into three areas: planning, preparation, and completion.

  2. Planning - Activities associated with planning include creating a review schedule for LCSR activities, determining and inviting participants, and determining how to conduct the kickoff meeting.

  3. Preparation - Activities associated with preparation include conducting the kickoff meeting, evaluating and commenting on the LCSR review material, and responding to and consolidating comments.

  4. Completion - Activities associated with completion include conducting the review, assigning and developing solutions for issues, risks and action items, incorporating records management controls, and completing/reviewing the minutes of the LCSR.

2.16.1.2.4.5  (04-25-2012)
End of Sprint Checkpoint

  1. For projects undertaking the Iterative path, End of Sprint Checkpoints will replace the Customer Technical Reviews and Life Cycle Stage Reviews. An End of Sprint Checkpoint is an opportunity for the project team to summarize progress made, get feedback and approvals from stakeholders, and adjust planning for the subsequent iterations. The End of Sprint Checkpoint should include the following activities:

    • Demonstrate Functionality

    • Checkpoint Review

    • Provide Feedback

    • Plan for the next iteration

  2. Demonstrate functionality – Project team would demonstrate developed functionality at the end of each sprint, and celebrate the success of completing one block of functionality. Audience for the demonstration would include the integrated project team. Relevant process owner groups (e.g., RADM, EA, SA&E, Cybersecurity, IRAP, and Privacy) will also be invited.

  3. Checkpoint review – Project team would share relevant sprint summary documents (e.g., summary of all outstanding project issues and changes, select draft ELC artifacts or functional equivalents) for checkpoint reviews by select process owners. Project team would typically rotate through process owners to avoid constantly updating documents (i.e., meet with 1-2 process owners each iteration).

  4. Check escalation criteria - Determine if thresholds are reached; if so, the project manager escalates issues and risks to the Governance Board.

  5. Provide feedback – Stakeholders, based on the product demonstration and checkpoint review, would choose to either: provide documented approval of new functionality that would then be considered complete, or provide documented feedback (e.g., suggestion to add or change requirements, raise design issues), which the team would address in subsequent iterations.

  6. Plan for next sprint – Project team would incorporate input from stakeholders and lessons learned from the current Iteration (e.g., add, remove, or change functionality) into the overall project planning and technical design. The team would then create a more detailed plan to get ready for the next sprint. The team may escalate concerns (e.g., funding, risks, and architectural concerns) regarding the changes to the project governance, if applicable.

2.16.1.2.4.6  (06-16-2008)
Configuration Management Baselines

  1. A Configuration Management (CM) Baseline is an agreed-upon description of the attributes (i.e., functional and physical characteristics) of a product at a point in time, and serves as a basis for defining change. All baselined products need to be formally protected from unwarranted and uncontrolled change. Baselines serve as the basis for future development and can be changed only when authorized by the appropriate Configuration Control Board (CCB).

  2. There are three CM Baselines: Functional, Allocated, and Product.

  3. Functional Baseline: The Functional Baseline comprises the initial system-level requirements and system architecture describing a configuration system (CS) or configuration item (CI) functional, interoperability, and interface characteristics. The Functional Baseline is established during the Domain Architecture Phase.

  4. Allocated Baseline: The Allocated Baseline contains requirements that have been refined and/or derived from system-level requirements, and requirements allocated to specific software, hardware, or interfaces from a CS or higher-level CI, as well as additional design constraints. The Allocated Baseline is established during the Preliminary Design Phase.

  5. Product Baseline: The Product Baseline contains design and descriptive information for the as-built CI, including what would be necessary should the system need to be rebuilt, as well as the actual products themselves (i.e., software, hardware, etc.). The Product Baseline is established after the Physical Configuration Audit in the System Development Phase.

  6. CM baselines are independent of the life cycle development path.

2.16.1.2.4.7  (06-16-2008)
Tests

  1. Tests are one of the major tools of system evaluation. System evaluation demonstrates, with object evidence, that products provided to the customer organizations satisfy agreed upon requirements. There are three general categories of tests in the ELC:

    • Unit tests

    • System tests

    • Readiness tests

2.16.1.2.4.7.1  (06-16-2008)
Unit Tests

  1. Unit tests are tests of a program, module, object class, or other unit of the solution performed by the developer prior to integration to verify that the unit works correctly and satisfies its requirements. Unit tests are usually conducted in the development environment.

2.16.1.2.4.7.2  (06-16-2008)
System Tests

  1. System tests determine that the complete integrated solution works as intended. This includes:

    • System executes properly without errors

    • Expected results are obtained

    • Performance is acceptable

    • Requirements are satisfied

  2. System tests are performed during the Integration, Test and Evaluation Stage of the life cycle while the system resides in the test environment. The following subsections describe the specific tests that may be executed (depending on the tailoring for the project).

2.16.1.2.4.7.2.1  (06-16-2008)
System Acceptability Test

  1. The System Acceptability Test (SAT) verifies that the system satisfies software application requirements.

2.16.1.2.4.7.2.2  (06-16-2008)
System Integration Test

  1. The System Integration Test (SIT) verifies that the system is integrated properly and functions as required. The test is performed when the development organization delivers individual, unit tested system and software components to the test organization for integration and testing. The purpose of SIT is to accept, integrate and test system and software components received from development until the full system has been successfully built and all agreed upon customer requirements are tested. All types of requirements (application, security, disaster recovery/contingency planning, infrastructure, capacity, performance, accessibility, and usability) are addressed during SIT.

2.16.1.2.4.7.2.3  (06-16-2008)
Government Acceptance Test

  1. The Government Acceptance Test (GAT) allows the government to independently verify aspects of the functionality tested during system testing (e.g., startup, operations, and external interfaces). GAT includes running a set of regression tests that validate key requirements. It is recommended that GAT is performed when system testing is not performed by an independent government testing organization. GAT provides the government system owner with an independent assessment of the system to determine its fitness for implementation.

2.16.1.2.4.7.2.4  (06-16-2008)
Final Integration Test

  1. Final Integration Test (FIT) is the integrated end-to-end testing of mainline tax processing systems that support high-level business requirements of the IRS. FIT is conducted up to four times each year to verify that new releases of interrelated systems and hardware platforms can collectively support the IRS business functions allocated to them. It is conducted with a copy of production data and consists of activities designed to ensure the interoperability of systems at the release level with the current processing environment.

2.16.1.2.4.7.3  (06-16-2008)
Readiness Tests

  1. Readiness tests determine that the system is ready for deployment to users and for conducting live business. This includes ensuring that the system functions properly in the target production environment and meets security requirements. Readiness tests are performed during the Certification Stage of the life cycle while the system resides in the target production environment. The following subsections describe the tests that may be executed (depending on the tailoring for the project).

2.16.1.2.4.7.3.1  (09-04-2010)
Security Test and Evaluation

  1. Security Control Assessment (SCA) is conducted in the IRS production environment and consists of activities designed to ensure that the system's security safeguards are in place and functioning as intended. SCA is conducted through functional security testing and evaluation, regression testing (if required), as well as internal and external penetration testing (if necessary).

2.16.1.2.4.8  (08-03-2009)
Configuration Management Audits

  1. Configuration audits are performed by the government to ascertain that it is getting what is expected. These audits support a decision to accept or not accept the product. There are two types of configuration management audits:

    • Functional Configuration Audit

    • Physical Configuration Audit

2.16.1.2.4.8.1  (06-16-2008)
Functional Configuration Audit

  1. A Functional Configuration Audit (FCA) confirms that a product performs as it is supposed to perform. It includes examination of requirements traceability to ensure that requirements trace through test cases, examination of test results against test plans to verify that tests were successfully executed as planned, and examination of test results against requirements to verify that demonstrated functionality is consistent with required functionality. This involves witnessing SIT and SAT to ensure tests are successfully executed. FCA is performed during the Integration, Test, and Evaluation Stage of the life cycle.

2.16.1.2.4.8.2  (06-16-2008)
Physical Configuration Audit

  1. Physical Configuration Audit (PCA) confirms that the product and its documentation are consistent. It ensures that all deliverables are provided, the right versions are provided and under configuration control, all authorized changes have been made, no unauthorized changes have been made, and as-built documentation matches the product and is sufficient to maintain the system. PCA may be performed during the Integration, Test, and Evaluation Stage or the Certification Stage of the life cycle.

2.16.1.2.5  (06-16-2008)
Methodology Layer

  1. The Methodology Layer provides a placeholder for any selected methodology to interact with the rest of the Framework. A methodology is the standard set of practices, procedures, and templates used when executing the life cycle. It details how to do the work and specifies a unique set of artifacts to be produced. Methodologies used to produce business change and information systems solutions must ensure that solutions are adequately developed from all perspectives appropriate for the project. The methodology used may be an IRS methodology (e.g., Software Development Life Cycle - SDLC) or a contractor's methodology (e.g., CSC Catalyst or the IBM Rational Unified Process - RUP) as determined most appropriate to support the initiative. Note that the Methodology Layer does not specify the specific methodology to use, projects must make a specific choice of an appropriate methodology to follow. The following components constitute this layer:

    • Business Change Methodology

    • System Development Methodology

    • Operations and Maintenance Methodology

2.16.1.2.5.1  (06-16-2008)
Business Change Methodology

  1. Business Change Methodology specifies processes, procedures, techniques, templates, and standards for achieving sustainable modifications to an organization or business. This may include development of systems, but also addresses design and development of the business processes, organizations, and work locations that are part of the solution. It also may include organizational change initiatives. A Business Change Methodology is applicable over the life cycle of a project.

2.16.1.2.5.2  (06-16-2008)
System Development Methodology

  1. System Development Methodology specifies processes, procedures, techniques, templates, and standards for producing information systems. This includes design, development, and deployment of applications, data and infrastructure. A System Development Methodology is applicable over the life cycle of a project, but does not necessarily address ongoing operation of the solutions produced.

2.16.1.2.5.3  (06-16-2008)
Operation and Maintenance Methodology

  1. Operation and Maintenance Methodology specifies processes, procedures, techniques, templates, and standards for supporting a solution that is in production. This addresses the technical aspects rather than the business aspects. Operation refers to the actions required to run the system while Maintenance refers to actions required to fix and/or enhance the system. Operation and Maintenance Methodology may be a part of System Development Methodology or may stand alone.

2.16.1.2.6  (09-04-2010)
Specialty Areas Layer

  1. The Specialty Areas Layer specifies and identifies areas with special emphasis, importance, or requirements within the IRS environment. These areas may progress through life cycles on their own that are either parallel to or embedded within the greater system life cycle. The Specialty Areas Layer makes these subordinate life cycles visible and provides a single comprehensive source for information regarding how the topic is addressed by the ELC. Since many of these areas contain approaches or treatments that may be beyond what is covered by conventional methodologies, the Specialty Areas Layer provides guidance to contractors or others as to how to operate and comply with the ELC. The following features constitute this layer:

    • Enterprise Integration, Test, and Evaluation

    • Transition Management (TM)

    • Enterprise Architecture (EA)

    • Enterprise Data Management (EDM)

    • Requirements Engineering

    • Configuration Management (CM)

    • Security (and Disaster Recovery), Privacy, and Records Management

    • Strategy and Capital Planning (SCP)

    • 508 Accessibility and Mitigation

2.16.1.2.6.1  (09-04-2010)
Enterprise Integration, Test and Evaluation

  1. Enterprise Integration, Test and Evaluation includes processes for integrating multiple components of a solution and conducting various types and levels of testing on the solution. These tests (which are over and above standard unit testing of individual solution components) along with reviews conducted throughout the life cycle comprise the system evaluation process. They must be planned and conducted for all solutions unless specifically tailored out and omitted from the project Statement of Work. This includes testing of system integration, system acceptability, end-to-end performance, deployment readiness, and security testing and evaluation. Descriptions of these various tests as well as processes for conducting them are provided by the Test Support Section (TSS).

  2. Enterprise Integration, Test and Evaluation activities begin with high-level specification of how requirements are validated and verified, and conclude with security testing of the solution in the target environment. The feature is therefore represented in the Framework as commencing during the Business Solution Architecture Stage of the Domain Architecture Phase and spans the life cycle to the Operations and Maintenance Phase.

  3. The IRS Test Support Section (TSS) is responsible for the Enterprise Integration, Test and Evaluation specialty area. For applicable directives (i.e., MITS Test Directive), standards (e.g., MITS Test Standard), procedures, and additional pertinent information, contact the TSS website (http://adweb.irs.gov/DomainAreas/EnterpriseSystemsTesting/TestSupportandAutomationBranch/TestSupportSection/default.aspx ) or access the ELC website (http://elc.nc.no.irs.gov/).

2.16.1.2.6.2  (08-03-2009)
Transition Management

  1. Transition Management (TM) manages all activities to ensure the smooth transfer of new or enhanced business processes and systems from developing organizations to IRS receiving organizations. TM is an ongoing ELC process that uses a sound, repeatable approach to effectively integrate new or enhanced business capabilities into the IRS. Transition management differs from system readiness and deployment management.

    • System readiness prepares the system through activities that focus on development, testing, and integration

    • Deployment management delivers the new system to the receiving organization's technical environment

  2. Transition management prepares the receiving organization by considering both organizational and technological factors that enable it to assimilate the new system into its operations.

  3. The TM process helps receiving organizations consider the organizational requirements for supporting the future state; this includes evaluating four main readiness categories:

    • People

    • Process

    • Assets

    • Financial

  4. Readiness Assessment workshops are conducted to determine what an organization needs to be ready for system or process changes. The following is a sample of readiness assessment questions:

    • How are business processes and procedures impacted?

    • Will you have enough staff when the system is delivered?

    • Does your staff need additional skills?

    • What hardware, software, documentation, license agreements are needed/affected?

    • How will funding, budgets and finances be affected?

  5. The TM process uncovers gaps between the receiving organization's current environment and the future environment created by delivery of new or enhanced systems. The process results in a detailed plan for managing each gap to closure.

  6. The IRS Transition Management Office (TMO) is responsible for the Transition Management specialty area. For additional pertinent information, visit the TMO website ( http://ss.ds.irsnet.gov/sites/mvs/TMgmt/default.aspx) or access the PAL (http://paig.ds.irsnet.gov).

2.16.1.2.6.3  (08-03-2009)
Enterprise Architecture

  1. The Enterprise Architecture (EA) Specialty Area provides guidance on how to update and maintain the architecture, how to charter projects from architecture, and how to determine that the solution is consistent with the architecture. This ensures that the EA, once developed, remains a living artifact that is vital, robust, and pertinent. The EA feature commences with the Enterprise Architecture Stage (within the Vision & Strategy/Enterprise Architecture Phase), and spans the life cycle until MS 5 when implementation projects conclude.

  2. This specialty area describes the content and use of charters and architecture compliance. As governance mechanisms, these items are illustrated at appropriate points in the life cycle as part of the Governance Layer.

  3. The IRS Enterprise Architecture organization is responsible for the Enterprise Architecture specialty area. For applicable directives, standards, procedures, and additional pertinent information, contact EA, visit the EA website ( http://ss.ds.irsnet.gov/sites/ea/default.aspx) or access the ELC website (http://elc.nc.no.irs.gov/).

2.16.1.2.6.4  (08-03-2009)
Enterprise Data Management

  1. The Enterprise Data Management Specialty Area defines an enterprise-wide data environment that enables the business to organize, identify, share, reuse, correlate, and consume data. Process assets supporting Enterprise Data Management help to maximize the value of data to the IRS.

  2. Enterprise Data Management:

    • Helps ensure that projects adhere to the IRS Data Strategy, Data Architecture, Data Requirements, Interface Control, and Data Standards

    • Guides projects to develop ELC-compliant data artifacts that document the flow of an information system's data throughout its life cycle: from acquiring, conversion, migration, and storage to the time when it becomes obsolete and is deleted

    • Defines current and future IRS data strategies, data models, and data standards

    • Eliminates data duplication within the enterprise

    • Provides schemes for information sharing

    • Supports interoperability among information systems

    • Enhances Federal Enterprise Architecture (FEA) Data Architecture

  3. The Enterprise Data Management feature begins with the Vision & Strategy/Enterprise Architecture Phase, and spans the life cycle to the Operations and Maintenance Phase.

  4. The IRS Enterprise Data Management Office (EDMO) is responsible for the Data Management specialty areas. For applicable directives, standards, procedures, guides, and additional pertinent information, contact EDMO, visit the EDMO website ( http://mits.web.irs.gov/ES/SI/EDMO/) or access the ELC website (http://elc.nc.no.irs.gov/).

2.16.1.2.6.5  (09-04-2010)
Requirements Engineering

  1. Requirements Engineering is the process to capture, communicate, and manage the scope and description of the stakeholder needs, constraints and expectations. This description should cover all six ELC perspectives (process, organization, location, data, application, and technology) and includes requirement statements and modeling components (e.g., models, business rules, terms, and assumptions). These requirements are used by the testing group to verify that the developed solution addresses what was requested as well as providing developers the information to design the solution.

  2. The Requirements Engineering Specialty Area provides guidance on the development and management approach for implementing this process at IRS. This includes development techniques and tasks for eliciting, analyzing, documenting and reviewing requirements engineering components. It also outlines management guidance for implementing traceability between the captured requirements engineering components and other artifacts, establishing baselines, and controlling change. Finally, it provides further guidance on the content and organization of models and requirements statements.

  3. The Requirements Engineering Specialty Area begins with the Project Initiation Phase and spans the life cycle through the Operations and Maintenance Phase.

  4. The IRS Requirements and Demand Management Office (RADM) is responsible for the Requirements Engineering specialty area. For applicable directives, standards, procedures, and additional pertinent information, contact RADM, visit the RADM website ( http://mits.web.irs.gov/ES/DM/).

2.16.1.2.6.6  (08-03-2009)
Configuration Management

  1. The Configuration Management (CM) process establishes and maintains consistency of a product with its requirements and configuration information throughout the life cycle. CM is used to identify, control, and report the functional and physical characteristics of configuration items and their associated artifacts. The CM Specialty Area provides guidance on:

    • Configuration Identification activities

    • Configuration Control and Change Management activities

    • Configuration Item Structure Chart & Configuration Management Worksheet

    • Configuration Audits

  2. The CM Specialty Area begins with the Domain Architecture Phase (where the Functional Baseline is established) and spans the life cycle through the Operations and Maintenance Phase (which is covered by the Product Baseline).

  3. The Chief, Configuration Management Branch of Technology Release Management Division is responsible for the Configuration Management specialty area. For applicable directives, standards, procedures, and additional pertinent information, contact MITS CM, visit the MITS CM website ( http://mits.web.irs.gov/ConfigurationManagement/ ) or access the PAL (http://paig.ds.irsnet.gov).

2.16.1.2.6.7  (09-04-2010)
Security (and Disaster Recovery), Privacy and Records Management

  1. Security (and Disaster Recovery), Privacy, and Records Management are three separate but related disciplines represented in the ELC by a single specialty area. The Security and Privacy Specialty Area provides guidance on defining, planning, implementing, monitoring, and certifying security and privacy considerations in the business change solution. Projects are required to comply with the following related legislative requirements:

    • Federal Information Security Management Act (FISMA) of 2002, November 25, 2002

    • Public Law 104-106, Clinger-Cohen Act of 1996, formerly, Information Technology Management Reform Act (ITMRA), February 10, 1996

    • Privacy Act of 1974, As Amended. 5 United States Code (U. S. C.) 552a, Public Law 93-579, Washington, D.C., July 14, 1987

    • Computer Security Act of 1987 (Public Law [PL] 100-235)

    • Executive Order 13231, Critical Infrastructure Protection in the Information Age, October 16, 2001

    • Office of Management and Budget Circular A-130, Management of Federal Information Resources

    • 5 Code of Federal Regulations (CFR) §2635, Office of Government Ethics, Standards of Ethical Conduct for Employees of the Executive Branch

    • Various National Institute of Standards and Technology (NIST) Special Publications (e.g., 800-16, 800-26, 800-34, 800-37 Rev. 1, 800-50, 800-53) and Federal Information Processing Standards (FIPS) (e.g., FIPS 199)

    • Electronic Government Act (eGov Act) of 2002, H.R. 2458, Sec. 208, Privacy Provisions

    • Treasury Directive TDP 71-10

    • Treasury Directive TDP 85-01

    • Information Technology Security Policies: Internal Revenue Manual (IRM) 10.8.X Series

    • Treasury Directive 80-05

    • 44 U.S.C Chapter 33, Disposal of Records

    • 36 C.F.R Chapter XII, Subchapter B

  2. Security, privacy, and records management considerations must be addressed in all aspects of all initiatives. The Security, Privacy, and Records Management features commences with the Vision & Strategy/Enterprise Architecture Phase and spans the life cycle through the Operations and Maintenance Phase.

  3. This specialty area describes the content and use of security assessment and authorization, privacy, and records management. As a governance mechanism, the actual certifications are illustrated at the appropriate point in the life cycle as part of the Governance Layer.

2.16.1.2.6.7.1  (09-04-2010)
Privacy

  1. Privacy considerations, including privacy of an individual's information or information identifiable to an individual, and records accessibility and disposition capabilities must be addressed as an integral part of the design, development, and operation of all business change and information systems solutions throughout the life cycle. The privacy requirements are found in the Privacy section of the current Enterprise Architecture and Privacy Reusable Program Level Requirements as approved by the Security Services & Privacy Executive Steering Committee, and are validated through analysis and approval of the Privacy Impact Assessment (PIA). Records Management requirements are found in the Asset Management section of the Enterprise Architecture, and validated through the PIA process.

2.16.1.2.6.7.2  (04-25-2012)
Security

  1. The IRS Cybersecurity, Privacy, and Records organizations are responsible for their respective specialty areas. For applicable directives, standards, procedures, and additional pertinent information , contact Cybersecurity, visit the Cybersecurity website and for Privacy visit the Privacy, Governmental Liaison and Disclosure (PGLD) website, http://irweb.irs.gov/AboutIRS/bu/pipds/default.aspx. For additional Records Management information, contact the RIM staff or visit the RIM website, http://awss.web.irs.gov/refm/Logisticsmanagement/recordsmanagement/recordsmanagement.aspx, Security considerations must be addressed as an integral part of the design, development, and operation of all business change and information systems solutions throughout the life cycle. These considerations include:

    • Administration/Management Security

    • Communications Security

    • Contingency Planning

    • Information Security

    • Computer Security

    • Personnel Security

    • Physical Security

  2. Administration/Management Security - Administration/Management Security concerns the establishment, management, and composition of a security and privacy organization, and programs necessary to support operations while meeting security and privacy procedural requirements. This includes conducting functional security reviews, risk assessments, creating training programs, and maintaining assessment and authorization documentation.

  3. Communications Security - Communication security concerns the protection of all communications equipment and interfaces (wires, cables, lines, etc.) as well as data transmitted on or by them in support of data processing/operations.

  4. Contingency Planning - Contingency planning concerns assessment and authorization purposes. This is accomplished by completing a technical contingency planning document. This document provides sufficient information to operational sites to allow modification of their disaster recovery plan to support the recovery expectations for new or enhanced system/applications.

  5. Information Security - Information security concerns the protection of all sensitive information as defined in the Computer Security Act of 1987.

  6. Computer Security - Computer security is the protection of the entire information system (hardware, software, electronically stored and processed data). This security category focuses on the requirements for the actual hardware, software, and electronic data.

  7. Personnel Security - Personnel security concerns proper control of personnel access to and the use of computing resources (e.g., hardware, software, data). This includes all services that apply to employees of an organization (e.g., covers requirements for security training of personnel).

  8. Physical Security - Physical security concerns controlling access: protecting the physical building, computing area/room, computing resources, support areas, and all human resources. This includes all services provided by the physical environment (e.g., locked doors, combination locks, guards, and fences).

  9. The IRS Cybersecurity organization is responsible for the Security and Privacy specialty area. For applicable directives, standards, procedures, and additional pertinent information, contact Cybersecurity, visit the Cybersecurity website ( http://mits.web.irs.gov/Cybersecurity/).

2.16.1.2.6.8  (09-04-2010)
Strategy and Capital Planning

  1. The Strategy and Capital Planning Specialty Area outlines methods used by the IRS to propose, evaluate, compare, prioritize, select, and monitor capital investments, including programs and projects for business change and information systems. It also includes specification of OMB vehicles for documenting the investment portfolio (ex. E53 and/or E300).

  2. The Capital Planning and Investment Control feature within Strategy and Capital Planning begins within the Vision & Strategy/Enterprise Architecture Phase (Milestone 0) and spans the remainder of the life cycle. Investments identified during the Vision & Strategy/Enterprise Architecture Phase must prepare OMB documents for approval. The OMB documents are regularly updated and resubmitted throughout the investments' life cycle. Operational solutions must also be tracked with the OMB documents to ascertain that planned quantitative and qualitative benefits are realized. For quantitative benefits, appropriate performance goals and measures must be identified and maintained.

  3. Note that compliance with OMB requirements as a governance mechanism is illustrated at appropriate points in the life cycle as part of the Governance Layer.

  4. The IRS Strategy and Capital Planning organization is responsible for the Strategy and Capital Planning specialty area. For applicable directives, standards, procedures, and additional pertinent information, contact Strategy and Capital Planning or visit the Strategy and Capital Planning website ( http://ss.ds.irsnet.gov/sites/mvs/default.aspx).

2.16.1.2.6.9  (08-03-2009)
508 Accessibility and Mitigation

  1. The Section 508 Accessibility and Mitigation Specialty Area provides the procedures and other guidance that enable projects to meet Section 508 requirements of the Rehabilitation Act of 1973. The legal requirements of Section 508 are that all information technology developed, maintained, used or procured by the Federal Government be accessible to persons with disabilities.

  2. Some of the activities under this specialty area are:

    • Delivering technical guidance and support on Section 508 accessibility principles

    • Providing oversight to ensure conformance with Section 508 for all IT requisitions, capital planning documents, and ELC Milestones

    • Instituting procedures and creating templates that ensure 508 issues are addressed during the earliest stages of project development and/or acquisition

  3. The Information Resources Accessibility Program (IRAP) office is responsible for the 508 Accessibility and Mitigation Specialty Area. For procedures, templates, and additional pertinent information, contact IRAP, visit the IRAP website (http://irap.web.irs.gov/elc.asp ) or access the ELC website (http://elc.nc.no.irs.gov/).

2.16.1.3  (06-16-2008)
Guidelines for Effective Use of the ELC

  1. This subsection provides guidelines for using the ELC in a practical and effective manner. These guidelines address the foundations for successful business change using perspectives, tailoring, and conducting reviews.

2.16.1.3.1  (06-16-2008)
Foundations for Successful Business Change

  1. The ELC is used to accomplish business change. At a high level, the objective of all business change initiatives may be said to consist of successfully implementing the most appropriate business solution with high quality, at an acceptable cost, within an acceptable time frame, and with an acceptable level of risk. The following concepts provide the foundation for successful business change and should be incorporated in the project technical and management approaches:

    • Develop solutions from the business vision

    • Deliver early benefits through an incremental approach

    • Guide solution development with an architectural blueprint

    • Provide a solution that meets customer and user needs at delivery

    • Consider the solution from all perspectives

    • Consider business processes before other perspectives

    • Recognize and maintain the integrity of subordinate cycles

    • Incorporate organizational learning into the life cycle

    • Gain commitment through participation

    • Enable business change through organizational transition

2.16.1.3.1.1  (06-16-2008)
Develop Solutions from the Business Vision

  1. Business solutions may be developed from two opposing points of view: improvement and redesign. Solutions developed from an improvement point of view place high emphasis on the current state as a base and aim at making small, incremental adjustments. Solutions developed from a redesign point of view aim at fundamental change with high emphasis placed on achieving a defined future state. While both approaches are accommodated within the ELC, the redesign approach is often most useful in addressing significant business change.

  2. The ELC helps solution providers to achieve the desired future state, which includes operational resiliency. When using the ELC, all architectural, design, implementation, and management decisions are made with the desired future state in mind. Although this does not mean that the current or as-is state should be ignored, it does mean that the current state documentation should be limited in detail and analyzed only to the extent necessary (i.e., to avoid perpetuation of current problems, to determine performance gaps, and to plan transition). The objective should be to focus on achieving the future vision.

2.16.1.3.1.2  (06-16-2008)
Deliver Early Benefits through Incremental Approach

  1. Many projects take the big bang approach by developing and implementing the entire solution at the same time. For small projects, this approach may be acceptable. However, for large, complex projects, this approach may cause problems and result in increasing the risk level. This may happen for several reasons. First, it is difficult to maintain interest, commitment, morale, and momentum for the length of time large projects need to deliver results. Second, because of the length of time before testing begins, problems and risks are not exposed until they have become difficult and costly to fix. Finally, project costs accumulate without offsetting benefits. A better approach is to focus on delivering quality results that produce smaller benefits early and incrementally throughout the life of the project.

  2. To support an incremental delivery approach, use the ELC to divide big, high-risk projects into smaller, more manageable pieces, each of which can deliver business benefits relatively quickly. This approach creates module of development with short delivery times and provides opportunities for continuous improvement. The resulting iterative operating style allows users to gain the experience necessary to refine requirements and evolve the ultimate solution. With each success, the project gains credibility, momentum builds, and organizational learning increases. It is possible that solutions will become self-funding as the business benefits of each success offset development costs. However, managers must take advantage of these features. Examples of devices that may be employed include:

    1. Dividing the project into a series of releases in which each delivers usable functionality over time with measurable performance improvements derived from the OMB vehicle's performance goals, measures, and targets

    2. Dividing the solution into components that may be developed independently; and

    3. Employing EA (which provides unifying structure for many business areas and/or systems across the entire enterprise) and domain architecture (which provides unifying structure to an individual business area and/or system) to coordinate the overall solution.

2.16.1.3.1.3  (06-16-2008)
Guide Solution Development with Architecture Blueprint

  1. Breaking a solution into component pieces is an effective way to manage a large, complex effort and to obtain early business benefit. This approach requires a high degree of coordination and integration of the solution components. Use architecture to provide the coordination and integration, and to provide a blueprint for how the solution components fit together and interact. Architecture identifies solution components, describes the interaction between components, specifies standards to adhere to, and lays out a solution migration path. This provides several benefits, including:

    1. Ability for the organization to make a substantial and definitive commitment to a business and technical direction before all the facts and requirements are known

    2. Ability to spread development of the overall solution over time, knowing that each piece will fit into the grand scheme and each effort advances the solution in the desired direction

    3. Ability for multiple, independent projects and/or teams performing portions of the required work with assurance that all will properly converge and fit together as planned; and

    4. Ability to swap out or update components with newer versions or updated designs yet maintain the integrity of the overall solution.

  2. Two levels of architecture are employed:

    • EA (provides unifying structure for many business areas and/or systems across an entire enterprise)

    • Domain architecture (provides unifying structure for an individual business area and/or system)

  3. To effectively use architecture in the ELC, ensure that:

    1. The architecture satisfies the vision and provides a clear path from current to future state

    2. Portions of the architecture are parceled out unambiguously to individual efforts

    3. Designs produced are checked to ensure consistency with the architecture

    4. Architecture is maintained and modified when necessary, to reflect design and implementation realities; and

    5. Architecture is centrally managed at a level above individual projects or efforts.

2.16.1.3.1.4  (06-16-2008)
Provide Solutions that Meet Customer and User Needs

  1. Solutions that do not meet the needs of customers and users are costly in terms of cost, time, and effort, and in terms of the resources required to fix or develop a more appropriate solution. There are two aspects to having the right solution at the right time. First, the solution must meet the customer/user needs and requirements. Second, the solution must not only meet the needs when a project begins, but also the needs anticipated to exist at the time the solution is implemented, otherwise the solution will be obsolete by the time it is completed.

  2. To meet the customer/user needs and requirements at delivery ensure that:

    1. Requirements are specified accurately up front

    2. Requirements are relatively stable; and

    3. Elapsed time between requirements specification and solution delivery is relatively short.

  3. However, business change solutions may be large and complex with extended delivery periods. The business environment frequently changes and users' understanding of what they need evolves with design, development, and use of the solution. Appropriate measures should be taken to deal with this type of situation. These may include:

    1. Allowing controlled change when approved by the CCB (when it makes sense for solution validity and project Business Case) if requirements are specified and approved up front

    2. Ensuring that requirements are forward-looking when specified, verified, and validated

    3. Employing methods (e.g., prototyping) to reduce the time between requirements specification and solution implementation, and that support evolution of user understanding; and

    4. Avoiding premature, unnecessary, or inappropriate specification of design detail (e.g., by delaying design decisions as long as possible) if requirements are anticipated to be fluid.

2.16.1.3.1.5  (06-16-2008)
Consider the Solution from All Perspectives

  1. Business change problems often involve a variety of business and technical dimensions. It is only by addressing all dimensions of the problem that a successful solution can be implemented. When addressing a business change problem, a comprehensive view should be taken. It should be worked simultaneously from all ELC perspectives, including the business processes performed, the people performing them, the locations where the work is done, the data and information processed, and the enabling technology and software applications. This multifaceted focus should begin with initial project planning and extend through the development processes.

2.16.1.3.1.6  (06-16-2008)
Consider Business Processes Before Other Perspectives

  1. In the past, information technology projects have automated existing processes or applied leading edge technology for its own sake. To prevent this, the Clinger-Cohen Act and OMB's Raines Rules require that business processes are documented, benchmarked against best practices, and redesigned (where appropriate) before any significant IT investments are made.

  2. The ELC illustrates early attention to business processes in the descriptions of life cycle stages and LCSRs. But, in practice, the order in which various design activities take place is dictated by the project schedule. Therefore, whenever the intended change affects the business, managers must insist and verify that business processes are redesigned prior to designing the solution from other perspectives.

  3. Redesign of business processes should focus on end-to-end processes; that is, processes starting with an external action and ending with an external result. If focus is on sub-processes that occur within a single organization, the result could optimize the sub-processes and result in sub-optimization of the overall process. The end-to-end process view may be difficult to address and is often ignored when a business change is spread over multiple teams and/or multiple projects. Managers must ensure the entire process is addressed, either at the program level, or through joint effort of multiple teams or projects.

2.16.1.3.1.7  (09-04-2010)
Recognize and Maintain Integrity of Subordinate Cycles

  1. The system life cycle illustrated in the ELC Framework describes a progression of work from vision and strategy through implementation and operation of the solution. The nature of this work is described by the ELC stages. However, within this life cycle, there are multiple other life cycles. These embedded cycles include the progression of work related to specific topics (what the ELC refers to as "specialty areas" ), and include:

    • Enterprise Integration, Test and Evaluation

    • Transition Management

    • Enterprise Architecture

    • Enterprise Data Management

    • Requirements Engineering

    • Configuration Management

    • Security (and Disaster Recovery), Privacy, and Records Management

    • Strategy and Capital Planning

    • 508 Accessibility and Mitigation

    Each of these areas evolves on its own throughout the system life cycle and has specific influences and activities included within the system life cycle progression of work.

  2. Management should ensure that each specialty area and its related cycle are continually addressed as an integral part of the overall solution. Appropriate subject matter experts should address the detail of each specialty area cycle to ensure that internal integrity and consistency are maintained.

2.16.1.3.1.8  (06-16-2008)
Incorporate Organizational Learning into the Life Cycle

  1. Performance targets, quality improvements, and development efficiencies are attained most readily when varying expertise and perspectives are leveraged throughout the change process. The ELC establishes mechanisms that provide for knowledge-sharing and organizational learning. It is up to managers to encourage use of these mechanisms and ensure that the desired learning occurs. Examples are documenting lessons learned, reusing previous work, and learning as you go.

  2. Lessons Learned - The ELC includes directives and procedures related to the capture of lessons learned and specifies the requirement for a lessons learned report at the end of each life cycle phase. However, although capturing these is good practice, they must be used to be of value. Managers should take steps to ensure the review of lessons learned by every project team at the start of every project phase.

  3. Reuse - Organizational learning may also be in the form of actual system components made available for use on a widespread basis. Such components may be in the form of reusable objects, subroutines, common services, etc. These may be defined at a program level for use across projects or within a project for use across subsystems or programs. Reusable components can only be leveraged if their existence is known and they are readily accessible. Managers should ensure that projects and programs establish mechanisms for maintaining libraries of reusable system components.

  4. Learn As You Go - Learning is an iterative process; it is evolutionary and occurs over time. With respect to business change, designing, developing, and initially using the solution will cause the original requirements and expectations to change. A successful change process must support these inherent characteristics of learning. When something new is successfully introduced, it should be added to the process to teach others. The ELC provides for this type of ongoing learning and provides iterative development approaches and activities such as prototyping to realize it. Managers should foster use of these techniques when appropriate. In addition, even when approaches which embody early and rigorous control of requirements and design are used (e.g., waterfall), managers should ensure that an adequate degree of control is exercised without stifling the need for or ability to enact legitimate change.

2.16.1.3.1.9  (06-16-2008)
Gain Commitment Through Participation

  1. Involving all stakeholders (users and developers) in the solution process throughout the life cycle and obtaining their agreement will increase the likelihood of implementing business change successfully. The ELC provides opportunities for active stakeholder participation. Examples are:

    • Customer and user workshops to develop business vision and design of business processes

    • Active participation of IRS stakeholders on project teams

    • Prototyping in which user participation is integral

    • Formal stakeholder reviews (e.g., CTRs)

    • Considering transition throughout the life cycle

  2. To obtain the advantages of stakeholder participation, managers must:

    • Identify the appropriate stakeholders

    • Apprise stakeholders of nature, timing, and degree of desired participation

    • Ensure commitments are fulfilled through active and consistent participation by the right personnel

2.16.1.3.1.10  (06-16-2008)
Enable Business Change through Organizational Transition

  1. Because insufficient attention to organizational change is one of the top reasons for project failure, managers must ensure that organizational change and transition are addressed as an integral part of project activities throughout the life cycle. This requires a two part approach: organizational perspective and transition management.

  2. Use Organization Perspective to design and develop organizational aspects as an integral part of the solution. This includes leadership, culture, commitment, capabilities, structure, communication, decision-making and performance.

  3. Use Transition Management from the earliest stages of the life cycle to ensure that all stakeholders and facilities are prepared to receive, operate, and work with the solution, and that the necessary behavior changes have occurred.

2.16.1.3.2  (06-16-2008)
Using Perspectives

  1. Perspectives are an integral part of how the ELC addresses business change throughout the life cycle. This subsection explains how perspectives are used to assist in planning, architecture and design.

2.16.1.3.2.1  (06-16-2008)
Using Perspectives During Planning

  1. When planning a business change project, evaluate the situation to determine the required degree of change from the view of each life cycle perspective. Use the following table to make these judgments:

    Solution Perspectives
    Business Process Organization Location Data Applications Technology
    No change = Same processes No change = Same organization No change = Same locations No change = Same data No change = Same applications No change = Same technology
    Minor change = Support for existing processes Minor change = Different procedures Minor change = Changed use of existing facilities Minor change = Same entities, new attributes Minor change = Minor changes to existing applications Minor change = Same products, additional uses
    Moderate change = Revised activities in current processes Moderate change = Different job content Moderate change = New facilities Moderate change = New entities Moderate change = Enhancements to existing applications Moderate change = Same products, increased capacity, workload
    Major change = Revised processes (process improvement) Major change = Different jobs and organizational structure Major change = Relocation of work Major change = New data structure Major change = New application Major change = New products
    Radical change = New processes (process redesign) Radical change = Different culture Radical change = Relocation of workers Radical change = New data types (e.g., images, voice, objects) Radical change = New application architecture Radical change = New technology types (e.g., imaging)

  2. Analyzing the degree of change has multiple benefits and assists decision making for tailoring, staffing, and risk identification.

  3. For tailoring decisions, use degree of change analysis to determine those perspectives that will be most and least important in the solution. For example, if there will be little or no change in the current state from the location perspective, the life cycle can be tailored to reduce or eliminate activities, artifacts and reviews pertaining to location

  4. For staffing decisions, use degree of change analysis to help determine high-level staffing needs. For example, if there will be a major change in the business process perspective, there will be a corresponding need for Business Architects or other roles to support business aspects of the solution.

  5. For risk identification, use degree of change analysis to identify project areas with high degrees of risk, and to identify high versus low risk projects. In general, the higher the degree of change in a perspective, the higher the associated risk. Plan risk mitigation strategies for the affected areas. A project with several areas of major or radical change is classified as a high risk project. For these projects, plan to use methods and approached that will mitigate overall project risk.

2.16.1.3.2.2  (06-16-2008)
Using Perspectives During Architecture

  1. During the Domain Architecture Phase, multiple, individual solution components may be identified. These components are later designed and developed independently, possibly by different teams, and then integrated into the overall solution. When identifying solution components, do not address only the obvious technical components (e.g., applications, databases, and local area networks (LANs)). Also consider the necessity for components from business perspectives. The following table provides examples:

    Perspective System Component
    Business Process Working process, process documentation
    Organization Department, trained workers
    Location Site, facility
    Data Database, file
    Application Business application, interface
    Technology LAN, server

2.16.1.3.2.3  (06-16-2008)
Using Perspectives During Design

  1. When preparing the architecture and design for a business change solution:

    • address all perspectives together

    • ensure that the perspectives evolve synchronously

    • evaluate the solution to determine that each perspective is at the appropriate level of detail (i.e., conceptual, logical, or physical) at each stage of the life cycle

  2. LCSRs have been developed to accomplish this. If reviews are tailored, be sure to preserve this synchronous treatment of the perspectives. The following table depicts how perspectives progress through design:

    Domain Architecture Phase Preliminary Design Phase Detailed Design Phase
    Business Process Perspective: Conceptual, Logical Business Process Perspective: Logical Business Process Perspective: Physical
    Organization Perspective: Conceptual, Logical Organization Perspective: Logical Organization Perspective: Physical
    Location Perspective: Conceptual, Logical Location Perspective: Logical Location Perspective: Physical
    Data Perspective: Conceptual Data Perspective: Logical Data Perspective: Physical
    Application Perspective: Conceptual Application Perspective: Logical Application Perspective: Physical
    Technology Perspective: Conceptual, Logical Technology Perspective: Logical Technology Perspective: Physical

2.16.1.3.3  (09-04-2010)
ELC Tailoring

  1. Tailoring is customization of the ELC and its various features for use by an individual project. The objective is to arrive at an approach that is based on standard methods but that has been modified (as necessary) to take into account the specific needs and unique conditions of the project. The ELC was meant to be tailored and many types of modifications may be permissible as long as the appropriate approvals are obtained for the modifications. ELC tailoring does not mean project tailoring. The intent of tailoring is not to fit a project into the constrictions of the ELC, but to adapt the ELC so that it is practical and effective given the realities of the project

  2. ELC Tailoring is performed throughout the project life cycle to address different scopes and levels of detail. The following scopes of tailoring are performed:

    • Project-wide Tailoring

    • Release-wide Tailoring

  3. Project-wide Tailoring - Project-wide tailoring is performed at the beginning of the project during the Project Initiation Phase. It lays out a life cycle for the entire project to the extent that it is known at the time and makes high-level decisions regarding the types and placement of key ELC features. In addition, detailed tailoring decisions are made regarding how all ELC features will be handled during the imminent project phase (Domain Architecture) including the path to be followed.

  4. Release-wide Tailoring - Release-wide tailoring is performed for the imminent project release. It is performed for each subsequent release. Release tailoring lays out the life cycle for the entire release and makes intermediate-level decisions regarding the types and placement of key ELC features for the release. In addition, detailed tailoring decisions are made regarding how all ELC features will be handled during the imminent project phase (Preliminary Design) including the development path that will be followed for each solution component that will be developed for the release.

  5. Project Tailoring Plan ELC tailoring must be documented in a Project Tailoring Plan (PTP) and approved. This plan must identify all tailoring decisions and explain the rationale and impact of each decision. Impact should include a discussion of any risk associated with the change. The approved tailoring decisions must be reflected in the project Work Breakdown Structure (WBS) and the project schedule. All approved waivers and deferrals for tailoring decisions must be maintained in the projects repository. Tailoring Plan templates and other tailoring plan support can be found on the ELC website.

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

  7. Several key aspects of tailoring are:

    • Structuring the Life Cycle

    • Selecting the Life Cycle Paths

    • Focusing the Tailoring Effort

    • General Tailoring

    • Ensuring Proper Tailoring Results

    Note:

    IRM 2.16.1.3.4 for additional approaches to tailoring the ELC for small projects.

2.16.1.3.3.1  (06-16-2008)
Structuring the Life Cycle

  1. The ELC does not prescribe how to develop systems and it does not provide a single life cycle that is usable for all possible development approaches. The outcome of ELC tailoring is to support the project's approach to developing a solution. ELC tailoring must start with an understanding of the solution structure and development approach that the project will use. The tailoring must describe how the appropriate development approach fits within the life cycle.

  2. There are various approaches to building the solution and managing the project that may introduce variations to a simple, linear, single-threaded life cycle execution. For tailoring, it is imperative to understand the technical and management approaches that will be applied so that an appropriate life cycle can be configured. The following subsections address the life cycle impacts of several approaches that are commonly used, including:

    • Builds and Drops

    • Releases

2.16.1.3.3.1.1  (04-25-2012)
Builds and Drops

  1. A common variation of linear life cycle execution is to perform development (i.e., coding and unit testing) in increments. In this scenario, the life cycle follows a waterfall approach through the Detailed Design Phase. During the Detailed Design Phase, a plan for development is created and the approved physical design is divided into multiple functionality subsets. Development is then performed separately for each subset.

  2. There are two primary variations of this scenario:

    • Builds

    • Drops

  3. Builds - A build is a component of a solution that moves through development and testing environments, but is not deployed into a production environment. Builds do not require governance board approval. A build becomes a drop or release when it is approved and deployed.

  4. Drops - A drop is a release that has been previously approved by a governance board, usually within 3 months of a release, and deploys into a production environment.

2.16.1.3.3.1.2  (04-25-2012)
Releases

  1. A release is any solution that is deployed into a production environment. A release requires governance board approval prior to deployment.

2.16.1.3.3.2  (08-03-2009)
Selecting the Life Cycle Paths

  1. When developing a business change solution, important decisions must be made concerning which path or paths will be used. If warranted, a project may combine features of multiple paths to meet its unique requirements. Or if a project develops more than one solution component, different paths may be selected to address each component.

    Note:

    The use of multiple paths, though it may be necessary in order to properly fit the ELC to the solution, will increase project complexity and risk.

  2. In all cases, a complete and detailed life cycle must be specified for the project. Detail for portions of the life cycle will depend on which path is selected. The subsections below provide guidance for selecting paths and producing a complete picture of the life cycle for the project to follow.

2.16.1.3.3.2.1  (09-04-2010)
Selecting an ELC Path

  1. The selection of the ELC path should occur during the Project Initiation Phase of the life cycle. The decision would be made based on the project characteristics outlined in the Business Solution Concept and the resources allocated to the project, which should both be available by the Project Initiation Phase. The selection of the path a project will use normally starts with the question of how much of the solution is already in production. If the answer is that none or most of the solution desired is not in production, then one of the new project paths (Waterfall, COTS, Managed Services, Iterative and JAD/RAD) is used. If most of the solution is already in production, then the Planned Maintenance path is used.

  2. For new projects, the selection of the ELC path normally occurs during the Project Initiation Phase of the life cycle. For the most part, the first two phases (the Project Initiation and Domain Architecture phases) are the same for all new project paths (Waterfall, COTS, Managed Services, Iterative and JAD/RAD). So all new projects complete the Project Initiation artifacts establishing the scope of the project and the technical approach they will use. During the Domain Architecture Phase, the new projects define all requirements known at that time. New projects that have problems defining their requirements, may use either Iterative or JAD/RAD paths to “prototype” various possible solutions to help define the desired requirements. Normally, projects using the JAD/RAD path have more of the requirements defined to and use prototypes to refine those requirements that are more difficult to define. At the end of the JAD/RAD Domain Architecture phase all of the requirements are defined, unlike in the Iterative Path. In the Iterative Path only a high level definition of the requirements are defined at the end of the Domain Architecture phase. The process of refining the requirements is iterative during each iteration or sprint of the Iteration Path. For projects where the majority or all of the solution is already in production and maintenance needs to be performed, the “maintenance needs” are the requirements and are clearly defined by a Change Control Board (CCB) or some other management authority.

  3. Once the requirements for the new projects is defined, in the Domain Architecture Phase, the project team needs to determine what is the “best” way to obtain a solution that fulfills the most requirements defined. Depending on which approach they take (build, buy or rent) determines which new project path the project will follow for that release. If it is determined that the “best” approach is to develop the solution, then the project will follow the Waterfall Path. If the “best” approach is to buy a solution and have the IRS maintain it, then the project will follow the Commercial-Off-the-Shelf (COTS) Path. If the “best” approach is to buy a service (rent a solution) and have the vendor maintain it, then the project will follow the Managed Service Path.

  4. Tailoring is used to further refine the paths that are the most appropriate for the size of the project. Tailoring can be used to scale down any particular path to be more in line with limited resources available to small projects.


More Internal Revenue Manual