LMM Tailoring Plan Template€¦ · Web viewBusiness Impact Analysis (BIA), including Appendix A...

LMM Tailoring Plan Template[Lifecycle Management Methodology – Appendix C]

Version 2.1 ● 7/17/2019

FINAL

LMM Tailoring Plan Template Document Version Control

Document Version Control

VERSION DATE AUTHOR DESCRIPTION

2.0 - Draft 12/01/2017 LMM Tailoring Plan and Process Workgroup / LMM Improvement Initiative

Re-write of LMM Tailoring Plan from MS Excel Format to MS Word format. Modified tailoring plan to approach LMM Tailoring from an information system view. Complete re-write of document from previous version.

2.0 – Final 5/22/2018 LMM Tailoring Plan and Process Workgroup / LMM Improvement Initiative

Updated cover page to reflect Appendix C reference to link the Tailoring Plan Template to the Process Document.

2.1 7/17/2019 LMM Operations Team Minor updates based on feedback from subject matter experts and experience after first year under the 2.0 LMM.

Updates to several security and privacy document descriptions / guidance items.

Removed User Interface Specification document from requirements section. FSA SMEs no longer maintaining this as a template.

Added four test plan documents (Phase Level Test Plan, Hardware Test Plan, System Test Plan, and UAT Test Plan).

Acronym updates.

[When using this template, modify the cover page to identify the information system covered by the tailoring plan, include a version number for that system’s tailoring plan (first final version for a system should be 1.0), and include the date of the tailoring plan. Modify the document version control (above) to reflect the tailoring plan for the specific information system rather than the tailoring plan template. Delete this block of blue guidance text after the cover page and version control items have been completed.]

Version: 2.1 ii 7/17/2019

LMM Tailoring Plan Template Table of Contents

Table of ContentsSECTION 1. INTRODUCTION........................................................................................................................................1

1.1. PURPOSE..............................................................................................................................................................11.2. SCOPE.................................................................................................................................................................. 11.3. INTENDED AUDIENCE.............................................................................................................................................11.4. REFERENCE DOCUMENTS......................................................................................................................................2

SECTION 2. SYSTEM SPECIFIC INFORMATION.........................................................................................................3

2.1. RELEASE MANAGEMENT PRACTICES.......................................................................................................................32.2. RELEASE DEFINITIONS...........................................................................................................................................3

2.2.1. Major....................................................................................................................................................... 32.2.2. Minor....................................................................................................................................................... 42.2.3. Patch....................................................................................................................................................... 4

2.3. ARTIFACT/DOCUMENT STORAGE............................................................................................................................5

SECTION 3. PROGRAM/PROJECT MONITORING......................................................................................................6

3.1. PROGRAM/PROJECT MONITORING DOCUMENT GUIDANCE.......................................................................................63.2. PROGRAM/PROJECT MONITORING DOCUMENT TAILORING.......................................................................................6

SECTION 4. SECURITY AND PRIVACY........................................................................................................................7

4.1. SECURITY AND PRIVACY DOCUMENT GUIDANCE.....................................................................................................74.2. SECURITY AND PRIVACY DOCUMENT TAILORING...................................................................................................10

SECTION 5. REQUIREMENTS.....................................................................................................................................11

5.1. REQUIREMENTS DOCUMENT GUIDANCE................................................................................................................115.2. REQUIREMENTS DOCUMENT TAILORING................................................................................................................115.3. REQUIREMENTS REVIEW STAGE GATE.................................................................................................................11

SECTION 6. DESIGN AND DEVELOPMENT...............................................................................................................13

6.1. DESIGN AND DEVELOPMENT DOCUMENT GUIDANCE..............................................................................................136.2. DESIGN AND DEVELOPMENT DOCUMENT TAILORING..............................................................................................136.3. TECHNICAL DESIGN REVIEW - TECHNICAL STAGE GATE........................................................................................13

SECTION 7. TESTING.................................................................................................................................................. 14

7.1. TESTING DOCUMENT GUIDANCE...........................................................................................................................147.2. TESTING DOCUMENT TAILORING...........................................................................................................................147.3. TEST READINESS REVIEW (TRR) STAGE GATE....................................................................................................15

SECTION 8. IMPLEMENTATION.................................................................................................................................16

8.1. IMPLEMENTATION DOCUMENT GUIDANCE..............................................................................................................168.2. IMPLEMENTATION DOCUMENT TAILORING..............................................................................................................168.3. PRODUCTION READINESS REVIEW (PRR) STAGE GATE........................................................................................16

SECTION 9. RETIREMENT AND DISPOSAL..............................................................................................................17

9.1. RETIREMENT AND DISPOSAL GUIDANCE................................................................................................................179.2. RETIREMENT AND DISPOSAL DOCUMENT TAILORING.............................................................................................179.3. RETIREMENT AND DISPOSAL REVIEW STAGE GATE...............................................................................................17

APPENDIX A - ACRONYMS AND ABBREVIATIONS...............................................................................................A-1

APPENDIX B - GLOSSARY.......................................................................................................................................B-1

List of TablesTable 1-1: Intended Audience.........................................................................................................................................1Table 1-2: Reference Documents....................................................................................................................................2Table 2-1: Types of Work................................................................................................................................................ 4Table 2-2: LMM Artifact Storage Locations.....................................................................................................................5

Version: 2.1 7/17/2019

LMM Tailoring Plan Template Table of Contents

Version: 2.1 7/17/2019

LMM Tailoring Plan Template Introduction

Section 1. Introduction1.1. Purpose The purpose of this Lifecycle Management Methodology (LMM) Tailoring Plan document is to describe how the [System Name] uses LMM artifacts and stage gates to support the specific system development lifecycle (SDLC) approach for the system; existing or new. This tailoring plan is intended to be used in conjunction with the Lifecycle Management Methodology (LMM Process Document) as well as guidance information, templates, exemplars, and subject matter expert information available on Federal Student Aid’s (FSA) LMM Library site at https://fsa.share.ed.gov/LMM.

