Attachment_H-BOR_SDLC_Description.pdf

RECLAMATION ENTERPRISE APPLICATION

LIFECYCLE MANAGEMENT (ALM) DESCRIPTION

DOCUMENT

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 SDLC 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 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:

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

- 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

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 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), 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

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 could 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:

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 and Awarded Task Order

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

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 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

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 and Awarded Task Order

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

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.

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 providing ongoing monitoring throughout the life of the system.

4.3 Security Evaluation

The Security Team has an established timeline for performing security evaluations in accordance with NIST requirements and guidelines. The security team will track the schedule and initiate work with the application Project Manager to coordinate the events related to the evaluation

Output:

● Continuous Monitoring

● Revised Security Authorization

● Security Reauthorization Decision

● Security Documentation

4.4 Solutions Architect Review

Roles:

Solutions Architect

Processes 4.1, 4.2, and 4.3 all may trigger this process. Each process will require a review of the change, enhancement, performance or security event by the Technical Infrastructure Group.

4.4.1 Change Management Process?

The Project Manager will determine if a Change Request is required. If so, then the Change Management Process will be engaged. If no change to the system is going to be made, the work will end.

4.5 POA&M Process

Roles:

Security

The security team has an established process for managing POA&Ms and will engage the process, adding the findings from the evaluation/assessment to the POA&M and proceeding with the corrective actions and tracking of the POA&Ms.

4.6 Process for Change Management (6.1 or 7.1)

Once requests have been identified through bugs, enhancements, day to day monitoring or security evaluations and assessment, the request to change the application will follow the Application Change Management Process or approved vendor defined process.

