Attachemnt G Seed Task Order Three PWS_0007.pdf

Task Order 003 Application Management Performance Work Statement

3/16/2020

140R8120R0005

IMT Enterprise Support Solutions IDIQ

Attachment G

Enterprise Support Services IDIQ PWS

Contents

Page

1.0 INTRODUCTION

2.0 OBJECTIVES

3.0 TECHNICAL REQUIREMENTS

4.0 SERVICE REQUIREMENTS

5.0 APPLICABLE DOCUMENTS

6.0 CLIN POSITIONS

7.0 REPORTS

8.0 DOCUMENTS

9.0 DELIVERABLES

10.0 GOVERNMENT FURNISHED EQUIPMENT

11.0 PERIOD AND PLACE OF PERFORMANCE

12.0 ACRONYM LIST

Modified Date: 8/5/2020 11:25 AM Page 3 of 10

Performance Work Statement Application Management Services

03/09/2020

1.0 INTRODUCTION

1.1 The Bureau of Reclamation (herein Reclamation) requires Information Technology (IT) enterprise application management support.

2.0 OBJECTIVES

2.1 The primary objective of this contract is to provide Application Development and Application

Support services for the Bureau of Reclamation (Reclamation) applications throughout the

Application Life Cycle.

3.0 TECHNICAL REQUIREMENTS

3.1 The Task Order shall comply with the base requirements in accordance with the IDIQ contract.

3.2 Reclamation currently develops, installs, maintains, and supports the following technologies, development tools, and applications:

3.3 Technologies.

3.3.1 The following technologies are currently utilized by Reclamation under this contract;

3.3.1.1 Oracle RDBMS 11g and higher

3.3.1.2 Cold Fusion v7.0 and higher

3.3.1.3 BIRT Reporting

3.3.1.4 Impromptu Web Reporting v7.3/4

3.3.1.5 Jasper v2.x and higher

3.3.1.6 Java 1.6 and higher

3.3.1.7 JBoss 5, JBoss 7, JBoss WildFly 8

3.3.1.8 Struts

3.3.1.9 WebSphere 6 and higher

3.3.1.10 IBM Actuate Report Writer

3.3.1.11 TRM Rules Manager

3.3.1.12 IBM Maximo Asset Management 7.5 and higher

3.3.1.13 CiM Visual Planner Suite

3.3.1.14 Java Web Services

3.3.1.15 Maximo Integration Framework (MIF)

3.3.1.16 Java Script

3.3.1.17 Python

3.3.1.18 SQL Server 2005,2012 and higher

3.3.1.19 ANT

Modified Date: 8/5/2020 11:25 AM Page 4 of 10

3.3.1.20 Java Server Pages (jsp)

3.3.1.21 Java Server Faces (JSF)

3.3.1.22 Maven

3.3.1.23 Editor.js

3.3.1.24 Fusion Charts

3.3.1.25 PL/SQL

3.3.1.26 PHP

3.3.1.27 MySQL

3.3.1.28 MS Power Apps

3.3.1.29 MS Power BI

3.3.1.30 Oracle Forms and Reports

3.3.1.31 Oracle BI Publisher

3.3.1.32 .NET/C#

3.3.1.33 Apache Web Server

3.3.1.34 NodeJS

3.3.1.35 Webpack

3.3.1.36 Composer

3.3.1.37 Symfony (PHP Framework)

3.3.1.38 KendoUI (JS UI Components)

3.4 Development Tools.

3.4.1 The following development tools are currently utilized by Reclamation under this contract;

3.4.1.1 TOAD

3.4.1.2 PL/SQL Developer

3.4.1.3 Eclipse

3.4.1.4 Dream Weaver

3.4.1.5 JIRA

3.4.1.6 Apache Subversion

3.4.1.7 Jenkins

3.4.1.8 PHP Storm

3.4.1.9 Visual Studio

3.4.1.10 Oracle Forms and Reports

3.4.1.11 Oracle BI Publisher

3.4.1.12 Azure DevOps

3.4.1.13 GitLab

3.4.1.14 SQL Management Studio

3.4.1.15 Git Client

Modified Date: 8/5/2020 11:25 AM Page 5 of 10

4.0 SERVICE REQUIREMENTS

4.1 Contractor shall provide integration and coordination support to the Applications Development organization that encompasses risk mitigation planning, application system requirements management and impact coordination, test planning, deployment and operations/production process support, financial material weakness resolution and related integration and coordination activities as required.

4.2 Representative activities that the Contractor shall include:

4.2.1 Identify the appropriate integration points for impact analysis in support of the requirements management process for the program.

4.2.2 Provide integration support for data exchange compatibility test planning.

4.2.3 Support AD-wide internal and external stakeholder communications.

4.2.4 Support the development and documentation of new systems and changes to legacy systems.

4.2.5 Review project and release designs, solution assurance plans and validation plans to identify risks associated with implementation and achieving expected objectives.

4.3 Contractor shall follow Reclamation Enterprise Application Lifecycle Management process as the framework for the base requirement for tasks under this Task Order. Refer to Applicable

Documents Section.

4.4 The ALM outlines required deliverable along the entire workflow process and are referenced in the document as “output”.

4.5 All deliverables schedules shall be developed as part of the project plan for each with coordination of the client, key stakeholders, COR and/or government staff as applicable.