The LMM Tailoring Plan should be completed prior to completing the Information Resource Program Elements (IRPE) checklist in order to plan deliverables for acquisitions and determine the appropriate statements to include in the acquisition document. Both the LMM and IRPE are completed ahead of an acquisition so that the resulting information can be used to inform and create the Acquisition Package (including the Performance Work Statement and other supporting documents).

Investment Management for this information system is addressed in the [investment request name(s)] investment requests and the [business case name] business case. Management Stage Gates and other program and project management activities must be completed prior to scheduling requirements (scope) into a release. Investment Management and Oversight of the system (capital asset) is managed through the investment request and business case processes. The relationship between the investment management and program and project management processes are discussed in the Lifecycle Management Methodology (LMM Process Document). Although these artifacts are not addressed in the LMM Tailoring Plan, they can be modified or combined to leverage existing business unit processes. More detailed guidance on investment, program and project management artifacts is available from the FSA Performance Management Organization.

1.2. ScopeThis tailoring plan covers [System Name] and associated components of the system. The contents of the tailoring plan only include those items that are permitted to be modified (tailored) per the Lifecycle Management Methodology (LMM Process Document). This plan provides guidance for applying the LMM to new system development, system enhancements or maintenance releases that may be undertaken.

1.3. Intended AudienceThe table below lists the intended users and the purpose for which they may utilize the information in this document:

USERS USES System Owners Communicate to the FSA organization how the LMM is tailored for a

particular information system.System Support Personnel To understand document expectations for system and releases of the

system.Project Managers To understand document expectations of the FSA organization for projects

undertaken to enhance a system.Contract Officer / Contract Specialist

To understand document expectations of the FSA organization as applied to a particular information system acquisition.

LMM Operations Team To understand how the system will address various federal requirements and documentation needs.

LMM Stage Gate Owners To understand how the system will address the LMM stage gates.External Review/Audit Entities To understand FSA’s plan for organizational level oversight of an

information system.Table 1-1: Intended Audience

Version: 2.1 7/17/2019

LMM Tailoring Plan Template Introduction

1.4. Reference DocumentsThe following documents provide either governance or guidance for use of this document.

DOCUMENT T ITLE

Lifecycle Management Methodology (LMM Process Document)Requirements Review Stage Gate Process GuideTechnical Design Review- Technical Stage Gate Process DescriptionEnterprise Test Management Standards (Test Readiness Review Stage Gate)Production Readiness Review (PRR) Process DescriptionSystem Retirement and Disposal GuideFSA Enterprise Change Management PlanInformation Resource Program Elements (IRPE)FSA Investment, Program, and Project Management Artifact Guidance

Table 1-2: Reference Documents

Version: 2.1 7/17/2019

LMM Tailoring Plan Template Retirement and Disposal

Section 2. System Specific Information[Provide a high-level overview of the system including a description of business functionality and the significant IT components that are used by the system. If a similar description exists in another document, please use it for this section.]

The Point of Contact for this tailoring plan is: [Name of individual responsible for maintaining the tailoring plan].

2.1. Release Management PracticesFSA’s Enterprise Change Management (ECM) Process operates at the FSA organizational level. ECM tracks and relates (links) both Organizational (business) Needs and information system releases (initial deployment, enhancements, maintenance releases, etc.). Within the ECM Process, Organizational Needs are tracked through Organizational Needs Requests (ONRs) and information system releases are communicated and tracked by Release Requests (RRs). For additional information on the mandatory ECM Process, refer to the Enterprise Change Management Plan. When planning releases, System Owners should include consideration of time/effort for entry and approval of the Organizational Needs Request(s) and Release Request(s) through the ECM Process.

[Please describe the Release Management practices used by the system at a high level. This description should be detailed enough to understand release construction and packaging but does not need to include detail on each step of the System Development Lifecycle (SDLC). The description must address the approach to incremental development that is used by the system. Generally, systems should plan to implement useful functionality, updates, and appropriate patching at least once every six months (more frequently is considered better). If the system maintains this information in another document, please provide a high-level description here and reference the other document.]

2.2. Release Definitions

2.2.1. Major[Describe the types of changes that constitute a major release for the system. To the extent feasible, please quantify changes with metrics that the system can produce on a reliable basis. In addition, please address system component changes that would trigger a major release (for example, in some cases an upgrade of an important COTS product could trigger a system to classify the release as major even if the functional enhancements being implemented are minimal). Use descriptions from LMM IT Project Definition for types of work to assist in defining major, minor, and patch releases.

Types of work may include:

TYPE OF WORK DESCRIPTION

New Software / Application Development

The first release or version of a system built from any combination of COTS, GOTS and custom developed code. (e.g., This should be a v1.0 release)

Software / Application Development Upgrade

A software release of an existing system consisting of new functionality, interface changes, product changes, or any combination thereof. These changes are typically denoted by an increase to the version number to the left or right of the decimal point (example: v1.3 to v1.4 or v2.0 to v3.0 )

Software Bug Fix/Patch

A release of an existing system consisting of bug fixes, changes to static content, COTS component patches or any combination thereof. These changes are typically denoted by an increase to the version number of the rightmost decimal point (example: v1.3.1 to v1.3.2)

Version: 2.1 3 7/17/2019


TYPE OF WORK DESCRIPTION

New COTS/non-ED GOTS Installation

The first introduction of a Commercial off the Shelf or Government off the Shelf product not developed by ED and not requiring custom developed code or modifications beyond infrastructure integration and configuration tasks. Products falling into this category include Operating systems, applications, and desktop or server tools. (e.g., Microsoft Windows XP, Microsoft Exchange, Adobe Photoshop, etc.) The complexity level of the product will determine the level of "Case Specific" items required.

COTS/ non-ED GOTS Upgrade

A COTS/GOTS product release consisting of new functionality, interface changes, product changes, or any combination thereof. These changes are typically denoted by an increase to the version number to the left of the decimal point (e.g., v1.3 to v2.0) for major releases, and to the right for minor releases (example v1.4 to v1.5).

Infrastructure Change/Upgrade

A change to core infrastructure, major system component configurations; network, server, or storage topology; enterprise routing or switching; major application or server operating systems; or facility location/configuration. This includes any decommissioning and/or transitioning of data center assets, and disaster recovery.

New Hardware New hardware unrelated to major system fielding or development. Examples include new storage, IDS equipment, voice over IP, audio/visual systems, and peripheral devices beyond printers, scanners, and multi-function devices.

Table 2-3: Types of Work

The following sections defining minor and patch releases should utilize a similar approach and terminology, but also explain the differences between major, minor, and patch releases such that an outside reviewer can understand the system’s approach to categorizing releases between major, minor, and patch.]

