Clarification_-_003_-_Final_-_1-16-15.pdf

U. S. DEPARTMENT OF COMMERCE

U.S. CENSUS BUREAU

RFI-Enterprise Systems Architecture, Engineering, Development and

Integration Clarification #003

1/16/2015

RFI Clarification #003

Supplemental Information for RFI #YA1323-15-RFI-ESF2 (USCB Enterprise Systems

Architecture, Engineering, Development and Integration Support Services)

REFERENCE SUPPLEMENTAL INFORMATION

DRAFT

PERFORMANCE

WORK

STATEMENT-(para

C.3 Objectives)

The draft performance work statement includes a reference to USCB standards and policies. As supplemental information to this RFI the USCB is providing the most current versions of both the

Census Enterprise Systems Development Life Cycle-

User Guide and the Census Enterprise Architecture

Policy. These documents are considered living documents and are updated periodically. They are being provided to enhance vendor understanding of the USCB environment. See attached supplemental documents.

Enterprise Systems Development Life Cycle

Template Version 1.0

SDLC USER GUIDE

DOCUMENT REVISION HISTORY

[Use the table below to record information regarding changes made to the document over time.]

Version Date Revision Description Author

10/2013 Version 1.0 ii

TABLE OF CONTENTS

Document Approval ............................................................. Error! Bookmark not defined.

Document Revision History .............................................................................................. ii Table of CONTENTS ...................................................................................................... iii 1 Introduction

1.1 DOCUMENT PURPOSE

1.2 ENTERPRISE SDLC SCOPE

2 Overview of the Enterprise SDLC

2.1 QUICK START GUIDE

2.1.1 Understand the Enterprise Systems Development Life Cycle (SDLC)

2.1.2 Develop and document a tailoring plan for your project

2.1.3 Apply the Enterprise Systems Development Life Cycle to your project

2.2 ROLES AND RESPONSIBILITIES

2.3 ENTERPRISE SDLC ARTIFACTS

2.3.1 Purpose of Artifacts

2.3.2 Using the Templates

2.3.3 Review and Approval of Artifacts

2.4 PHASE REVIEW AND APPROVAL

2.4.1 Phase Review Preparation

2.4.2 Project Phase Review

2.4.3 Project Phase Approval

3 Methodologies

3.1 WATERFALL METHODOLOGY

3.1.1 Initiation Phase

3.1.2 Concept Development Phase

3.1.3 Planning Phase

3.1.4 Requirements Phase

3.1.5 Design Phase

3.1.6 Development Phase

3.1.7 Integration and Test Phase

10/2013 Version 1.0 iii

3.1.8 Deployment Phase

3.1.9 Operations and Maintenance Phase

3.1.10 Disposition Phase

3.2 AGILE METHODOLOGY

3.2.1 Initiation Phase

3.2.2 Concept Development Phase

3.2.3 Sprint 0 Phase

3.2.4 Sprint 1-N (Continuous) Phase

3.2.5 Release Phase

3.2.6 Operations and Maintenance Phase

3.2.7 Disposition Phase

3.3 CONDITIONAL ARTIFACTS

3.3.1 Conditional Enterprise SDLC Artifacts – Waterfall Methodology

3.3.2 Conditional Enterprise SDLC Artifacts – Agile Methodology

4 Tailoring

4.1 TAILORING SELECTION

4.2 CORE TAILORING GUIDANCE

WATERFALL PROJECT TAILORING

AGILE PROJECT TAILORING

4.3 ADDITIONAL TAILORING GUIDANCE

4.3.1 Additional Tailoring Guidance for Architecture Review Board

4.3.2 Additional Tailoring Guidance for Agile Projects

5 SDLC Maintenance intervals

Enterprise Agile Methodology .......................................................... 95 APPENDIX A “Agile EVM at Census” ...................................................................... 96 APPENDIX B

10/2013 Version 1.0 iv

1 INTRODUCTION

This Census Bureau Systems Development Life Cycle User Guide provides Census Directorates and Operating Units with detailed information about the Census Bureau Enterprise Systems Development Life Cycle (SDLC) methodology. The Enterprise SDLC serves as an organized process model for initiating, defining, planning, analyzing, designing, developing, testing, implementing, and continuing support of a system or solution. The Enterprise SDLC organizes all project and system engineering activities in a logical sequence to make the process easier to manage. The purpose of the Enterprise SDLC is to provide a structured framework against which project and system development activities occur. Employing a structured framework facilitates coordination, control and management of all project and system development efforts, including the development of new systems or solutions and enhancements to existing systems.

1.1 Document Purpose

The Enterprise SDLC emphasizes the activities needed to successfully execute a project and ultimately to accomplish the program, and to define the documentation needed to ensure communication between all groups during the development effort (which also serves as a historical record of the development effort at given points in the life cycle.) This User Guide is designed to help you comply with Census Bureau policy in the development and delivery of Census Bureau projects and to execute widely-accepted industry best practices. The processes, tools, techniques, and templates are designed to facilitate a successful development and deployment of a system or solution and to satisfy project and program requirements. This User Guide identifies the phases of the Systems Development Life Cycle and describes the associated responsibilities, activities, deliverables, and reviews associated with each phase.