4.6 Contractor shall work with government to develop a project plan for each application development project undertaken during the term of the contract and shall take into consideration our ALM and standard ITIL processes where applicable.

4.7 Contractor shall support in the selection, tailoring, management, and execution of Enterprise

Lifecycle Support (ELC) paths, methodologies, and approaches for development and delivery of program capabilities.

4.8 Contractor shall employ best practices and proven expertise in managing and executing capability delivery utilizing these paths, methods, and approaches. Agile expertise shall include the ability to employ the Scaled Agile Framework (SAFe) as appropriate to realize the benefits of Agile and Lean development at enterprise scale. As specified by Reclamation, contractor services and support shall be provided in alignment with existing Reclamation frameworks, processes, standards, and tools.

4.9 Representative activities that the contractor shall include:

Modified Date: 8/5/2020 11:25 AM Page 6 of 10

4.9.1 Assist in the selection and tailoring of ELC paths, methodologies, and approaches to managing and delivering program capabilities.

4.9.2 Assist in the development, communication, and execution of supporting program delivery strategies, incorporating and blending elements from multiple ELC paths, methodologies, and approaches, as needed, to accomplish delivery within the constraints and limitations of the existing Reclamation environment and culture.

4.9.3 Assist Reclamation in the adoption of new software development and delivery approaches, including, but not limited to Agile and DevOps, and provide coaching support to assist in operationalizing supporting methodologies, processes, practices, and tools, as needed.

4.9.4 Utilize web-based enterprise project management software specifically designed for the Reclamation-selected software development approach (e.g., Agile, Waterfall, etc.).

4.9.5 Facilitate capture of business needs through agile practices of defining and decomposing epics and user stories to ensure accurate interpretation of requirements.

4.9.6 Assist with prioritization of requirements, epics, and user stories, as needed, to facilitate rapid and timely delivery of high-value capabilities in accordance with business needs and priorities.

4.9.7 Engage Business, Development, Quality Assurance, Operations and Maintenance

(O&M), and Cybersecurity stakeholders as equal partners in a multi-disciplinary delivery team to specify, design, develop, integrate, test, deliver, operate, and maintain program capabilities.

4.9.8 Support development and execution of strategies for frequent and continuous building, testing, integration, and deployment of software, utilizing automation, whenever possible, to provision, configure, and modify environments and infrastructure.

4.9.9 Create and manage documentation required by the ELC.

4.9.10 Track and report on the delivery of agreed-upon capability, functionality, documentation, and other artifacts.

4.9.11 Provide support to facilitate common understanding and consistent application of methodologies, approaches, processes, practices, standards, and tools within and across

Reclamation and its Programs.

4.9.12 Provide continuous analysis of the efficiency and effectiveness of program practices, processes, methodologies, approaches, and tools, along with recommendations for change or improvement, as needed.

Modified Date: 8/5/2020 11:25 AM Page 7 of 10

5.0 APPLICABLE DOCUMENTS

5.1 In addition to the applicable documents identified in the base IDIQ, the Contractor shall follow

Reclamation Application Lifecycle Management (ALM1) document as the standard for requirements under this Task Order.

5.1.1 See Attachment A-1, Reclamation Enterprise Application Lifecycle Management; and

5.1.2 See Attachment A-2, Reclamation Enterprise Application Lifecycle Management

Workflow Diagrams.

6.0 CLIN POSITIONS

CLIN DESCRIPTION Quantity

0002 Application Developer 2 7

0003 Application Developer 3 5

0023 Database Administrator 2 2

0024 Database Administrator 3 1

0052 Systems Administrator 2 1

0065 Testing Specialist Sr 2

7.0 REPORTS

7.1 The Task Order shall comply with the base requirements in accordance with the IDIQ contract identified in this Task Order.

7.2 The contractor’s invoice shall be in accordance with IDIQ 52.212-4(g) Addendum.

8.0 DOCUMENTS

8.1 Standard Operating Procedures (SOPs). Contractor shall maintain and update existing SOP documents and/or manuals to explain various procedures within the Reclamation information systems environment. Contractor shall develop an SOP for any process or procedure that does not have documentation established.

1 The ALM provides a standard model to establish the steps and phases involved in an information system development project at Reclamation. The document identifies the processes, activities, and artifacts needed to ensure Reclamations’ investments in custom applications are planned, cost-effective, and support the mission and business goals of the organization.

Modified Date: 8/5/2020 11:25 AM Page 8 of 10

8.2 Contractor shall provide the required documentation to the Government on tasks and projects assigned; specific documentation will be clarified through technical task clarifications. This documentation includes SOPs, flowcharts, wiring diagrams, network diagrams, and system design documents, ad hoc reports, Security Technical Implementation Guides (STIGs), operating and maintenance requirements, progress reports and milestone reports and any other documentation required by the Federal Government.

8.3 The ALM document outlines all required documents under this Task Order.

9.0 DELIVERABLES

9.1 The Task Order shall comply with the base requirements in accordance with the IDIQ contract identified in this Task Order on deliverables.

9.2 Provide all applicable, application development documents as defined by each project plan.

9.3 The following deliverables as applicable.

PWS Para Title Delivery Schedule

Parent Solicitation Monthly Status Report

10th calendar day