2.2.2. Minor[Describe the types of changes that constitute a minor release for the system.]

2.2.3. Patch[Describe the types of changes that constitute a patch release for the system.]

Version: 2.1 4 7/17/2019


2.3. Artifact/Document StorageThe table below identifies the locations of LMM-related artifacts and documents for the system. The following bullets provide guidance for completing the table:

Program / Project Monitoring documents/artifacts may be stored in FSA’s Microsoft SharePoint implementation (Enterprise Employee Business Collaboration, EEBC) or in the Enterprise Project Portfolio Management (EPPM) system.

Security and privacy documents/artifacts must be stored in the Cyber Security Asset Management System (CSAM), as this is the central ED-wide solution for those documents.

Requirements, Design and Development, Source Code, Testing, Implementation, and Retirement and Disposal documents/artifacts may be stored in a variety of repositories maintained by FSA. These locations include EEBC, EPPM, FSA Rational, shared network folders on the EDUCATE Network, and other locations under control of support contractors (contractor-hosted SharePoint sites, contractor hosted Rational Implementation, and other contractor-hosted tools).

When documents/artifacts are stored at locations hosted by support contractors, the LMM requires that the support contract include language addressing turnover of the documents/artifacts to FSA at any contract transition (change in contractor, contract recompete, etc.). System Owners and Contract Officers are responsible to ensure that such turnover clauses are appropriately incorporated into each contract. It is advisable that system owners identify specific artifacts as deliverables to FSA to ensure continued support upon turnover or transition to other support contractors.

LMM ARTIFACT CATEGORY LOCATION DESCRIPTION

SYSTEM ROLES AND TYPE OF

ACCESS (VIEW VS MODIFY)

Program / Project Monitoring [EEBC or EPPM] [Role – Access Type]Security and Privacy Cyber Security Asset Management (CSAM) System Owner - View

ISSO – ModifyAuditor - View

Requirements [Location Description] [Role – Access Type]Design and Development [Location Description] [Role – Access Type]Source Code Repository [Location Description] [Role – Access Type]Testing [Location Description] [Role – Access Type]Implementation [Location Description] [Role – Access Type]Retirement and Disposal [Location Description] [Role – Access Type]

Table 2-4: LMM Artifact Storage Locations

Note: The location description should provide a general written description of the planned storage location for each category of LMM Artifact/Document. Do NOT include hyperlinks in the table above.

Version: 2.1 5 7/17/2019


Section 3. Program/Project Monitoring

3.1. Program/Project Monitoring Document GuidanceThe following documents cover Program/Project Monitoring along with associated descriptions and LMM Guidance. In the following section, please describe how each of these documents will be applied to the work of major, minor, and patch releases of the information system.

Project Schedule - The planned dates to start and complete tasks and milestones. Schedules should include work to be done by FSA as well as any vendors participating on the project. The schedule should be managed using the Schedule Management Plan. The LMM recommends that a full baselined project schedule be produced and maintained for major releases; that a milestone schedule be produced and maintained for minor releases; and that patch releases be managed to a target implementation date.

Risk Log - The Risk Log or Risk Register tracks all identified risks, triggers, and mitigation plans for the project. The risks should be reviewed on a regular basis and updated as needed. The risk log may be maintained at the system level covering all releases plus operational type of risks or there may be different risk logs for each release. Please specify how the system is organizing maintenance of the risk log(s).

Action and Issue Log - The Action and Issue Log tracks action items, issues (risks when the trigger date is within 30 days of occurring), status, and resolution. Action and Issue logs may be maintained at the system level covering all releases plus operational type of actions or there may be different action/issue logs for each release. Please specify how the system is organizing maintenance of the action/issues log(s).

Contractor Performance Management Plan - The Contactor Performance Management Plan describes all dealings between the agency and the contractor; from the time the contract is awarded until the work has been completed and accepted or the contract terminated, payment has been made, and disputes have been resolved. It should contain clear measurements of the contractor’s performance against the stated objectives. A Quality Assurance Surveillance Plan or Contract Monitoring Plan are types of Performance Monitoring Plan. The day-to-day administrative monitoring such as invoice inspection and acceptance, timely review of submitted deliverables, and other activities may be documented in a COR Work Plan separate from this plan. Prepares Contractor Past Performance Assessments (CPAR). (NOTE: contracts with a value exceeding $150,000 are required to have an associated monitoring plan in which the agency outlines a process for managing, modifying, and closing out a contract. The CORs are required to keep/maintain all performance related documentation i.e., deliverable acceptance, key emails/correspondence with the vendor etc.). There should be one Contractor Performance Management Plan (or similar document) per contract that supports the information system.

3.2. Program/Project Monitoring Document Tailoring [Describe how the Program/Project Monitoring Documents from the previous section are applied to the information system. If a particular document does not apply, explain why is does not apply and how the purpose and intent of that document is satisfied by another document, artifact, or practice that is in place to support the information system. If the system uses a substantially equivalent document, but uses a different name, then indicate the name of the document that meets the intent of the LMM document name. Each of the documents listed as a bullet in the previous section must be explicitly addressed in this response.]

Version: 2.1 6 7/17/2019


Section 4. Security and Privacy