After reviewing this User Guide and by using it to develop and deploy systems, solutions, software and related components, you should be able to:

• Understand the activities and tasks within the Enterprise SDLC

• Understand how the to employ the Enterprise SDLC

• Identify the deliverables and phase gates required for compliance with Census Bureau policy and standards.

1.2 Enterprise SDLC Scope

As of October 1, 2013, all new information technology systems development projects at the Census Bureau must use the Enterprise SDLC.

A project is a defined effort with a beginning and an end and requires dedicated management to ensure its success. A project could be focused on developing a new capability or it could be the modernization or upgrade of an existing capability. 1

1 Definition of a project from Commerce Acquisition Framework definitions.

10/2013 Version 1.0 1

A system is a collection of components and/or activities organized to accomplish a specific function or set of functions (adapted from Institute of Electrical and Electronics Engineers Glossary of Software Engineering Terminology, p.73) 2

New means the project has not yet been chartered using a previous process.

The process described in this document is required for all system development activities and solutions across all directorates at the Census Bureau including the following:

• Modification to existing functionality for existing systems or solutions;

• Addition of new functionality to existing systems or solutions; and

• Creation of new systems or solutions

• Creation or modification of a system by a contracted resource Tailoring guidance provided later in this document will describe how to right-size the documentation and oversight based on the project type, methodology, and level however all system development projects should be following a path of the Enterprise SDLC.

2 Definition of a system from Commerce Acquisition Framework definitions.

10/2013 Version 1.0 2

2 OVERVIEW OF THE ENTERPRISE SDLC

In order to use the Enterprise SDLC, you must have a general understanding of your project’s size, risks, costs as well as the ability to determine which project type and methodology best represents your project. This information will allow you to use the available documentation to determine what path through the Enterprise SDLC your project must take.

2.1 Quick Start Guide

This Quick Start Guide is a useful reference for locating the templates and guidance you need to develop and document your system according to the Census Bureau’s Enterprise System Development Life Cycle (SDLC).

2.1.1 Understand the Enterprise Systems Development Life Cycle (SDLC).

• The Enterprise SDLC begins with project initiation and ends when the developed system is dispositioned.

o The SDLC process for Waterfall projects consists of 10 distinct phases, each requiring specific artifacts and reviews before the project can move forward to the next phase.

o The SDLC process for Agile projects combines the Waterfall phases to satisfy the spirit of Agile. Each phase requires specific artifacts and reviews before the project can move forward to the next.

• The Enterprise SDLC Calendar provides a guide to the artifacts, key decision points, and reviews to keep your project on track. In addition, the calendar describes what activities take place in each phase and which stakeholder groups you should consider including.

• The Enterprise SDLC Waterfall Traceability Matrix and Enterprise SDLC Agile Traceability Matrix show which artifacts are drafted in each phase of the SDLC, and indicate which are mandatory for the successful completion of a phase.

• The calendars and the matrixes document the requirements for the largest new development efforts. Tailoring these to your specific projects is described below.

2.1.2 Develop and document a tailoring plan for your project.

• Every project should be tailored so the amount of documentation and frequency of review suits the project. Use the SDLC Tailoring Selection Tool to determine the project type, methodology, and level for your project. Use this criteria and the SDLC Tailoring Guidance document to determine the level of documentation and oversight that your project warrants.

• Complete the Tailoring Plan section of the Project Charter to reflect specifics for your project based on the provided guidance and get it approved by the appropriate parties.

2.1.3 Apply the Enterprise Systems Development Life Cycle to your project

• If you need further assistance applying the Enterprise SDLC:

10/2013 Version 1.0 3 o Contact the Enterprise SDLC Center of Excellence for one-on-one coaching for you or your project team at ASD Enterprise SDLC@census.gov o Attend Enterprise SDLC training

2.2 Roles and Responsibilities

There are four categories of roles and responsibilities used throughout the Enterprise SDLC documentation. Each role type is further broken down by phase to indicate more specific roles and responsibilities.

Role Responsibilities

Project Team The roles associated with the project team are main responsible and accountable parties for the successful development and deployment of the system. They provide key roles throughout the life of the development effort.

Contributors The roles associated with the contributors provide additional input to the project team as necessary throughout the phases.

Reviewers The roles associated with the reviewers are responsible for reviewing project documentation to ensure compliance with various enterprise standards and providing feedback to the project team for incorporation prior to approval.

Approvers The approval roles are responsible for reviewing the project’s progress through the phase, evaluating the risks and benefits of continuing to the next phase, and providing approval to continue with the project.

2.3 Enterprise SDLC Artifacts

2.3.1 Purpose of Artifacts