Parent Solicitation Staffing/Transition-In Plan Submit with proposal and update if any personnel changes occur during POP

Parent Solicitation Meeting Minutes

On Going

Parent Solicitation Standard Operating Procedures

On Going

Section 4.0 and 5.0 Technical documentation- Refer to ALM Document for complete list of required deliverables.

Per Each Project

10.0 GOVERNMENT FURNISHED EQUIPMENT

10.1 The Government will provide the following GFE under this Task Order;

10.1.1 Suitable workspace cubicle.

10.1.2 Government STIG computer (Accountable Property).

10.1.3 Microsoft Office O365 Suite.

10.1.4 Desk VoIP Telephone/Cisco Jabber.

10.1.5 Photo ID PIV Card (after security adjudication).

10.1.6 Active Directory Account.

Modified Date: 8/5/2020 11:25 AM Page 9 of 10

10.1.7 Government Email Account.

10.1.8 VPN Account.

10.1.9 Mobile Phone (Accountable Property), if applicable depending on position assignment of each contractor personnel. COR has final determination on the issuance of this item.

10.1.10 Multi-functional copier/printer access.

10.1.11 Basic office supplies.

10.1.12 Suitable surface parking near Building 67.

11.0 TELEWORK

11.1 Telework. The Government has determined that the services provided under this Task Order are not eligible for regular scheduled or recurring basis telework. The Government may authorize situational2 telework to Contractor personnel as deemed appropriate on a case-by-case basis authorized by the

CO/COR/TSAL and Contractor Project Manager discretion.

12.0 HOURS OF OPERATION

12.1 The Task Order shall comply with the base requirements in accordance with the IDIQ contract for hours of operation identified in this Task Order.

13.0 PERIOD AND PLACE OF PERFORMANCE

13.1 The period of performance will be October 01, 2020 through September 30, 2021.

13.2 The location for the effort is the Bureau of Reclamation, Denver Federal Center, Building 67, Denver, Colorado, 80225.

14.0 ACRONYM LIST

Acronym Definition Acronym Definition

APEX Oracle Application Express

BIRT Business Intelligence and Reporting Tools

CARMA Capital Asset and Resource Management Application

CDW Corporate Data Warehouse

DBA Database Administrator

DRO Denver Regional Office

2 Situational Telework is a case-by-case work arrangement conditional to government advance approval that allows contractor personnel to perform work, during any part of regular scheduled work hours on a particular work day, at an approved alternative worksite as a result of inclement weather, special work assignments, or irregular in nature (i.e., continuity of operations (COOP) in the event of a crisis or national emergency). If granted the contractor shall be responsible to ensure personnel have valid VPN accounts and are connected and responsive to all work requirements with no difference in the level of support, responsiveness and availability while teleworking.

ESAM Electronic Service Agreement Module

ETAS Electronic Time and Attendance System

FBMS Financial and Business Management System

IG Inspector General

IMATS Information Monitoring and Tracking System

IV&V Independent Verification and Validation

Modified Date: 8/5/2020 11:25 AM Page 10 of 10

POAM Plan of Action & Milestones

WMS Web Map Service

UAT User Acceptance Testing

Appendix A-1

RECLAMATION ENTERPRISE APPLICATION

LIFECYCLE MANAGEMENT (ALM) DESCRIPTION

DOCUMENT

Project Title:

Reclamation Enterprise ALM Description Document

Project Manager:

Eva Bauer 84-21200

Project Manager Supervisor:

Patrick McFall Division Chief, IT Services Division 84-21100

Sponsor:

Randy Brammer Program Manager, Information Resources Office 84-21000

SCOPE

The Reclamation Enterprise Application Lifecycle Management (ALM) provides a standard model to establish the steps/phases involved in an information system development project at the Bureau of Reclamation. This document identifies the processes, activities, and artifacts needed to ensure Reclamation’s investments in custom applications are planned, cost-effective, and support the mission and business goals of the organization. The phases start with project definition, investment analysis and approval, development and deployment and continue through maintenance of the completed application to include the end of life cycle processes. This document identifies the roles, activities, inputs and outputs required to manage Reclamation’s complete software development life cycle from planning to monitoring. It is not the objective to change existing processes (e.g. Security, Change Management, etc …) but to identify where the existing processes will be engaged in the overall lifecycle. The Project Manager will work with his or her management to determine the deliverables required for the project and will engage the Capital Planning team to determine business case modifications and adjustments.

PHASES

The Reclamation Enterprise ALM is defined in 5 phases: Initiation, Analysis, Development & Implementation, Operations & Maintenance and Decommission. Each phase incorporates the components necessary to develop a Reclamation-approved software product from cradle to grave. This can be applied to Buy (COTS), Borrow (GOTS) or Build (Custom) solutions. According to Memo M-16- 21, government organizations are required to investigate Buy or Borrow options prior to Building new technical solutions. Buying or Borrowing the solution could be acquiring of the product off the shelf or from another government organization with minor configuration changes or enhancements. Building would require a complete software development team to create the solutions using gathered business needs/requirements and provide an environment (infrastructure) to support the solution. No specific methodology is identified (e.g. waterfall, agile, etc), however, the process should accommodate any methodology. The phases and processes should be applicable to any methodology while ensuring that Reclamation specific policies and processes are followed. The security team is engaged throughout the entire life of the application, this is noted within the workflow.