4.1. Security and Privacy Document GuidanceThe following documents cover Security and Privacy along with associated descriptions and LMM Guidance. In the following section, please describe how each of these documents will be applied to the work of major, minor, and patch releases of the information system.

System of Records Notice (SORN) - Describes the Privacy Act system of records, and the categories of PII collected, maintained, retrieved, and used within the system. It provides information to the public on various characteristics of the system (e.g. description, purpose, data collection, notification, retention and disposal, etc.) The template is located at the end of the directive on Privacy Act issuances. The PTA will help determine if a SORN is required; however, it is best to check with the FSA Privacy Advocate during the "Vision" stage. The SORN process can take up to 8 months and requires many levels of approval, including letters to Congress. Further, the SORN must be posted for public comment in the Federal Register 40 days before the system goes live. Note that one SORN may cover multiple information systems.

Record Retention Schedule for System Data - The Record Retention Schedule for the system’s data details the length of time and manner in which information must be retained managed and deposed. The Record Retention Schedule for data typically does not make a distinction between major, minor, and patch releases. The Record Retention Schedule for data may be specific to the information system, but it is important to treat like records in the same manner, therefore, FSA groups systems that handle similar types of data into a single data retention schedule (for example, FSA contact centers share a common data retention schedule that may span multiple systems). The tailoring description in the following section should indicate which ED record retention schedule(s) applies to the system that is the subject of this tailoring plan or reference where that information may be found. Adherence to the records retention schedule and to data disposition is exercised annually by the ISSO and reviewed by the System Owner annually.

Memorandum of Understanding - Defines the responsibilities of distinct organizations/units in securing the interconnection between connected systems including the Interconnection Service Agreement (ISA). The MOU process can be lengthy, and requires multiple levels of approval. Discussions about MOUs should be started during the "Vision" stage. Systems may have zero, one, or multiple MOUs; the tailoring description in the following section should provide a listing of MOUs maintained for the system or provide a reference to where this information can be found.

Computer Matching Agreement (CMA) - A computer matching agreement is a written document that establishes the conditions, safeguards, and procedures under which one government entity agrees to disclose data to another entity, where there is to be a computerized comparison of two or more automated Systems of Records (SORNs). CMAs are required by the Computer Matching and Privacy Protection Act of 1988 (Pub. L. No. 100-503) and the Computer Matching and Privacy Protection Amendments of 1990 (Pub. L. No. 101-508), both of which amended the Privacy Act of 1974 (Privacy Act), 5 U.S.C. §552a. If one agency exchanges Privacy Act data (i.e., PII) with another Federal agency to determine if someone is eligible for a Federal benefit, then a CMA is required (even if there is already a memorandum of understanding and interconnection security agreement in place). The CMA process can be lengthy and requires multiple levels of approval. Discussions about CMAs should be started with the FSA Privacy Advocate during the "Vision" stage. Systems may have zero, one, or multiple CMAs; the tailoring description in the following section should provide a listing of CMAs maintained for the system or provide a reference to where this information can be found.

Interconnection Security Agreement (ISA) - Required for Inter-agency Agreements (IAAs) involving the interconnection of two systems owned by two different agencies. The ISA provides

Version: 2.1 7 7/17/2019


the technical solution and security requirements for the interconnection. The ISA also supports a Memorandum of Understanding or Agreement (MOU/A) between organizations. The ISA process can be lengthy, and requires multiple levels of approval. Discussions about ISAs should be started with the FSA Privacy Advocate during the "Vision" stage. Systems may have zero, one, or multiple ISAs; the tailoring description in the following section should provide a listing of ISAs maintained for the system or provide a reference to where this information can be found.

Information System Security Officer (ISSO) Appointment Letter - A three-page memorandum officially appointing an Information System Security Officer to the system in question. All systems must have an ISSO assigned to them, and this assignment is done via the ISSO appointment letter. This letter must be updated to reflect personnel changes. The letter must be signed in the "Definition" stage. Typically, there is one ISSO Appointment Letter per system (no distinction between major, minor, and patch releases).

Data Sensitivity Worksheet - The Data Sensitivity Worksheet is used to assess the security and sensitivity of a system. It is used to classify a system as either a general support system (GSS) or a major application (MA), identify data sensitivities, and to ensure that the system has the appropriate level of security. Because the data sensitivity worksheet, to a large extent, will determine the security control requirements (e.g., if a full security authorization is required), for new systems, it must be completed during the "Vision" stage. For upgrades/enhancement releases, the worksheet must be reviewed and updated accordingly. There should be one data sensitivity worksheet per system; no distinction between major, minor, and patch releases. This artifact may be completed using data fields in CSAM rather than a document. Please consult with LMM SME.

Privacy Threshold Analysis (PTA) - The Privacy Threshold Analysis is used to determine whether a Privacy Impact Analysis is necessary. The PTA determines all subsequent privacy requirements (e.g., Privacy Impact Assessment, System of Records Notice, Computer Matching Agreement), and should be completed in the "Definition" stage. Typically, there is one PTA per system (no distinction between major, minor, and patch releases).

Privacy Impact Assessment (PIA) - The Privacy Impact Assessment is used to identify if a system contains privacy information and lets the public know what information is collected and how it is secured, used, and shared. Information collected may include Social Security Numbers, PINs, Addresses, Dates of Birth, etc. The PTA (above) determines whether a PIA is required. PIAs often require multiple levels of approvals/signatures (including ED OM Privacy), and should be completed as soon as possible due to the length of time required for necessary approvals. A system cannot go live until the PIA is reported to the Office of Management and Budget and posted to the OM Privacy website. Typically, there is one PIA per system (no distinction between major, minor, and patch releases).

Business Impact Analysis (BIA), including Appendix A - This is an application level document that reveals any vulnerabilities, and a planning component to develop strategies for minimizing risks. Often part of the disaster recovery plan, it is likely to identify costs linked to failures, such as loss of cash flow, replacement of equipment, salaries paid to catch up with a backlog of work, and loss of profits. There should be one BIA per system; no distinction between major, minor, and patch releases. Please specify what conditions would prompt a review/update of the BIA and if there is a cyclical review (i.e. annual) of the BIA.

