Attachment_IDIQ03_EPLC_WaterfallMethodologyOverviewForContractors.pdf

Food and Drug Administration

ENTERPRISE PERFORMANCE LIFECYCLE

(EPLC)

WATERFALL METHODOLOGY OVERVIEW

Version Number: 2.0

Version Date: August 2014

VERSION HISTORY

Version Number

Implemented

By

Revision

Date

Approved

By

Approval

Date

Description of Change

1.0 Heidi Snyder 7/15/2010 Lori Davis 7/13/2010 Initial version

2.0 Greg Hoover 8/22/2014

Introduction

A key to successful IT management is a solid project management methodology that incorporates best government and commercial practices through a consistent and repeatable process, and provides a standard structure for planning, managing and overseeing IT projects over their entire life cycle. The HHS Enterprise Performance Life Cycle (EPLC) framework provides that methodology for HHS OPDIVs including FDA.

The EPLC framework consists of ten life cycle phases shown in Figure 1. Within each phase, activities, responsibilities, reviews, and deliverables are defined. Exit criteria are established for each phase and Stage Gate reviews are conducted through the IT Governance process to ensure that the project’s management quality, soundness, and technical feasibility remain adequate and the project is ready to move forward to the next phase. The EPLC framework provides a guide to Project Managers, supporting Contractors, Business Owners, IT Governance, Critical Partners, and other Stakeholders throughout the life of the project.

Figure 1

Various organizations are involved with authoring and validating the FDA EPLC project artifacts.

Projects can tailor the EPLC (number of Artifacts and Stage Gate Reviews) using the Project Process Agreement (PPA), based on the project needs and the release or project type (Figure 2).

Each EPLC Phase is described in more detail in the sections below. The EPLC Artifacts that are finalized in each phase are listed under EPLC Artifacts. Contractors may be responsible for input, validation or development of the artifacts. The artifacts that a contractor may be responsible for delivering, depending on the type of contract and contract owner, are listed under Potential Contractor Deliverables. Additionally, Contractor participation is expected during Project Readiness Reviews to prepare for Stage Gate Reviews.

INITIAL

RELEASE

DME or MAJOR

RELEASE

O&M or MINOR

RELEASE

DEFECT or EMERGENCY

RELEASE

ACTION ACTION ACTION ACTION

Boundary Document Business Provide (New Doc) Review Review Waive

Business Case Business Provide (New Doc) Review Review Waive

Project Charter IT PM and Business PM Provide (New Doc) Review Review Waive

Project Management Plan IT PM and Business Provide (New Doc) Review Review Waive

Master Test Plan IPT w/Business input for UAT Provide (New Doc) Review Review Waive

Business Requirements Document Business Provide (New Doc) Review Review Waive

Project Process Agreement (PPA) IT Project Manager (IT PM) with Business

Provide (New Doc) Provide (New Doc) Provide (New Doc) Provide (New Doc)

Project Schedule IT PM and Business PM Provide (New Doc) Provide (New Doc) Provide (New Doc) Provide (New Doc)

Logical Data Model and Data Dictionary (ERWIN) IPT Provide (New Doc) Review Review Review

System Design and Requirements Specifications IPT Provide (New Doc) Provide (Update) Provide (Update) Review

Physical Data Model and Data Dictionary (ERWIN) IPT Provide (New Doc) Review Review Review

Version Description Document (VDD) IPT Provide (New Doc) Provide (New Doc) Provide (New Doc) Provide (New Doc)

Test Cases Specifications IPT Provide (New Doc) Provide (Update) Provide (Update) Waive

Test Reports IPT Provide (New Doc) Provide (New Doc) Provide (New Doc) Waive

Implementation Plan IPT Provide (New Doc) Provide (Update) Review Review

Requirements Traceability Matrix (RTM) IPT Provide (New Doc) Provide (Update) Provide (Update) Waive

Operation and Maintenance Manual IPT Provide (New Doc) Provide (Update) Provide (Update) Waive

Security Categorization Form IPT and Business with

Security SME

Provide (New Doc) Review Review Waive

(updated annually)

Privacy Impact Analysis (PIA) Freedom of Information

(OA/OM/OS/OPILS)

Provide (New Doc) Review Review Waive

(updated annually)

E-Authentication IPT and Business with

Security SME

Provide (New Doc) Review Review Waive

(updated annually)

Systems Security Plan IPT with Security SME

Provide (New Doc) Review Review Waive

(updated annually)