1.0 Initiation Phase: During the initiation phase, the justification for a system is defined and presented to the stakeholders and decision makers. The purpose, scope and vision of the system is documented. Any discussions with customers and agreements will be documented and signed as necessary.

2.0 Analysis Phase: During this phase, the requirements and high-level use cases are defined and all alternatives are considered. The decision to buy, borrow or build is made. Requirements are finalized and documented in preparation for development, implementation and deployment.

3.0 Development and Implementation Phase: During development and implementation, the methodology is determined based on the decision to buy, borrow, or build as selected in the previous phase.

Requirements are defined by modules (if applicable) and the product design is built. The development phase is performed according to type and tested both functionally and through Functional Testing and User Acceptance Testing (UAT). Once acceptance is made, the product is deployed and implemented in the production environment. Updates are presented to stakeholders based on the specifications in the communication plan.

4.0 Operation and Maintenance Phase: During this phase, the system performs its work. The system is typc being continuously modified by the addition of hardware and software and by numerous other events. Activities include: enhancements, security operations and administration, operational assurance, audits, and monitoring.

5.0 Decommission/Conversion Phase: The decommission/conversion phase involves the disposition of information, hardware, and software or the conversion of data into another application according to organizational needs, federal requirements, laws, and regulations and the Decommission/Conversion Plan.

Activities include: moving, archiving, discarding or destroying information, sanitizing the media, and performing the necessary security activities to ensure no vulnerabilities are created.

These phases form the basis for the Reclamation Enterprise SDLC and are discussed further below.

SDLC PROCESS

1.0 Initiation Phase

1.1 - Service Request Received. All requests for new development or products will follow the ALM Standard Operating Procedure (SOP) and should begin with the Help Desk. However, not all requests will be received through the Help Desk and IT leadership throughout Reclamation should be trained to follow the approved SDLC SOP and create a ticket with the Help Desk. The initial business needs statement will be created by the Business Owner using a predefined template found in the SOP.

Roles:

- Application Development Leadership

- Business Owner/Sponsor

The SDLC process begins with a request being made through an approved path. After receiving the request, several gates are defined that will need to be passed to determine if the request should proceed to the next step (see workflow diagram). The service request will be accompanied by a Business Needs Statement which will outline the reason for the request, the business issue that will be solved and other information (including the Initial Project Description) which will help in making the decision to move forward with the request.

Templates are available for all identified outputs and deliverables within the Software Development Lifecycle: SDLC Template Library

Output: Business Needs Statement, Initial Project Description

1.2 Initial PM Assigned and Planning Funding Identified

For the initial steps of the process funding to proceed with the assessment and recommendation will be identified, this will be based on the resources required to manage the initial steps up to gaining IRBAC/ACIO approval to pass the initial gate. The initial Project Manager will be assigned proceed with the initial recommendation steps.

Roles to complete step:

- Application Development Leadership

- Business Owner/Sponsor

- Assigned Preliminary Project Manager (the PM assigned at the beginning may or may not continue after project approval)

The Project Manager will create the Draft Record of Decision and determine the estimated budget for funding the recommendation phase.

Output: Draft Record of Decision, Business Needs and Impact Analysis

1.3 Data Analysis

https://drive.google.com/drive/folders/0B0K5Y_YOftSBX1lGaEY5LTI1U3M

An organizational review of the data will be performed by the Data Analyst to define the requirements around the collection of data and to ensure proper handling of data is defined throughout the SDLC process.

Roles:

- Data Analyst

- Business Owner/Sponsor

- Security

- Assigned Project Manager

- Privacy Officer

Does the project involve the collection of data? If so, then customer develops Data Acquisition & Management Plan (DAMP, see template for guidance).

Output: Data Acquisition & Management Plan (DAMP)

1.4 Architecture Review

The Security, Infrastructure Manager, Solutions Architect and Enterprise Architect will review the project description and perform an initial architectural review. During this process the team will identify the high-level technical requirements and provide risks and opportunities to be presented in the Initial IRBAC Review.

Roles:

- Business Owner/Sponsor

- Assigned Project Manager

- Solutions Architect (SA)

- Enterprise Architect (EA)

- Infrastructure Manager (or assigned team member)

- Security

This list of topics will be guided and managed by the Enterprise Architect and Solutions Architect working with the Project Manager. During the early stages of a software development project, the team will determine design and solution needs and will include the information in the Architectural Plan. This may include some of the following:

● Develop Business Requirements

● Create the business justification for the system

● Write general system description

● Determine the user base (internal or external)

● Determine any special requirements for this project

● Define processes

● Determine if there is any shared data

● Determine the performance needs

● Assess security needs

● Describe other data/issues/information known about the project at this time

● Define the integration level and strategy with other systems

● Describe the design, data storage, and delivery systems

● Define the high-level system requirements

● Create the initial architectural diagram

● Identify other applications and/or systems which will require integration

● Determine the size of the project (technical, user base, and support)

● Define the resource requirements

● Prepare initial cost estimate

The results of the architectural review will be documented in the Feasibility Statement. The Feasibility Statement is an analysis and evaluation of the proposed project to determine if it is technically possible, is within the budgetary guidelines, and will provide a solution to meet the business needs defined in the Business Needs Statement. The document will provide information to assess potential solutions to the business problem or opportunity, and help the IRBAC and ACIO determine if the project is viable for further analysis.