Enterprise SDLC artifacts are designed to document systems throughout the Census Bureau in a standard way to ensure successful development and deployment. These common artifacts will allow for a streamlined review by all required parties no matter the size or scope of the development effort. Using common practices across the Bureau to develop and document systems will also allow for easier reuse and repurposing of systems as well as transition of staff from one area in the Bureau to another. The artifacts within the Enterprise SDLC MAY NOT be replaced with a functional equivalent. The subsection below will provide additional information on how to complete the templates.

2.3.2 Using the Templates

Each template includes instructions to the author, boilerplate text, and fields that must be replaced with the values specific to the project.

10/2013 Version 1.0 4 mailto:ASD%20Enterprise%20SDLC@census.gov

• Blue italicized text enclosed in square brackets ([text]) provides instructions to the document author, or describes the intent, assumptions and context for content included in this document.

• Blue italicized text enclosed in angle brackets (<text>) indicates a field that should be replaced with information specific to a particular project.

• Text and tables in black are provided as boilerplate examples of wording and formats that may be used or modified as appropriate to a specific project. These are offered only as suggestions to assist in developing project documents; they are not mandatory formats.

• When using this template to develop your project document, it is recommended that you create and manage the content of each section in a single place so it is easy to reuse content in documents in future phases.

To update the document:

1. Replace all text enclosed in angle brackets (e.g., <Project Name>) with the correct field values. These angle brackets appear in both the body of the document and in headers and footers. To customize fields in Microsoft Word (which display a gray background when selected):

a. Select File>Properties>Summary and fill in the Title field with the Document Name and the Subject field with the Project Name.

b. Select File>Properties>Custom and fill in the Last Modified, Status, and Version fields with the appropriate information for this document.

c. After you click OK to close the dialog box, update the fields throughout the document with these values by selecting Edit>Select All (or Ctrl-A) and pressing F9. You can update an individual field by clicking on it and pressing F9. This must be done separately for Headers and Footers.

2. Modify boilerplate text as appropriate to the specific project.

3. Do not delete sections from the template. If a section does not pertain to your project, indicate that it is not applicable and provide a brief explanation. For example, “This section is not applicable because this project will not develop software.”

4. To maintain consistency across the templates for all projects and facilitate Phase Gate Reviews, add new sections following the last template section and before the first Appendix. When adding new sections to the document, ensure that the appropriate header and body text styles are maintained. Styles used for the Section Headings are Heading 1, Heading 2 and Heading 3. Style used for boilerplate text is Body Text.

5. To update the Table of Contents, right-click and select “Update field” and choose the option- “Update entire table”]

10/2013 Version 1.0 5

2.3.3 Review and Approval of Artifacts

After artifacts are completed, they should be routed and approved by all necessary parties as documented in your project tailoring plan (section 3 of the project charter). The Enterprise SDLC does not require any sort of routing and approval process of documents, so areas may continue to use methods they have employed in the past.

2.4 Phase Review and Approval

In order to successfully pass to a subsequent phase in the Enterprise SDLC, a project team must receive appropriate phase review and approvals as defined in their project tailoring plan (section 3 of the Project Charter).

2.4.1 Phase Review Preparation

Prior to phase review, the project team should review the project’s tailoring plan and ensure all necessary artifacts have been created and approved as documented.

2.4.2 Project Phase Review

In order to streamline phase reviews by the necessary IT directorate representatives, the Enterprise SDLC COE will coordinate all necessary reviewers. The Enterprise SDLC COE will meet every Tuesday afternoon from 3-5 to review submitted projects to ensure any outstanding issues requiring attention prior to final phase approval are brought to the attention of the project team.

To submit your project for Enterprise SDLC COE Phase Review:

1. Access the Enterprise SDLC COE Phase Review site at https://collab.ecm.census.gov/teamsites/sdlc/intranet/Pages/SDLC_COE_Phase_Re view.aspx

2. Determine which Enterprise SDLC Phase Review meeting on the calendar you would like to attend.

3. Select Add on the selected date.

4. In the pop-up window, fill in your “Project Title”, “Review Start Time” and “Review End Time”. Make sure your selected time is an available 15 minute increment during the schedule meeting.

5. Select the “Attach File” icon to upload the documents you want the SDLC COE to review. Upload the documentation relevant to your phase review. Please refer to your project tailoring plan to ensure all necessary artifacts are submitted.

6. Click “Save”.

The Enterprise SDLC COE review team will provide any comments to the project team by COB the Wednesday following the review. Comments will either indicate acknowledgement the review team feels the project is ready to move to the next phase or a recommendation not to

10/2013 Version 1.0 6 https://collab.ecm.census.gov/teamsites/sdlc/intranet/Pages/SDLC_COE_Phase_Review.aspx https://collab.ecm.census.gov/teamsites/sdlc/intranet/Pages/SDLC_COE_Phase_Review.aspx move to the next phase until a specific set of comments are addressed. This information will be available to the SDLC phase approvers who should consider it, along with other factors during their final review and approval.

2.4.3 Project Phase Approval

Below is a checklist that will be provided by the project team to their phase approval board for consideration and sign off of approval prior to moving to a subsequent phase. Project teams should use their existing processes for routing information to their approval boards.

