2.16.1  ELC Guidance (Cont. 1)

2.16.1.4 
ELC Paths

2.16.1.4.3 
Maintenance Paths

2.16.1.4.3.1  (05-21-2014)
Planned Maintenance Path

  1. General Description - The Planned Maintenance path has defined requirements, sequential progression through the phases, evolving teams and uses a developmental technical approach for correcting solutions that are already in production. 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. Characteristics - The following are characteristics of the Planned Maintenance approach:

    • Defined Requirements - When maintenance needs to be performed on a system already in production, the CCB defines the maintenance needs as requirements and are clearly defined by a Change Control Board (CCB) or some other management authority. These may include functional, operational, programmatic, and other types of requirements. Planned Maintenance typically addresses numerous system requirements 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); and Changes under Planned Maintenance include permanent repairs to replace temporary patches implemented by Emergency Maintenance.

    • Sequential Progression - A Planned Maintenance approach begins in either the Design or Development phases depending on the nature of the changes. 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. Once the starting phase is determined, Planned Maintenance projects evolve in a sequential manner. Movement through the phases is authorized through an approved governance board. The Planned Maintenance path does not have a System Deployment (MS 5) phase.

    • Fixed Teams - Projects using the Planned Maintenance path will form integrated teams, consisting of solution engineers, developers, testers, and any other relevant functional or domain experts.

    • Technical Approach - the Planned Maintenance path involves maintenance of an existing solution. Planned Maintenance projects may follow the most appropriate development approach given the nature of the changes being made. For example, a project which originally used the Iterative approach to promote a new solution into O&M, can use the same Iterative approach when following Planned Maintenance. Criteria for choosing an appropriate development approach for Planned Maintenance are the same as for selecting a development path. The ELC Office has determined that more than 17% change to a system is considered a significant impact to the project that the project does not qualify to use the Planned Maintenance Path. For additional information related to the 17% rule, see IRM 2.16.1.4.1.1, Considerations for ELC Path Selection.

  3. Diagram - The following diagram exhibits six (6) columns representing ELC project phases: Project Initiation (MS 1), Domain Architecture (MS 2), Preliminary Design (MS 3), Detailed Design (MS 4a), System Development (MS 4b), and System Deployment (MS 5). Milestones terminate each phase. Within the System Development Phase, a Planned Maintenance project must conduct ELC reviews in the following order: MRR and MER. The diagram depicts the following baselines: Functional Baseline (occurs within the Domain Architecture Phase), Allocated Baseline Logical Design (occurs within the Preliminary Design Phase), Allocated Baseline Physical Design (occurs within the Detailed Design Phase), and Product Baseline (occurs within the System Development Phase). The following figure depicts the diagram.

    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.

    Planned Maintenance Path

2.16.1.4.3.2  (05-21-2014)
Emergency Maintenance Path

  1. General Description - Emergency Maintenance is for system maintenance of an emergency nature. This constitutes a sudden or unexpected impending situation that may cause injury, loss of life, damage to property, and/or interference with the normal activities of a system or application. This would therefore require immediate attention and remedial action (i.e. when a system or application is "down" and incapable of making/ doing what it is meant to do at an opportune time). As such, Emergency Maintenance changes occur in a manner befitting their urgency, and are thus not subject to the same documentation and management considerations as a path.

2.16.1.4.4  (05-21-2014)
Summary of Path Characteristics

  1. The following table summarizes the characteristics of each path. For each path, the table identifies the path, identifies the typal requirements appropriate for the path, specifies the progression of the path, specifies the team structure used with the path, identifies the technical approach used with the path, and identifies the typal project associated with the path.

    Path Name Requirements Progression Team Structure Technical Approach Project Type
    Waterfall Defined Sequential Evolving Developmental New
    COTS Defined Sequential Evolving Vendor solution New
    Managed Services Defined Sequential Evolving Vendor supplied service New
    Iterative Evolving Repetitive Fixed Developmental New
    Mobile Apps Defined Sequential Fixed Developmental (only for mobile apps) New
    Planned Maintenance Defined Sequential Fixed Developmental In production