Contingency and Disaster Recovery Plan IPT with Security SME Provide (New Doc) Review Review Waive

System of Records Notice (SORN) Freedom of Information

(OA/OM/OS/OPILS)

Plan of Action and Milestones IPT with Security SME

Service Level Agreement(s) and/or Memorandum(s) of Understanding TBD

(depends on content)

TBD

Training Materials IPT with inputput by Business

User Manual IPT with inputput by Business

Annual Operational Analysis Business with Input by IT PM

Disposition Plan Business with IT Support

ARTIFACTS TO PROVIDE NEW DOCUMENTS 22 4 4 3

ARTIFACTS TO PROVIDE UPDATES TO EXISTING DOCS 0 5 4 0

ARTIFACTS TO REVIEW and/or UPDATE 0 13 14 4

ARTIFACTS COMBINED 0 0 0 0

ARTIFACTS WAIVED 0 0 0 15

IT Artifacts Business Artifacts Artifact collaboration

Business and IT Security Artifacts/Other

9 5 8 7

INITIAL

RELEASE

DME or MAJOR

RELEASE

O&M or MINOR

RELEASE

DEFECT or EMERGENCY

RELEASE

HOLD WAIVE WAIVE

HOLD WAIVE WAIVE

HOLD WAIVE

HOLD HOLD WAIVE

HOLD HOLD HOLD WAIVE

HOLD HOLD WAIVE WAIVE

HOLD

HOLD

WAIVE WAIVE WAIVE WAIVE

WAIVE WAIVE WAIVE WAIVE

8 5 3 1

EPLC PROJECT LEVEL ARTIFACTS

Created when directed by Freedom of Information (OA/OM/OS/OPILS)

Created when deficiencies are found and updated when POAM findings are resolved

HOLD (COMBINE)

EPLC ARTIFACT

Requirements

EPLC ARTIFACTS SUMMARY

HOLD (COMBINE)

Initiation

EPLC RELEASE LEVEL ARTIFACTS

TIME OR EVENT DRIVEN EPLC ARTIFACTS

OPTIONAL (IF NECESSARY) ARTIFACTS

Artifact created when needed

Created when required by the contract

Created when required by the contract

FDA EPLC PROJECT PROCESS AGREEMENT

SUMMARY OF BEST PRACTICES BY RELEASE TYPE

Test

Implementation

Concept

Planning

HOLD (COMBINE) HOLD (COMBINE)HOLD (COMBINE)

AUTHOR

Artifact created annually during annual operation analysis

Artifact created when the annual operation analysis determines system is ready for disposition

Operations and Maintenance

Disposition

STAGE GATE REVIEW SUMMARY

FDA EPLC BASELINE PROJECT PROCESS AGREEMENT (PPA)

ARTIFACT AUTHOR SUMMARY

STAGE GATE

STAGE GATE REVIEWS

Design

Development

Figure 2

Initiation Phase

Overview:

During the Initiation Phase, a Business Owner identifies a business need for which a technological solution is required and a preliminary enterprise architecture review is conducted to determine if there is sufficient justification to proceed into the Concept Phase. The Initiation Phase may be triggered as a result of business process improvement activities, changes in business functions, advances in information technology, or may arise from external sources, such as public law or the general public.

When an opportunity to improve business/mission accomplishments or to address a deficiency is identified, the Business Owner and/or Business Project Manager document these opportunities in the Business Needs Document. Sufficient high-level functional requirements are required to understand what the project is intended to do and how it supports the business needs.

The Initiation Phase ends with a review to determine readiness for Critical Partner review during the Initiation Stage Gate Review.

Outcome:

The outcome of the Initiation Phase is the decision to invest in a full business case analysis and preliminary project management plan.

EPLC Artifacts:

Business Needs Document

Potential Contractor Deliverables:

Business Needs Document

Concept Phase

Overview:

The Concept Phase begins after the Initiation Stage Gate Review occurs and the Business Needs Document is approved to enable a new business process or enhance an existing business process through the application of information technology. The purposes of the Concept Phase are to:

Identify and validate an opportunity to improve business accomplishments of the organization or to correct a deficiency related to a business need.

Identify significant assumptions and constraints on solutions relative to that need.

Explore alternative concepts and methods to satisfy the need.

Establish project sponsorship / ownership

Develop and establish the Business Requirements

Determine IPT staffing requirements for the project

Document all the considerations of Privacy Act