Output: Feasibility Statement, Architectural Plan

1.5 Initial Security Impact Assessment

Roles:

- Information Systems Security Officer (ISSO)

- Business Owner/Sponsor

- Assigned Project Manager

- Solutions Architect

- Enterprise Architect

The Information Systems Security Officer for the BOR General Support System (GSS) should be engaged early in the software development process. They should do an initial Security Impact Assessment following NIST guidelines and the FIPS 199 Standards for Security Categorization of Federal Information and Information Systems - this will ensure that the information being used in the project is categorized correctly and the data is managed properly from the very beginning of the project.

A Privacy Impact Assessment is also performed to ensure information about people is handled properly.

Refer to the Secure coding requirements and best Practices document for details about the security practices and required processes.

Output: Privacy Impact Assessment (PIA), Updated Needs and Business Impact Analysis,

1.6 Initial Information Resources Business Advisory Council (IRBAC) and Associate CIO (ACIO) Review

Roles:

- ACIO

- Information Resources Business Advisory Council (IRBAC)

- Information Systems Security Officer (ISSO)

- Business Owner/Sponsor

- Assigned Project manager

- Solutions Architect

- Enterprise Architect

Once the project is initially defined, the data analysis is performed, the Architectural review is conducted and the Initial Security Assessment is finalized, the information is presented to the IRBAC for review and recommendations for next steps. This meeting should include high level costs, resources, timeline, and scope. The resources will indicate regional involvement.

Output: Decision for next steps

1.6.1 Decision: Approval to Proceed to Analysis Phase

1. “Yes” - proceed with project

2. “No” - project idea ends or

3. “Further analysis is required” and return to 1.1

All details of unaccepted projects will be maintained in the SDLC SharePoint site for future reference.

Output: Initial Record of Decision Document

1.7 Assign Project Manager

An initial project manager was assigned during the feasibility phase (steps 1.2 - 1.6), this person may or may not continue as the official Project Manager so an assignment step is included to account for a possible change.

Roles:

- Program Management Office (PMO)

- Assigned Permanent Project Manager (if different)

Following the FAC-P/PM standards, the project manager will be assigned. The project manager will be responsible for following the SDLC and ensuring that all steps are followed and documentation is properly completed.

1.8 Develop Project Charter

Roles:

- Project Manager

- Identified Stakeholders (including Security)

The Project Manager (PM) will develop the Project Charter, using the Project Charter Template.

Depending on the size of the project, the Charter may be a separate document or can be incorporated into the Project Management Plan (PMP). A schedule will be included with the start date and expected end date included. The Scope, Costs, and Resources should be defined in the charter. The project size, the artifacts for the project size and resources will be identified in the charter.

Output: Project Charter

1.9 Project Kick-Off

Roles:

- Project Manager

- Identified Stakeholders who sign the charter

- Security

- Division Manager

The PM will ensure all necessary signatures for the project charter are acquired during the kick off meeting. The kick off meeting will include the following:

● Establish Vision and Identify Deliverables

● Identify Team and set roles

● Present initial Project Plan

● Define how to measure project success

● Review the plan and identify potential risks

● Establish logistics of communication

● Establish best practices the team will follow

● Decide which tools will be used

● Present high-level schedule and timelines

● Establish how change requests will be handled

Output: Signed Project Charter

1.10 Coordinate with Capital Planning

Roles:

- PM

- Capital Planning Lead

During this step, the Business Case is identified and potentially modified. Using the Capitalization Document to record estimated software costs, benefactors and outline the proposed capitalization strategy.

Output: Business Case Documentation, Capitalization Planning, TBM - Business Capability

1.11 Develop Project Management Plan (PMP)

Role:

- Stakeholders as needed

The PM will create the Project Management Plan (PMP) using the approved template. The overall size of the project will determine what amount of detail is required and will be part of the approval process determined during the initial IRBAC meeting.

Once all steps are complete move to the Analysis phase.

Output: Initial Project Management Plan

2.0 Analysis Phase

The focus of the phase is two-fold: 1) evaluate feasibility of alternatives and 2) clearly define and approve project scope, including the system. This may also include building the Statement of Work (SOW) if the requirements gathering and analysis will be done outside of Reclamation. System design will include identifying, gathering and documenting high level requirements and Use Case Scenarios.

Roles:

- Project Team (includes Security)

2.1 Establish Resources

The initiation of defining the resources facilitates the implementation of project management and IT best practices and ensure the correct teams and roles are engaged throughout the analysis phase.

Activities include:

● Establish Project Teams (including security and privacy)

● Develop Partnerships

● Determine Planning Level of Effort (LOE) for Business Case

Output: Defined Project Team, Statement of Work (SOW) if determined to use a vendor for developing the Project Requirements and Use Cases/User Stories and documenting them using Reclamation defined templates.

2.2 Define High Level Use Cases/ Requirements

This process includes working with stakeholders and business users/customers to further define the requirements and ensure their needs are included in the requirements and documented. Create a Requirements Traceability Matrix (RTM) to map to the development effort and use in the testing phase of the project.

Output: Requirements Traceability Matrix, High Level Use Case Documents