SDLC APPROVERS CHECKLIST

PROJECT NAME: ___________________________

PHASE: ____________________________________

Refer to the project tailoring plan to determine which artifacts are in scope in each phase.

1. Have any new risks or potential scope changes been identified?

2. Are there issues that may prevent project success at this point? (i.e., resource availability)

3. Have you engaged other areas of the Census Bureau as identified in the project tailoring plan (i.e., Office of Information Security (OIS), Privacy Office, Enterprise Architecture (EA), etc.)

4. Have all mandatory artifacts identified in the project tailoring plan been initiated?

5. Have the conditional artifacts identified in the project tailoring plan been initiated?

6. Were all documents reviewed as required by the project tailoring plan?

7. Are there any outstanding comments from phase reviewers that have not incorporated?

If so, why?

8. Were lessons learned captured during this phase?

APPROVED BY: _____________________________________

DATE: _____________________________________________

10/2013 Version 1.0 7

NOT APPROVED (State corrective action to be taken)

10/2013 Version 1.0 8

3 METHODOLOGIES

Project Managers and Project Sponsors, along with their technical leads, are responsible for selecting the development methodology best suited to address the objectives and risk profile of the project. Use the guidance below to determine which methodology best fits your project. As part of the selection process, the business requirements, risks, operational, environment, and organizational impact should be considered.

Waterfall Methodology Each phase of the project must follow a sequential and linear progression. Consider using this approach when the project requirements are very well understood, the system is relatively small, incremental capability is not required, or there isn’t a need to produce the system in the shortest possible time.

WATERFALL METHODOLOGY

Application Advantages Disadvantages

Useful when requirements are:

• Well understood at project start

• Not expected to change/evolve over life of project

• Project risk is relatively low

• Project costs and schedule estimates tend to be less relative to other methodologies and project management is less complex

• All risks must be dealt with in a single development cycle

• Any early stage errors in requirements or design can feed through to later stages

• A working product is not available until late in the project cycle

• Any errors in the design or deployment will not be discovered until late in the delivery of the system, and may have to wait until the maintenance phase to be corrected

Agile Methodology An agile development project evolves to its ultimate capabilities on the basis of mature technologies and available resources. Final capability has been identified; but the end-state system requirements are not known and are refined through short iterations. Emphasis is on learning and requirements discovery.

AGILE METHODOLOGY

Application Advantages Disadvantages

10/2013 Version 1.0 9

• Projects that need early delivery of functionality

• Requirements are not clearly understood at the beginning of the project

• Systems that benefit from feedback of earlier cycles

• Allows organizations to develop and produce more sophisticated products faster and less expensively than their predecessors

• Early stage errors are correctable in later iterations

• Can rapidly adapt to changes in program requirements

• Delay of full functionality -all product features and capabilities may not be achieved in the initial development

• Features must be planned for development in the product’s future, when the technology has proven mature and other resources are available

3.1 Waterfall Methodology

INITIATION

CONCEPT

DEVELOPMENT

PLANNING REQUIREMENTS DESIGN DEVELOPMENT

INTEGRATION &

TEST

DEPLOYMENT

OPERATIONS &

MAINTENANCE

DISPOSITION

PHASE

PURPOSE

Business identifies a need or opportunity that is aligned with organization's strategy and defines the benefits of the proposed investment.

Goals and objectives of the system are identified and the feasibility of the system is established.

Scope and boundaries of concept solution are defined.

Planning documents are developed to guide the work on the project.

Requirements based on business and user needs are elicited and documented.

Requirements are translated into logical and technical solution design that will deliver functionality.

Design is transformed into a complete product.

System is integrated into the environment.

Product functionality is tested and verified against business and technical requirements.

System, users, and other stakeholders are prepared for production use.

System is in service, maintained, and managed at defined levels.

The Disposition Plan is executed.

PHASE GATE

REVIEW

SUCCESSFUL

OUTCOME OF

PHASE

Approved proposals are granted the authority to develop a detailed business case and concept of operations.

A project is chartered and resources are allocated to the project.

The project schedule is baselined and risk register is created.

Project requirements are validated.

System design and detailed specifications are approved.

Component(s) are built (and assembled).

The system is proven to function as expected and satisfies business and technical requirements.

The system is promoted to production environment.

Project is closed out.

Work continues to ensure that the system meets the stakeholder needs and continues to perform at defined levels.

This phase will continue as long as the system is in use.

System is retired or replaced.

10/2013 Version 1.0 10

10/2013 Version 1.0 11

3.1.1 Initiation Phase

During the Initiation Phase, a Business Owner describes the business need for which a technological solution is required and a preliminary review is conducted to determine if there is sufficient justification to proceed into the Concept Development Phase. The Initiation Phase may be triggered because 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.

Phase Purpose: Business identifies a need or opportunity that is aligned with the organization’s strategy and defines the benefits of the proposed investment.

3.1.1.1 Stakeholder Responsibilities

• Project Team:

o Project Sponsor: Champions the project. Defines business need, owns requirements, and secures funding.