In the Concept Phase, sufficient requirements detail is developed to support the detailed cost and schedule estimates, alternatives analyses, and other elements of the Business Case and preliminary Project Management Plan.

The Concept Phase ends with a review to determine readiness for Critical Partner review during the Concept Stage Gate Review.

The outcome of the Concept Phase is the proposal and approval of a high level Rough Order of Magnitude; approval of initial project cost, schedule and performance baselines; and issuance of a Project Charter; and the documentation and prioritization of Business Requirements.

Business Case Project Security Categorization Privacy Impact Analysis (PIA) System of Records Notice (SORN) E-Authentication Project Charter Business Requirements Document

Business Requirements Document

Planning Phase

Overview:

The Planning Phase begins after the Concept Stage Gate Review when the project has been formally approved and funded, and the Project Charter is approved. This Phase requires study and analysis culminating in the full Project Management Plan. Specific plans for management and governance of the project are established and documented to guide ongoing project execution and control. The degree of project management rigor that is to be applied to the project is determined, the EPLC is tailored (via the Project Process Agreement), project work is broken down into specific tasks and sub-tasks, and milestones are established.

The Planning Phase ends with a readiness review to determine if sufficient project plans have been defined and are ready for Critical Partner review during the Planning Stage Gate Review.

Outcomes of the Planning phase are complete and adequate project planning artifacts including refinement of project cost, schedule and performance baselines.

Project Process Agreement Project Management Plan Project Schedule

Project Management Plan (contract specific) Project Schedule (contractor activities)

Requirements Analysis Phase

Overview:

During the Requirements Analysis Phase, the business requirements that were documented during the Concept Phase are validated and decomposed into functional and non-functional requirements.

These requirements define the Business Product in more detail with regard to inputs, processes, outputs, and interfaces, and permit further detailed project management planning.

The Requirements Analysis Phase ends with a readiness review to determine if the requirements have been defined sufficiently and are ready for Critical Partner review during the Requirements Analysis Stage Gate Review.

The outcome of the Requirements Analysis Phase is to develop and prioritize detailed functional and non-functional requirements.

Logical Data Model and Logical Data Dictionary (ERWIN) System Requirement Specifications (if done separately) Requirements Traceability Matrix (tracing Business Requirements to technical requirements) Data Dictionary

Logical Data Model and Logical Data Dictionary (ERWIN) System Requirement Specifications (if done separately) Requirements Traceability Matrix (tracing Business Requirements to technical requirements) Data Dictionary

Design Phase

Overview:

The Design Phase seeks to develop detailed specifications that emphasize the physical solution to the end user's information technology needs for a particular release. The system requirements and logical description of the entities, relationships, and attributes of the data that were documented during the Requirements Analysis Phase are further refined and allocated into system and database design specifications that are organized in a way suitable for implementation within the constraints of a physical environment (e.g., computer, database, facilities).

The Design Phase may include a review prior to detailed design of the Business Product to achieve confidence that the design satisfies the system requirements, is in conformance with the enterprise architecture and prescribed design standards. The Design Phase ends with a readiness review to determine if the design is ready for Critical Partner review during the Design Stage Gate Review.

The outcome of the Design Phase is completion of the Business Product design and successful completion of Preliminary and Detailed Design Reviews.

System Design Document (if done separately) Physical Data Model and Physical Data Dictionary (ERWIN) Interface Control Document (ICD) (if done separately) Requirements Traceability Matrix (tracing requirements to design) Systems Security Plan System Architecture Document (if done separately)

System Design Document (if done separately) Physical Data Model and Physical Data Dictionary (ERWIN) Interface Control Document (ICD) (if done separately) Requirements Traceability Matrix (tracing requirements to design) Systems Security Plan System Architecture Document (if done separately)

Development Phase

Overview:

During the Development Phase, the system developer takes the detailed design information documented in the previous phase and transforms it into machine-executable form, and ensures that all of the individual components of the Business Product function correctly and interface properly with other components within the system/application. As necessary and appropriate, system hardware, networking and telecommunications equipment, and COTS/GOTS software is configured. New custom-software programs are developed, database(s) are built, and software components are integrated. Test data and test case specifications are finalized. Unit and integration testing is performed by the developer with test results appropriately documented. Data conversion and training plans are finalized and user procedures are baselined, while operations, office and maintenance procedures are also initially developed.

The Development Phase ends with a readiness review to determine if the system has been sufficiently developed and associated artifacts are ready for Critical Partner review during the Development Stage Gate Review.

The outcome of the Development Phase is completion of all coding and associated documentation;