2.3 Create/Develop High Level (Business) Data Model

The Project Manager will engage the Data Resource Manager to work together and build the data model.

Output: Data Model

2.4 Develop Functional Use Cases

The purpose of developing functional use cases is to further expand on the Use Cases by interviewing users and documenting the User Stories and building the Use Case Scenario Document. Business Analysis documents are available to be reviewed and incorporated into this process. This will be done by the project Business Analyst and might be procured through the Application Development IDIQ or other contract services.

Output: User Stories, Use Case Scenarios

2.5 Perform Alternatives Analysis

Engaging Infrastructure Representation, Security Team and Capital planning, the Alternatives Analysis will ensure that the Investment Team assesses multiple options when either: (1) defining a solution for a new investment (project), (2) deciding whether it is worthwhile to continue funding of a current investment as status quo, or (3) seeking options for enhancing a current investment’s products or services.

The Analysis is conducted at the onset (during Feasibility) of a new investment opportunity/application/system. This provides rationale for recommendation on the investment for review by the IRBAC.

During the process the team will determine how this project should be implemented including Buy/Borrow/Build scenarios. The technical team will do a Market Research Analysis to see if solutions exist in the market which will satisfy the defined requirements including the option of “cloud first”, borrow from other organizations, buy COTS or build a new application.

Output: Alternatives Analysis Document, Cost Estimate, Recommendation

Note: Known COTS product purchase request triggers TRB (This may need to be included in the initiation phase)

2.5.1 Decision: Accept Recommendation of Alternatives Analysis? (buy, borrow, build decision)

The Project Manager, Business Owner and identified/required SMEs will present the Recommendation to the IRBAC and a discussion of the recommendations will commence. The possible decisions will include:

● A Buy/Borrow/ Build decision is made - team to follow appropriate path.

● The IRBAC requires further research, return to Alternatives analysis - this is a process of evaluate and reevaluate as required to come to a decision.

● The IRBAC declines to move forward and ends the project.

Output: Record of Decision (RoD)

2.6 BUY/BORROW

The decision has been made that an application exists either in the market or within other government agencies and the project team will perform the required tasks to acquire the application for use within Reclamation.

2.6.1 Determine Customer Support Needs

Working with the business sponsor, the project manager and team will determine the needs of the customer and define how they will be supported. This will include creating a Service Level Agreement to agree upon the process for supporting the application.

Project management change management (not application change management) will be determined to support the customer’s requirements. Any changes to the scope of the project will need to be reviewed and agreed upon by the Project Team. During this process, the following will be determined:

● Vendor POC

● Vendor Change Management Process

The Project Manager will be the Point of Contact for any project changes and will engage the appropriate team members as changes are introduced.

Output: Service Level Agreement, Define Project Change Management Process adopted

2.6.2 Verify with the Infrastructure group

After determining if the application will be hosted within Reclamation’s boundaries, Hosted in the Cloud or Shared Service, the Project Manager will engage the Manager of the Infrastructure group or assigned infrastructure representative and the Solution’s Architect. Both Infrastructure and the Solution’s Architect will be engaged throughout the development life cycle to ensure the current Reclamation infrastructure can support the technical needs of the project. This will also allow the decision/discussion of adding additional equipment if needed.

Potential Output: Acquire additional hardware/software

2.6.3 Security Review and Assessment

The ISSO (or assigned alternate) will work with the solutions architect, infrastructure team, and the Project Manager to create a calendar/schedule for the System Security Assessments. The Security team will be engaged and follow their defined processes.

The following will be determined:

● Data Management

● High-Level Security Requirements

● Initial Schedule of Security activities/decisions

2.6.3.1 Identify Product/Determine Product Options

A solution exists in the market to satisfy the identified requirements and the decision is made to move forward. If no solution can be determined or it is determined that the market does not have an adequate solution, no decision may be made and analysis will continue (return to section 2.5).

Output: Record of Decision

2.6.4 Acquisitions Process

The Statement of Work (SOW) for the task order is created. Procurement is engaged, following the predefined Acquisitions process. The Reclamation Procurement team assigns a Contracts Specialist and the Reclamation Procurement Process is started. During review of the Vendor responses, security will be present to ensure all security requirements are met. (Possibly a new task order on the Application Development IDIQ)

Output: Acquisition Plan/IA Document, Product Acquisition

2.6.5 Add Solution to Change Management Baseline

The solution is turned over to operations for all changes to be managed. The baseline provides the base from which all changes are measured. Changes to the base will follow both the operational and application change management processes as applicable.

This concludes the Analysis Phase for the Buy/Borrow solution decision. Proceed to Development and Implementation.

2.7 BUILD

2.7.1 Determine the Evaluation Team

The Project Manager will ensure the team is defined to make the best decisions for the project, including the following:

● Business SMEs

● Extended Project Team (CPIC, Privacy, Infrastructure)

● Security

● If integrated application, identify Partnerships

Output: Project Management Team (PMT) defined

2.7.2 Develop Infrastructure Software/Hardware Requirements Specifications

The team will meet to define the infrastructure specifications of the development project. Depending on the size of the project, this could take several meetings to finalize the specifications. Along with the Project Manager, the meetings could include the following roles:

● Solutions Architect

● Infrastructure Representative

● Data Manager