Information Technology (IT) Contingency Plan (Includes Test Plan) - Documents the critical business functions that need to be resumed and in what order, what technical components are affected in the case of a disaster, and the key individuals who should be familiar with their duties under the plan. The same template may be used for both the Contingency Test Plan and Disaster Recovery Plan, depending upon need. Typically, this is updated annually. One document per system, no distinction between major, minor, and patch releases.

IT Contingency Test Plan Results - Test Plan Results are not at the application level. Test Plan Results are only required if not already covered by an existing enterprise level Contingency Plan

Version: 2.1 8 7/17/2019


Test Results document. Typically, these results are obtained through annual disaster recovery testing. One document per system, no distinction between major, minor, and patch releases.

Disaster Recovery Plan - This is a standard operating procedure that describes how at an enterprise level the organization is to deal with potential disasters by explaining the precautions taken so that the effects of a disaster will be minimized and the organization will be able to either maintain or quickly resume mission-critical functions. Disaster Recovery Exercise reports quality management findings and human capital results at the enterprise level. This artifact is required unless already covered by an existing enterprise level Disaster Recovery Plan prepared by the vendor responsible for management of the Next Generation Data Center (NGDC) contract. The same template may be used for both the Contingency Test Plan and Disaster Recovery Plan, depending upon need. Typically, the Disaster Recovery Plan is maintained by the Data Center Provider. For NGDC Systems, refer to the NGDC Continuity of Services / Disaster Recovery Plan. For information systems hosted in data centers other than the NGDC, please indicate the artifact where the Disaster Recovery Plan can be found.

System Boundary (System Authorization Boundary) - Artifact developed during the definition phase if constructing a new system or application or updating an existing system. Defines system boundaries for and relationships between systems and communication channels. If an artifact is necessary, a Memorandum of Understanding (MOU) specific to the boundary document must be prepared. For new systems, the boundary template must be completed during the "Vision" stage. For upgrades/enhancement releases, the boundary template must be reviewed and updated accordingly. There should be one system boundary per system.

Configuration Management Plan - The Configuration Management (CM) Plan provides an overview of the organization, activities, overall tasks, and objectives of CM for an initiative. It addresses: baseline work products, describes the mechanism to track and control changes/change requests, and the mechanism to establish and maintain baseline integrity.

System Security Plan - Provides an overview of the security requirements of the system and describes the controls in place or planned responsibilities and expected behavior of all individuals who access the system. The System Security Plan should be viewed as documentation of the structured process of planning adequate, cost-effective security protection for a system. Describes general system information such as its Federal Information Processing Standards (FIPS) 199 categorization, type of data processed, points of contact, system environment, applicable Federal laws and guidelines, and sensitivity of information processed by the system. It includes the management, operational, and technical controls required for the system. System Boundary Document and all other project related security documentation must be developed in compliance with NIST Special Publication (SP) 800-18 and SP 800-53. Please note, adherence to the record retention schedule and disposition of data per the schedule and NARA guidelines is part of NIST 800-53 (Control S12). System capability for scheduled systems must meet NARA requirements under CFR 1236. Further security compliance information can be found at http://csrc.nist.gov/publications/PubsSPs.html. As deemed necessary, contractors may obtain a copy of the Federal Student Aid Security Architecture Model and other security documentation by contacting their Contracting Officer post award. Different versions are available based on need. For new systems, the system security plan is generally completed during the "Definition/Development" stages. For upgrades/enhancement releases, the plan must be reviewed and updated accordingly. There should be one System Security Plan per system; no distinction between major, minor, and patch releases. Indicate what conditions would trigger an update to the Security Plan and how often the plan is to be reviewed. Also, if there is a regular update cycle (i.e. annual update incorporating changes over the past year), then please include a description of the update process.

Security Assessment Plan - The system's Security Assessment Plan is a document that identifies all the security controls that will be assessed and the assessment methods used for a System Security Authorization Assessment. The security assessment plan must be completed before any security assessment activities may take place.

Version: 2.1 9 7/17/2019


System Security Plan Checklists - These checklists are to be compared against security plans. For new systems, this step is completed in parallel with development activities. For existing systems, this step must be completed either every 3 years, or whenever there is a major change to the system.

Security Assessment Report - Report defines accreditation boundary, system characteristics, and Risk Assessment Results. For new systems, this step is completed in parallel with development activities. For existing systems, this step must be completed either every 3 years, or whenever there is a major change to the system.

Authority to Operate Letter and Briefing - The Authority to Operate Letter and Briefing proves the system has gone through system accreditation and certification. The briefing is a presentation to the authorizing official, providing an overview of the security authorization and risk. An independent contractor creates this Power Point presentation. For new systems, these must be completed before a system is implemented in production. For existing systems, these must be completed every three years or whenever a system undergoes a major change. This document is produced by the Technology Office/IT Risk Management Group and provided to the system; the system is responsible for maintaining the document in its records.

4.2. Security and Privacy Document Tailoring[Describe how the information system manages Security and Privacy and how each of the LMM Artifact Documents from the previous section are applied to the information system. If a particular document does not apply, explain why is does not apply and how the purpose and intent of that document is satisfied by another document, artifact, or practice that is in place to support the information system. If the system uses a substantially equivalent document, but uses a different name, then indicate the name of the document that meets the intent of the LMM document name. Each of the documents listed as a bullet in the previous section must be explicitly addressed in this response.]

Version: 2.1 10 7/17/2019


Section 5. Requirements

5.1. Requirements Document GuidanceThe following documents cover Requirements along with associated descriptions and LMM Guidance. In the following section, please describe how each of these documents will be applied to the work of major, minor, and patch releases of the information system.