o Project Manager: May or may not be assigned at this time but has responsibility for performing the Project Phase Gate Review. Follows established project management practices and meets the Business Owner’s needs. Ensures that the project is technically sound.

o Portfolio Manager: Collaborates with Project Sponsor and Project Manager to define scope and provide Project Management guidance.

• Contributors o There are no additional contributors for this phase.

• Reviewers o Enterprise Architecture: Ensures business driven, non-duplicative technology solutions are developed where feasible.

• Approvers o Portfolio Management Governing Board: Verifies initial scope will adequately address a mission or strategic need and adequate financial resources are available to conduct Concept Development Phase.

3.1.1.2 Phase Activities

• Determine in the project aligns with organization’s mission and strategic goals

10/2013 Version 1.0 12

• Identify and validate an opportunity to improve business accomplishments or to correct a deficiency related to a business need

• Review ORMPE Investment Management guidance and lessons learned from other projects

• Identify opportunities for shared services

• Justify developing a Detailed Business Proposal

3.1.1.3 Phase Artifacts

Artifact Description

Initial Business Proposal

The Project Sponsor prepares the Initial Business Proposal during the Initiation phase. The Initial Business Proposal is mandatory for all projects and may not be tailored; all sections are required.

The Initial Business Proposal outlines what the investment/project (hereafter referred to as the “project”) is about, what benefits it will provide, and how it aligns with the goals and objectives of the organization.

3.1.1.4 Phase Review and Approval

Successful Outcome: Approved proposals are granted the authority to develop a detailed business case and concept of operations.

3.1.2 Concept Development Phase

The Concept Development Phase begins when the Governance organization approves the Initial Business Proposal to enable a new business process or enhance an existing business process through the application of information technology. The purpose of the Concept Development Phase is 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.

In the Concept Development Phase, sufficient requirements detail is developed to support the detailed cost and schedule estimates, alternatives analyses, and other elements of the Detailed Business Proposal. The primary outcome of the Concept Development Phase is the approval of a high level Rough Order of Magnitude (ROM) and signature of a charter initiating a project.

Phase Purpose: Goals and objectives of the system are identified and the feasibility of the system is established. Scope and boundaries of concept solution are defined.

10/2013 Version 1.0 13

3.1.2.1 Stakeholder Responsibilities

• Project Team:

o Project Sponsor: Champions the project, defines business need, owns requirements, secures funding.

o Project Manager: Writes and delivers Detailed Business Proposal and Project Charter, coordinate all activities of the phase.

o Portfolio Manager: Assists with Detailed Business Proposal and Project Charter development.

o Technical Lead: Develops solution and validates the technical content in the Detailed Business Proposal and Project Charter.

• Contributors o ISSRO: Assists with and coordinates acquisition and purchasing activities to obtain IT services and products (as needed)

• Reviewers:

o Enterprise Architecture: Ensures project outcomes advance or align to the target architecture o System Engineering: Ensures solution is viable, complete and meets performance timelines and business objectives. Ensures technical risks are identified.

o Information Security: Informs and advices the project team regarding relevant security requirements.

o SDLC COE: Works with project leadership team to tailor SDLC.

• Approvers o Portfolio Management Governing Board: Determines if the project has been clearly defined and has the supporting organizational structure to proceed with full planning and is worthy of funding.

o IT Investment Review Board: Determines if the project has been clearly defined and has the supporting organizational structure to proceed with full planning and is worthy of funding.

o Department of Commerce: Reviews projects that meet DOC high profile criteria (see DOC Scalable Acquisition Framework)

3.1.2.2 Phase Activities

• Identify significant assumptions and constraints relative to the business need

• Explore alternative concepts and methods to satisfy the need

10/2013 Version 1.0 14

• Confirm project sponsorship/ownership

• Develop and establish the Detailed Business Proposal (including business case, concept of operations, and cost and staffing ROMs) for the project

• SDLC COE applies tailoring guidance to the project to specify project deliverables and formal review process

• Develop the Project Charter for approval

3.1.2.3 Phase Deliverables

Artifact Description

Detailed Business Proposal

The Project Sponsor prepares the Detailed Business Proposal during the Concept Development phase. The Detailed Business Proposal is mandatory for all projects and may not be tailored; all sections are required.

The Detailed Business Proposal provides information that allows the governance authority to make a decision on whether or not the project should be chartered. It follows the Initial Business Proposal and includes more detailed information on scope, cost, and resources, gathered during initial research about project feasibility.

Project Charter The Project Manager prepares the Project Charter during the Concept Development phase. The Project Charter is mandatory for all projects; the only section that may be tailored is “Commitments to External Stakeholders,” which may not be applicable.

The Project Charter is the instrument used to grant the project manager the authority to take responsibility of the project. It is used to document and communicate the purpose, scope, resources, and milestones for the project. Approval and sign-off by senior management is required.

3.1.2.4 Phase Review and Approval

Successful Outcome: A project is chartered and resources are allocated to the project.

3.1.3 Planning Phase

The Planning Phase begins 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 and that may lead to system development activities.