● Development Representative

● Security Representative

Infrastructure considerations during this phase:

● Platform - Determine the hardware needed. Is it available? Does hardware need to be purchased to support the application?

● Software - Determine the development software needs. Does Reclamation already own the software, is a purchase required?

● Technical Data Management Requirements

● Security Requirements

Output: Software Requirements Specification (SRS) document

2.7.3 Security

The infrastructure and system requirements must include all the security considerations and the process

2.20 and 2.21 could be combined into one process depending on the size of the project. However, the specifications for security are specific and will follow the already defined security practices. The ISSO (or assigned Security Manager) will perform the security assessment to include the following:

● Data Management - define the data / data types

● High-Level Security Requirements

● Initial Schedule of Security Activities/ Decisions

The customer will determine whether the data or subset of data is to be published based on project scope or become part of a deliverable that is published externally. If so, then a data screening process will be conducted by engaging the Data Resource Manager to conduct the screening.

Output: Updated Software Requirements Specification (SRS) document, Documented high-level Security Requirements, Initial Schedule of Security Activities, Dataset screening documentation

2.7.4 Change Management

This process is project change management (not application change management). Any changes to the scope of the project will need to be reviewed and agreed upon by the Project Team. During this process, the following will be determined:

● Change Management POC

● Project Change Management Process

● Set up Change Board

Output: Define Project Change Management Process adopted

2.7.5 Requirements Concurrence with Project Sponsor and Determine Functionality Priorities (Include Security in the review)

The Project Sponsor and representatives will review and agree upon the project requirements and establish the priorities of the requirements. The Security manager will also provide guidance to ensure that security practices are prioritized appropriately for the project.

Output: Updated SRS

2.7.5.1 Requirements approved?

If the requirements are not approved or need further review, the refinement of the requirements will continue until approval/concurrence is achieved.

Output: Updated Project Management Plan, Configuration Management Plan, Data Management Plan, Business Case When the requirements are approved the project will move to the Development and Implementation Phase.

2.7.6 Developer Staffing Analysis

Review requirements and determine staffing needs for the project. This will include all phases in developing and will provide management with information to determine if additional staff will be required. The Project Management Plan will be updated with the results of the analysis.

2.7.6.1 Additional Staffing Required?

If the staffing plan includes resources not currently on staff or on contract, then a new task will be created and the acquisitions process will begin.

Output: Acquisition Plan

2.7.7 Acquisitions Process

The Statement of Work (SOW) for the task order is created. Procurement is engaged, following the predefined Acquisitions process. The Reclamation Procurement team assigns a Contracts Specialist and the Reclamation Procurement Process is started. During review of the Vendor responses, security will be present to ensure all security requirements are met.

Output: Resource Acquisition, Acquisition Plan, SOW and Awarded Task Order (if applicable)

Final Tasks:

Update:

Project Management Plan Configuration Management Plan Data Management Plan Business Case

3.0 Development and Implementation

The development and implementation work may be performed either by Reclamation development staff or by an outside vendor. Regardless of the place of performance (in-house or via a vendor) the following steps will be performed. These steps should be followed regardless of the selected development methodology. It is crucial to follow the approval gates to ensure that the project is on expected course and requirements are being properly implemented and checked.

3.1 Analyze Requirements

This phase can be entered from the end of the Analysis Phase or from the Operations and Maintenance Phase (4.6) for Change Management. For enhancements, every document should be looked at but not necessarily changed. For Bug Fixes, the following documents must be reviewed and possibly updated:

Design Document, Helpdesk Ticket, Code Documentation, Release Notes, Security Implications Test Results, Pre Vulnerability Scan Results, Test Plan, System Performance Test, Training Materials, User Manual, Post Vulnerability Scan Results, Sponsor Agreement Document, and Lessons Learned.

3.1.1 Analyze Requirements

The development team (Reclamation staff (contract or government) or Task Order awarded vendor) will review the requirements and determine how they will be developed in the application. Modules may be prioritized. All modules will be defined and the development team will document them in the development plan as well as identify any risks (maintained in a Risk Register), and create a Quality Management Plan to ensure best practices are included in the development project.

Output: Development Plan, Risk Register, and Quality Management Plan

3.1.2 Accept to Continue

The Project Manager will review the Development Plan and either accept to continue or ask the development team to revise the plan. The PM will gather input from other organizational members as needed (e.g. Solutions Architect, Security Representative, etc…).

3.2 Design

Create the design of the development project. The Development team (including functional testing and security personnel) will provide a documented design. The format of the design may vary depending on the size of the project. This could be an architectural diagram, workflows, detailed process flows or other design methodologies as determined by the development team. The design should include an understanding of the data needs and include an analysis of the data types and their sensitivity.

Output: Design Document(s), Helpdesk Ticket

3.2.1. Accept to Continue?

The Project Manager will review the Design and either accept to continue or ask the development team to revise the design(s). The PM will gather input from other organizational members as needed (e.g.

Solutions Architect, Security Representative, etc…).

3.3 Develop / Configure Application

The Application is developed according to the defined Development Plan. If this is a buy or build scenario, the customization and configuration is performed in this process.

Output: Configured/Developed module/product, Release Notes, and Code Documentation

3.4 Test (Repeat as needed)

