Attachment_C_DCAS_LMM_WBS_Template.pdf

Attachment C RFP #ED-FSA-14-R-0028: Data Challenges and Appeals Solution (DCAS)

Element Name Definition Activities Acceptance Criteria Business Impact Analysis

(BIA)

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.

Retrieve the BIA and Appendix A templates and complete the templates in their entirety. Obtain the necessary signatures. Upload the completed document on OVMS (only system/application specific ISSO/SSO will have access.

The BIA must define all potential system vulnerabilities and related cost impacts, as well as describe the strategies for minimizing vulnerabilities and risks.

Change Management Plan

The Change Management Plan describes the formal process for making changes to the project’s original scope, schedule, cost or quality.

Document how changes will be made to the project. The plan adequately documents the change management process and clearly identifies roles and responsibilities. The sponsor has accepted the plan.

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.

Identify roles and responsibilities of all participants in the Configuration Management Plan. Define process to track hardware and software changes and deployment procedures.

Ensure all interfacing systems are taken into consideration. Ensure the plan doesn't conflict with existing CM's of other interfacing systems.

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 Test Results document.

Access the template and complete it in its entirety after an Exercise. Obtain the appropriate signatures.

Upload the completed document on OVMS (only system/application specific ISSO/SSO will have access).

Test Plan Results must document results of conducting the predefined Contingency Test Plan.

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.

The ISSO will ensure that it is appropriately filled out to identify the correct data sensitivities. These data sensitivities will be used to identify the appropriate controls to be implemented for the security of the system. The data sensitivities identified here will be used along with NIST SP800-53 to develop the System Security Plan and the Security Assessment Plan.

The artifact must be able to assess the security and sensitivity of a system. It should be able to classify the system as either a GSS or MA, identify any data sensitivities, and document support that the system has the appropriate level of security.

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.

Develop/determine a conversion strategy, data migration details, data migration order, data migration exceptions, and data migration validations.

The data migration plan features a comprehensive migration strategy with a risk minimizing means of performing the migration.

Defect Management Report

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

Report defects and related metrics. The reported metrics should include both successes and failures. This report will also be used for process improvement efforts to either minimize defects in the future or to identify defects earlier in the development process.

The Defect Management Report must detail all defects discovered during testing.

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.

Document physical design and physical data model. Document possible system interfaces. Design is consistent with requirements, Preliminary Design and Technology Standards. Proposed design is feasible and workable.

Detailed Requirements Document

The Detailed Requirements Document captures detailed functional and non-functional requirements in the form of declarative statements. Requirements in this document are captured at the level from which they can be coded.

Define and develop system context diagram and detailed use cases. Describe interfaces with external systems.

Define the detailed system level requirements for the solution. Detail detailed functional and non-functional requirements for the solution. Define system constraints to provide the IT standards and other constraints applicable to the solution. Define the various business rules and messages required of the solution. Provide the logical data model.

Use cases and requirements are clear and understandable. Project sponsor accepts use cases, all functional and non-functional requirements, and business rules and messages for the system.

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 VDC contract. The same template may be used for both the Contingency Test Plan and Disaster Recovery Plan, depending upon need.

This contains VDC restoration activities that are compiled into one document versus application specific. The Disaster Recovery Plan must describe how the organization will deal with a potential disaster by defining vulnerabilities and precautions taken to mitigate or quickly resume mission critical functions. The plan must define how to execute the Disaster Recovery Plan and what data is expected from quality management and human capital reporting post exercise.

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.

Establish Scope of the target product. Develop high level use case and functional and non-functional requirements. Group and prioritize requirements. Identify preliminary options for transitioning from current state to implementation of the requirements.

Functional and non-functional requirements are traceable to customer wants and needs in the Initiative Vision Document. Requirements are clearly articulated and testable. Requirements, and their grouping and prioritization, are sufficient to plan further elaboration, and are accepted by the project sponsor.

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.

The implementation plan must document planning, preparing items to be delivered, packaging, shipping, installation, training that must take place, and support plan.

The Implementation Plan must document planning, preparing items to be delivered, packaging, shipping, installation, training that must take place, and support plan.

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.

Access the template and complete it in its entirety. Obtain the appropriate signatures. Upload the completed document on OVMS (only system/application specific ISSO/SSO will have access).

The plan must include procedures and technical measures that enable the recovery of IT systems, operations, and data after a disruption. Contingency planning generally includes one or more of the approaches to restore disrupted IT services:

•Restoring IT operations at an alternate location •Recovering IT operations using alternate equipment •Performing some or all of the affected business processes using non-IT (manual) means (typically acceptable for only short-term disruptions).

Master Test Plan 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

Master Test Plan-Document testing, provides details at a high level and overall test planning and test management for multiple phases of testing (one project or across multiple projects). Phase Level- Document testing provides phase specific details for System , User Acceptance, Performance, Inter-system, etc. test plans.

Master Test Plan addresses all aspects of testing covering all functional, non functional requirements covering all phase level test plans.

NOTE: Based on proposed solution, Offeror shall incorporate those elements as deliverables with target due dates, definition/description and acceptance criteria as part of its technical proposal/PWS based upon Offeror’s proposed solution. If deemed appropriate, Offeror may propose additional LMM elements in accordance to FSA's standard as posted on IT Standards Library.

Attachment D: Lifecycle Management Methodology (LMM) Work Breakdown Structure (WBS)

Element Name Definition Activities Acceptance Criteria 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.

Define operational procedures related to system startup, restart, backup, recovery and archiving. Determine resource planning needs. Map resource needs to operational procedures. Define ongoing training requirements for end-users, and resources maintaining system. Write a Service Level Agreement. Complete the Operations and Maintenance plan.

All fields of the Operations and Maintenance Plan have been completed and validated for quality and accuracy. System operations and maintenance is properly functioning, with resources aware of their responsibilities, and completing those tasks during ongoing maintenance, and in the case of any necessary system updates.

Performance Management Plan

This plan includes activities to ensure that goals are consistently being met in an effective and efficient manner. A performance measurement baseline is established at the beginning of the project. An integrated scope-schedule-cost plan for the project work is compared to measure and manage performance.

Establish performance measurement baseline. Approve integrated scope-schedule-cost plan. Compare project work against project execution to measure and manage performance.

Performance Monitoring Plan

The Performance Monitoring Plan describes all dealings between the agency and the contractor and should contain clear measurements of the contractor’s performance against the stated objectives.

Determine the required level of contract surveillance. The Performance Monitoring Plan is comprehensive in its assignment of roles and functions for contract oversight. The plan ensures that contractor performance will be closely monitored and that administering personnel will be quickly able to identify and take appropriate action if contract performance becomes unsatisfactory. See ACS Directive 2108.

Preliminary Design Document

The Preliminary Design Document provides a high level design, using a number of different architectural views (to include use case diagrams) to depict different aspects of a system. It is intended to capture and convey the significant architectural decisions that have been made on the system in the early stages, allowing the high-level design to be effectively evaluated before proceeding to the detailed design stage.

Document logical design and logical data model. Identify and document design decisions. Design addresses all the functional and non functional requirements. Design addresses impact on other systems.

Privacy Impact Assessment

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. Information collected may include Social Security Numbers, PINs, Addresses, Dates of Birth, etc.

If the system processes or contains personally identifiable information, a Privacy Impact Assessment must be completed and signed by program officials.

The artifact must provide information that details whether the system contains privacy information, how the data is collected and secured. The standard FSA PIA template must be used, and all questions must be sufficiently answered.

The PIA must be signed by the program officials. If the system uses Social Security numbers, the PIA must be signed by the COO.

Privacy Threshold Analysis

The Privacy Threshold Analysis is used to determine whether a Privacy Impact Analysis is necessary. Determine whether or not the system will handle personally identifiable information. Once this determination has been made, determine how this information will be collected, used and secured.

The document must comply with the standards set forth in the E-Government Act. The standard FSA PTA template must be used. Fields must contain the same data collected from the from the FSA PTA artifact and support the analysis necessary to perform the Privacy Impact Analysis.

Production Readiness Review Briefing

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. There is a PowerPoint presentation template for those going through PRR, and a checklist template.

Complete PRR Presentation (including a review of Business Drivers, Schedule, Open Risks, Test Results, Security Impacts, Communication to End Users, Implementation Plans, and a high-level discussion of lessons learned). Obtain formal sign-off from business and technology organizations needed to support implementation of the system release.

Management acceptance of any outstanding risks associated with implementing the system release. Business and technology organizations agree that the necessary resources are in place to support implementation of the system release.

Quality Management Plan

The Quality Management Plan describes the activities and tasks required to deliver the scope of the project while focusing on achieving customer's quality expectations. The Plan identifies which quality standards are relevant to the project and determines how can they be satisfied. It includes the implementation of quality events such as peer reviews, checklists and independent validation and verification.

Determine quality standards and document the process by which quality will be measured and by whom. The plan documents how quality will be managed on the project and includes defined quality control metrics, quality objectives and defines a process for conducting quality assurance reviews for proposed deliverables.

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.

Identify list of changes to the software, hardware, and other plug-in software components that are included in this release.

Ensure release aligns with technology standards. Ensure release is tested to have no known issues or defects.

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; how requirements will be recorded; how requirements will be modified; and how requirements will be traced and reconciled for final delivery of the product.

To be proposed by Offeror To be proposed by Offeror

Requirements Traceability Matrix

The Requirements Traceability Matrix associates 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.

Document system requirements and how the system will meet these requirements. The requirements are thoroughly documented and compartmentalized in a way that facilitates system testing. Each requirement is uniquely identifiable and reflects bidirectional traceability.

Security Risk Assessment Artifacts

The Security Risk Assessment artifacts provide an assessment of a system’s security controls and determines the extent to which those controls have been implemented correctly - operating as intended and producing the desired outcome with respect to meeting system security requirements and a plan to mitigate findings. The security assessment also includes a list of any recommended corrective actions. The guidance is used to create the artifacts.

Work with FSA security personnel to perform a thorough assessment/analysis of the system's security. The security assessments and respective reports are thorough and actionable.

Security, Certification & Accreditation and Post Implementation Evaluation Report

Documents the results of the Security, Certification and Accreditation and Post Implementation Evaluation. The purpose of the report is to review and ensure that each general support system's and major application's security controls are implemented and/or documented in compliance with the U.S. Department of Education, U.S. Office of Management and Budget (OMB), and National Institute for Standards and Technology (NIST) guidance.

Documents developed here are updated on a regular basis and provide actionable steps and concrete timelines for mitigating system risks and security concerns.

The Security, Certification and Accreditation and Post Implementation Evaluation Report documents the results of the Security Authorization and Post Implementation Evaluation. This includes assurance that general support system and major application security controls are implemented and documented in compliance with ED, OMB, and NIST guidance.

Solution Source Code and Deployable Artifacts

Solution Source Code is a collection of statements or declarations written in a human-readable computer programming language.

Package the deployable code. Define prerequisites for deployment. Deployable environment both hardware and software are defined and source are provided. Dependencies are defined. Deployment procedures are unambiguously defined.

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.

Identify and define all user interfaces. Identify and define all roles. Ensure all the user interfaces are addressed. Ensure information flow is sequential.

System Boundary Template (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.

Define the system boundary and the relationship between the system and other systems where relevant.

Provide an overview of the security requirements for the system and methods by which the system will be secured. Define the upfront system actions and performance.

The System Boundary Template must define the system boundaries for and relationship between different systems and communication channels.

Element Name Definition Activities Acceptance Criteria System Retirement Plan The System Retirement Plan describes the system retirement strategy, the solution replacement and retirement requirements list, and the data/documentation plan.

Define the system retirement strategy, document the requirements necessary prior to retirement, which include solution replacement if applicable. Complete System Retirement Plan.

Stage Gate Review Body acceptance of artifacts.

System Security Plan Provides an overview of the security requirements of the system and describe 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. 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.

The System Security Plan (SSP) is either created by a contractor or by in-house resources. The ISSO is responsible to ensure it is created based on the data sensitivities, system boundaries, and controls identified for implementation. It is first drafted in the Definition phase and authorized for use prior to a system moving into production. The SSP is a living document and will be updated throughout the system's lifecycle.

The SSP will be reviewed at least annually.

The System Security Plan must provide system security requirements and describe the management, operational and technical controls in place as well as responsibilities and expected behavior of those accessing the system. It should describe general system information mapping to FIPS 199 categorization, the type of data processed, points of contact, system environment, applicable federal laws and guidelines and any sensitive information processed by the system. The System Security Plan will be approved by the FSA CISO.

Technical Stage Gate 3:

Requirements Review Briefing

This stage gate obtains agreement from key stakeholders that the requirements are ready for use by the solution delivery teams, and are sufficient to move from definition to the design phase of the project.

Stage Gate SMEs assess IPT inputs, obtain clarification when necessary and document their conclusions.

Assess risks associated with the state of product artifacts and overall project status.

IPT receives recommendation from Stage Gate governance body and approval as appropriate.

Test Reports The Test Reports provide a summary of the system test phase of the project. The reports include support materials pertaining to the software version; deviations from those areas that were agreed to in the System Test Plan. The reports give an overall assessment of the product that was tested, and provide an overall status of the incidents found during the system test activity. The test reports also include a summary of findings from business user acceptance testing.

Document test results. Identify issues that will have major impact on the success of the project. Reports address the results of testing, provides a summarization of the test effort and a final assessment.

Test Suites Test Suites outline a set of several test scenarios, test cases and test scripts for a component or system under test. Identify and create test scenarios and map to requirements. Define associated test procedures and test scripts.

All test suites and test cases are mapped back to requirements.

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.

Summarize test activities and results. Evaluate the corresponding test items against the determined exit criteria.

The Test Summary Report must summarize the system test phase of the project and include support materials related to version, deviations from the agreed upon System Test Plan. It must perform an overall assessment of the product tested and status of incidents identified during system test activity.

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.

Document the techniques and tools, training requirements, schedule, curriculum, and materials and equipment required for the training effort. Outline the training evaluation strategy and metrics.

All sections of Training Plan have been completed. The individual in charge of completing deployment has reviewed the plan, and has no questions related to deployment. The project sponsor has accepted the plan. Training deployment is successful.

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.

Summarize the user acceptance criteria and document whether the system satisfies the acceptance criteria.

Also document whether users, customers, and other authorized entities can accept the system.

The User Acceptance Test Summary Report summarizes the user acceptance test phase of the project. It must provide an overall assessment of the product tested and status of incidents occurring during user acceptance testing.

DCS LMM