10/2013 Version 1.0 15

If contractor support will be necessary, then acquisition plans should be developed. The project work is broken down into specific tasks and sub-tasks, referred to as a work breakdown structure, including the identification of project deliverables and assignment of allocated resources to each task. Control documents relating to that effort are produced. The degree of project management rigor that is to be applied to the project is determined and milestones are established. Specific plans for management and governance of the project are established and documented to guide ongoing project execution and control. The Planning Phase ends with a formal review during which the adequacy of the Project Management Plan is determined.

In the planning phase, sufficient requirements detail is required to support the development of the project’s PMP and permit outside validation of this deliverable.

Phase Purpose: Planning documents are developed to guide the work on the project.

3.1.3.1 Stakeholder Responsibilities

• Project Team:

o Project Sponsor: Participates in planning activities and reviews/approves all planning documents o Project Manager: Oversees and directs all phase activities, develops schedule, risk register and other project related artifacts.

o Portfolio Manager: Participates in planning activities. Reviews/approves PMP and schedule.

o Technical Lead: Develops SEMP, Deployment Plan, and conditional technical documents.

• Contributors o ISSRO: Assists with and coordinates acquisition and purchasing activities to obtain IT services and products (as needed) o Acquisition: Guides PM/Contracting Officer Representative (COR) with acquisition activities to obtain contact support)

• Reviewers:

o Enterprise Architecture: Ensures compliance with Enterprise Architecture policy o System Engineering: Ensures technical management processes, controls and policies are well defined and reflect best practices.

o Information Security: Informs and advices the project team regarding relevant security requirements.

o SDLC COE: Verifies the project deliverables comply with the tailoring plan.

o Policy Coordination Office: Reviews Privacy Threshold Analysis and completes the Privacy Impact Assessment (as needed).

10/2013 Version 1.0 16

• Approvers o Portfolio Management Governing Board: Renders a Go/No-Go decision whether to proceed to the next phase.

o IT Investment Review Board: Renders a Go/No-Go decision whether to proceed to the next phase o Department of Commerce: Reviews projects that meet DOC high profile criteria (see DOC Scalable Acquisition Framework)

3.1.3.2 Phase Activities

• Create and approve the Project Management Plan (PMP) and associated plans (e.g.

Acquisition Strategy, risk register, etc.)

• Build, approve, and baseline the project schedule, and validate budget estimates

• Identify and assess project risks in accordance with ORMPE risk management guidance

• Engage information security engineers to create Risk Profile to address information security concerns

• Create and approve Systems Engineering Management Plan (SEMP)

• Determine which of the conditional planning documents (e.g., IT Product Request, Software Approval Request, etc.) are required based on project conditions (e.g., new applications, new COTS product needs, etc.) and create/submit as necessary

• Capture lessons learned from this phase

3.1.3.3 Phase Deliverables

Artifact Description

Project Management Plan (PMP)

The Project Manager prepares the PMP during the Planning phase. The PMP is a mandatory artifact for all projects. It may be tailored to be commensurate with the project scope and objectives. The following sections may reference other documents that provide the requested information in lower levels of detail, may be combined as the Project Manager determines reasonable, or may be deemed not applicable:

• Project Staff Training Plan

• Stakeholder Training Plan

• Start-Up Plans

• Acquisition Plan

• Schedule Management Plan

10/2013 Version 1.0 17

Artifact Description

• Metrics Collection Plan

• Enterprise IT Change Management Plan

• Process Improvement Plan

The PMP is one of several key project-planning documents that use a building-block approach to planning. It is a vehicle for documenting project scope, tasks, schedule, allocated resources, and interrelationships with other projects. It also provides details on the involved functional units, required job tasks, cost and schedule performance measurement, and milestone and review scheduling. Revisions to the PMP occur at the end of each life cycle phase and as information becomes available. The size of the PMP should be commensurate with the size and complexity of the project.

System Engineering Management Plan

(SEMP)

The Technical Lead prepares the SEMP during the Planning phase. The SEMP is a mandatory artifact for all projects. It may be tailored to be commensurate with the project scope and objectives. The following sections may reference other documents that provide the requested information in lower levels of detail, may be combined as the Technical Lead determines reasonable, or may be deemed not applicable:

• Interface Management

• Technical Reviews

• Defect Management

• Configuration Management

• Integration Management

• Performance Management

• Release Management

• Disposition Management

• Specialty Engineering

The purpose of the SEMP is to document all of the technical management processes, controls, policies, and procedures that will be in effect during the project or program. It represents the top-most technical planning document and should complement the Project Management Plan.

10/2013 Version 1.0 18

System Deployment Plan

The Project Manager prepares the System Deployment Plan during the Planning Phase. The System Deployment Plan is a mandatory artifact for all projects. It may be tailored to be commensurate with the project scope and objectives. The following sections may reference other documents that provide the requested information in lower levels of detail, may be combined as the Project Manager determines reasonable, or may be deemed not applicable:

• Description of Deployment

• Deployment Schedule Review