Testing is performed against the requirements, using the defined Test Plan. Sections 3.5 and 3.6 work in conjunction with each other.

If testing finds an issue, it is documented and returned to Section 3.3.

*See Testing Process tab of workflow for more details

3.4.1 Formal Code Review

The code review process will be established and followed according to the project requirements.

3.5 Security Checklist

The security team will review the developed module/product and perform the security assessments as required including the pre-vulnerability scanning. All critical and high vulnerabilities must be remediated before moving forward.

Output - First time through, these documents are created. After the initial pass, each document is updated:

● Systems Security Plan

● Security Risk Assessment

● Security Implications Test Results

● Security Authorization Decision

● List of Operational Security Controls

● Security Assessment Report

● Pre Vulnerability Scan Results

3.5.1 Scan Results Acceptable

The security team will determine if the developed module/product passes the security scans. All critical and high vulnerabilities must be remediated. If all scans (both STIG compliance and other Security tests and scans), successfully meet the requirements, then determine if the system is complete. If it does not pass, the module/product will return to development with the list of issues associated with the scan output.

3.5.2 Is the System Complete?

Since this can be an iterative process, determine if the last work completes the module/system or if more development work is required. The answer will determine the next steps.

3.6 User Acceptance Testing

If the User Acceptance team finds issues, they work with the testing team to resolve the issues and the Testing team will work with the developers. This phase will ensure the requirements are acceptable to the customer/business sponsor/users.

Output: Test Plan, System Performance Results (updated depending on the iteration)

3.6.1 Sponsor Approval of system acceptance?

The Project Manager will review the Test Results and either accept to continue or ask the development team to perform additional tests. The PM will gather input from other organizational members as needed (e.g. SMEs, Solutions Architect, Security Representative, etc…).

Output: Sponsor Agreement Document

3.7 Deployment

The product is deployed to the production environment. (IT/Infrastructure Step, product ready)

Output: Deployment Plan, Training Materials, User Manual

3.8 Implement

The Product is implemented. Users are trained and begin using the application, communication to the users will provide information about the application, its use and any planned updates. During this process, the Post Vulnerability Scan will be performed prior to Implementation.

Output: Post Vulnerability Scan Results

3.9 Add Solution to Change Management Baseline

The solution is turned over to operations for all changes to be managed. The baseline provides the base from which all changes are measured. Changes to the base will follow both the operational and application change management processes as applicable.

During this step, either the Contingency Plan for an existing portfolio is updated or a new Contingency Plan is developed. Security will drive this and the document will be updated/developed at the point when the baseline is established or updated.

3.9.1 Other Modules to be Developed?

The decision will be made if the project is complete or if other development will be performed on the application. This will be a review of the currently completed work.

3.10 Notify & Update IRBAC, Capital Planning, Security, Solutions Architect, Capitalization Process

Ensure all stakeholders are notified of the new release and place the new product in the Operations and Maintenance Phase. If contracts are involved, follow the steps for closing a contract. The Business Case will be updated and the Capitalization Process will be Documented and Implemented.

Output:

● Project Management Plan

● Contingency/Disaster Recovery Plan

● System of Record Notice

● Business Case – TBM – Identify IT Tower

● O&M Manual Draft

● Lessons Learned

Once all development has been done, the application/product is deployed and implemented and all reviews are complete, the application will move to the Operations and Maintenance Phase.

3.11 Staffing Analysis

Review requirements and determine staffing needs for this phase of the project. This will provide management with information to determine if additional staff will be required. The Project Management Plan will be updated with the results of the analysis.

3.11.1 Additional Staffing Required?

If the staffing analysis includes resources not currently on staff or on contract, then a new task will be created and the acquisitions process will begin.

Output: Acquisition Plan

3.12 Acquisitions Process

The Statement of Work (SOW) for the task order is created. Procurement is engaged, following the predefined Acquisitions process. The Reclamation Procurement team assigns a Contracts Specialist and the Reclamation Procurement Process is started. During review of the Vendor responses, security will be present to ensure all security requirements are met.

Output: Resource Acquisition, Acquisition Plan, SOW and Awarded Task Order

4.0 Operations and Maintenance

When the product enters the Operations and Maintenance Phase it is in use by the customers and users.

Any change or fix is required to be processed through the Reclamation Application Change Process or pre-approved process defined by a vendor. User support for Operations and Maintenance is as defined in the application requirements.

4.1 Bug Fixes and Enhancements

During the life of the production application, bug fixes and enhancements are part of the process. In order to manage the issue tracking process and additional development needs, all users will be reporting requests (both enhancements and bugs) according to the process established by the Application Business Owner. The Project Manager and Application Business Owner will work together to establish the application change management process (see 4.6). The issue will be escalated to the appropriate tier application team. The process may be initiated by the user discovering a bug, customer recognizing a new business requirement or the technical team finding an issue through routine product maintenance.

Tools will be used to track these - either vendor supplied or government supplied.

Post Implementation Review - System Performance Issues ; Support was determined in the SLA and will continue.

4.2 Monitor/Analyze Application Performance

Throughout the life of an application, the IT staff will monitor and analyze the performance of the system.

Issues will be tracked and documented and could result in an update to the system architecture depending on the problem. The Project Manager will maintain a plan for monitoring application performance with the Infrastructure Team and Development Team…