Requirements Management Plan – The purpose of the Requirements Management Plan is to define the requirements processes and procedures to be used by the project team. This Plan defines how requirements will be elicited, structured and prioritized; how requirements will be recorded; how requirements will be modified; and how requirements will be traced and reconciled for final delivery of the product. The plan also specifies roles and responsibilities. Tailoring Guidance: A Requirements Management Plan is generally required. For small in-house projects where overall project risks are low, requirements management controls may be addressed directly in the Project Management Plan, the Change Management Plan and the Configuration Management Plan. The project team must demonstrate that the requisite subjects have been addressed (consult with designated LMM subject matter expert).

High Level Requirements Document - This document captures high-level functional and non-functional requirements in a format suitable for the project at hand. The document must address the breadth of coverage and provide at least a preliminary description of how requirements may be grouped into releases and iterations.

Detailed Requirements Document - The Detailed Requirements Document captures detailed functional and non-functional requirements in the form of declarative statements, uses cases and other requirement artifact types as applicable to the project. Requirements in this document are captured at the level from which they can inform design and development.

Requirements Traceability Matrix - The Requirements Traceability Matrix (RTM) ensures bi-directional traceability between high level/business and detailed/system requirements. The RTM also associates detailed/system requirements with portions of the build designed to satisfy them. Testing is also tied to the requirements on which they are based to ensure that the build meets all requirements.

Data Migration Plan - Document defines the processes associated with completion of the data migration effort; which includes conversion strategies, data mapping (which are the detailed requirements), data clean up, and testing.

5.2. Requirements Document Tailoring[Describe how the information system manages Requirements and how each of the LMM Artifact Documents from the previous section are applied to the information system. If a particular document does not apply, explain why is does not apply and how the purpose and intent of that document is satisfied by another document, artifact, or practice that is in place to support the information system. If there are different approaches to updating the documents for major, minor, and patch releases; then please explain those different approaches. If the system uses a substantially equivalent document, but uses a different name, then indicate the name of the document that meets the intent of the LMM document name. Each of the documents listed as a bullet in the previous section must be explicitly addressed in this response.]

5.3. Requirements Review Stage GateRequirements Review Stage Gate - This stage gate may be repeated at key project points to obtain agreement from key stakeholders that the requirements management practices are sound and that detailed requirements are ready for use by the system support personnel, and are sufficient to move from definition to the design phase of the project.

Version: 2.1 11 7/17/2019


[Describe how the system (or business unit) plans to implement a requirements review stage gate. This may vary between major, minor, and patch releases or it may be consistent across different types of releases. Refer to the Requirements Review Stage Gate Process document and consult the Stage Gate Owner for additional guidance.]

Version: 2.1 12 7/17/2019


Section 6. Design and Development

6.1. Design and Development Document GuidanceThe following documents cover Design and Development along with associated descriptions and LMM Guidance. In the following section, please describe how each of these documents will be applied to the work of major, minor, and patch releases of the information system.

Detailed Design Document - The Detailed Design Document provides a detailed design, using a number of different architectural views (to include use case diagrams) to depict different aspects of the system. It is intended to capture and convey the detail necessary to allow coders to develop the system, and to support critical design reviews before beginning development.

Solution User Manual - The Solution User Manual describes in detail the user/system interaction facilities offered by the system, which allow the users to leverage the system functionality in support of their business processes.

Release Version Description Document - The Release Version Description Document is used to track, and control versions of software and hardware being released to implementation, testing, or the final operational environment. For COTS products, this typically takes the form a “release notes” from a software vendor.

6.2. Design and Development Document Tailoring[Describe how the information system manages Design and Development and how each of the LMM Artifact Documents from the previous section are applied to the information system. If a particular document does not apply, explain why is does not apply and how the purpose and intent of that document is satisfied by another document, artifact, or practice that is in place to support the information system. If there are different approaches to updating the documents for major, minor, and patch releases; then please explain those different approaches. If the system uses a substantially equivalent document, but uses a different name, then indicate the name of the document that meets the intent of the LMM document name. Each of the documents listed as a bullet in the previous section must be explicitly addressed in this response.]

6.3. Technical Design Review - Technical Stage GateTechnical Design Review – The design review stage gate verifies that a system's technical solutions are in compliance with FSA's technical, architectural and target state vision objectives and the project is ready to pass from technical design to the development stage.

[Describe how the system plans to implement a design review stage gate. This may vary between major, minor, and patch releases or it may be consistent across different types of releases. Refer to the Technical Design Review Stage Gate Process document and consult the Stage Gate Owner for additional guidance.]

Version: 2.1 13 7/17/2019


Section 7. Testing

7.1. Testing Document GuidanceThe following documents cover Testing along with associated descriptions and LMM Guidance. In the following section, please describe how each of these documents will be applied to the work of major, minor, and patch releases of the information system.

Master Test Plan - Provides a central artifact to govern the planning, control and test management of the test effort. It defines the general approach that will be employed to test the solution and to evaluate the results of that testing, and is the top-level plan that will be used by managers to govern and direct detailed testing activities. Supplemental phase level test plans (System, User Acceptance, Performance, Inter-system, etc.) provide detailed strategy (covering scope, resources, and approach) for the phase of testing focusing on what is to be tested in the phase. Additionally, the Master Test Plan provides objectives for the security control assessment and procedures for testing each security control.

Phase Level Test Plan – Documents the approach to a specific phase of testing for a system release (System Test, Intersystem Test, Performance Test, User Acceptance Test, etc.).

Hardware Test Plan – Test plan that documents the approach and resources needed to test a hardware implementation.

System Test Plan – Test plan that documents the approach and resources needed to conduct system testing for a specific release of a system.

UAT Test Plan – Test plan that documents the approach and resources needed to conduct User Acceptance Testing (UAT) for a specific release of a system.

Test Suites - Test Suites outline a set of several test scenarios, test cases and test scripts for a component or system under test.

User Acceptance Test Summary Report - The User Acceptance Test Summary Report gives a summarization of the user acceptance test phase of the project. The report includes support materials pertaining to the software version, deviations from those areas that were agreed to in the User Acceptance Test Plan, gives an overall assessment of the product that was tested and gives an overall status of the incidents found during the user acceptance test.