user, operator and maintenance documentation, and test planning.

Requirements Traceability Matrix (RTM) (tracing design to code) Release Test Plan Rel x.xx Test Cases Specifications Rel x.xx Version Description Document (VDD) (release package)

Requirements Traceability Matrix (RTM) (tracing design to code) Release Test Plan Rel x.xx Test Cases Specifications Rel x.xx Version Description Document (VDD) (release package)

Test Phase

Overview:

The primary purpose of the Test Phase is to determine whether the Business Product developed or configured during the Development Phase is ready for implementation. During the Test Phase, formally controlled and focused testing is performed to uncover errors and bugs in the Business Product that need to be resolved. There are a number of specific validation tests that are performed during the Test Phase (e.g., requirements validation, system integration, interface, regression, information security, performance, stress, 508 compliance, and user acceptance).

The Test Phase ends with a readiness review to determine if the results of testing the system meet the defined exit criteria as described in the Master Test Plan, and associated artifacts are ready for Critical Partner review during the Development Stage Gate Review.

The outcome of the Test Phase is completed testing, including user acceptance testing, and readiness for implementation and training.

Requirements Traceability Matrix (RTM) (tracing code to test cases) Test Reports Project Implementation Plan Training Materials User Manual

Requirements Traceability Matrix (RTM) (tracing code to test cases) Test Reports Project Implementation Plan Training Materials User Manual

Implementation Phase

Overview:

During the Implementation Phase, the Business Product is moved from the Test environment status to the production environment. The process of implementation is dependent on the characteristics of the project and the Business Product, and thus may be synonymous with installation, deployment, rollout, or go-live. If necessary, data conversion, phased implementation, and training for using, operating, and maintaining the system are accomplished during the Implementation Phase. The final system must be certified and accredited before use in the production environment.

The Implementation Phase ends with a readiness review to ensure that all artifacts are ready for Critical Partner review during the Implementation Stage Gate Review. The Implementation Stage Gate review may result in:

Approval of going live with the current release and go back to the Planning Phase for the next release; or

Approval of going live with the current release and approval to move the project to the Operations and Maintenance (O&M) Phase where O&M releases for bug fixes and maintenance occur

The outcome of the Implementation Phase is successful implementation of the current release into production and a decision as to whether additional new development will be done or movement to O&M status.

Operations & Maintenance (O&M) Manual Contingency and Disaster Recovery Plan Service Level Agreement(s) (SLAs) / Memorandum(s) of Understanding (MOUs)

Operations & Maintenance (O&M) Manual Contingency and Disaster Recovery Plan Service Level Agreement(s) (SLAs) / Memorandum(s) of Understanding (MOUs)

Operations & Maintenance Phase

Overview:

During the Operations & Maintenance (O&M) Phase, the certified and accredited Business Product operates in full-scale production environment for sustained use with releases for bug fixes and maintenance. Major changes to the scope will require the project to return to Initiation Phase for modifications to the Boundary Document. Major changes to the product that are within scope will require a new development release and therefore require the project to return to the Planning Phase.

Periodically the Business Product will also need to be re-certified and re-accredited for continued operation in the production environment. When the time comes that the Business Product will no longer be needed or will be replaced, then a plan for final disposition of the Business Product must be prepared and approved prior to moving into the Disposition Phase.

The outcome of the Operations and Maintenance Phase includes ensuring all processes, manual and automated, are documented in the operating procedures, as well as successful operation of the system against current cost, schedule and performance benchmarks.

Plan of Action and Milestones Annual Operational Analysis Disposition Plan

Potential Contractor Deliverables:

Plan of Action and Milestones Annual Operational Analysis Disposition Plan

Disposition Phase

Overview:

During the Disposition Phase, the operation of a Business Product is formally ended in accordance with organization needs and pertinent laws and regulations. The Business Product is retired or disposed of based on the formal Disposition Plan approved during the Operations & Maintenance Phase. The disposition activities ensure the orderly termination of the Business Product and preserve vital information about the system so that some or all of the information may be reactivated in the future if necessary. Particular emphasis is given to proper preservation of the data processed by the Business Product, so that the data is effectively migrated to another Business Product or archived in accordance with applicable records management regulations and policies for potential future access.

The outcome of the Disposition Phase is the deliberate and systematic decommissioning of the Business Product with appropriate consideration of data archiving and security, migration of data or functionality to new assets, and incorporation of lessons learned over the project life cycle.

None

None