2.16.1.5  (05-21-2014)
ELC Artifacts

  1. An artifact is the output of an activity performed in a process/procedure. Artifacts are created throughout the lifecycle of a project and can support either project management or the IT technical solution such as the design.

  2. The ELC Artifacts by Phase Chart lists the required artifacts for New Development (Waterfall) projects and when they are created or updated in the life cycle. The artifacts listed in this chart are those required for milestone exit purposes. The latest ELC Artifacts by Phase chart can be found on the ELC website at http://elc.nc.no.irs.gov/.

  3. ELC artifact templates are created and maintained by Process Owner organizations. Process Owners approve the artifact completed by the project (if applicable). Artifact templates are subject to change as deemed necessary by the Process Owner. Projects should visit the IT PAL (http://itpal.ds.irsnet.gov/index.asp) for the latest artifact templates.

  4. The ELC Office provides an independent validation and verification that projects have had all artifacts listed in their approved tailoring plan approved by the appropriate Process Owners.

  5. A detailed list of assets and resources that support the ELC are located in the ELC Roadmap and can be found on the ELC website at http://elc.nc.no.irs.gov/.

2.16.1.5.1  (05-21-2014)
Data Item Descriptions (DID) and Templates

  1. A DID provides a description of the information that is required within an artifact. A template provides both the information that is required within an artifact as well as the format of the information. Most IRS DIDs include the artifact template.

  2. DIDs help to ensure consistency regardless of which organization produces an artifact or what methodology is used. All projects following the ELC are required to provide artifacts that conform to specified DIDs unless deviations are authorized and approved by their Process Owner and documented in the PTP. Artifacts produced using alternate formats must include a mapping of all sections in the alternate format back to the sections of the standard DID.

  3. DIDs and templates supporting ELC can be found on the IT PAL (http://itpal.ds.irsnet.gov/) and on the ELC website (http://elc.nc.no.irs.gov/). Projects should also contact Process Owners for the latest DIDs and templates.

2.16.1.5.2  (05-21-2014)
ELC Required Artifacts

  1. Projects following the ELC are required to complete and submit various artifacts for Process Owner approval. These artifacts are listed in the project’s approved Tailoring Plan and include ELC owned artifacts and other Process Owner owned artifacts. The ELC Office does not maintain or approve all ELC required artifacts.

  2. The list of ELC artifacts below is from the Artifacts by Phase Chart. Please visit the IT PAL (http://paig.ds.irsnet.gov) and the ELC website (http://elc.nc.no.irs.gov/) for more information on ELC required artifacts. Additionally, projects should contact applicable Process Owners for the latest artifact(s).

2.16.1.5.2.1  (05-21-2014)
Project Tailoring Plan (PTP)

  1. The PTP is the first artifact a project should produce while following the ELC. The PTP lists all of the adaptations made in the tailoring process for a specific project. Additionally, the PTP lists the agreed to artifacts to be completed by the project team and submitted for approval to the appropriate Process Owners. The adaptations are suggested by the project team and agreed to by their ELC Coach during their initial interview.

  2. Projects can generate their initial PTP by using the ELC Tailoring Plan Tool located on the ELC website (http://elc.nc.no.irs.gov/). The generated PTP is pre-tailored based on the information provided by the project and the selected path.

  3. Any deviations from the mandatory artifacts listed in the PTP require approval/concurrence from corresponding Process Owners. Additionally, projects must adhere to the latest PTP template located on the ELC website.

  4. The ELC Office is the Process Owner for the PTP. For additional information related to the PTP, visit the ELC website (http://elc.nc.no.irs.gov/).

2.16.1.5.2.2  (05-21-2014)
Project Charter

  1. The Project Charter is required for all new development IRS projects and is a statement of the scope, objectives and participants in a project. The purpose of the Project Charter is to provide authority for the future of the project.

  2. The Project 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. The Project Charter must be created using the latest approved template and must comply with existing IRS document standards. Additionally, the Project Charter should provide content that meets the purpose and intent of the document, and the content of the artifact at a minimum, shall include the following sections listed in the template.

  4. The EA Office is the Process Owner for the Project Charter. For additional information related to the Project Charter, contact the EA Office (http://ss.ds.irsnet.gov/sites/ea/default.aspx).

2.16.1.5.2.3  (05-21-2014)
Project Management Plan (PMP)

  1. The PMP defines the project's scope of work and its approach to managing all project activities. The purpose of the PMP is to provide a framework for managing project activities and for completing the project successfully. The PMP is a requirement for all IRS IT projects and is a key project planning artifact.

  2. The PMP comprises subsidiary plans. The following table itemizes these plans. For each plan, the table identifies the plan, identifies the organization that owns the plan, and describes the plan.

    Name Owned By Description
    Contingency Management Plan (COMP) Risk Management Describes the approach that will be employed to in the event the project cannot make the “operational readiness” date
    Quality Management Plan (QMP) Quality Assurance Describes the quality activities that the project will perform to assure that quality processes and procedures are followed throughout the life cycle.
    Risk Management Plan (RMP) Risk Management Describes the processes, techniques, and tools that will be used to track, manage, and control project risks
    Requirements Plan (RP) Requirements Engineering Program Office Describes the processes, techniques, and tools that will be used to manage and control project requirements and the mechanisms that will be used to establish and maintain an agreement with the customer on the requirements for a project.
    Engineering Plan (EP) Solution Engineering (SE) Describes the activities that the project will perform to assure that the Enterprise Technical Solution, Enterprise Solution Integration, Decision Analysis and Resolution, and Government Equipment List engineering processes and procedures from the IRM are followed throughout the life cycle.

  3. Projects must adhere to the latest PMP and subsidiary plan templates located on the ELC website.

  4. The ELC Office is the Process Owner for the PMP. For additional information related to the PMP, visit the ELC website (http://elc.nc.no.irs.gov/).

2.16.1.5.2.4  (05-21-2014)
Configuration Management Plan (CMP)

  1. (1)The configuration management plan (CMP) documents the CM activities that an organization uses to maintain the integrity of Configuration Items (CIs), CI associated artifacts, and other products throughout the life cycle. The CMP is developed during the Project Initiation Phase and is maintained throughout the life cycle. The CMP is configuration controlled and should be reviewed and updated annually. An organization’s approved CMP will be distributed to the next higher-level organization and the approving organization may further distribute the CMP as appropriate.

  2. (2)The Information Technology Enterprise Service Management (ITESM) Office is the Process Owner for the CMP. For additional information related to the CMP, contact the ITESM Office (http://it.web.irs.gov/ES/BRSD/ITESM/default.htm).

2.16.1.5.2.5  (05-21-2014)
Security Package

  1. The Security Package includes a testing and evaluation process that results in authorization based on the NIST Special Publication 800-series. The purpose of the Security Package is to validate that a system has the Authorization to Operate (ATO). Systems must go through the reauthorization process every three years to evaluate the system and determine if the ATO will be continued. The Security Package must be completed and certified by the Process Owner prior to the system processing live data.

  2. The Cybersecurity Office is the Process Owner for the Security Package. For additional information related to the Security Package (including additional security-related documents), contact the Cybersecurity Office http://mits.web.irs.gov/Cybersecurity/.

2.16.1.5.2.6  (05-21-2014)
Privacy Package

  1. The Privacy Package or Privacy Impact Assessment (PIA) includes a process for examining the risks and ramifications of using information technology to collect, maintain and disseminate information in identifiable form about members of the public and agency employees. The Privacy Package also identifies and evaluates protections to mitigate the impact to privacy of collecting such information. The Privacy Package must be completed by the project and approved by the Process Owner prior to the system processing live data.

  2. The Office of Privacy Compliance is the Process Owner for the Privacy Package. For additional information related to the Privacy Package, contact the Office of Privacy Compliance via email Privacy@irs.govor access their website http://irweb.irs.gov/AboutIRS/bu/pipds/pip/privacy/pia/default.aspx.

2.16.1.5.2.7  (05-21-2014)
508 Accessibility and Mitigation Package

  1. The 508 Accessibility and Mitigation Package describes the approach and tests to be conducted to ensure the proposed solution is accessible to users with disabilities, and demonstrates compliance via actual test results. The purpose of the 508 Accessibility and Mitigation Package is to validate that the proposed solution adheres to the requirements of Section 508.

  2. The 508 package currently consists of the following documents that must be updated and approved for each milestone:

    • Accessibility Compliance Approach

    • Accessibility Risk Information

    • ELC Signature Sheet

  3. The Information Resources Accessibility Program (IRAP) Office is the Process Owner for the 508 Accessibility and Mitigation Package. For additional information related to the 508 Accessibility and Mitigation Package (including additional 508-related documents), contact the IRAP Office (http://irap.web.irs.gov/).

2.16.1.5.2.8  (05-21-2014)
Project/Phase Kickoff Meeting Minutes

  1. The Project/Phase Kickoff Meeting Minutes contain a list of the meeting attendees and all key decisions, action items, and issues. The purpose of the Project/Phase Kickoff Meeting Minutes is to confirm that the kickoff meeting was held and document key items discussed. Kickoff meetings are held to ensure that IT leadership and stakeholders understand and are in agreement with the goals, objectives, scope, business capabilities and projected costs of the project, and are prepared to fully support the execution of the project.

  2. The Project Kickoff Meeting is performed during the Project Initiation Phase and covers the scope, objective, business capabilities and end-to-end costing as projected at the time of kickoff for the entire project (to include the O&M phase).

  3. Subsequent Phase Kickoff Meetings are performed at the start of each subsequent lifecycle phase (i.e., Domain Architecture, Preliminary Design, Detailed Design, System Development and System Deployment) and will address detailed requirements, implementation approach (including tailoring plans), schedule, budget, risk/issues for that phase, and revisit the release strategy.

  4. The ELC Office validates completion of the Project/Phase Kickoff Meeting Minutes during the project’s MRR meeting. For additional information related to the Project/Phase Kickoff Meeting Minutes, please visit the ELC website (http://elc.nc.no.irs.gov/) and review the Project/Phase Kickoff Meeting Procedure.

2.16.1.5.2.9  (05-21-2014)
Lessons Learned Report (LLR)

  1. The LLR provides a summary of a project’s important points, including what went right, what went wrong, and what could have been done differently. This information is reviewed and approved by a project manager for use as a reference for subsequent project efforts. The LLR is subject to a sensitivity analysis and is posted to the Lessons Learned Library so other projects may enhance their likelihood of success.

  2. The Program Evaluation Office (PEO) is the Process Owner for the LLR. For additional information related to the LLR, contact the PEO (http://ss.ds.irsnet.gov/sites/mvs/evaluate/default.aspx).

2.16.1.5.2.10  (05-21-2014)
Business System Concept Report (BSCR)

  1. The BSCR describes a vision for the future system and its operation, grounded in an awareness of the current situation and customer/user needs, and describes key aspects of how that vision may be realized. It includes an identification of core functionality, users, cross-cutting conceptual information, and related tools/systems and technology that are shared across business processes specific to a particular business area. The BSCR is intended to facilitate understanding of the context, in which the proposed solution will operate, and the nature and scope of that solution, and confirm its feasibility. Specifically the BSCR is used to:

    • Validate the current state weaknesses and improvement opportunities

    • Identify key customer and user needs and expectations

    • Characterize the envisioned future state environment

    • Establish the system solution concept by describing the purpose and key aspects of the selected solution

    • Identify key impacts on the existing environment and associated issues and solution strategy - across all perspectives (process, organization, location, data, application and technology)

    • Define or refine release strategy, based on inherent dependencies and business priorities

    • Lay the groundwork for the system architecture and associated technology needed to achieve the solution concept

    • Clarify and confirm scope, and confirm feasibility of the proposed solution concept through accomplishing all of the above

  2. The Requirements Engineering Program Office is the Process Owner for the BSCR. For additional information related to the BSCR, contact the Requirements Engineering Program Office (http://mits.web.irs.gov/brrm/).

2.16.1.5.2.11  (05-21-2014)
Business System Requirements Report (BSRR)

  1. The BSRR documents a feasible, quantified, verifiable set of requirements that define and bound the business system or subsystem(s) being developed or enhanced by the project. These requirements form the basis for the business system design, development, integration, and deployment. The requirements in the BSRR document the nature and scope, or boundary, of the business system.

  2. The BSRR provides a concise and unambiguous mechanism for communicating these requirements to all team members and to the stakeholders in a commonly understood form. It also establishes traceability of requirements beginning with the enterprise business and information system requirements through the remaining phases of the life cycle. Finally, the BSRR serves as a scope control mechanism against which changes can be assessed and applied and through which an understanding of the customer's needs evolves. The BSRR is mandatory for all projects.

  3. The Requirements Engineering Program Office is the Process Owner for the BSRR. For additional information related to the BSRR, contact the Requirements Engineering Program Office (http://mits.web.irs.gov/brrm/).

2.16.1.5.2.12  (05-21-2014)
Business System Architecture Report (BSAR)

  1. The BSAR specifies the business and system architectures for a particular business area or business system. It must be consistent with the EA and provides the basis from which system design proceeds. The BSAR is mandatory for all projects, unless the project is pre-approved to produce a Business System Report (BSR) (which integrates the BSCR, BSAR and BSRR). It documents the work typically performed during the Domain Architecture and Preliminary Design Phases.

  2. The EA Office is the Process Owner for the BSAR. For additional information related to the BSAR, contact the EA Office (http://mits.web.irs.gov/brrm/).

2.16.1.5.2.13  (05-21-2014)
Government Equipment List (GEL)

  1. The GEL provides a complete listing of equipment to be installed for use in various system environments. The system environments needing a GEL are: Development, Unit Test, Integration, Production and Disaster Recovery. The purpose of the GEL is to identify and track the incremental hardware and software required by a project for the proposed system.

  2. The Solution Engineering (SE) Office is the Process Owner for the GEL. For additional information related to the GEL, contact the SE Office (http://docit.web.irs.gov/docit/drl/objectId/090075628048826a).

2.16.1.5.2.14  (05-21-2014)
System Deployment Plan (SDP)

  1. The System Deployment Plan (SDP) can be used by systems classified as New Development or Planned Maintenance. The SDP is an Enterprise Life Cycle (ELC) requirement. The purpose of the SDP is to provide a standard artifact to summarize the planned deployment activities for the release. The SDP gives the project an opportunity to mitigate risks that may cause delays to project implementation.

  2. The Test Support Section (TSS) Office is the Process Owner for the SDP. For additional information related to the SDP, contact the TSS Office (http://docit.web.irs.gov/docit/drl/objectId/090075628048826a).

2.16.1.5.2.15  (05-21-2014)
Transition Management (TM) Package

  1. The TM Package documents the transition strategy and readiness gaps for each receiving organization, described in terms of People, Processes, Assets and Financials. The purpose of the TM Package is to provide an overview of the project’s release, current/future state, transition readiness gaps, and mitigation strategies.

  2. The Enterprise Transition Management Office (ETMO) is the Process Owner for the TM Package. For additional information related to the TM Package, contact the ETMO (http://it.web.irs.gov/ES/BRSD/ETMO/default.htm).

2.16.1.5.2.16  (05-21-2014)
Design Specification Report (DSR)

  1. The DSR documents the logical and physical design of a proposed solution from all applicable perspectives. The DSR is created in the Preliminary Design phase (MS 3) and is updated with physical design details during the Detailed Design phase (MS 4A).

  2. The DSR has two template options - the Iterative DSR (IDSR) or the Simplified DSR (SDSR). For most projects, the SDSR is the proper choice. The IDSR was created for a specific purpose for ACA projects. Upon request and SE approval, projects outside of ACA which would prefer to use the IDSR may do so.

  3. The SE Office is the Process Owner for the DSR. For additional information related to the DSR, contact the SE Office (http://mits.web.irs.gov/ES/SI/EDMO/default_new.htm).

2.16.1.5.2.17  (05-21-2014)
Interface Control Document (ICD)

  1. The ICD defines the details for boundary conditions and data at the design solution interfaces. The purpose of the ICD is to establish an agreement of responsibilities among the organizations owning the interfacing entities. The ICD is first created in the Preliminary Design phase (MS 3) and is subsequently updated during the Detailed Design phase (MS 4A).

  2. The SE Office is the Process Owner for the ICD. For additional information related to the ICD, contact the SE Office (http://mits.web.irs.gov/ES/SI/EDMO/default_new.htm).

2.16.1.5.2.18  (05-21-2014)
System Test Plan (STP)

  1. The System Test Plan (STP) can be used by systems classified as New Development or Planned Maintenance. The STP is an Enterprise Life Cycle (ELC) requirement. The purpose of the STP is to provide a standard artifact to summarize the complete test effort for the release. The STP gives the project an opportunity to mitigate risks that may cause delays to project implementation.

  2. The TSS Office is the Process Owner for the STP. For additional information related to the STP, contact the TSS Office (http://docit.web.irs.gov/docit/drl/objectId/0900756280488263).

2.16.1.5.2.19  (05-21-2014)
Computer Operator Handbook (COH)

  1. The purpose of the COH is to provide all responsible personnel for the operation and support of a solution with operational instructions for supporting daily operations. The COH documents the tasks that must be performed to support the applications and servers deployed for the solution. The COH is prepared during the System Development Phase (MS 4B) and should be updated to reflect the completed product during the System Deployment Phase (MS 5).

  2. The Enterprise Computer Center (ECC) is the Process Owner for the COH. For additional information related to the COH, contact the ECC.

2.16.1.5.2.20  (05-21-2014)
End of Test Completion Report (EoTCR)

  1. The End of Test Completion Report (EOTCR) can be used by systems classified as New Development or Planned Maintenance. The EOTCR is an Enterprise Life Cycle (ELC) requirement. The purpose of the EOTCR is to provide a standard artifact to summarize the complete test effort for the release. The EOTCR gives the project an opportunity to mitigate risks that may cause delays to project implementation.

  2. The TSS Office is the Process Owner for the EoTCR. For additional information related to the EOTCR, contact the TSS Office (http://docit.web.irs.gov/docit/drl/objectId/090075628048826d).

2.16.1.5.3  (05-21-2014)
Minor Artifact Revisions (Errata Sheet)

  1. An errata sheet is an optional mechanism in the ELC process used to make minor revisions to a published document. These minor revisions include any changes which are non-technical and non-architectural (i.e. spelling corrections, typing mistakes, etc.).

  2. The errata sheet should 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 signers believe the changes are significant and they notify the originator of such in writing, the whole ELC artifact must be re-published and re-approved/concurred by all individuals originally approved/concurred on the artifact.

  3. The errata sheet should be listed in the Revision History of the final version of the document being updated. The following 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;

    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 and offices of those who originally signed the artifact;

    9. reason the artifact was changed; and

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

  4. For detailed information on the errata sheet, refer to the Errata Sheet Guidance document (http://elc.nc.no.irs.gov/Library/DIDs/Errata%20Sheet%20Guidance%20final.doc).

2.16.1.6  (05-21-2014)
ELC Reviews

  1. The ELC Framework includes various reviews to ensure that a project is progressing through its life cycle efficiently and within the directives of the IRS. These reviews include:

    • Customer Technical Review (CTR)

    • Life Cycle Stage Review (LCSR)

    • End of Sprint Checkpoint Review (EoSCR)

    • Milestone Readiness Review (MRR)

    • Milestone Exit Review (MER)

  2. Decisions as to which reviews will be mandatory for a given project are made during the planning phase and documented in the Project Tailoring Plan (PTP).

2.16.1.6.1  (05-21-2014)
Customer Technical Review (CTR)

  1. A CTR is conducted by the project with stakeholders to review select artifacts produced by the project. CTRs facilitate Process Owner approval of artifacts by:

    • Ensuring stakeholder feedback

    • Identifying any weaknesses and resolving issues and actions required to gain approval

    • Providing a forum to resolve conflicting comments, deliverables, and/or feedback

  2. Depending on the Path, a CTR may be held during the following phases:

    • Domain Architecture Phase (At a minimum, the select artifact is the Requirements document)

    • Preliminary Design Phase (At a minimum, the select artifact is the logical design document)

    • Detailed Design Phase (At a minimum, the select artifact is the physical design document)

    • System Development Phase (At a minimum, the select artifact is the user training/COH document)

  3. CTR activities include:

    1. Planning and Scheduling the CTR - Includes distributing the artifact to be reviewed, instructions associated with the review, and confirming review participants.

    2. Conducting the CTR - Includes evaluating the distributed material for compliance, recording reviewer comments, and disposing of comments.

    3. Closing Out the CTR - Includes responding to reviewer questions, updating the artifact according to the comments, capturing outstanding issues/action items for the subsequent LCSR, and distributing the updated artifact.

  4. A CTR is complete when:

    • The Project Manager and Reviewers have agreed to the disposition of comments

    • All review documents have been discussed and issues have been resolved

    • All applicable artifacts have been updated

    • Final checklist of open items and meeting minutes have been created and archived

  5. For further detail, please refer to the CTR Procedure located at: http://elc.nc.no.irs.gov/elcpmoweb/ELCAssets.asp

2.16.1.6.2  (05-21-2014)
Life Cycle Status Review (LCSR)

  1. A LCSR is conducted by the project with stakeholders to verify that the Process Owner processes have been conducted appropriately at that point in its life cycle. Upon verification, the solution may be approved for a projects baseline. A LCSR occurs during a phase, prior to the MRR. Accordingly, a successful LCSR consists of:

    • Specifying an applicable set of Process Owner criteria for review

    • Verifying that the project followed the Process Owner processes completely, correctly and consistently

    • Reviewing Process Owner artifacts (appropriate at that point in its life cycle) and discussing outstanding items from the previous CTRs

  2. Depending on the Path, a LCSR may be held during the following phases:

    • Domain Architecture Phase (Business System Requirements and Architecture LCSR)

    • Preliminary Design Phase (Logical Design LCSR)

    • Detailed Design Phase (Physical Design LCSR)

    • System Development Phase (Development LCSR)

  3. LCSR activities include:

    1. Planning and Scheduling the LCSR – Includes determining which artifacts will be reviewed, reviewing the LCSR Checklist for the appropriate phase, and completing the LCSR Presentation Deck.

    2. Conducting the LCSR – Includes presenting the LCSR Presentation Deck, participating in and moderating the LCSR discussion to resolve any open items, and capturing any new risks, issues, and/or action items.

    3. Closing Out the LCSR – Includes developing mitigation plans for any risks, issues, and/or action items.

  4. An LCSR is complete when:

    • The Project Manager has reviewed and responded to Reviewer comments

    • All issues have been resolved and the final checklist of items still open and meeting minutes have been created and archived

    • The LCSR meeting minutes have been distributed.

  5. For further detail, please refer to the LCSR Procedure located at: http://elc.nc.no.irs.gov/elcpmoweb/ELCAssets.asp

2.16.1.6.3  (05-21-2014)
End of Sprint Checkpoint Review (EoSCR)

  1. For projects following the Iterative Path, EoSCRs replace the CTRs and LCSRs. A EoSCR is an opportunity for the project team to summarize the progress made, obtain feedback and approvals from stakeholders, and adjust planning for subsequent iterations. A successful EoSCR includes:

    • Demonstrating the functionality developed for the stakeholders

    • Sharing sprint documentation, including draft ELC artifacts, and project issues and changes with selected Process Owners

    • Determining whether issues and risks meet escalation criteria

    • Providing feedback on whether the functionality meets stakeholder requirements, and/or suggesting changes for subsequent iterations

    • Planning for the next sprint based on stakeholder input and lessons learned, including escalating any concerns

  2. EoSCRs are held iteratively during the Design and System Development Phase.

  3. EoSCR activities include:

    1. Planning and Scheduling the EoSCR – Includes completing the EoSCR Template, and scheduling the EoSCR meeting.

    2. Conducting the EoSCR – Includes presenting the EoSCR Template, discussing key objectives, and validating that concurrence was provided.

    3. Closing out the EoSCR – Includes distributing EoSCR meeting minutes, providing feedback, soliciting lessons learned, conducting Sprint Reflection and Sprint Planning meetings to prepare for the next sprint, and escalating any risks, issues, and/or action items, if applicable.

  4. A EoSCR is complete when:

    • Product has been demonstrated and the functionality is documented and approved

    • Business Owner and stakeholders have accepted and approved product functionality

    • EoSCR presentation has been archived in the project repository

    • Issues, next steps, and/or risks are documented

  5. For further detail, please refer to the EoSCR Procedure located at: http://elc.nc.no.irs.gov/elcpmoweb/ELCAssets.asp

2.16.1.6.4  (05-21-2014)
Milestone Readiness Review (MRR)

  1. A MRR is conducted by the ELC Office at least 5 business days prior to the MER to determine if the project is in compliance with ELC Process Owner processes and is ready to begin the milestone exit process and proceed to the next phase. The MRR is a detailed and extensive review of the project status for IRS executive review. The purpose of the MRR is to provide IRS executives with the status of the projects compliance with Process Owner processes and its readiness to exit the milestone so that the executives can make go/no-go MER decisions. As such, an MRR results in a formal recommendation from the ELC Office to the project’s governance board. A successful MRR involves:

    • Verifying the approval of Process Owner artifacts identified for that phase in the Project Tailoring Plan

    • Sharing information on existing project information, including project status, lessons learned, risk identification, and decision criteria from LCSRs and/or EoSCRs

  2. It is recommended that the project complete a pre-MRR at least 5 business days prior to the MRR which is a dress rehearsal for the MRR. The pre-MRR is an opportunity to identify issues and/or risks/action items that may impact the outcome of the MRR, as well as, resolve any process related issues and/or project risks/issues/action items of the previous phase or phase being exited.

  3. MRRs are required for all ELC phases and monitors readiness to exit each phase’s respective milestone. Note, Planned Maintenance Path projects do not have a MS 5 exit. Therefore, there is no MS 5 MRR. (5)MRR activities include:

    1. Planning and Scheduling the MRR – Includes confirming that all ELC required artifacts have been approved, developing and distributing project documentation to be reviewed during the MRR, and scheduling the MRR meeting.

    2. Conducting the MRR – Includes creating an MRR attendance list, validating that the ELC required artifacts have been approved and that the required reviews (CTR, LCSR, EoSCR) have been conducted, and examining the status of risks, issues, action items, and/or prior or current project conditions.

    3. Preparing the MRR package – Inputting the impact of all risks, issues, and action items on the MS Exit into the MRR recommendation, developing the MRR Memorandum including all attachments and inputs, routing the MRR package to the appropriate Executives for approval, obtaining executive approval, and routing the approved package to the applicable governance office.

  4. An MRR is complete when the MRR Package has been approved. Additionally:

    • If there are no risks, issues, and action items, the ELC Office will make a formal recommendation to the appropriate level governance board that the project is ready for an unconditional exit.

    • If there are risks, issues, and action items, the ELC Office will recommend a conditional exit and document the outstanding risks, issues, and action items in the formal memorandum.

    • If there are a substantial number of risks, issues, and action items, the ELC Office may recommend that the project not proceed to an exit until all risks, issues, and action items are mitigated or have a mitigation plan.

  5. For further detail, please refer to the MRR Procedure located at: http://elc.nc.no.irs.gov/elcpmoweb/ELCAssets.asp

2.16.1.6.5  (05-21-2014)
Milestone Exit Review (MER)

  1. A MER is a mandatory project review performed by IRS executives when a project has reached a life cycle milestone. MERs are discussed further in the Governance section of this ELC IRM.

2.16.1.7  (05-21-2014)
ELC Tailoring

  1. Tailoring is the process of adapting an approved set of processes, procedures and artifacts to the needs of a specific project or projects. Tailoring can be done at several levels, however, the most common are:

    1. Tailoring for an organization, division or program - If specific tailoring is requested, it is the responsibility of the requestor, (i.e., organization) to convince the appropriate Process Owners the benefits of their proposed tailoring and to obtain the Process Owners formal approval. Once approved, the tailoring may be applied to all projects within that organization. These tailoring changes must be within the ELC framework.

    2. Tailoring for individual projects - A project must convince the appropriate Process Owners of the benefits of their proposed tailoring and must obtain formal Process Owner approval. Once approved, the tailoring may be applied to the remaining phases of the project and all subsequent releases of that project.

  2. There are several factors that influence ELC path tailoring. These include:

    • Project size

    • Number of planned releases

    • When the project transitions into ELC (i.e. how much work has been completed prior to following ELC)

    • Flexibility in terms of what functionality is actually deployed

  3. Project tailoring must be formally documented in the project’s Tailoring Plan and presented to affected Process Owners for approval. The PTP must identify all tailoring decisions and list the approving authority (Process Owner) that approved the tailoring and the date the approval was granted.

  4. Process Owner(s) can make an assessment and determination on a case by case basis that their artifact or process is not required. Deletions, waivers or deferrals will be provided, as needed. All approved deletions, waivers and deferral documentation is annotated in the PTP and approved by the affected Process Owners. The PTP must be maintained in the project’s repository in accordance with IRS guidelines.

  5. A project can also request that a Process Owner review an alternative document for an artifact. If the Process Owner decides that the alternative is functionally equivalent (FE) to the required artifact, the Process Owner would concur on the project’s Tailoring Plan.

2.16.1.8  (05-21-2014)
Governance

  1. Governance is a process of putting structure around how IRS aligns IT strategy with business strategy, ensuring that it stays on track to achieve their strategies and goals, and implementing good ways to measure IT’s performance. It makes sure that all stakeholders’ interests are taken into account and that processes provide measurable results.

  2. The primary objective of IRS Governance is to ensure assigned investment, program and project objectives are met, risks are managed appropriately, and enterprise expenditures are fiscally sound. This process includes review and concurrence of the Office of Management and Budget’s (OMB) related submissions Circular No. A-11 Part 2, Exhibit 53 (E53) and Circular No. A-11 part 7, Exhibit 300 (E300) and baseline change requests. It provides control for all investments, programs and projects within its assigned portfolio.

  3. The specific duties of the IRS Governance process are documented in the IT Enterprise Governance Authority and Operations Directive. The Directive can be located at http://it.web.irs.gov/sp/RM/PGO/default.htm.Contact the I&PG Office for more details and assistance.

  4. Governance activities are a critical component of the ELC process and occur at specific points in the life cycle. The Milestone Exit Review (MER) is one of these governance activities and is performed throughout the life cycle.

2.16.1.8.1  (05-21-2014)
Milestone Exit Review (MER)

  1. A MER is a mandatory project review performed by IRS executives when a project has reached a life cycle milestone. The purpose of the MER is to assess the viability of continuing the project, identifying any risks and issues, verifying any changes to cost, scope, schedule, and business results.

  2. Generally, the MER does not begin until the project's governance organization receives a formal recommendation from the reviewing organization that the Milestone Readiness Review (MRR) was successfully completed. The governance board decision review is based primarily on previously conducted reviews and recommendations. Specifically, MER decisions are based on the following key decision criteria:

    • Project Status (i.e., is the project on-time, is it within budget, are there major issues and risks, etc.?)

    • Contract status (i.e., if there is a contract for the work, are the terms and conditions being satisfied?)

    • Solution status (i.e., is the solution complete, consistent, and properly constituted, and does it reflect what is wanted?)

    • Business case (i.e., is there a well-reasoned argument documented to convince the stakeholders of the benefits of an IT investment, while educating them about the changes, costs, and risks that will be part of the effort?)

    • Funding (i.e., is there sufficient budget dollars available to fund the continuation of the project?)

  3. Irrespective of the ELC path a project is following, all projects must undergo MERs prior to exiting a single or combined phase and entering the next. Answers to these questions and considerations, along with recommendations from the appropriate authorities and subject matter experts, should be developed prior to the MER using the mechanism of other reviews (i.e., CTRs, LCSRs, EOSCRs, and MRRs). These answers and recommendations should be provided to the deciding governance board voting members for consideration. Note, the MER is not meant to be a detailed or extensive technical review. Rather, it is meant to be a venue for Governance Boards in making informed investment decisions.

  4. The outcome of a MER will be annotated in one of the following go/no go decisions: an unconditional approval, conditional approval, disapproval, or a recommendation to suspend or to terminate the project.

  5. For additional information related to the MER Procedure (including governance on the specific MER steps and activities), contact the I&PG Office http://it.web.irs.gov/sp/RM/PGO/default.htm.

Exhibit 2.16.1-1 
Acronyms

(1) The following table lists the acronyms used in this IRM. For each acronym, the table identifies the acronym and provides its meaning.

Acronym Meaning
ACIO Associate Chief Information Officer
AD Applications Development
ADPMO Applications Development Project Management Office
BC Business Case
BOD Business Operating Division
BSAR Business System Architecture Report
BSCR Business System Concept Report
BSP Business System Planning
BSRR Business System Requirements Report
CCB Configuration Control Board
CFR Code of Federal Regulations
CI Configuration Item
CII Configuration Identification Index
CM Configuration Management
CMMI Capability Maturity Model Integration
CMP Configuration Management Plan
COH Computer Operator Handbook
COMP Contingency Management Plan
COTS Commercial-Off-the-Shelf
CPE Current Production Environment
CPIC Capital Planning and Investment Control
CS Configuration System
CSC Computer Science Corporation
CTR Customer Technical Review
DAA Designated Approving Authority
DBMS Database Management System
DID Data Item Description
DIO Division Information Officer
DSRT Deployment Site Readiness Test
E300 OMB Exhibit E-300
E53 OMB Exhibit E-53
EA Enterprise Architecture
ECDM Enterprise Conceptual Data Model
EDM Enterprise Data Management
EDMO Enterprise Data Management Office
eGOV Electronic Government
EITE Enterprise Integration and Test Environment
ELC Enterprise Life Cycle
ESC Executive Steering Committee
EST Enterprise Systems Testing
EoSCR End of Sprint Checkpoint Review
EoTCR End of Test Completion Report
FEA Federal Enterprise Architecture
FIPS Federal Information Processing Standards
FISMA Federal Information Security Management Act
FIT Final Integration Test
FOC Full Operational Capability
FOD Functional Operating Division
FRA Federal Records Act
FRC Federal Records Center
GAO Government Accountability Office
GAT Government Acceptance Test
GEL Government Equipment List
GPRA Government Performance and Results Act
GSS General Support System
IA&E Infrastructure Architecture & Engineering
IBM International Business Machines
ICD Interface Control Document
IDSS Investment Decision Support Services
IOC Initial Operational Capability
IPM Integrated Process Management
IRAP Information Resources Accessibility Program
IRM Internal Revenue Manual
IRS Internal Revenue Service
ISA Interconnection Security Agreement
ISAT Independent Systems Acceptability Testing
ISCP Information Systems Contingency Plan
IT Information Technology
IT&E Integration, Test and Evaluation
ITMRA Information Technology Management Reform Act
ITRAC Item Tracking System
ITSM IT Service Management
ITS Information Technology Services
KISAM Knowledge Incident/Problem Service Assess Management
KPI Key Performance Indicator
LAN Local Area Network
LCSR Life Cycle Status Review
LL Lessons Learned
MER Milestone Exit Review
MOA Memorandum of Agreement
MITS Modernization & Information Technology Services
MRR Milestone Readiness Review
MS Milestone
NIST National Institute of Standards and Technology
O&M Operations and Maintenance
OC Organizational Change
OMB Office of Management and Budget
PAL Process Asset Library
PD Process Description
PES Product Evaluation and Selection
PGO Program Governance Office
PIA Privacy Impact Assessment
PL Public Law
PM Project Manager
PMI Project Management Institute
PMO Program Management Office
PMP Project Management Plan
POs Process Owner(s)
PTP Project Tailoring Plan
PPM Program Performance Management
PR Procedure
QA Quality Assurance
QMP Quality Management Plan
RADM Requirements and Demand Management
RCS Records Control Schedule
RFP Request for Proposal
RFSS Request for Service Solution
RIM Records and Information Management
RM Risk Management
RMA Records Management Application
RMP Risk Management Plan
RP Requirements Plan
RUP Rational Unified Process
SA&A Security Assessment & Authorization
SAE Security Architecture & Engineering
SAR Security Assessment Report
SAT Systems Acceptability Testing
SBU Sensitive But Unclassified
SCA Security Control Assessment
SCP Strategy and Capital Planning
SDLC Software Development Life Cycle
SDP System Deployment Plan
SIA Security Impact Assessment
SDSR Simplified Design Specification Report
SIT System Integration Test
SME Subject Matter Expert
SP Security Package
SSP System Security Plan
STP System Test Plan
TD Treasury Directive
TIGTA Treasury Inspector General for Tax Administration
TM Transition Management
TMP Transition Management Plan
TMO Transition Management Office
TSS Test Support Section
USC United States Code
USI User System Interface
UWR Unified Work Request
V&S Vision and Strategy
WBS Work Breakdown Structure
WR Work Request
WRMS Work Request Management System

Exhibit 2.16.1-2 
Definitions

(1) The following table lists and defines terms used in this manual.

Term Definition
17% Rule A rule that 1) is promoted by the ELC Office and 2) states, “more than 17% change to a system is considered a significant impact to the project that the project does not qualify to use the Planned Maintenance Path”.
Acquisition The process of obtaining products or services through contractual agreements with outside vendors or contractors.
Agile Development Specific group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Agile promotes development, teamwork, collaboration, and process adaptability throughout the life-cycle of the project. Agile represents a type of development methodology that can be used when following the Iterative path.
Allocated Baseline Contains requirements that have been refined and/or derived from system-level requirements, requirements allocated to specific software, hardware, or interfaces from a CS or higher-level CI, as well as additional design constraints.
Application An IT component of a system that utilizes IT resources to store, process, retrieve or transmit data or information using IT hardware and software.
Application Software (Also, "Application" ). Computer software that supports the conduct of business (as opposed to "system software," which supports operation of the computers and infrastructure).
Architecture A unifying overall design or structure that divides a system into its component parts and relationships and provides the principles, constraints, and standards that help align development efforts in a common direction.
Artifact The tangible result (output) of an activity or task performed by a project during the life cycle.
Build 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.
Burn Down Chart A graphical representation of the work left to do in a given project versus time. The outstanding work (or functionality backlog) is typically on the vertical axis, with time along the horizontal. Over time, the project team plots the number of features/requirements in the functionality backlog. Burn down charts are effective tools for communicating progress and predicting when work will be completed. The burn down chart is also an effective means for teams to make adjustments in order to meet product/project delivery expectations.
Business Analyst Serves as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems.
Business Case A formal justification for a project or program that outlines the associated benefits, costs, risks, and alignment with strategic objectives, and that is used to help determine whether or not the effort should be funded.
Business Change A lasting revision to the nature or structure of an organization or the manner in which the organization conducts business. This may include change in the business processes, in the organization structure, in the locations for doing business, and/or in the technology, data, and computer applications used.
Business Change Initiative An organized effort (e.g., programs or projects) to accomplish business change and/or implement information systems.
Business Owner The individual from the business ultimately accountable for success of the system (e.g., defining and prioritizing product requirements, ensuring business process change if needed). The Business Owner sets the vision and direction of the product. Since the Iterative path involves frequent change, the Business Owner must be available to answer questions regarding the direction or vision of the Product. The Business Owner also:
  • Ensures the right features are included in the project

  • Obtains resources from and reports to the Executives

  • Removes obstacles impeding progress

Business Process What the enterprise must do to conduct its business successfully. A business process comprises actions taken to respond to particular events and produce particular results, and may cross multiple business functions or organizations.
Business Risk The risk that the business or organization may be harmed in some way.
Business Rules "A directive that is intended to influence or guide business behavior. Such directives exist in support of business policy, which is formalized in response to risks, threats, or opportunities" . This definition is from the publication," Organizing Business Plans: The Standard Model for Business Rule Motivation, Revision 1, Nov. 2000" prepared by the Business Rules Group.
Business Sponsor The highest business executive sponsoring the system, which may be the business PMO Director, Deputy Commissioner or the Executive Steering Committee.
Capability Maturity Model® Integration (CMMI) Used to judge the maturity of an organization’s processes and related procedures and process assets and can be used to plan further improvements. CMMI sets the standard for the essential elements of effective and mature processes, improved with quality and efficiency.
Capital Planning and Investment Control CPIC 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.
Certification A technical evaluation process resulting in a judgment stating whether a particular information system design or implementation (e.g., computer system, application or network design, and implementation) meets a pre-specified set of security requirements.
Clinger-Cohen Act Legislation that requires government agencies to integrate their IT investment plans into the budget process. Clinger-Cohen specifies requirements to identify and adopt best practices for IT management (including commercial sector practices); to identify quantitative measurements for net benefits and risk; to manage projects according to defined milestones; and to baseline, benchmark, and revise business processes before making significant IT investments. Also known as the Information Technology Management Reform Act of 1996.
Commercial-Off-the-Shelf Solution Pre-packaged computer software for a particular purpose or application developed by a vendor for same to numerous companies and organizations or a standard technical infrastructure component.
Completed Solution A solution for which all releases are operational.
Conditional Exit An MRR result provided to a project when there are critical action items, issues, risk, or impediments (e.g., pending test results or unapproved PO artifacts(s)) that are unresolved.
Configuration Item An aggregation of hardware, software, and documentation that is treated as a single entity in the CM process, satisfies an end use function, and is specifically designated as a CI.
Configuration Management A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.
Configuration Management Baseline An agreed upon description of the attributes (i.e., functional and physical characteristics) of a product at a point in time that serves as a basis for defining change.
Contractor An organization external to the IRS that supplies goods and services according to a formal contract or Task Order. A contractor is a type of provider.
COTS Path One of the five paths of the ELC. The COTS Path specifies a development approach based on the purchase and use of pre- packaged software.
Customer Technical Review Review performed by the project with IRS stakeholders on a work product or small group of closely related work products produced by a project. The purpose is to facilitate approval of the work product by ensuring early stakeholder feedback as well as early identification and resolution of issues and actions.
Daily Scrum The Daily Scrum, also referred to as ’the daily stand-up’ in Agile world is a brief, daily communication and planning forum, in which Agile/Scrum teams come together to evaluate the health and progress of the sprint. As a daily, team planning meeting, an effective daily scrum should be a tightly focused and time boxed meeting that occurs at the same time and place, on a daily basis. The intent of the daily scrum is to better understand the progress of the sprint, by all contributing team members honestly answering the following three questions: what have you done since the last Daily Scrum; what will you do between now and the next Daily Scrum; and what got in your way of doing your work?
Data Item Description A DID outlines standard content and presentation format for major artifacts (reports, plans, documentation, etc.) generated during the life cycle.
Defect Backlog Typically specifies only the defects identified in sprints.
Degree of Difficulty A subjective measure of how easy or hard it is likely to be to execute a project or portions of the life cycle.
Deliverable An artifact produced by a project that is identified in the applicable contract or task order as an item that must be turned over to and formally accepted by the IRS.
Detailed Design Phase The Detailed Design Phase includes the portion of the life cycle between Milestones 3 and 4A, and includes physical solution design.
Development Path A distinct approach to tailoring and performing the Preliminary Design, Detailed Design, System Development, and System Deployment Phases of the life cycle for a project or solution component.
Development Project A project initiated after Milestone 0 to design, develop, and implement solutions in support of the enterprise vision and architecture (if any).
Disposition The shipping of records to an agency storage facility or to a Federal Records Center (FRC) for storage.
Domain Architecture Phase The Domain Architecture Phase includes the portion of the life cycle between Milestones 1 and 2, and includes development of a business system concept, business system requirements, and business system architecture.
Directive Centralizes and establishes the essential practices for effective project management. Directives contain guidance for planning, measuring, and performing project management to foster an environment where good practices are employed.
Drop 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. Note, for the Iterative Path, a drop can be developed in one or more sprints.
End of Iteration Checkpoint This is done instead of a CTR or LCSR when using the Iterative Path.
End of Sprint Checkpoint Review The sprint review is an important communication forum that occurs at the end of a sprint. During the sprint review an agile team will evaluate and agree on which stories have been completed and which stories need to be deferred or split. The sprint review is an event that generally ignites the closing of a sprint. Often times, teams will also use the sprint review as a forum to demonstrate the work that was completed within the sprint.
End of Test Completion Report The End of Test Completion Report can be used by systems classified as New Development or Planned Maintenance. The report is an Enterprise Life Cycle (ELC) requirement. The purpose of the report is to provide a standard artifact to summarize the complete test effort for the release. The report gives the project an opportunity to mitigate risks that may cause delays to project implementation.
Enterprise A major organization with its own mission, goals, and performance objectives. An enterprise may be an independent company, a major division of a large company, a corporation, or a government agency. The typical enterprise includes a number of business areas.
Enterprise Architecture A unifying overall design or structure for an enterprise that includes business and organizational aspects of the enterprise as well as technical aspects. Enterprise Architecture divides the enterprise into its component parts and relationships, and provides the principles, constraints, and standards to help align business area development efforts in a common direction. An enterprise architecture ensures that subordinate architectures and business system components developed within particular business areas and multiple projects fit together into a consistent, integrated whole.
Enterprise Data Management Includes processes for defining and managing data throughout the life cycle.
Enterprise Integration, Test and Evaluation Includes processes for integrating multiple components of a solution and conducting various types and levels of testing that are over and above standard unit testing of individual solution components.
Enterprise Life Cycle The approach used by the IRS to manage and effect business change. The ELC provides the direction, processes, tools and assets for accomplishing business change in a repeatable and reliable manner.
Entry Criteria The elements and conditions (state) necessary to trigger the beginning of a process step.
ELC Framework A structure for organizing, understanding, and applying IRS process assets to manage and effect business change.
Enterprise Planning Project A project conducted during the Vision and Strategy/Enterprise Architecture Phase that addresses enterprise-level issues such as vision and strategy and/or enterprise architecture.
Exhibit 300 A document that contains project information and is submitted by the IRS in conformance with provisions of Exhibit 300 of the Office of Management and Budget Circular No. A-11, Part 7 to obtain funding approval for projects.
Exhibit 53 The proposed IRS IT Investment Portfolio that is submitted to request funds from OMB as part of the normal budgeting cycle. All projects requiring OMB funding are listed on the E53.
Exit Criteria The elements or conditions (state) necessary to trigger the completion of a process step.
Federal Enterprise Architecture The FEA Program, which builds a comprehensive business-driven blueprint of the entire Federal government. The FEA consists of a collection of interrelated “reference models” designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps, and opportunities for collaboration within and across Federal agencies.
Federal Records Act All Federal employees (and Federal contractors) are required by law to preserve records containing adequate and proper documentation of the organization, functions, policies, decisions, procedures, and essential transactions of the agency. Records must be properly stored and preserved, available for retrieval, and subject to appropriate approved disposition schedules. The Federal Records Act applies to e-mail records just as it does to records that are created using other media.
Final Integration Test A system test consisting of integrated end-to-end testing of mainline tax processing systems to verify that new releases of interrelated systems and hardware platforms can collectively support the IRS business functions allocated to them.
Framework A structure that facilitates understanding of a complex topic by breaking the topic into multiple pieces or features, classifying the features, illustrating relationships between the features, and organizing them in a manner that facilitates visualization and practical usage.
Functional Baseline Comprises the initial system-level requirements and system architecture describing a CS’s or CI’s functional, interoperability and interface characteristics.
Functional Equivalent An artifact that, although it does not have the same form or format as a standard ELC artifact, has the same general content, adequately serves the same purpose, and with approval may be used in lieu of the standard artifact.
Functionality Backlog The list of features and functionality people have requested for the system. The Business Owner and Project Manager are responsible for deciding which features are included or excluded from the system.
Governance The decision making authority over a project or program derived by a formal charter in accordance with the IRS Governance directive.
Government Acceptance Test A system test that allows the government to independently verify aspects of the functionality tested during system testing to determine the system’s fitness for implementation.
Government Performance and Results Act Legislation that aims to improve performance of government programs by implementing results-oriented management. GPRA directs government agencies to prepare strategic plans, prepare annual performance plans, monitor performance, and report annually on results.
High Performance Team A team of people using specialized methods, processes, procedures, tools and work environment to achieve extremely efficient system development or other endeavor.
Increment A subset of the logical design that independently undergoes physical design and development but is not deployed.
Independent Systems Acceptability Testing A test for software functionality and is done independent of the developer of the software. It is conducted to validate core and specific functions within a system satisfy requirements and confirm that changes work correctly when receiving data from and sending data to external systems.
Information Technology Infrastructure Library (ITIL) Contains a collection of best practices, enabling organizations to build an efficient framework for delivering IT Service Management (ITSM) and ensuring that they are meeting business goals and delivering benefits that facilitate business change, transformation, and growth.
Initiative An organized effort over an extended period of time to accomplish a major objective.
Issue A known event that may impact project goals.
Issue and Action Item Management The process of identifying, tracking, reporting, and resolving project and/or program-related issues and actions to be completed.
IT Investment An organizational investment employing or producing IT or IT- related assets. Each investment has or will incur costs for the investment, has expected or realized benefits arising from the in- vestment, has a schedule of project activities and deadlines, and has or will incur risks associated with engaging in the investment.
IT Process Asset Library (IT-PAL) The authoritative repository for IT Assets. The IT PAL stores process and procedure assets and Best Practice Examples that are potentially useful to those who are defining, implementing and managing processes.
IT Service Management (ITSM) An industry standard model for managing technology support services, based on the Information Technology Infrastructure Library (ITIL), a collection of books describing service management and best practices.
Item Tracking Reporting and Control (ITRAC) System used to track and report on issues, risks, and action items.
Iteration See IRS preferred term: Sprint.
Iterative Path New ELC software development methodology at the IRS. The Iterative ELC path combines Milestones 1 and 2 into a single MS 2 exit; Milestones 3, 4A, and 4B into a single MS 4B exit; and retains the standard MS 5 exit. Specific details about Iterative path can be found in IRM 2.16.1 or on the ELC Office website.
Joint Application Design An approach to rapidly producing solution requirements and/or high- level design using time-boxed work sessions involving all key stakeholders.
Life Cycle A repeatable sequence that identifies all of the work required to accomplish an initiative, and partitions the work into a series of coherent segments that lead sequentially from inception to culmination. The life cycle provides a standard for what work needs to be done but does not prescribe how to do or manage the work.
Life Cycle Analysis An analysis of which portions of a project’s life cycle are likely to be high difficulty and which are likely to be low difficulty.
Life Cycle Status Review Performed by the project with 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.
Maintenance The process of making fixes, enhancements, and upgrades to op- erational systems, either on a planned or emergency Managed Services basis.
Major Project A project meeting the criteria established by OMB for major projects.
Managed Services Path One of the six paths of the ELC. The Path is designed to capitalize on the benefits of Managed Services provided by either an outside services (3rd party); internal intra-business processes; and/or existing infrastructure (operational) service providers.
Methodology A standard, repeatable set of practices, procedures, and templates for accomplishing a specific type of endeavor (e.g., business change).
Milestone Milestones usually occur at the end of a life cycle phase, and provide natural breakpoints at which new information regarding costs, benefits, and risks may be evaluated. Milestones also serve as executive management decision points at which IRS executives make go/no-go decisions for continuation of a project. Project funding decisions are often associated with milestones. 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.
Milestone Exit Review Project review performed by IRS executives when a project has completed a life cycle phase to determine if the project will be allowed to continue on to the next phase and, if necessary, to approve the required funding.
Milestone Readiness Review A review to determine whether or not a project has satisfied the exit conditions for the next Milestone Exit Review. An MRR results in a formal go/no go recommendation to the Governance Board, (i.e., Executive Steering Committee (ESC)).
Mobile Path A modified life cycle approach that is designed only for mobile applications and is comprised of substantially pre-approved technology components, data usage, and development tools. The criteria for use of the mobile path is that a project has a narrowly defined project scope with a short project delivery schedule with limited estimated risk and user impact.
Modernization Modernization is the process of updating, improving, and bringing in line with modern standards. Modernization is an IRS program that includes Organization Modernization and Business System Modernization (processes and technology).
Mitigation Plan Plan that documents how and when a condition, risk, issue, and/or action item will be resolved.
New Development Release A project release that addresses development of new functionality assigned during the Domain Architecture Stage.
Non-Major Project A project that meets OMB criteria for non-major projects.
OMB Compliance Consists of OMB vehicles or other documentation required to comply with OMB reporting requirements.
Operations The ongoing operation of an information systems solution as part of ongoing business, including daily production, call center or help desk assistance, disaster recovery, and service-level agreements (SLAs).
Operations and Maintenance Phase The Operations and Maintenance Phase includes the portion of the life cycle subsequent to Milestone 5 and concluding with retirement of the solution.
Organizational Change (OC) A disciplined process for defining the future organizational characteristics required to enable the intended business results and for supporting stakeholders in their transition to and realization of that organizational future state.
Oversight IRS management of project work conducted by outside contractors to assure that IRS needs and contractual terms are met. Also, monitoring or governance of IRS projects by organizations outside the IRS.
Partial Solution A solution for which all planned releases are not operational.
Path Embodies a specific technical or system engineering approach for performing the work.
Phase Phases divide the life cycle into portions that represent work of varying nature (e.g., visioning vs. conceptual design vs. logical design vs. physical design vs. coding and testing vs. deployment vs. operations, etc.).
Planned Maintenance Path One of the paths of the ELC. Maintenance may address numerous system changes concurrently under the auspices of a project that is planned in advance, and simultaneously implements all of the changes as a new version (or release) of the system.
Procedure A written description of a course of action to be taken to perform a given task.
Process A set of interrelated activities, which transform inputs into outputs, to achieve a given purpose.
Process Asset An aid (e.g., directive, process, procedure, standard, template, example, methodology, etc.) that provides guidance, support, direction, or assistance in the execution of work to be performed.
Process Asset Library An on-line repository containing IRS process assets.
Process Description Describes “what” happens within a set of interrelated activities and provides an operational definition of the major components of the process.
Process Owner The owner of an ELC requirement that reviews project and process document(s) and/or artifact(s) to ensure the project meets requirements and guidelines for their process areas.
Product Backlog The product backlog is a repository for high level requirements with high level estimates provided by the product stakeholders. It is typically owned and managed by the product owner who reviews it on a regular cadence to ensure that the development unit is focusing on the completion of those items that represent the highest impact on the overall product value.
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 them- selves (i.e., software, hardware, listings, and schematics).
Product Owner A business representative who:
  • Leads the development effort by communicating product vision in Product Backlog

  • Ensures the right features are included in the product backlog

  • Prioritizes features in the Product Backlog based on business value

  • Assists Scrum teams with product, scope, and timing questions

  • Assists in removing obstacles that impede progress

  • Works with stakeholders and leaders to ensure all product interests are reflected in the product backlog

  • Is available to the development teams to answer questions and provide direction

  • Validates and provides feedback on product development during each iterative cycle

Program A group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually.
Program Management Program Management involves planning, directing, con- trolling, and administering activities throughout the life cycle of the program. This does not include management of individual projects, but focuses on the coordination between individual projects as well as guidance and direction for aspects common to all projects.
Project A group of tasks to accomplish a specific objective, with a beginning and ending date, that is planned, monitored, and measured, follows a life cycle process, and results in deliverables or end products.
Project Asset An artifact that a project has produced.
Project Charter It is a requirement for all new IRS projects. A Project Charter provides the formal objectives, mandates, and scope for a project and specifies (from the Enterprise Architecture) the business processes, key stakeholders, locations, requirements, systems, interfaces, tools, standards, and target releases to be dealt with by the project.
Project Kickoff Meeting Minutes Conducted during the Project Initiation Phase, ensures that the leadership and stakeholders are in agreement with the scope, objectives and business capabilities of the project.
Project Initiation Phase The Project Initiation Phase includes the portion of the life cycle between Milestones 0 and 1.
Project Life Cycle The sequence of work performed by a project from inception to completion. The project life cycle begins when the project is chartered and concludes when the portion of the system being addressed has been deployed.
Project Management Project management involves planning, directing, con- trolling, and administering discrete projects throughout their life cycle.
Project Management Institute (PMI) Organization that advances the project management profession through globally recognized standards and certifications.
Project Manager Responsible for ensuring the project is progressing properly. The Project Manager also:
  • Ensures team members have the information and tools necessary to complete their work

  • Organizes meetings

  • Facilitates release planning

  • Monitors work being done

Project Risk The risk that the project will not complete on schedule or within budget.
Project Tailoring Plan Adapts the ELC Framework to the unique and specific needs of the individual project or release. This tailoring includes selection and modification of the following ELC components to be commensurate with the scope and risk of the project: project life cycle (including phases and milestones), life cycle path(s), major types of activities, work products/deliverables, data item descriptions, customer technical reviews, life cycle status reviews and scope of management.
Proof-of-Technical-Concept Prototype A short and/or incomplete realization (or synopsis) of a certain method or idea(s) to demonstrate its feasibility, or a demonstration in principle.
Prototyping Prototyping is the process of quickly putting together a working model (a prototype) in order to test various aspects of a design, illustrate ideas or features and gather early user feedback. Prototyping is often treated as an integral part of the system design process.
Provider The organization responsible for development of a solution. May be an internal IRS organization or a contractor.
Quality Management The process of monitoring and assessing project and program processes and artifacts to assure that they meet accepted standards for high quality.
Raines Rules OMB's implementation of the provisions of the Clinger-Cohen Act. Raines Rules establish decision criteria that should be used when evaluating investments in major information systems. Included are requirements to use commercial software wherever possible as opposed to custom developing solutions; to implement small projects that provide incremental benefit; to pilot, prototype and simulate solutions prior to full scale implementation; and to be consistent with Federal, agency, and bureau information architectures.
Rapid Application Development A highly accelerated approach to system development characterized by small, joint teams of users and technical personnel who work together to discover solution requirements and design and to develop a workable solution via prototyping conducted in a strict timeframe.
Rational Unified Process A proprietary system development methodology of IBM often used for object-oriented design.
Readiness Test Readiness tests determine that the system is ready to be deployed to users for the conduct of live business.
Records and Information Management A program office which fully support the IRS mission and programs by promoting current information, guidance, and awareness of the importance of managing records throughout the IRS.
Records Control Schedule A document providing mandatory instructions for what to do with records (and nonrecord materials) no longer needed for current Government business, with provision of authority for the final disposition of recurring or nonrecurring records.
Records Management Application The form used by Federal agencies (SF-115) to obtain disposition authority from NARA for records for which the General Records Schedules are inapplicable.
Re-engineering Radical redesign of process from scratch to support aggressive performance objectives.
Release A release is any solution that is deployed into a production environment. A release requires governance board approval prior to deployment.
Release Backlog The Release Backlog is a subset of Product Backlog. Requirements are pulled from the product backlog and identified and prioritized for an upcoming release. The release backlog contains more details about the requirement and low level estimate which are usually estimated by the team performing the work.
Requirement A verifiable statement of a capability or condition that a system must have or meet to satisfy a contract, standard, or other formally imposed specification.
Requirements Analyst See IRS preferred term: Business Analyst.
Requirements Engineering Requirements Engineering provides guidance on how to capture, refine, verify, validate, and trace requirements throughout the life cycle. Also provides guidance on how to identify and capture business rules, how to associate rules with business requirements and how to manage rules throughout the life cycle.
Reuse Taking advantage of existing assets instead of developing new ones from scratch.
Risk An uncertain event or condition that, if it occurs, has a negative effect on the project.
Risk Management (RM) The process of identifying, monitoring, and mitigating project and program risks.
Scrum Scrum is a incremental and iterative software development framework, and is arguably one of the most commonly used agile methods. Scrum outlines a process framework in which Product Owners and Team Members, all work together collaboratively to define product and sprint backlogs that are executed in short, time-boxed iterations that are called sprints. At the end of each sprint, a working increment of the software is delivered/demonstrated to the product owner and the entire process repeats itself.
Scrum Master Facilitates the Sprint Planning meeting, Daily Scrum meeting, End of Sprint Checkpoint Review meeting, and Sprint Reflection meeting.  Responsible for removing obstacles brought up by the team during the Sprint. The Scrum Master’s key role is to protect the team from distracting influences and keep them focused on the tasks. The Scrum Master should have in depth knowledge of the Iterative software development lifecycle utilized by the project and possess essential soft skills including moderation, facilitation, conflict resolution and communication.  The Scrum Master reviews the lessons learned from each Sprint and continually takes steps to improve the Iterative process to fit the needs of the Sprint team and project. The PM will serve as the Scrum Master, as appropriate.
Security and Privacy Security protects information and assets. Privacy protects rights of individuals to control collection, use, retention, and disclosure of their personal information. Security helps protect privacy. Privacy protection helps to select appropriate security.
Security Control Assessment A readiness test consisting of activities designed to ensure that the system’s security safeguards are in place and functioning as intended.
Security Package Determines whether or not the system, as installed at the target site, meets a pre-specified set of security requirements and to obtain official management authorization for the system to process sensitive by unclassified data in an operational environment.
Service Management Service Management involves planning, directing, con- trolling, and administering the support of a solution from the time it is delivered until the time it is retired. This includes management of service operations (e.g., operating and maintaining the technical infrastructure and automated solutions), maintenance and enhancement of the solution, and providing related services to users of the solution (e.g., help desk).
Simulation Prototype A temporary representation that mimics the functioning of a system but does not access real data or perform real work. May be constructed in software or on paper.
Solution A set of project assets which, when taken together, satisfy the goals of the initiative.
Solution Component A part of the overall solution that is developed separately and then integrated into the overall solution.
Solution Risk The risk of producing an inappropriate, inadequate, or poorly functioning solution.
Solution State The degree of development to which the solution has evolved.
Specialty Area A subject area of importance that has its own subordinate life cycle and requires heightened emphasis in the manner it is addressed during the life cycle of a project.
Spiral Development A method of system development characterized by a try and see approach that iteratively hones in on the final solution via successive rounds of requirements discovery, design and development.
Sprint Between MS 2 and MS 4B, projects will run through a series of "Sprints," either sequentially or even in parallel, within each release. The goal of each sprint is to get a subset of the project's functionality to a "production-ready" state. At the end of the sprint the functionality developed will be fully tested (although it will not be put into production until a MS 4B exit is achieved for the full release). Each project (or each release, for large projects) will include sprints of between 2 weeks and 4 months, typically 4-6 weeks.
Sprint Backlog The Sprint Backlog contains requirements/sub-requirements that the team anticipates completing at the end of the sprint. These are the items that the team will "Burn Down" against throughout the duration of the sprint.
Sprint Planning Task at the beginning of each Sprint to size and pick which Sprint Backlog items can make that Sprint.
Sprint Reflection At the end of each Sprint the team gets together to reflect on the last Sprint. What went well, what can be improved, changes to next Sprint?
Stakeholders A group of individuals that is affected by, or in some way is accountable for, the outcome and undertaking. Stakeholders may include project members, suppliers, customers, end users, and others.
Story points A unit of functionality within a use case (or user story). Each use case would include multiple story points. These story points are typically used for time and cost estimating purposes by the development team. The size/scope of a typical story point is typically defined by the project team itself (which makes it a bad idea to compare story points across project teams).
Subject Matter Expert A Subject Matter Expert is a skilled authority that represents the various process areas (e.g., Configuration Management expert, Requirements and Demand Management expert, IRAP expert, ELC expert) whom should be invited to the project kickoff meeting.
Sub-release A subset of the logical design that independently undergoes physical design and development and is then integrated and deployed.
System A set of interdependent components that perform a specific function and are operational. IT systems may also include software, hardware, and processes.
Systems Acceptability Testing Testing conducted to verify a system satisfies application requirements.
System Deployment Phase The System Deployment Phase includes the portion of the life cycle between Milestones 4B and 5, and includes deployment of the solution to all users at all target sites. This is the last phase a project will usually perform.
System Deployment Plan The System Deployment Plan can be used by systems classified as New Development or Planned Maintenance. The plan is an Enterprise Life Cycle (ELC) requirement. The purpose of the plan is to provide a standard artifact to summarize the planned deployment activities for the release. The plan gives the project an opportunity to mitigate risks that may cause delays to project implementation.
System Development Phase The System Development Phase includes the portion of the life cycle between Milestones 4A and 4B, and includes programming, integration and testing the solution.
System Integration Test A system test conducted to verify that the system is integrated properly and functions as required.
System Life Cycle The sequence of work spanning the lifetime of a system. The life cycle of a system begins when the problem or desired change is first conceptualized and ends when the system produced is retired from active use. Note that this includes not only development and implementation of the solution but also the entire period during which the solution is in operation.
System Test A test that determines the complete integrated solution works as intended. Includes SIT, SAT, GAT, and FIT.
System Test Plan The System Test Plan can be used by systems classified as New Development or Planned Maintenance. The plan is an Enterprise Life Cycle (ELC) requirement. The purpose of the plan is to provide a standard artifact to summarize the complete test effort for the release. The plan gives the project an opportunity to mitigate risks that may cause delays to project implementation.
Tailoring Modification of a standard approach to customize it for a specific situation. For example, ELC tailoring is modification of the standard ELC for the unique needs of a specific project.
Technical Infrastructure The hardware, system software, networks, and communication mechanisms that constitute the underlying technology for a system.
Termination/Retirement 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.
Tool Job aid for a specific purpose, e.g., Checklist, template, application.
Transition Preparation of all resources, including personnel and facilities, needed to operate and use the solution, plus the actual transfer of responsibility and physical transfer of solution components to the organizations where they will reside.
Transition Management Transition Management specifies how to plan and execute effective solution transition at each phase of the life cycle so that targeted personnel and organizations are prepared to receive, use, operate, and maintain the business processes and technology provided by a project.
Unconditional Exit When all critical action items, issues, risks, or impediments have been resolved (e.g., all pending test results) and ELC required PO artifacts have been approved.
Unified Work Request (UWR) The UWR process initiative is to provide a single system to request products and services from the IRS MITS organization, except for those services that are requested through OS GetIT services.
Unit Test 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.
Use case A use case is a document that attempts to describes system behavior from an end-user’s perspective, by outlining the flow of data, system behavioral interchanges and corresponding end-user interactions in a sequential, step-by-step manner. In other words, a use case describes ″″who″″ can do ″″what″″ with the system in question and it should vary in detail based on the needs of the requirements. Uses cases often make use of the following artifacts to describe how a system should work: Goal - What is end goal and desired effect of the functionality that the use case is attempting to describe. Summary - A brief, high-level and easily understood description of the use case. Actors - The consumers of the system that will be interacting with the system within the scope of the use cases. Actors can be people or other systems or services. Preconditions - System conditions and assumptions that must be true for the use case to be valid. Triggers - The specific events required to initiate the use case. Body Text - The description of each of the steps involved/required to complete the use case. Generally, body text will focus only the main (happy) path. Alternative Path - Steps that deviate from the main path due to exceptions, alternative logic or other conditional events. Post Conditions - The changes in the system and data as a result of executing steps outlined in the use case.
User Story User Stories are simple, brief and concise statements in a more conversational tone, used to describe “raw” user need. It’s something that the user needs to do in his day-to-day job. If you never build any software for him, then that need will still exist! It’s something that anyone can understand, in the language of the users. Recommended formats for users stories are as follows: Short format: As a (User Role), I would like (Statement of need). Long format: As a (User Role), I would like (Statement of need), so that I can (desired benefit) Example: As a Business User, I would like an Agile Lexicon, so that I can understand the meanings of words that I hear in daily meeting.
Velocity A measure of productivity calculated by counting the number of units of work completed in a certain interval. The number of units are defined at the outset of the project based on the project characteristics, but would typically be any of: features, requirements, story points, use cases, hours, or days. The length of an interval is also determined up front and can be weekly, bi-weekly, monthly, or the length of the sprint.
Vision and Strategy/Enterprise Architecture Phase The Vision and Strategy/Enterprise Architecture Phase includes the portion of the life cycle leading up to Milestone 1, and includes development of the enterprise vision and strategy, Enterprise Architecture, and transformation strategy.
Waterfall Approach A rigorous method for system development characterized by serial performance of work with frequent breakpoints at which the solution must be formally approved prior to any additional work being performed.
Waterfall Path One of the six paths of the ELC. The Waterfall Path is based on the sequential development method typical of a waterfall approach.


More Internal Revenue Manual