Test Summary Report – This report gives a summarization of the system test phase of the project. The report includes support materials pertaining to the software version, deviations from those areas that were agreed to in the System Test Plan, gives an overall assessment of the product that was tested, and provides an overall status of the incidents found during the system test activity.

Defect Management Report - The Defect Management Report details the defects discovered during testing. Various reports are required for each phase of testing.

7.2. Testing Document Tailoring[Describe how the information system manages Testing and how each of the LMM Artifact Documents from the previous section are applied to the information system. If a particular document does not apply, explain why is does not apply and how the purpose and intent of that document is satisfied by another document, artifact, or practice that is in place to support the information system. If there are different

Version: 2.1 14 7/17/2019


approaches to updating the documents for major, minor, and patch releases; then please explain those different approaches. If the system uses a substantially equivalent document, but uses a different name, then indicate the name of the document that meets the intent of the LMM document name. Each of the documents listed as a bullet in the previous section must be explicitly addressed in this response.]

7.3. Test Readiness Review (TRR) Stage GateTest Readiness Reviews are conducted prior to each testing cycle. The most common reviews are completed prior to system testing and prior to user acceptance testing.

Test Readiness Review – System Test - The Test Readiness Review artifacts provide management with an assessment of the readiness of the development maturity, test environment, test data, test processes, deliverables and other dependencies to ensure the system is ready to pass from build/construct to formal system testing and that known risks have been documented, accepted or mitigated.

Test Readiness Review – User Acceptance Test - The Test Readiness Review artifacts provide management with an assessment of the readiness of the development maturity, test environment, test data, test processes, deliverables and other dependencies to ensure the system is ready to pass from system testing to user acceptance testing and that known risks have been documented, accepted or mitigated. Typically, user acceptance testing is a resource intensive activity for FSA personnel and management should be confident that the system is ready to move into the test phase.

[Describe how the system plans to implement any test readiness review stage gates. This may vary between major, minor, and patch releases or it may be consistent across different types of releases. Refer to the FSA Enterprise Test Management Standards and consult the Stage Gate Owner for additional guidance.]

Version: 2.1 15 7/17/2019


Section 8. Implementation

8.1. Implementation Document GuidanceThe following documents cover Implementation along with associated descriptions and LMM Guidance. In the following section, please describe how each of these documents will be applied to the work of major, minor, and patch releases of the information system.

Implementation Plan - This document describes the planned procedures for releasing a new system or system module to production. It lists deployment goals; critical success factors; deployment tasks (including post implementation testing); resources, and tools; task and resource dependencies; task responsibilities and timelines for completion; and significant risks and contingency plans. A full implementation plan is appropriate for new system implementations; existing systems typically meet this requirement by producing an hour-by-hour plan of the implementation activities.

Training Plan - The Training Plan documents the approach to knowledge transfer and the training to be provided or arranged for end-users and support staff, including prerequisites, courses, course curricula, mode of delivery and attendees.

Operations and Maintenance Plan - This plan documents all ongoing activities necessary to operate and maintain the system in proper functioning condition. This plan includes a description of the resources required and their responsibilities, operational procedures for system startup and restart, backup and recovery, system archiving, and job scheduling. In addition, this plan addresses any training required by the user community in order to use the system and Service Level Agreement metrics associated with the system.

8.2. Implementation Document Tailoring[Describe how the information system manages Implementation of releases and how each of the LMM Artifact Documents from the previous section are applied to the information system. If a particular document does not apply, explain why is does not apply and how the purpose and intent of that document is satisfied by another document, artifact, or practice that is in place to support the information system. If there are different approaches to updating the documents for major, minor, and patch releases; then please explain those different approaches. If the system uses a substantially equivalent document, but uses a different name, then indicate the name of the document that meets the intent of the LMM document name. Each of the documents listed as a bullet in the previous section must be explicitly addressed in this response.]

8.3. Production Readiness Review (PRR) Stage GateProduction Readiness Review - Production Readiness Review includes a review of test results, changes to the security posture of the system, and activities that have been completed to prepare a system release for implementation. PRR is the final management decision point before a system release is implemented. The applicability of the PRR stage gate is determined on a release-by-release basis by FSA’s Enterprise Change Management (ECM) Process; the Technical Review Board (TRB) performs the initial risk evaluation and makes a recommendation regarding PRR, which is then reviewed and approved (or changed) by the Enterprise Change Control Board (ECCB).

[The PRR is applied uniformly across all systems and their releases as described in the paragraph above. No further explanation is required. In completing the tailoring plan, simply delete this comment (bracketed blue text) to confirm your understanding of the PRR Stage Gate.]

Version: 2.1 16 7/17/2019


Section 9. Retirement and Disposal

9.1. Retirement and Disposal GuidanceThe following documents cover Retirement and Disposal along with associated descriptions and LMM Guidance. In the following section, please describe how each of these documents will be applied to the work of major, minor, and patch releases of the information system.

System Retirement Plan - The System Retirement Plan describes the system retirement strategy, the solution replacement and retirement requirements list, and the data/documentation plan.

System Disposal Plan - The System Disposal Plan documents the data that needs to be preserved when the system is disposed of, the timeline for the disposal activities, the software components and data to be preserved, the equipment and software disposal plan, the security measures to be taken to dispose of the system and its data, and the archival of lifecycle products.

9.2. Retirement and Disposal Document Tailoring[Describe how the information system manages Retirement and Disposal and how each of the LMM Artifact Documents from the previous section are applied to the information system. If a particular document does not apply, explain why is does not apply and how the purpose and intent of that document is satisfied by another document, artifact, or practice that is in place to support the information system. If there are different approaches to updating the documents for major, minor, and patch releases; then please explain those different approaches. If the system uses a substantially equivalent document, but uses a different name, then indicate the name of the document that meets the intent of the LMM document name. Each of the documents listed as a bullet in the previous section must be explicitly addressed in this response.]