• Information Security Authorization Planning

• Deployment Requirements for Multiple Operating Environments and/or Physical Sites

The System Deployment Plan describes how the information system will be deployed, installed and transitioned into an operational system. The plan contains an overview of the system, a brief description of the major tasks involved in the deployment, the overall resources needed to support the deployment effort (such as hardware, software, facilities, materials, and personnel), and any site-specific deployment requirements. The plan is developed during the Planning Phase and is updated during the Development Phase; the final version is provided in the Integration and Test Phase and is used for guidance during the Deployment Phase.

Privacy Threshold Analysis

See http://cww.census.gov/dir/priv/

Risk Profile/System Security Plan

See http://cww.census.gov/it/ois/

3.1.3.4 Phase Review and Approval

Successful Outcome: The project schedule is baselined and risk register is created.

3.1.4 Requirements Phase

During the Requirements Analysis Phase, the business requirements are validated and further analyzed and decomposed into functional and non-functional requirements that define the product in more detail with regard to inputs, processes, outputs, and interfaces. If appropriate, a

10/2013 Version 1.0 19 http://cww.census.gov/dir/priv/ http://cww.census.gov/it/ois/ logical depiction of the data entities, relationships and attributes of the system/application is also created. During the Requirements Analysis Phase, the initial strategy for testing should be considered. In addition, the work planned for future phases is redefined, if necessary, based on information acquired during the Requirements Analysis Phase. The Requirements Analysis Phase ends with a review to determine readiness to proceed to the Design Phase.

Detailed application requirements (both functional and non-functional) are required to permit detailed project management planning, execution and control. If detailed requirements and subsequent planning identify a breach of the project-level cost, schedule or performance baselines established at the end of the planning phase, a formal change to the Project Baselines should be requested.

Projects are required to follow the Enterprise Requirement Development Process described in Appendix C.

Phase Purpose: Requirements based on business and user needs are elicited and documented

3.1.4.1 Stakeholder Responsibilities

• Project Team:

o Project Sponsor: Participates in the requirements activities and approves final requirements o Project Manager: Oversees and directs all phase activities and engages key stakeholders to capture requirements o Portfolio Manager: Participates in requirements activities and reviews final project requirements.

o Technical Lead: Ensures requirements are organized to facilitate design and develops TEMP.

o Integrated Project Team: Accomplishes assigned tasks according to the project schedule.

• Contributors o ISSRO: Assists with and coordinates acquisition and purchasing activities to obtain IT services and products (as needed) o Acquisition: Guides PM/Contracting Officer Representative (COR) with acquisition activities to obtain contact support o Stakeholder Representatives: Ensures technical and business requirements are understood.

• Reviewers:

o Enterprise Architecture: Ensures that the requirements provide a suitable basis for subsequent design activities

10/2013 Version 1.0 20 o System Engineering: Ensures requirements are organized to facilitate design and are complete from an engineering perspective o Information Security: Ensures security requirements are incorporated o SDLC COE: Verifies the project deliverables comply with the tailoring plan.

• Approvers o Portfolio Management Governing Board: Renders a Go/No-Go decision whether to proceed to the next phase.

o IT Investment Review Board: Renders a Go/No-Go decision whether to proceed to the next phase o Department of Commerce: Reviews projects that meet DOC high profile criteria (see DOC Scalable Acquisition Framework)

3.1.4.2 Phase Activities

• Validate, analyze, and decompose Business Requirements into functional and non-functional requirements during sessions with stakeholders

• Organize requirements according to the components of the solution

• Create a logical depiction of the data entities, relationships, and attributes of the Business Process

• Define the Business Process in more detail with regard to inputs, processes, outputs, and interfaces

• Engage information security engineers to perform review of requirements and provide Security Requirement Recommendations

• Develop the Test and Evaluation Management Plan

• Capture lessons learned from this phase

• Revise or update documentation from prior phases as needed

3.1.4.3 Phase Deliverables

Artifact Description

Requirements Document

The Project Manager or Business Analyst prepares the Requirements Document. The document should be developed iteratively beginning in the Concept Development phase, when initial business requirements are identified in the Project Charter. The Requirements Document should be updated throughout the Planning and Requirements phases. The Requirements Document is mandatory for all projects using the Waterfall development methodology. Projects using the Agile development methodology document requirements in Use Cases and User Stories, and are

10/2013 Version 1.0 21 not required to develop a Requirements Document.

Test and Evaluation Management Plan (TEMP)

The Technical Lead prepares the TEMP during the Requirements Phase. The TEMP is mandatory for all projects and may not be tailored; all sections are required.

The TEMP identifies the tasks and activities that need to be performed to ensure that all aspects of the system are adequately tested and the system can be successfully implemented. The TEMP documents the scope, content, methodology, sequence, management of, and responsibilities for the identified test activities. The TEMP describes these test activities (levels) of the system in progressive levels of detail. These test activities will include at a minimum, but are not limited to, the following:

* Unit Testing

* Integration Testing

* System Testing

* Regression Testing

* Security Testing