(To access Reclamation’s Application Change Process:

https://sp.bor.doi.net/CM/_layouts/15/start.aspx#/SitePages/Home.aspx)

If the change request results in developing a new system, then proceed to the Lifecycle Replacement step in this phase.

https://sp.bor.doi.net/CM/_layouts/15/start.aspx#/SitePages/Home.aspx

4.7 Data Management

(I think Jim N. will provide something for this )

4.8 Update Business Case

The project manager will coordinate with the investment manager for potential changes to the business case. (a business will have funding for O&M and anticipates costs of changes).

The Operations and Maintenance Phase will continue for the remaining life of the system and its supporting components (data, equipment, etc…). Enhancements may result in returning to the Development and Implementation Phase. The system remains in this phase until a predetermined termination date or the Business Sponsor has determined the application is no longer needed, the Project Manager will be notified and the Decommission Phase will begin.

4.9 Lifecycle Replacement/Major Revision

All software development projects have an end of life, in some cases the application is completely ended and archival of data is the final step. However, there are times when an updated application is required to replace the existing system. This step in the process will require overlap with the current O&M and may include transition of data from the old system to the new system. If it is determined in this phase to replace an existing system, the SDLC process will start from the beginning and parts of the existing system will be decommissioned while other parts might be utilized (e.g. data).

Proceed to Phase 1.0 (Initiation Phase) of the SDLC process.

5.0 Decommission/Conversion Phase

The Decommission/Conversion Phase is the end of an application/system’s life cycle. The application/system is formally retired or data is converted into another application according to organizational needs, federal requirements, laws, and regulations and the Decommission/Conversion Plan.

When it has been determined that the life of the application/system has come to an end, it will be formally decommissioned and the process initiated to ensure all equipment is removed properly, the application data is properly destroyed or preserved and the software components of the system are removed from the Reclamation infrastructure.

The Decommission/Conversion Phase is initiated based on a decision made during and in-process review in the Operations and Maintenance Phase or based on predetermined life of the application/system.

5.1 Develop Decommission/Conversion Plan

The Decommission Plan should be an extension of the Records Management function. Records Management - what is kept, what is a legal “record,” retention period, etc. - is a topic beyond the scope of this SDLC. The software, hardware, and data of the current system are disposed of in accordance with organizational needs and pertinent laws and regulations.

The Application Project Manager will create a decommissioning plan to identify all the components of the system/application and how they will be decommissioned.

Output: Decommission/Conversion Plan and Privacy Impact Assessment

5.2 User Management

User Management is important to the decommissioning. Users will be notified of the removal of the system (and if a replacement system is being deployed). Also, the RESC supporting the user community will be provided with information to provide to users calling in for support. A standard memorandum should be written and distributed to the user community as well as provided in the location of accessing the decommissioned system (e.g. if the application is accessed online, it should be displayed on the initial application page.

Output: Decommission Memorandum (detailing the date of system closure and information about how to access data - if needed.)

5.3 Data Management Archive Database

The categorization of the data will determine the archive requirements, or disposal requirements for the data. Established data management processes will be engaged based on the categorization. Software or data of the system may be transferred to other existing systems, migrated to an entirely new system, or archived for future use.

Note: This is a records consideration. We should always plan new systems, applications, and data collections / databases with the forethought of archival in terms of records management. All data may be considered part of records if they are party to reporting, decision making, business activities, etc. So, this should be part of the planning process from the beginning. People need to consider this LONG before we are in decommission mode.

Output: Seems like there should be some sort of output to this.

5.4 Infrastructure/Software Management Archive Application Remove Servers

In some cases, specialized equipment is required for an application but typically the equipment is shared -depending on the needs of the system, the infrastructure representative will be engaged to remove the system or its components from the Reclamation production environment. Hardware may be made available for future use, added to surplus, discarded, or destroyed.

5.5 Security

In order to ensure all parts of the application/system have been removed, the security team will perform their activities associated with removal of equipment.

Output:

● Disposal/Transition Plan

● Index of Information, Location and Retention Attributes

● Disposition Records for Hardware and Software

● Media Sanitation Records

● Security Documentation

● Decommissioning/Conversion Plan

● Closing or transfer of any POA&Ms

● Retire system within CSAM

5.6 Capital Planning

The final step to the removal of an application is the Capital Planning step. This will include revising any funding sources that are no longer needed, updating any contingency planning that incorporated the application and other document updates. The final step is to perform the Lessons Learned and document all notable items that might be used to improve the process, improve any replacement applications and document the final stages of the application removal.

Output:

● Project Management Plan

● Contingency/Disaster Recovery Plan

● System of Record Notice

● Business Case

● Lessons Learned

ROLES AND RESPONSIBILITIES

Below are the Roles and Responsibilities of the SDLC team.

SDLC Role Responsibilities

Functional Manager/Business Owners/ITSD Management

Participate in the initial planning until work packages or activities are assigned. Provide subject matter expertise. Approve the final schedule during schedule development. Approve the final project management plan during project management plan development.

Information Resources Business Advisory Council (IRBAC)

Make the final determination of whether or not a project will move forward.

Information Resources Management Council

(IRMC)

Project Sponsor Define the project. Identify the end goal of the project. Act as liaisons to the organizational stakeholders. Effectively communicate the organization’s vision, goals and expectations to the team throughout the life cycle.

Data Manager Oversee the development and use of data systems.

Data Analyst Analyze and manage data.

Group Manager, Application Development Responsible for managing the design, development and implementation of software solutions and the platform upon which those solutions are developed and deployed.

Information System Security Officer The Security Officer is responsible for the overall security of the system and the security of the resources associated with processing functions. He or she ensures system adherence to the agency’s IT security program, implements IT security certification and accreditation processes, and ensures the confidentiality, integrity, availability, and accountability for all agency information in the system while it is processed, stored, and/or transmitted electronically.

Solutions Architect Translate requirements into the architecture for the solution.

Enterprise Architect Design, plan, and govern strategic and cross-organizational rationalization or optimization of the enterprise's services, processes, or components.

Infrastructure Manager Plan, direct and design the IT infrastructure.

Ensure that all relevant data is properly collected and stored. Implement processes and procedures.

Develop strategies and oversee the IT Department, Contracting Officer Representative Provides technical direction, clarification and guidance with respect to the contract specifications and statement of work.

Project Manager Determine objectives and schedule. Design a project management plan. Determine the team‘s work procedures, reporting systems and communication infrastructure. Accomplish project objective within time and budget. Monitor performance against the plan. Control changes in the project. Report on project activities to upper management. Keep the client informed and committed.

Capital Planning Lead Ensures that projects adhere to CPIC standards

Contractor/Developers Researching, designing, developing, and testing software.

Subject Matter Expert/Testers Provide first-hand knowledge, expertise and understanding of business rules, business process and business requirements.

Release Manager Identify all items that need to be coordinated, managed, scheduled, and planned across a release.

System Manager The System Manager has overall responsibility for the operations and maintenance of the project deliverables post-implementation.