9.3. Retirement and Disposal Review Stage GateRetirement and Disposal Review - The Retirement and Disposal Review ensures that a system and the system components are properly retired, sanitized, decommissioned, and archived according to NIST, Department of Education, and FSA guidelines, policies, standards, and procedures before passing from operations and maintenance into retirement.

[Indicate if a retirement and disposal stage gate is planned for the system. This stage gate is required when eliminating/retiring an entire information system; not only a component of the system. Refer to the System Retirement and Disposal Guide, or contact the Stage Gate Owner, for specific information on different types of retirement/disposal activities (disposal of a component but not entire system, system migration/re-platforming, and full system retirement).]

Version: 2.1 17 7/17/2019

LMM Tailoring Plan Template Acronyms and Abbreviations

Appendix A - Acronyms and AbbreviationsACRONYM DEFINIT ION

BIA Business Impact AnalysisCM Configuration ManagementCMA Computer Matching AgreementCO Contracting OfficerCOR Contracting Officer RepresentativeCOTS Commercial Off The ShelfCPARS Contractor Performance Assessment Reporting SystemCSAM Cybersecurity Assessment and Management SystemECCB Enterprise Change Control BoardECM Enterprise Change ManagementED U.S. Department of EducationEEBC Enterprise Employee Business Collaboration (FSA internal SharePoint)EPPM Enterprise Project Portfolio ManagementFIPS Federal Information Processing StandardFSA Federal Student AidGOTS Government Off The ShelfGSS General Support SystemIAA Inter-Agency AgreementIDS Intrusion Detection SystemIP Internet ProtocolIRPE Information Resource Program ElementsISA Interconnection Security AgreementISSO Information System Security OfficerIT Information TechnologyLMM Lifecycle Management MethodologyMA Major ApplicationMOU Memorandum of UnderstandingNARA National Archives and Records AdministrationNGDC Next Generation Data CenterNIST National Institute of Standards & TechnologyOCIO Office of the Chief Information OfficerOMB Office of Management & BudgetONR Organizational Need RequestPIA Privacy Impact AssessmentPII Personally Identifiable InformationPOAM Plans of Action and MilestonesPRR Production Readiness ReviewPTA Privacy Threshold AnalysisRR Release RequestRTM Requirements Traceability MatrixSDLC System Development LifecycleSME Subject Matter ExpertSG Stage GateSOR System of RecordsSORN System of Records NoticeSP Special Publication (from NIST)SR Service Request

Version: 2.1 1 7/17/2019


ACRONYM DEFINIT ION

TRB Technical Review BoardTRR Testing Readiness Review

Table A-1: Acronyms and Abbreviations

Version: 2.1 2 7/17/2019


Appendix B - GlossaryThis glossary addresses terms that are not explicitly defined elsewhere in the document and are important to be defined in the context of the LMM Tailoring Plan.

TERM DEFINIT IONAcquisition Package

The documents needed to execute a procurement (contract) activity from the solicitation to contract award. These documents will vary depending on the requirements and type of the contract. Typical documents include Statement of Work, Performance Work Statement, Statement of Objectives, Independent Government Cost Estimate, Instructions to Offerors, the Announcement/Solicitation, Technical Reference Materials, and the Awarded Contract.

Artifact An LMM artifact is any document produced in the process of planning and executing a project. The LMM maintains a set of artifacts with prescribed templates that can be used for creating LMM artifacts (or used as a standard of compliance when a non-LMM template is used).

Exemplar An LMM document that is used to demonstrate the most effective and compliant utilization of an LMM template.

Guidance An LMM Document (either created by the LMM team or an external source) that gives direction on how to use templates, complete stage gates or better understand the LMM process.

Information System A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. [44 U.S.C., SEC. 3502] (Definition Source: FIPS 199 02/2004)

Investment Manager

The individual responsible for managing an IT Investment and fulfilling the associated reporting requirements.

Information Resources Program Elements

The IRPE defines and establishes consistent language for use in solicitation and award documents in projects and programs related to the Information Technology Resources services and assets. Proper inclusion of consistent language will ensure compliance with Federal and Departmental law and regulation, and will also ensure accurate and effective delivery of services and assets that meet Departmental standards and requirements.

Project (as used in LMM)

A temporary IT endeavor undertaken to accomplish a unique set of outcomes with a defined start and end point that, when attained, signify completion. Projects are composed of activities undertaken for development, modernization, enhancement, disposal, or maintenance of a new or existing IT system, program, or investment asset.

Stage Gate An IT Governance review process to review risk associated with moving to the next lifecycle phase, identify any corrective actions needed, and provide management with insight into areas where additional resources may be needed.

Stage Gate Owner The Subject Matter Expert that provides guidance and oversight for a Stage Gate.Subject Matter Expert

The Subject Matter Expert is the individual who is knowledgeable in a particular domain and maintains ownership over an artifact or artifact groupings on behalf of the FSA organization. The SME is responsible for updating artifacts, providing guidance on tailoring individual projects, providing coaching and guidance in the knowledge domain, and participating during Stage Gates and reviews.

Release (as used in LMM)

Grouping of changes or enhancements to an information system that are managed as a unit through the system development lifecycle. Typically, a release is managed via a release schedule, is reported as a single project, has a unified approach to testing the release, and results in implementation of a new software product version or change to infrastructure. Releases may be classified as major, minor, or patch to identify the scope, scale, and complexity of the underlying changes.

System See Information System.Tailoring Plan Document that describes how components of the Lifecycle Management Methodology

(LMM) are applied to an information system. The tailoring plan includes only those components that may vary between information systems, thus requiring a documented explanation of such variance.

Template A document used to set the format and information requirements for creating a particular LMM Artifact.

Version: 2.1 1 7/17/2019


Table B-2: Glossary

Version: 2.1 2 7/17/2019

LMM Tailoring Plan Template€¦ · Web viewBusiness Impact Analysis (BIA), including Appendix A...

Documents

Transcript of LMM Tailoring Plan Template€¦ · Web viewBusiness Impact Analysis (BIA), including Appendix A...