* User Acceptance Testing

The TEMP also provides guidance for the management of test activities, including organization, relationships, and responsibilities. The test case procedures may be included in the TEMP or in a separate document, depending on system size; they provide a basis for verification of test results and validation of the system. The validation process ensures that the system conforms to the Requirements Document (RD) and that other applications or related systems are not adversely affected. When using a Waterfall development methodology, the Test Analysis Report (TAR) is updated at each level of testing to record the results of testing and certify readiness for system implementation. Problems, deficiencies, modifications, and refinements identified during testing or implementation should be tracked under configuration management and re-tested accordingly. Add new test cases and/or procedures to the TEMP if necessary.

3.1.4.4 Phase Review and Approval

Successful Outcome: Project requirements are validated.

10/2013 Version 1.0 22

3.1.5 Design Phase

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

A formal review of the solution architecture is conducted prior to detailed design of the product to achieve confidence that the design satisfies the system requirements, is in conformance with the enterprise architecture and prescribed design standards, to raise and resolve any critical technical and/or project-related issues, and to identify and mitigate project, technical, security, and/or business risks affecting continued detailed design and subsequent life cycle activities.

Estimates of project expenses are updated to reflect actual costs and estimates for future phases.

In addition, the work planned for future phases is redefined, if necessary, based on information acquired during the Design Phase.

Phase Purpose: Requirements are translated into logical and technical solution design that will deliver functionality.

3.1.5.1 Stakeholder Responsibilities

• Project Team:

o Project Sponsor: Participates in the design activities and approves final design o Project Manager: Oversees and directs all phase activities and engages key stakeholders to develop design o Technical Lead: Guides project team activities to develop and document the design o Integrated Project Team: Accomplishes assigned tasks according to the project schedule.

• Contributors o Stakeholder Representatives: Ensures technical and business requirements are understood. Stakeholders include: Usability and Accessibility Office and ISSRO

CCT

• Reviewers:

o Enterprise Architecture: Ensures compliance with enterprise architecture guidance and standards o System Engineering: Ensures design incorporates enterprise design patterns and best practices, and will meet defined performance goals.

o Information Security: Ensures design address security requirements

10/2013 Version 1.0 23 o SDLC COE: Verifies the project deliverables comply with the tailoring plan.

o Business Owner: Verifies design meets business needs

• Approvers o Portfolio Management Governing Board: Renders a Go/No-Go decision whether to proceed to the next phase.

o IT Investment Review Board: Renders a Go/No-Go decision whether to proceed to the next phase o Department of Commerce: Reviews projects that meet DOC high profile criteria (see DOC Scalable Acquisition Framework)

3.1.5.2 Phase Activities

• Document system requirements and logical description of the entities, relationships, and attributes of the data developed during the Requirements Phase

• Develop detailed specifications that emphasize the physical solution and trace to the stakeholders’ information technology requirements

• Ensure Physical Data Model, Data Dictionary, and System Design adhere to standards

• Develop unit test cases to validate system subcomponents’ function during development

• Engage information security engineers to perform review of designs and provide Security Design Recommendations

• Present design for Architecture Review Board approval

• Capture lessons learned from this phase

• Revise or update documentation from prior phases as needed

3.1.5.3 Phase Deliverables

Artifact Description

Solution Architecture Document

The Solution Architecture is completed by the Technical Lead during the Design phase. The Solution Architecture is an optional artifact based on Project Type. For example, a Solution Architecture must be developed when an information technology system is being built or enhanced, but is not needed when a new business process is being developed. The Solution Architecture may be tailored to be commensurate with the project scope and objectives. The following sections may reference other documents that provide the requested information in lower levels of detail, may be combined as the Technical Lead determines reasonable, or may be deemed not applicable:

10/2013 Version 1.0 24

• Design Plan

• Considerations and Tradeoffs

• Goals and Guidelines

• Reliability, Maintainability and Availability Considerations

• Performance Engineering Considerations

The Solution Architecture document describes the major architecture and design components for the system. It provides information at the business and technical overview levels, but does not contain technical specifications intended for use by solution developers.

Interconnection Security Agreement and Control Document

(ISACD)

The ISACD is completed by the Technical Lead during the Design Phase.

The ISACD is an optional artifact based on Project Type. For example, an ISACD must be developed when an information technology system is being built,, but is not needed when a new business process is being developed or Commercial Off the Shelf (COTS) software is being configured for use.

When the ISACD is mandatory, it may not be tailored; all sections are required.

An Interconnection Security Agreement and Control Document (ICD) documents and tracks the necessary information required to effectively define the system’s interface as well as any rules for communicating with them in order to give the development team guidance on architecture of the system to be developed. The purpose of the ISACD is to clearly communicate all possible inputs and outputs from the system for all potential actions whether they are internal to the system or transparent to system users. Its intended audience is the project manager, project team, development team, and stakeholders interested in interfacing with the system. This ISACD helps ensure compatibility between system segments and components.

Detailed Design Specification Document

A detailed design specification document should be developed using guidance provided.