OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 1

Table of Contents

1. INTRODUCTION......................................................................................................... 4

1.1 Purpose............................................................................................................................ 4

1.1.1 OPM SDLC Policy ......................................................................................................... 4

1.1.2 Key Concepts and Principles ........................................................................................ 4

1.2 Scope and Applicability ................................................................................................. 5

1.3 Compliance, Enforcement and Exceptions .................................................................. 6

2. ROLES, RESPONSIBILITIES, AND GOVERNANCE ........................................... 7

3. PROJECT INITIATION............................................................................................ 16

3.1 Need Identified ............................................................................................................. 16

3.2 Executive Sponsor, Business Program Manager, Business Project Manager adopts

the need ......................................................................................................................... 16

3.3 Executive Sponsorship Approval ............................................................................... 17

3.4 Initiate the OPM SDLC ............................................................................................... 17

3.5 Critical Prerequisites to Investment Success ............................................................. 17

4. OPM SYSTEM DEVELOPMENT LIFE CYCLE (SDLC) .................................... 19

4.1 Introduction .................................................................................................................. 19

4.2 SDLC Phases ................................................................................................................. 20

4.2.1 Overview .......................................................................................................................... 20

4.2.2 Determine System Needs Phase....................................................................................... 20

4.2.3 Define System Requirements Phase ................................................................................ 21

4.2.4 Design System Components Phase .................................................................................. 22

4.2.5 Build System Components Phase .................................................................................... 23

4.2.6 Evaluate System Readiness Phase ................................................................................... 24

4.2.7 Deploy the System Phase ................................................................................................. 25

4.2.8 Decommission the System Phase..................................................................................... 26

5. METHODOLOGIES .................................................................................................. 26

5.1 Waterfall ....................................................................................................................... 27

5.1.1 Overview .......................................................................................................................... 27

5.1.2 Strengths .......................................................................................................................... 27

5.1.3 Weaknesses ...................................................................................................................... 27

5.2 Incremental ................................................................................................................... 27

5.2.1 Overview .......................................................................................................................... 27

5.2.2 Strengths .......................................................................................................................... 28

5.2.3 Weaknesses ...................................................................................................................... 28

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 2

5.3 Agile (Scrum) ............................................................................................................... 28

5.3.1 Overview ......................................................................................................................... 28

5.3.2 Strengths: ........................................................................................................................ 31

5.3.3 Weaknesses: .................................................................................................................... 31

6. PROJECT MANAGEMENT FRAMEWORK ........................................................ 31

7. CONFIGURATION MANAGEMENT FRAMEWORK ........................................ 34

8. QUALITY ASSURANCE FRAMEWORK .............................................................. 36

9. RECORDS MANAGEMENT FRAMEWORK ....................................................... 37

APPENDIX A: ACRONYMS ................................................................................................... 43

APPENDIX B: GLOSSARY ..................................................................................................... 46

APPENDIX C: REFERENCES ................................................................................................ 55

APPENDIX D : OPM SDLC PHASE ACTIVITIES ............................................................... 57

Appendix D.1: Determine System Needs Phase Activities ....................................................... 57

Appendix D.2 : Define System Requirements Phase Activities ................................................ 67

Appendix D.3: Design System Components Phase Activities ................................................... 79

Appendix D.4: Build System Components Phase Activities ..................................................... 87

Appendix D.5: Evaluate System Readiness Phase Activities .................................................... 98

Appendix D.6 : Deploy the System Phase Activities .............................................................. 106

Appendix D.7: Decommission the System Phase ................................................................... 113

APPENDIX E: PROJECT CATEGORIES AND PROJECT DOCUMENTATION LEVEL ....... 115

Appendix E.2.1: Project Documentation Level 1 .................................................................... 118

Appendix E.2.2: Project Documentation Level 2 .................................................................... 118

Appendix E.2.3: Project Documentation Level 3 .................................................................... 119

Appendix E.2.4: Project Documentation Level 4 .................................................................... 121

Appendix E.2.5: Project Documentation Level 5 .................................................................... 122

APPENDIX F: SCRUM PROCESS DETAILS .................................................................... 124

Appendix F.1 Determine Systems Needs / Idea Proposed ...................................................... 125

Appendix F.2 Develop and Prioritize Product Backlog.......................................................... 125

Appendix F.3 Sprint Planning Meeting Process ..................................................................... 126

Appendix F.4 Daily Scrum Process ........................................................................................ 126

Appendix F.5 Sprint Functionality Review Process ................................................................ 126

Appendix F.6 Monthly Business-related Performance Metric Reviews ................................ 127

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 3

Revision History

Version Number

Version Date

Revision Summary

1.0

June 2012

Official first OPM version of this document

1.1

April 2013

Address OPM’s Office of Inspector General

audit recommendations especially the one

regarding “We recommend that the OCIO

establish an SDLC review process in which the

OCIO must review and formally approve

SDLC work at various milestones for all OPM

system implementation projects.” as well as

others.

Executive Summary

The Office of Management and Budget (OMB), the Federal Chief Information Officer and the

Congress have set ever higher standards for the management and performance of information

technology investments within the Federal government. Those standards require IT programs and

projects to achieve consistently successful outcomes that maximize alignment with business

objectives and meet key cost, schedule and performance objectives.

A key to successful IT management is a solid program and project management methodology

that incorporates best government and commercial practices through a consistent and repeatable

process, and provides a standard structure for planning, managing and overseeing IT programs

and projects over their entire life cycle. Industry and government experience demonstrates that

the quality of IT investments is directly proportional to the quality of the management processes

used to acquire and operate the IT products those investments produce. This document is the

U.S. Office of Personnel Management (OPM) System Development Life Cycle (SDLC) policy

and standards guidance.

The OPM SDLC applies to all OPM and contractor personnel who are developing systems,

acquiring systems, managing new systems, and making modifications or enhancement of

existing systems. System developers, users, and all level of OPM management across all

functional areas must adhere to the OPM SDLC or equivalent SDLC processes. The OPM

SDLC is crucial to delivering cost effective information systems for OPM.

The version of this document that is posted to the Web is the official, authoritative version

and supersedes the Information Technology Systems Manager (ITSM) SDLC policy and

standards found in THEO.

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 4

1. INTRODUCTION

This document is provided as a resource for the management and development of OPM

information technology (IT). This document serves as the mechanism to assure that systems

under development are engineered to satisfy the user's requirements, within determined cost,

schedule and quality guidelines. It provides a structured approach to managing information

systems programs and projects beginning with establishing the need for a systems development

or maintenance effort, through development and deployment, and concluding with

decommissioning of the system.

1.1 Purpose

The OPM System Development Life Cycle (SDLC) Policy and Standards document provides

Business Program Managers, Business Project Managers, Technical Project Managers and other

program and project stakeholders guidance and implementation standards for system

development. It is a collection of resources designed to support the approval, planning and life

cycle development of OPM information systems. To deliver cost effective information, it is

crucial that system developers, customers, and all levels of OPM management across functional

areas adhere to the OPM SDLC.

1.1.1 OPM SDLC Policy

OPM IT programs and projects must use an SDLC according to standards outlined in this

document. An SDLC is a consistent and repeatable process which applies to planning,

managing, and overseeing IT programs and projects over their entire life cycle. The OPM

approved SDLC methodologies include Waterfall, Incremental, and Agile. In some cases,

deviating from one of the approved SDLC methodologies could be more advantageous to OPM.

In order to deviate from an approved SDLC methodology, the Technical Project Manager must

present to the SDLC Program Manager and Chief Information Officer (CIO) how the alternative

methodology meets all seven of the SDLC phases as discussed in section 1.2.

1.1.2 Key Concepts and Principles

OPM’s SDLC Policy is based on the following key concepts and principles:

1. Baseline Management. The careful development, monitoring, maintenance and

management of plans, including cost, schedule and business-related performance as

required by the OPM Baseline Management policy is fundamental to the success of all IT

programs and projects. All SDLC options addressed by this document require the use of

effective baseline management methods. For more information, see OPM’s IT Baseline

Management Policy at which can be found in an internal OPM link at Appendix C.1.1.

2. “Line of Sight”. The reporting of actual cost, schedule and performance of an IT

program or project must be easily traced to the original plans. Any reports generated

shall be simple and easy to understand. Major investments requiring Earned Value

Management reports should reference the OPM Baseline Management policy.

3. Accountability. The Clinger–Cohen Act provides that the OPM IT organization be

operated as an efficient and profitable entity. To meet that goal, the law requires the

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 5

OPM Director to establish clear accountability for IT management activities by

appointing a CIO with the visibility and management responsibilities necessary to carry

out the specific provisions of the Clinger-Cohen Act.

4. Cost and Schedule. Cost estimation for IT programs and projects must be performed

according to Federal standards. All SDLC options addressed by this document require the

use of the Government Accountability Office (GAO) Cost Estimating and Assessment

Guide which can be found in an external link at Appendix C.1.1. Since actual costs will

be reported on www.USASpending.gov and available for public review, it is imperative

that cost estimates be valid. This will also require that each program and project must

establish Service Level Agreements (SLA) or Operating Level Agreements (OLA) within

the cost estimates, if appropriate.

1.2 Scope and Applicability

This policy document applies to all OPM programs with an information technology component

regardless of funding type and funding amounts. There may be an OPM information technology

program and project that is not part of any internal OPM mission or program such as an

interagency or Government-wide effort, this policy document would still apply to those

initiatives. The document applies to both government and contractor efforts.

The use of the OPM SDLC Policy and Standards document applies to all OPM and contractor

personnel who are developing, acquiring or managing new systems or making modifications or

enhancements to existing systems. The use of the document includes the acquisition of all

commercial off-the-shelf (COTS) solutions and Cloud solutions by OPM.

When an analysis of alternatives indicates an IT solution is required to satisfy the identified

requirement, a Cloud solution strategy must be the primary focus for Business Program

Managers, Business Project Managers and Technical Project Managers as required by Vivek

Kundra's "25 POINT IMPLEMENTATION PLAN TO REFORM FEDERAL INFORMATION

TECHNOLOGY MANAGEMENT" document (see Appendix C). If Cloud solutions are found

to not meet OPM requirements, COTS or new systems development may be pursued.

OPM staffs are responsible for ensuring that the systems development and management approach

described in the document is practiced on a day-to-day basis. Because there may be external

Federal agencies (i.e., Government Accountability Office, Office of Management and Budget,

etc.) who may request investment information at a moment’s notice, the OPM staff must be

prepared to provide SDLC documentation or deliverables. This can only be achieved by

following the best practice of utilizing an SDLC and documenting the SDLC deliverables.

If the Technical Project Manager wishes to use an alternative SDLC then it must be equivalent in

all areas of the OPM SDLC as stated in Section 4 of this document. The Technical Project

Manager must provide a presentation to the SDLC Program Manager, other appropriate CIO

staff, and the Business Program Manager or Business Project Manager showing how the

equivalence is achieved for all seven SDLC phases:

 Determine System Need (Section 4.2.2)

 Define System Requirements (Section 4.2.3)

 Design System Components (Section 4.2.4)

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 6

 Build System Components (Section 4.2.5)

 Evaluate System Readiness (Section 4.2.6)

 Deploy the System (Section 4.2.7)

 Decommission the System (Section 4.2.8)

The presentation must include a portfolio of documentation deliverables which can be expected.

This document applies to the work of the individuals and groups filling the roles described in

section 2, “Roles, Responsibilities, and Governance”.

1.3 Compliance, Enforcement and Exceptions

The CIO will enforce the OPM SDLC process to ensure compliance through periodic reviews of

randomly selected OPM programs with IT components and OPM IT projects. The reviews may

be conducted by the SDLC Program Manager or a designated SDLC subject matter expert

(SME) on behalf of the CIO.

The CIO or an authorized designee is the official approver of submitted deviations and waivers

to the OPM SDLC Policy and Standards.

All OPM SDLC templates or process documents can be utilized in the Agile methodology. If the

Technical Project Manager wishes to use an alternative SDLC then it must be equivalent in all

areas of the OPM SDLC as stated in Section 4 of this document. It is recognized that there will

be alternative Agile documentation that Project Teams will wish to utilize. Waiver and deviation

requests from the OPM SDLC standard are not required when alternative Agile documentation

methods convey the OPM SDLC standards’ requirements.

OPM IT programs or projects currently utilizing the previous SDLC standard, Information

Technology Systems Manager (ITSM), are grandfathered in using the ITSM standards to

complete their implementation. All other OPM IT programs or projects which have just entered

into the initial planning stage are subject to the OPM SDLC policy and standards in this

document.

1.4 Authority

This document is issued under the following authorities:

 Clinger Cohen Act of 1996 which requires “the head of each executive agency [to] design

and implement … a process for maximizing the value and assessing and managing the

risks of the information technology acquisitions of the executive agency” (Clinger-Cohen

Act of 1996, Section 5122(a))

 Office of Management and Budget (OMB) Circular A-130, Management of Federal

Information Resources, which requires the Chief Information Officer to monitor and

evaluate the performance of information technology investments

 Paperwork Reduction Act (PRA)

 OMB Memorandum, M-11-29, CIO Authorities

 Berry, J. (OPM Director) (11/7/2011) “Chief Information Officer Authorities”,

Memorandum for Associate Directors and Heads of Offices. Office of Personnel

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 7

Management

2. ROLES, RESPONSIBILITIES, AND GOVERNANCE

The roles detailed in the following sections are required for new development as well as

maintenance and enhancement programs or projects. An individual can be responsible for

multiple roles especially for the small maintenance and enhancement program or project. For

example, an individual can be both the system developer and the system quality assurance team

of a project. The Business Program Manager or Business Project Manager in collaboration with

the Technical Project Manager must ensure that the roles are addressed within the constraints of

the assigned members to the program or project.

2.1 The Chief Information Officer (CIO)

The CIO has responsibilities in the following areas:

 Assigning the Technical Project Manager to the IT project;

 Jointly responsible with the OPM Associate Directors, Heads of Offices and Senior

Executives for selecting, assessing and managing information technologies;

 Reviewing and approving all information technology-related procurement plans and

strategies before any other OPM governance approvals (e.g., Capital Investment

Committee, etc.);

 Approving all IT-related procurements;

 Advising the OPM Director on the selection, management and use of information

technology, and on risks related to the management of IT;

 Advising the agency head on budgetary implications of information technology decisions

as the Chair of the Investment Review Board (IRB);

 Advising the agency head on whether to continue, modify or terminate an IT investment

as one of the TechStat Co-Chairs;

 Approving of new and revised baselines for an IT investment;

 Authorizing the waiving or deviating from the policy and standards of this document;

 Designating CIO staff to be on the Integrated Project Team for the program or project;

 Designate CIO staff to be dedicated technical advisors on IT projects if funded by the

program office or by the project;

 Chairing the OPM IRB.

2.2 OPM Associate Directors, Heads of Offices and Senior Executives

The OPM Associate Directors, Heads of Offices and Senior Executives have responsibilities in

the following areas:

 Selection of the Business Program Manager or Business Project Manager;

 Jointly responsible with the CIO for selecting, assessing and managing information

technology;

 Ensuring that all IT-related procurement plans and strategies are approved in advance by

the CIO;

 Serving as Authorizing Official (for more information, see Authorizing Official below in

Section 2.10.);

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 8

 Ensuring compliance with the requirements of this document.

2.3 Chief Financial Officer (CFO)

The CFO obtains the CIO’s concurrence on any budgeting decisions that affect OPM funding for

IT programs or projects.

2.4 Business Program Manager

The Business Program Manager manages one or more major multi-year IT initiatives of such

magnitude they must be carried out through multiple related IT projects and is accountable for

the overall success of the program. Responsibilities include:

 Report to the CIO within a matrix organization framework for the life of the program;

 Creating and leading an Integrated Project Team;

 Leading, coordinating, communicating, integrating program activities;

 Ensuring alignment with critical agency priorities;

 Ensuring the work efforts achieve the outcome specified within the agency’s business

strategy, including appropriate strategic, life cycle management and capital IT investment

plans;

 Managing the project selection, prioritization, evaluation and monitoring, cost schedule

management, risk management, quality management and resource allocations;

 Representing the program office and the customers during the life of the IT projects

within the investment;

 Preparing cost, schedule and business-related performance metric baselines for their

investments in accordance with the OPM Baseline Management Policy;

 Monitoring cost, schedule and performance baselines for the investment;

 Responsible for ensuring that IT projects meet budgetary constraints;

 Updating the Federal IT Dashboard with current status for major IT investments;

 Responding to CIO questions about the investment, including questions related to in-

depth reviews of the investment;

 Coordinating the business needs with the Technical Project Manager;

 Create and monitor the approved investment baseline and accepting the work products

produced as outlined in the OPM Baseline Management Policy;

 Based on the Risk Matrix of the program or project, periodically assess the entire

Program’s or Project’s return on investment (ROI) and successful completion of the

program within baseline milestones.

For the Agile (Scrum) methodology, the Business Program Manager can serve as the

Product Owner. The Product Owner will ensure that the scrum process is supported as

detailed in Appendix F “Scrum Process Details”.

2.5 Business Project Manager

The Business Project Manager manages one IT project and is accountable for the overall success

of the IT project. Responsibilities include:

 Report to the CIO within a matrix organization framework for the life of the project;

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 9

 Creating and leading an Integrated Project Team;

 Leading, coordinating, communicating, integrating and being accountable for the overall

success of the project;

 Ensuring alignment with critical agency priorities;

 Ensuring the work efforts achieve the outcome specified within the agency’s business

strategy, including appropriate strategic, life cycle management and capital IT investment

plans;

 Managing the project selection, prioritization, evaluation and monitoring, cost schedule

management, risk management, quality management and resource allocations;

 Representing the program office and the customers during the life of the IT project;

 Preparing cost, schedule and business-related performance metric baselines for their

project in accordance with the OPM Baseline Management Policy;

 Monitoring cost, schedule and performance baselines for the project;

 Responsible for ensuring that the IT project meet budgetary constraints;

 Updating the Federal IT Dashboard with current status for the major IT investments;

 Responding to CIO questions about the project, including questions related to in-depth

reviews of the investment;

 Coordinating the business needs with the Technical Project Manager;

 Create and monitor the approved investment baseline and accepting the work products

produced as outlined in the OPM Baseline Management Policy;

 Based on the Risk Matrix of the program or project, periodically assess the entire

Program’s or Project’s return on investment (ROI) and successful completion of the

program within baseline milestones.

For the Agile (Scrum) methodology, the Business Project Manager can serve as the

Product Owner. The Product Owner will ensure that the scrum process is supported as

detailed in Appendix F “Scrum Process Details”.

2.6 Technical Project Manager (Technical PM) (Scrum Master)

The Technical Project Manager (Technical PM) has responsibilities in the following areas:

 Meeting the objectives of a IT project;

 Creating and leading a technical Integrated Project Team;

 Coordinating with Business Program Manager or Business Project Manager from the

program office on the development of the IT project;

 Selecting a system life cycle methodology, the methods and tools to be used, and the

required controls and deliverables;

 Provide overview of the technical approach of the project to the Business Program

Manager or Business Project Manager;

 Providing the leadership and management of the SLDC implementation effort and the IT

project team;

 Reporting to the Executive Steering Committee on the performance of the IT project.

For the Agile (Scrum) methodology, the Technical Project Manager will serve as the

Scrum Master. The Scrum Master will ensure that the scrum process is managed as

detailed in Appendix F “Scrum Process Details”.

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 10

2.7 Program Management Offices (PMO)

Program Management Offices are responsible for the following:

 Planning for and managing implementation of the requirements of the OPM SDLC;

 Developing the following program or project requirements:

o The investment’s Work Breakdown Structure

o The investment’s Organizational Breakdown Structure

o The investment’s Responsibility Assignment Matrix

o Summary Earned Value or operational analysis reports

o The investment’s cost, schedule and performance baselines;

 Monitoring the investment’s cost, schedule and performance baselines;

 Performing operational analysis for the investment;

 Providing analytical support to the Business Program Manager or Business Project

Manager in response to CIO’s questions about the investment.

2.8 OPM Contracting Officers

OPM Contracting Officers must consult with the CIO on the development of contract clauses for

investments covered by this document to ensure that the clauses reflect the requirements of this

document. They must work with the CIO in requesting appropriate documentation from

contractors related to validating compliance with this document.

2.9 Configuration Control Board (CCB)

The Configuration Control Board reviews, approves/rejects, and prioritizes change requests

which deals with IT System changes. A CCB must exist for each IT program or project.

2.10 Authorizing Official (AO) (Associate Directors, Heads of Offices and Senior

Executives)

The following role definition for Authorizing Official is from the Information Security and Privacy

Policy which can found by following the link in Appendix C.

The Authorizing Official is an executive with the authority to formally assume responsibility for

operating an information system at an acceptable level of risk to organizational operations and assets,

individuals, other organizations, and the Nation. The role of an AO has inherent U.S. Government

authority and is assigned to Government personnel only. Only an executive can accept risk. Risk

justification must be supported with a compelling business case. With the increasing complexity of

missions/business processes, partnership arrangements, and the use of external/shared services, it is

possible that a particular information system may involve multiple AOs. The AO shall:

 Have budgetary oversight for an information system or be responsible for the mission and/or

business operations supported by the system;

 Be accountable for the security risks associated with information system operations;

 Review Security Assessment and Authorization documentation and discuss concerns with the

Chief Information Security Officer (CISO) as necessary;

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 11

 Deny authorization to operate an information system or if the system is operational, halt

operations, if unacceptable risks exist;

 Coordinate their activities with the CISO, System Owner (SO), Information System Security

Officers (ISSO), Security Control Assessors, and other interested parties during the security

authorization process;

 Establish agreements among AOs, if multiple AOs, and document in the SSP; and

 Be responsible for ensuring all activities and functions delegated to an Authorizing Official

Designated Representatives are carried out. The AO is responsible for determining that the

system meets appropriate security requirements and formally approves the system for

operation.

2.11 Executive Sponsor

The Executive Sponsor is a senior business executive who provides approval, guidance and

support for new information system initiatives.

2.12 Chief Architect

The OPM Chief Architect functions as the chief IT architect for all IT initiatives in OPM. The

Chief Architect guides the evolution of the OPM enterprise architecture. The Chief Architect

maintains the architecture vision, technical standards and implementation plan. The Chief

Architect reviews a project’s IT architecture to ensure it aligns with the OPM enterprise

architecture.

2.13 Customer (User)

The customer is a designated user representative from the investment or program office who

supports the Business Program Manager, Business Project Manager and Technical Project

Manager to help define requirements, resolve issues, and test IT user requirements for the

Technical Project team. There can be many customers who support the system development,

enhancement or maintenance process.

For the OPM SDLC, a reference to “user” is synonymous with customer.

2.14 Configuration Management (CM) Team

The CM Team is responsible for adhering to any CIO CM standards or establishing new CM

processes (if none exist). The CM Team maintains the integrity of configuration items

throughout a system’s life cycle. The CM Team can exist at the system, project or program

office level within OPM.

2.15 Configuration Management (CM) Practitioner

The CM Practitioner participates in a CM Team and performs the work required to control

versions of deliverables such as releases (e.g., system, hardware, etc.), documentation, program

artifacts and project artifacts.

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 12

2.16 Operations Team/Network Management Team

The Operations Team/Network Management Team is responsible for operations and

performance of all network systems (internal and external) related to program or project

operations. However, there are certain systems which are outside of Network Management’s

control and authority.

2.17 Integrated Project Team (IPT)

OMB Circular A-11 states: “An Integrated Project Team is a multidisciplinary team led by the

program manager to manage the acquisition process. Team members may change somewhat for

different phases of the project, but members must represent those who have a major interest in

the project. Members should be full time or dedicated to the program when needed. Members

should include qualified people able to advise the program manager about technical, business,

project, schedule, procurement, finance, and other issues, and identify users’ concerns about the

acquisition.”

2.18 Requirements Management Team (Requirements Practitioner)

The Requirements Management Team is responsible for the requirements derivation, traceability,

and ensuring that business needs are covered completely throughout the system’s life cycle.

2.19 Quality Assurance (QA) Team

QA Team reports to the Business Program Manager or Business Project Manager. QA Team is

responsible for the formal monitoring of the various work products of the program or project to

ensure standards, policies and procedures are being met in addition to monitoring for compliance

and effectiveness of the processes being used.

2.20 Software Quality Assurance (SQA) Team

SQA Team reports to the Technical Project Manager. SQA Team is responsible for the formal

monitoring of the software products of the program or project to ensure standards, policies and

procedures are being met in addition to monitoring for compliance and effectiveness of the

processes being used. This team is involved in the technical system development level.

2.21 Technical Advisor (Subject Matter Expert (SME))

Technical Advisor is an IT Specialist engaged to provide technical consultation and support in

various IT technical areas of the project to the Business Program Manager or Business Project

Manager. If the Program Office provides sufficient funds to the CIO, the CIO can designate

dedicated technical advisors to support their specific IT project.

2.22 Security and Privacy Team

The Security and Privacy Team provides the program or project with expertise in computer

security, communications security, emissions security, and/or network security and designates a

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 13

security officer to ensure security requirements are satisfied. The Security and Privacy Team is

an integral part of the development and operational management of any system in order to ensure

compliance with Federal Information Security Management Act (FISMA) and National Institute

of Standards and Technology (NIST) guidance. Refer to the Information Security and Privacy

Policy webpages for the contact information. A link to the webpages is located in Appendix C.

2.23 Designated Security Officers (DSOs)

The following role definition for DSOs is from the Information Security and Privacy Policy

which can found by following the link in Appendix C.

The Designated Security Officer (DSO) is appointed by an OPM Program Office or Department

to represent the interests of the program office or department in carrying out the security

functions of the organization. The DSO shall:

 Work closely with the CISO, ISSO, and appropriate staff in the program offices to protect

information resources from misuse, whether intentional or unintentional. This effort will

involve reviewing, evaluating, and recommending appropriate information security and

privacy measures along with safeguards;

 Conduct periodic security reviews of system facilities to ensure safeguards are

commensurate with the system information being stored, processed, or transmitted;

 Update system security documentation and work with the SO and ISSO to assess the

security impact of any information system changes;

 Coordinate with the Software Development Managers and ensure security requirements

and issues are addressed consistent with this policy;

 Assist the CISO, Information Systems Security Manager, and ISSO in the identification,

implementation, and assessment of common security controls;

 Ensure the implementation of any modifications necessary and correct security control

deficiencies found during security assessment testing;

 Advise users of the security features and procedures to be used for information systems;

 Establish access control criteria and administrative procedures consistent with OPM

policy;

 Review and approve new user accounts for system and network access after obtaining

supervisor or management approval;

 Ensure the development and timely completion of reports to security and privacy

including those related to POA&Ms, system inventory, security controls testing and

monitoring, contingency plan testing etc.;

 Ensure all actual and suspected security incidents and breaches of PII are reported to the

OPM Situation Room (SitRoom);

 Assist in the investigation of actual or suspected security incidents and breaches of PII as

appropriate;

 Participate in internal/external reviews, inspections, and audits to ensure compliance with

federal laws and OPM policy;

 Coordinate with the CISO to advise contracting officers developing or administering

contracts on behalf of OPM regarding the content and implementation of contract clauses

related to OPM’s information security and privacy policy;

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 14

 Review acquisition documentation to ensure the inclusion of appropriate information

security-related clauses, consistent with this policy and the Policy on IT Procurement;

 Develop and maintain (with the assistance of the CISO) an annually verified list of

systems requiring security authorization;

 Coordinate the Security Assessment and Authorization process for program office

systems (See OPM’s Security Assessment and Authorization Procedure for more

information.); and

 Attend monthly ITSWG meetings and participate in ITSWG activities.

2.24 System Development Team (Scrum Team)

The System Development Team is responsible for the development or configuration of the

technical design of the system and is the author of the work products (e.g., the program code,

specification, document, module, screen, component, etc.) actually produced by the program or

project in compliance with the system requirements fulfilling the customer needs.

For the Agile (Scrum) methodology, the System Development Team will serve as the Scrum

Team. The Scrum Team will ensure that the system development process is followed as detailed

in Appendix F “Scrum Process Details”.

2.25 System Development Team Lead

The System Development Team Lead is responsible for leading the system development team

assigned to perform the specific task of the project.

2.26 Testing Team

The Testing Team is responsible for testing and verifying that the system functions and performs

as expected, as defined by the system requirements and design documentation.

2.27 System Owner (Certifying Official)

The OPM Associate Directors, Heads of Offices and Senior Executives for the program offices

serves as the System Owners. In addition, the following role definition for System Owner is from the

Information Security and Privacy Policy which can found by following the link in Appendix C.

The System Owner is the official responsible for the overall security, procurement, development,

integration, modification, or operation and maintenance of an information system. The SO shall:

 Categorize the information system according to the potential impact to OPM of a breach of

confidentiality, integrity, or availability;

 Ensure the implementation of the security controls appropriate to the risk rating established

through the categorization process for the system;

 Identify and evaluate security risks and vulnerabilities and establish risk mitigation plans;

 Approve System Security Plans (SSPs), and review Memorandums of Agreement or

Understanding (MOA/U), and Plans of Action and Milestones (POA&Ms) and determine whether

significant changes in the information systems or environments of operation require reauthorization;

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 15

 Ensure the Information Security and Privacy Policy (ISPP) is followed by all users accessing

the information system;

 Ensure the management, operational and technical information security controls are

implemented and operating as intended for all of their information systems;

 Ensure system users and support personnel receive the requisite security and privacy training;

 Ensure that DSOs are identified and provide security-related support;

 Ensure that program office senior management is aware of the resources required to assess

and authorize information systems allowing appropriate work plans and budgets to be developed;

 Ensure appropriate staff (system administrators, technical developers, and other staff) are

assigned to coordinate with the DSO in developing Security Assessment and Authorization

documentation (See OPM’s Security Assessment and Authorization Procedure for more

information);

 Provide necessary system-related documentation to the CISO;

 Take appropriate steps to reduce or eliminate system vulnerabilities identified in the Security

Assessment and Authorization process;

 Ensure a Privacy Threshold Analysis (PTA) and if applicable, a Privacy Impact Assessment

are conducted on all systems before implementation or enhancement, in accordance with OPM’s

Privacy Impact Assessment Guide;

 Review acquisition documentation to ensure adequate and cost-effective security measures

and safeguards are included; and

 Ensure all contracts for IT services, both software and hardware, include clauses

incorporating OPM’s System Security Plan (SSP) and related references.

2.28 Training Team

The Training Team is responsible for training the users and develops all related training

materials as necessary.

2.29 IT Executive Governance Groups

The following are the IT executive governance groups who oversee OPM’s use of information

technology.

 Investment Review Board (IRB) - For more detail on the roles and responsibilities of the

IRB, see the IRB charter located at http://theo.opm.gov/References/IT/IRB/charter.asp

 Executive Steering Committee (ESC) - Responsible for providing direct oversight of

information technology investments.

2.30 Business Analyst

The Business Analyst provides functional support to the Business Program Manager or Business

Project Manager in the area of Business Process Re-engineering (BPR). The business processes

must be assessed, evaluated, revised, implemented and verified appropriately in order for the

investment to take advantage of the technology solution in an efficient and effective manner.

2.31 Customer Service/Help Desk

The Customer Service/Help Desk (CS/HD) provides support services for both business and

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 16

technical issues of an IT project. Issues can range from technical issues such as password resets

to business issues such as locating documentation for a software enhancement. The program and

project teams must ensure coordination by working with CS/HD to capture specific requirements

and touch points regarding the necessary CS/HD involvement for the program and projects.

2.32 Transition Team

A Transition Team may be required if a new IT project is replacing an older IT system. The

Transition Team will coordinate the necessary business and technical actions required to ensure

that a new IT project is implemented with the least disruption to all customers and capable of

being sustained throughout the life cycle.

3. PROJECT INITIATION

This section describes how the program or project’s initiation before entering the system

development life cycle. Before new system development, maintenance or enhancement begins,

the following steps must occur.

3.1 Need Identified

A program or project begins when a need for technology or a solution to a problem is identified.

This need can arise from the Business/Functional staff or from the Technical staff. This need

may require the development of a new application with new functionality or the

purchase/integration of Commercial Off-the-Shelf (COTS) software or Cloud solution; or the

need may be satisfied by maintenance/enhancement to an existing system.

3.1.1 New Development or Implementation

When the need is for development of a new application/system, implementation of new COTS

product or implementation of a Cloud solution, it must be submitted to the Executive Sponsor,

Business Program Manager or Business Project Manager via a recognized communication

channel such as email, memorandum or issue tracking software. When a need is new to OPM

and there is no assigned Business Program Manager or Business Project Manager, the Executive

Sponsor must initially assess the need and determine if it warrants assigning someone the

responsibility of being the Business Program Manager or Business Project Manager. The

assigned Business Program Manager or Business Project Manager would proceed to Section 3.2

below.

3.1.2 Maintenance or Enhancement

When the need is for maintenance or enhancement requirements to existing systems or Cloud

solutions, it must be documented as a Change Request (CR) which is routed to the Business

Program Manager or Business Project Manager. The Executive Sponsor had previously

authorized the system so review by the Executive Sponsor is not required.

3.2 Executive Sponsor, Business Program Manager, Business Project Manager adopts

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 17

the need

The user discusses the need and the rationale for the need with the Executive Sponsor, Business

Program Manager or Business Project Manager (in some instances the Business Program

Manager or Business Project Manager or user can be the same person).

3.2.1 New Development or Implementation

If the Business Program Manager or Business Project Manager decides the need for the new

system development or implementation is worthy of further development, he/she gathers

information in preparation for Executive Sponsorship approval.

3.2.2 Maintenance or Enhancement

If the Business Program Manager or Business Project Manager decides the need for the

maintenance or enhancement is worthy of further development, he/she gathers information in

preparation for Configuration Control Board (CCB) assessment and determination. If the CCB

approves the need based on the technical functions requested, the Business Program Manager or

Business Project Manager will proceed to Section 3.4 below.

3.3 Executive Sponsorship Approval

The Business Program Manager or Business Project Manager briefs his/her senior management

regarding the need. The executive sponsor then approves or disapproves the project for further

development and ensures that funding is provided to the Business Program Manager or Business

Project Manager.

3.4 Initiate the OPM SDLC

Once the need receives approval for further development, the Business Program Manager or

Business Project Manager begins the activities in the OPM SDLC Determine System Need

phase. The Business Program Manager or Business Project Manager will determine the Project

Documentation Level by selecting the appropriate project categories (i.e., Duration, Risks (High,

Medium, Low), etc.). Appendix E outlines the process to determine the Project Documentation

Level.

3.5 Critical Prerequisites to Investment Success

Four factors are critical to successful communication and development within OPM IT system

development programs and projects. The Business Program Manager or Business Project

Manager for the investment must ensure these factors are satisfied before initiating the OPM

SDLC. They include:

3.5.1 Integrated Project Teams (IPTs )

The Business Program Manager or Business Project Manager must ensure that an Integrated

Project Team (IPT) is formed and engaged throughout the system development phases. The IPT

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 18

facilitates communication and collaboration among all subject matter experts necessary to the

success of the investment. At a minimum, the IPT must have representation from the following

applicable IT functional areas in the CIO organization:

 IT Security and Privacy

 Accessibility (Section 508)

 Records Management

 Network Management

 Capital Planning and Investment Control.

 SDLC

 Performance Management (i.e., Earned Value Management, etc.)

3.5.2 Central Document Repository

In order to support the OPM SDLC, the Business Program Manager or Business Project Manager

must set up a central repository for all documentation, reports and artifacts created for the

investment. This central repository must be used as the basis of meeting Configuration

Management program or project requirements.

3.5.3 Secured Funding

The Business Program Manager or Business Project Manager must ensure that funding is

secured before any technical system development is initiated. This may require that the

investment must obtain Capital Investment Committee (CIC) approval for acquisitions over

$250,000.

3.5.4 Familiarization with IT Standards and Federal Laws

There are IT Standards and Federal Laws which the Business Program Manager or Business

Project Manager must follow and ensure that their teams adhere to. These IT Standards and

Federal Laws include:

 Reporting Standards.

o Performance reporting is described in the IT Baseline Management Policy. For

additional detail information, please contact the EVM PMO Program Manager

in the CIO IT Investment Management team. OPM’s IT Baseline Management

Policy can be found in the OPM reference at Appendix C.1.1.

 Section 508.

o IT components (hardware, software and services) must be accessible to the

disabled community. The OPM Section 508 Policy can be found at:

http://theo.opm.gov/policies/IT_policy-accessibility_0104.pdf

 Data Standards.

o The OPM Enterprise Human Resources Integration (EHRI) and OPM Human

Resources Line of Business (HR LOB) investment initiatives have developed

data standards for system interfaces which must be used by those IT systems

dealing with HR data. The EHRI data standards are located at:

http://www.opm.gov/feddata/guidance.asp. HR LOB data standards are located

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 19

at: http://www.opm.gov/egov/documents/architecture/HRLOB_DM.pdf

o In the event that there are additional data standard issues which need to be

brought to the attention of EHRI and HR LOB, there is a Data Governance

Board which is co-chaired by CIO Records Management and EHRI senior

management. Contact the EHRI Program Manager on how to engage the Data

Governance Board.

 System Integration.

o The Business Program Manager and Business Project Manager must ensure that

integration occurs when systems are designed. All hardware and software that

are part of the IT solution must work as a cohesive function in meeting the user

requirements in accordance with the OPM Enterprise Architecture. Any external

system interfaces with other Federal agencies must be managed through a

Memorandum of Understanding or Memorandum of Agreement.

 IT Procurement.

o Procurement of IT hardware and software must be initiated in the CIO on-line

system named IT Procurement Authorization (ITPA). Approved OPM hardware

and software that meet OPM Enterprise Architecture standards are stored within

ITPA. For hardware and software that are not approved in ITPA, a Business Case

Exception request must be submitted to the OPM Helpdesk. The ITPA is

accessed by submitting a request to the OPM Helpdesk for sign-in capability to

http://sbm.opm.gov/.

o Procurement of IT services must be coordinated with the Office of the CIO

through the contract vehicles (e.g., IT Support Services Blanket Purchase

Agreements, etc.) that the CIO has implemented with the OPM Contracting

Office.

 IT Security

o Information security must be integrated into the SDLC at all phases to ensure

appropriate protection for the information that the system will transmit, process, and

store in compliance with the OPM Information Security and Privacy Policy.

Compliance with OPM Information Security and Privacy Policy must be ensured in

coordination with the OCIO IT Security Team.

4. OPM SYSTEM DEVELOPMENT LIFE CYCLE (SDLC)

4.1 Introduction

An important objective of the OPM SDLC is to support various types of development within

OPM. The OPM SDLC provides the framework needed to accomplish work encompassing new

IT system development, implementation of COTS and Cloud solutions, maintenance, and

enhancement. The OPM SDLC describes all the phases of system development, process steps in

each phase, procedures, product templates and checklists needed to support the system

development life cycle. All templates and process documents referenced in this document can be

found in the OPM SDLC WebPages (currently in THEO).

After completing the four steps in the previous “Section 3: Project Initiation”, the Business

Program Manager or Business Project Manager must initiate the SDLC by documenting the

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 20

business need and requirements. The business need documentation will be used by the Technical

Project Manager in developing and implementing the IT system.

4.2 SDLC Phases

4.2.1 Overview

The OPM SDLC consists of the following seven phases:

 Determine System Need (Section 4.2.2)

 Define System Requirements (Section 4.2.3)

 Design System Components (Section 4.2.4)

 Build System Components (Section 4.2.5)

 Evaluate System Readiness (Section 4.2.6)

 Deploy the System (Section 4.2.7)

 Decommission the System (Section 4.2.8)

Using the Capability Maturity Model Integration (CMMI) for Development process model as

outlined by the Software Engineering Institute (SEI), each phase includes entry and exit criteria,

and process steps particular to each phase, and identifies the roles, document templates,

procedures, checklists and forms needed for each phase. These phases, combined with the

development methodology, define how the project to manage the system development will be

structured. The processes and resources within the OPM SDLC should be used for all

information systems, systems development, and system maintenance. These phases are

applicable across all information technology environments (e.g., enterprise server, distributed,

web) and apply to contractually developed and in-house developed applications.

4.2.2 Determine System Needs Phase

4.2.2.1 Purpose

The Determine System Need phase is the period in which an information system need is

identified and the decision is made whether to commit the necessary resources to solve the

deficiency.

4.2.2.2 Description

The activities of the Determine System Need Phase begin with the identification of an idea or a

need. A user or system sponsor may identify the need or it may be the result of a strategic

information architecture analysis. For a system which does not currently exist, the need is

documented in a Needs Statement (NS) document. For an existing system, the need is

documented in a Change Request (CR) document. These documents describe the need and

justify the exploration of alternative solutions.

Large-scale development and major system enhancements are described in the Needs Statement

by the project sponsoring organization and approved by the Investment Review Board. Smaller

development efforts, minor enhancements, or maintenance efforts are described in a CR and

approved at the group or division level Configuration Control Board (CCB). After the idea/need

has been documented, alternatives for solving the need are identified as necessary. Decisions are

made on whether or not to continue development of the need.

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 21

Entry Process

After the Customer or Executive Sponsor has identified a need OR a CR has been submitted,

there are tasks associated with the approval of the need and the documentation of the

requirements to meet the needs.

Tasks

The activities are outlined in Appendix D.1

Exit Criteria

 A CR package has been approved for an existing system

 The Information Technology Investment Analysis Package has been submitted and approved

 Needs Statement and User Requirements Document have been approved and baselined for

both new and existing systems

 Approval by the appropriate approvers to proceed to next phase when artifacts support the

methodology selected and approvals/directions have been given per the Project Plan and as

outlined in Appendix D.1. Approvers must include the Executive Sponsor, CIO, Technical

Advisor, Business Program Manager or Business Project Manager as appropriate.

4.2.3 Define System Requirements Phase

4.2.3.1 Purpose

The Define System Requirements Phase is the period in which the User Requirements are broken

down into more detailed requirements which can be used during designing and coding.

4.2.3.2 Description

This phase begins formal planning and requirements definition for new projects. The activities of

the Define System Requirements Phase include initial project planning activities. System and

software requirements are formally defined and delineated in terms of data, system performance,

security, and maintainability. All requirements are defined to a level of detail sufficient for

systems design to proceed. For applications requiring electronic signatures see the OPM Policy

on Electronic Signatures in the OPM THEO webpage as linked in Appendix C. Initial

documentation of the Test Plan (Unit & Integration) and the Training Plan begins in this phase

and are updated in subsequent phases.

Entry Criteria:

 The program or project has been approved and funded

 Needs Statement and User Requirements Document have been approved and baselined for

the new or existing system

 Approval by appropriate approvers to exit the previous phase has been granted

Tasks

The activities are outlined in Appendix D.2

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 22

Exit Criteria

 The Project Plan, Quality Assurance Plan, Configuration Management Plan, Security Impact

Analysis and Test Plan (Unit & Integration) have been documented and placed under

configuration control

 The System Architecture, Software Requirements Specification, Data Specification, FIPS-

199, Privacy Threshold Analysis/Privacy Impact Assessment, Requirements Traceability

Matrix and Training Plan have been approved and baselined

 The baselined requirements have been approved as meeting the acceptance criteria for this

cycle

 Approval by appropriate approvers to proceed to next phase when artifacts support the

methodology selected and approvals/directions have been given per the Project Plan and as

outlined in Appendix D.2. Approvers must include the Technical Project Manager, Chief

Architect, Business Program Manager or Business Project Manager as appropriate.

A requirements management software tool may be used in the place of a manual matrix. In this

case, the tool would need to be updated in place of the manual matrix.

4.2.4 Design System Components Phase

4.2.4.1 Purpose

The objective of the Design System Components Phase is to transform the detailed, defined

requirements into complete, detailed specifications for the system to guide the work of the

Development Phase. The decisions made in this phase address in detail how the system will

meet the defined functional, physical, interface, and data requirements. Design Phase activities

may be conducted in an iterative fashion, producing first a general system design that

emphasizes the functional features of the system, then a more detailed system design that

expands the general design by providing all the technical detail.

4.2.4.2 Description

This procedure defines the steps required to develop the system design. It gives the user details

on what activities and steps should occur during this phase, which include developing the

Software Design Description, the Database Design Description, Information Systems Security

Plan, User Manual, and training materials. It describes the steps required to document and

baseline system design.

Entry Criteria:

 The Project Plan, Quality Assurance Plan, Configuration Management Plan, and Test Plan

(Unit & Integration) have been documented and placed under Configuration Management

(CM) control

 The System Architecture, Software Requirements Specification, Data Specification,

Requirements Traceability Matrix, IT Security Planning, and the Training Plan have been

approved and baselined

 The baselined requirements have been approved as meeting the acceptance criteria for this

cycle

 Approvals by appropriate approvers to exit the previous phase has been granted

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 23

Tasks

 The activities are outlined in Appendix D.3.

Exit Criteria:

 The Software Design Description document, Database Design Description document,

Information Systems Security Plan, User Manual, Requirements Traceability Matrix, and

Training Materials have been approved and baselined

 The Project Plan, Test Plan (Unit & Integration) and Training Plan have been updated. (as

required)

 The baselined designs have been approved as meeting the acceptance criteria for this cycle.

 Approvals by appropriate approvers to proceed to next phase when artifacts support the

methodology selected and approvals/directions have been given per the Project Plan and as

outlined in Appendix D.3. Approvers must include the Technical Project Manager, Business

Program Manager or Business Project Manager as appropriate.

A testing support tool may be used in the place of Test Plans (Unit & Integration). In this case,

the tool would need to be updated in place of the Test Plans.

4.2.5 Build System Components Phase

4.2.5.1 Purpose

The objective of the Build Phase is to transform the detailed, system design into complete coded

software units and eventually, into an integrated product for release. Each software unit and

subsequent integrated units are tested thoroughly. System documents that support installation

and operations are also developed in this phase.

4.2.5.2 Description

The Version Description Document, Operations Manual, Verification Validation & Test Plan,

and the Installation and Conversion Plan are created as a result of this phase. As software source

objects and system configuration items are completed, they are placed under configuration

control.

Entry Criteria:

 The Software Design Description document, Database Design Description document,

Information Systems Security Plan, User Manual, Requirements Traceability Matrix, and

Training Materials have been approved and baselined

 The Project Plan, Test Plan (Unit & Integration) and Training Plan have been updated. (as

required)

 The baselined designs have been approved as meeting the acceptance criteria for this cycle

 Approvals by appropriate approvers to exit the previous phase has been granted

Tasks:

Follow the activities as detailed in Appendix D.4

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 24

Exit Criteria:

 Unit and integration testing has been conducted and results meet the acceptance criteria

 The Version Description Document, Verification Validation & Testing Plan, Installation &

Conversion Plan, Requirements Traceability Matrix

and Operations Manual have been

approved and baselined

 The Project Plan, Test Plan (Unit & Integration), Training Plan and Training Materials have

been updated (as required)

 Approvals by appropriate approvers to proceed to next phase when artifacts support the

methodology selected and approvals/directions have been given per the Project Plan and as

outlined in Appendix D.4. Approvers must include the Technical Project Manager, Business

Program Manager or Business Project Manager as appropriate.

4.2.6 Evaluate System Readiness Phase

4.2.6.1 Purpose

This objective of the Evaluate Phase is to ensure that the system as designed and built satisfies

the requirements of the user. Whenever possible, independent testers measure the system's

ability to perform the functions that are required by the customer and ensure an acceptable level

of quality and performance. Once the phase is complete, it will be evident whether or not the

system is ready for operation. This function shall be the responsibility of the system testers and

will be heavily supported by the user participants.

4.2.6.2 Description

The Verification, Validation & Testing Plan, Test Results & Evaluation Report, Installation &

Conversion Plan, User Manual, and Training Materials are updated, tested (if applicable), and

finalized in this phase. The Systems Assessment and Authorization package is created in this

phase. As work products are created they are placed under configuration control.

Entry Criteria:

 Unit and integration (including regression) testing has been conducted and results meet the

acceptance criteria

 The Verification, Validation, & Testing Plan, Installation & Conversion Plan, Requirements

Traceability Matrix,

and Operations Manual have been approved and baselined

 The Project Plan, Test Plan (Unit & Integration), Training Plan, and Training Materials have

been updated. (as required)

 Technical Project Manager approval with Business Program Manager or Business Project

Manager concurrent approval to exit the previous phase has been granted

Tasks:

Follow the activities as detailed in Appendix D.5

Exit Criteria:

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 25

 The System Assessment and Authorization has been approved by the Authorizing Official

 The Customer, Business Program Manager or Business Project Manager and IT Project

Manager has approved the baselined testing results as meeting the acceptance criteria for this

cycle

 Business Program Manager or Business Project Manager, IT Project Manager, Software

Quality Assurance and the Customer have approved the Test Results and Evaluation Report,

Version Description Document, Installation & Conversion Plan, User Manual, updated

Requirements Traceability Matrix, and the applicable Training Materials

 The Project Plan has been updated to reflect activities of this phase and has been placed

under CM control

 The Phase Exit Review meeting has occurred and Technical Project Manager approval along

with IPT members, Business Program Manager or Business Project Manager concurrent

approval to proceed to the next phase has been granted as outlined in Appendix D.5.

4.2.7 Deploy the System Phase

4.2.7.1 Purpose

Deploy the System Phase is the final phase of the development life cycle, when the system is

released initially to a pilot site and then into the production environment. All necessary training

for using the system is accomplished.

4.2.7.2 Description

This phase is to install the system in a production environment for use by the intended user. The

production environment is prepared for system installation, which includes the physical

environment as well as hardware and software components. Once the system is installed, a

thorough test of the system installation is conducted. User training is also conducted to prepare

the user for new system functionality or system changes. The Business Program Manager or

Business Project Manager and Technical Project Manager verify that the installed system meets

all requirements, all specifications and all deliverables have been received.

Entry Criteria:

 Test Results & Evaluation Report, and Requirements Traceability Matrix have been

approved and baselined

 System Assessment and Authorization have been approved and baselined

 The Project Plan, Test Plan (Unit & Integration), Training Plan, Training Materials, User

Manual, Installation & Conversion Plan, Operations Manual, Version Description Document

have been updated (as required)

 Established Service Level Agreements (SLA) or Operating Level Agreements (OLA) for the

project have been signed by all parties and ready for implementation

 Technical Project Manager approval along with IPT members, Business Program Manager or

Business Project Manager concurrent approval to exit the previous phase and deploy the

system has been granted.

Tasks:

Follow the activities as detailed in Appendix D.6

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 26

Exit Criteria:

 System has been installed and is operational

 System Sign-off Package has been approved by Technical Project Manager approval along

with Business Program Manager or Business Project Manager concurrent approval

 Project Plan has been updated. (as required)

4.2.8 Decommission the System Phase

4.2.8.1 Purpose

The Decommissioning a System phase is the period in which a system is completely taken off

line, or a portion of a system’s functionality (due to duplication in another system) is removed.

This phase is conducted to retire a system.

4.2.8.2 Description

Once the decision to decommission a system has been made, the activities of the

Decommissioning a System Phase begin with the completion of the decommission form. This

form documents the information and coordination necessary to end the target systems life cycle.

The system is decommissioned following the steps in the Decommissioning procedure. Systems

that have interfaces to the targeted system are checked to verify the decommissioning does not

adversely affect them. As a result of the system being decommissioned, affected business

processes and policies are updated. Once the system has been decommissioned, a formal system

close out meeting is conducted.

Entry Criteria:

 User/Executive Sponsor has identified a need OR a CR has been submitted

 Business Program Manager or Business Project Manager approval as well as CIO approval to

decommission a system

Tasks:

Follow the activities as detailed in Appendix D.7

Exit Criteria:

 A system, or part of a system, is decommissioned.

 System components and artifacts have been archived or disposed of.

 Completed Decommission Form with input and approval from the IT Security Team and

approved by CIO and Business Program Manager or Business Project Manager.

 Affected/interfacing systems continue to operate.

 Meeting Minutes which document that all parties are aware of decommission requirements.

5. METHODOLOGIES

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 27

A process model covers the whole life cycle and defines each phase as described in Section 4

above. It also defines the tasks and activities to be performed within that phase. There are

several systems development life cycle methodologies. This section provides an overview of the

methodologies that are commonly used within OPM. The Technical Project Manager should

select a system life cycle methodology based on the nature of the program and application, the

methods and tools to be used, and the required controls and deliverables. The Technical Project

Manager integrates the selected life cycle methodology with the phases of the OPM SDLC in

developing the project's schedule.

5.1 Waterfall

5.1.1 Overview

The waterfall (or "grand design") model is a program strategy which is a "once-through, do-

each-step once" strategy. In waterfall, each process as described in Section 4.2 above is

performed in sequence, and each process is completed before proceeding to the next process in

the sequence. For example, requirements are not documented until the need is approved.

Likewise, software build (construction) does not begin until the analysis and design are

complete.

5.1.2 Strengths

 Waterfall provides a structured, disciplined method for system development, and can be

useful for maintenance projects, and small, new projects with clearly defined and understood

requirements.

 Waterfall methodology is well-suited to systems of record where the current process (or lack

thereof) can proceed until delivery without negative impact to the organization.

5.1.3 Weaknesses

 Waterfall can prove to be a risky and inflexible strategy. With only a single pass through the

process, integration problems often surface too late in development, and a completed product

is not available until the very end of the process.

 The long period between project start and product delivery can discourage customer

involvement and lead to a system which does not meet changing customer requirements.

5.2 Incremental

5.2.1 Overview

The incremental model of systems development performs the waterfall approach in overlapping

phases attempting to compensate for the length of waterfall model projects by producing usable

functionality earlier. For those projects whose expertise lies with the waterfall model and may

not be able to secure the services of certified Scrum Masters, the incremental methodology is an

acceptable solution in lieu of the Agile (Scrum) methodology.

The incremental model of systems development involves sets of requirements that are

implemented in a series of small subprojects which follow the seven SDLC phases. A project

using the incremental model may start with general objectives. Then some portion of these

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 28

objectives is defined as requirements and is implemented as a subproject, followed by the next

portion of the objectives until all objectives are implemented within all subprojects.

Incremental model follows the same phases as the OPM SDLC within each small subproject

using the entry, activities and exit criteria.

5.2.2 Strengths

 Orderliness appeals to management

 Facilitates allocation of resources

 Early functionality

 Does not require a complete set of requirements at the onset

 Can size the increments based on available resources

 Well-suited to systems of record where the current process (or lack thereof) no longer meets

the organization's needs and must be replaced more rapidly than a big-bang delivery would

allow

5.2.3 Weaknesses

 Beginning with less defined general objectives may be uncomfortable for project team

members

 Requires clean interfaces between modules

 Tendency for difficult problems to be pushed to the future so that the initial promise of the

first increment is not met by subsequent products

5.3 Agile (Scrum)

5.3.1 Overview

Agile system development for OPM must adhere to the Manifesto for Agile Development (Beck,

2001) which is characterized by the following in the publication:

 Direct involvement of the customer in product development

 Use of multiple development iterations to learn about and evolve the product

 Customer willingness to share in the responsibility for decisions and risk

Agile system development methodologies meet the above by the implementation of a number of

phases that are repeated in cycles, with a feedback loop after each cycle is completed. The

project team learns from the preceding cycles and plans the next cycle in an attempt to converge

on an acceptable solution. At the discretion of the customer, the project team may release a

partial solution. The characteristics of Agile development include:

 Iterative structure - structured around iterations that are designed to find and complete the

solution

 Just‐in‐time planning - highest priority features are planned first and executed upon.

Planning is finely detailed for immediate features, coarsely detailed for features to be

developed later.

 Critical mission projects - Certain projects are considered high risk because of the

complexity and uncertainty associated with the project. With that high risk comes high

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 29

business value. They are undertaken because their successful completion is critical to the

enterprise.

 Thrives on change through learning and discovery - The learning and discovery can come

about only with the customer being heavily involved in the project.

Some of the best practices within the Agile methodology are:

 Teams should be co-located, long-lasting, and persistent

 Do not transition knowledge support of a product to another team

 Start staffing project teams with a focus on resource versatility so that the starting core

can do multiple tasks while experts are on-board

Scrum is one of the current popular Agile system development methodologies. The Scrum

software development team is self‐directed, operates in successive iterations (typically 2 to 3

weeks as indicated by best practices), holds daily team standup meetings of no longer than 15

minutes, continuously offers the customer demos of the current solution, and adapts its

development plan at the end of each iteration.

It is the Product Owner who defines the functions and features that the team prioritizes into

phases and builds a phase at a time in iterative cycles. The process allows the customer to change

functions and features as more of the solution depth is uncovered through the previous iterations.

A diagram of the Scrum life cycle (Figure 1) is presented below:

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 30

Figure 1: The Scrum Lifecycle

The Scrum Lifecycle diagram illustrates a general overview of the Scrum process. Scrum uses

the sprint as the basic unit of development. Each specific function or task is defined within the

sprint and can take no longer than six weeks for development as well as are "timeboxed" (i.e.

restricted to a specific duration). Each sprint is preceded by planning meetings, where the tasks

for the sprints are identified and an estimated commitment for the sprint goal is made. Scrum

reviews are conducted where the progress is reviewed and lessons for the next sprint are

identified. During each sprint, the team creates finished portions of a task or product. These

finished portions must be formally accepted and approved by the Product Owner and Scrum

Master using the appropriate SDLC Phase Exit Review procedures and documentation (defined

in Section 4.2 “SDLC Phases” above) before additional sprints are initiated or planned. The

functionality or tasks that go into a sprint is pulled from a product backlog, which is a prioritized

list of requirements, and is determined by sprint planning meetings.

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 31

For a more detailed overview of Scrum, the Scrum Process Details can be found in Appendix F

of this document.

5.3.2 Strengths:

 Avoids all management issues in processing scope change requests

 Does not waste time planning uncertainty

 Provides maximum business value within the given time and cost constraints

 Delivers finished, tested, usable code with each iteration

 Provides flexibility and quick feedback which is used to plan the next iteration

 Well-suited to systems of differentiation and innovation so that stakeholders can see a

resolving picture of unfamiliar technology/processes

 Utilizes the Rolling Wave planning method which embraces the Lean ideal of making

decisions at the last responsible moment, when the possible information is available, and

maximizes flexibility and planning accuracy

 Uses empirical methods to monitor progress and direct change, rather than use of definitive

methods (i.e. Waterfall) to try to predict progress and stop change

 Assists in:

o Strategic Planning (Strategic Product line goals)

o Product Planning (Strategic product goals)

o Lean/Six Sigma (Specific problems to solve)

o Release Planning (Large functional goals)

o Sprint Planning (Small, well-defined work items)

o Daily Scrum (Tactical organization & execution)

5.3.3 Weaknesses:

 High reliance on meaningful daily customer involvement leads to higher levels of risk

 Cannot identify precisely what will be delivered at the end of the project since requirements

may change

 Changes in scope results in rework through multiple iterations which can increase cost

6. PROJECT MANAGEMENT FRAMEWORK

Project management is the application of knowledge, skills, and techniques to project activities

in order to meet or exceed stakeholder needs and expectations from a project. Meeting or

exceeding stakeholder needs and expectations invariably involves balancing competing demands

among:

 Scope, time, cost and quality

 Stakeholders with differing needs and expectations

 Identified requirements (needs) and unidentified requirements (expectations)

The Business Program Manager, Business Project Manager, Technical Project Manager and the

Project Teams must follow project management best practices during the SDLC implementation.

The Project Management Institute (PMI) is a world-wide organization which has been

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 32

recognized as the expert in project management standards. PMI has defined the standards in

their publication called the Project Management Book of Knowledge (PMBOK). The PMBOK

uses the following 5 process areas with the appropriate procedures:

1. Project Initiation

a. Collect historical information

b. Determine Project objectives

c. Determine high-level deliverables, estimates

d. Determine high-level constraints and assumptions

e. Determine business need

f. Develop product description

g. Define Project Manager responsibilities

h. Determine high-level resource requirements

i. Finalize Project Charter

2. Project Planning

a. Create scope statement

b. Determine Integrated Project Team (IPT)

c. Create Work Breakdown Structure (WBS)

d. Finalize the IPT

e. Create WBS Dictionary

f. Create network diagram

g. Estimate time and cost

h. Determine critical path

i. Create risk management plan

j. Develop schedule

k. Develop budget

l. Determine communication requirements

m. Determine quality standards

n. Risk identification, qualification, quantification and response planning

o. Iterations — go back

p. Create other management plans

i. Scope

ii. Schedule

iii. Cost

iv. Quality

v. Staffing

vi. Communications

vii. Acquisition

q. Create project control system

r. Final project plan development

s. Gain formal project plan approval

t. Conduct Project Kickoff meeting

3. Project Execution

a. Execute project plan

b. Manage project progress

c. Complete Work Packages

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 33

d. Distribute information

e. Quality Assurance

f. Team Development

g. Progress Meetings

h. Identify Changes

i. Work Authorization

j. Manage by Exception to Project Plan

4. Project Control

a. Integrated change control

b. Project performance measurement

c. Performance reporting

d. Scope change control

e. Quality control

f. Risk monitoring and control

g. Schedule control

h. Cost control

i. Scope verification

j. Compliance with all plans

k. Project Plan updates

l. Corrective Action

5. Project Closing

a. Acquisition audits

b. Product verification

c. Financial closure

d. Lesson learned

e. Project performance reporting closure

f. Formal acceptance

g. Project archive (includes contract close-outs)

For more detail information in regards to the above processes and procedures, the IT project

team should consult or procure a copy of the PMBOK from the PMI.

In addition to the PMI, the Federal Acquisition Institute (FAI) has developed a Program

Management and Project Management certification program for Federal Program and Project

Managers. FAI established the necessary competencies, training, and experience requirements

for program and project managers in civilian agencies to become certified to manage the

acquisition-related aspects of projects. Information about the certification program can be

viewed on the FAI website at http://www.fai.gov/certification/management.asp.

6.1 OPM SDLC and Project Management

The OPM SDLC and Project Management best practices are interwoven within the IT solution

implementation. One cannot exist without the other when IT projects are planned, developed,

tested and implemented. For each of the SDLC phases, the Business Program Manager and

Business Project Manager must ensure that the appropriate Project Management process is

adhered to as follows:

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 34

 Project Initiation process must be part of the Determine System Need phase;

 Project Planning process must be part of the Determine System Need, Define System

Requirements and Design System Components phases;

 Project Execution must be part of the Design System Requirements and Build System

Components phases;

 Project Control must be part of the Evaluate System Readiness phase;

 Project Closing must be part of the Deploy the System and Decommission the System phase.

7. CONFIGURATION MANAGEMENT FRAMEWORK

Configuration Management is the discipline of identifying the configuration of a system at

discrete points in time for the purpose of systematically controlling changes to the configuration

throughout the system life cycle. The components of configuration management are:



Section 7.1: Software Configuration Identification



Section 7.2: Configuration Control



Section 7.3: Baseline Management



Section 7.4: Configuration Status Accounting



Section 7.5: Configuration Auditing

7.1 Software Configuration Identification

Configuration identification involves the effective management of the development of the system

by careful definition of its baseline components. Changes to these components are also defined

since these changes, together with the baselines, specify the system evolution. Configuration

identification also involves identifying what information has been approved for concurrent use in

the project, who owns the information, how the information was approved for CM control, and

the latest approved release. At a minimum, the following shall be selected as Configuration Items

(CIs):



The system itself, defined as the top-level CI.



All Commercial Off-the-Shelf (COTS) software and hardware needed for the system (or

application) to function or required for procurement.



Application software components already designated as CIs.



Project support software essential for system maintenance, including debuggers, test

scripts, and configuration checkers.

7.2 Configuration Control

Configuration control involves the process and procedures for designating the level of control

through which each work product must pass; identifying the persons or groups with authority to

authorize changes and to make changes at each level; and the steps to be followed to obtain

required authorization for changes, to process change requests, to track changes, to distribute

changes, and to maintain past versions. Configuration control is initiated after the Functional

Baseline (FBL) is established and extends to include the Allocated Baseline (ABL) and Product

Baseline (PBL). Change control provides the mechanism to build software systems for tests that

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 35

have a known configuration and can be exactly reproduced.

7.3 Baseline Management

Once a baseline (made up of baselined documentation) has been established, it should not be

changed without a formal action. The typical baselines used for information systems are the

FBL, ABL, and PBL. Baselines are normally established successively with each one adding

more detail about the final system. Each project Configuration Management Plan (CMP) must

list all required contents of each baseline.



Functional Baseline - The FBL is the approved documentation that describes the system

(or product) functional characteristics. After approval of the User Requirements

Document during the Define System Needs phase, the FBL is established. This baseline

should be maintained throughout the life cycle of the project.



Allocated Baseline - The ABL is the approved documentation that describes the design of

the functional and interface characteristics that are allocated from a higher level CI. All

fielded systems shall have an ABL to support test, training, and maintenance. This

baseline shall be maintained throughout the life cycle of the project, usually by the

organization responsible for maintaining the functional products.



Product Baseline - The PBL consists of completed and accepted system components and

the corresponding documentation that identifies these products. This baseline supports

the ability to accurately duplicate software, purchase COTS, and modify COTS. The PBL

includes source code on electronic media, COTS (hardware and software), maintenance

and user manuals, vendor-supplied COTS manuals, purchase specifications for modified

COTS, system and hardware drawings, Version Description Documents, and code

listings. This baseline should be maintained throughout the life cycle of the project.

7.4 Configuration Status Accounting

Configuration Status Accounting (CSA) records, stores, maintains, correlates, and reports the

status of an evolving CI throughout the system life cycle. CSA requires that all software and

related documentation be carefully tracked from initial development, through the approval or

disapproval of changes, to the implementation of changes. CSA records and monitors all changes

to baselines. As a result of this effort, CSA will maintain traceability of the hierarchy of

requirements from the stated user need at the top, through the functional and allocated baseline

documentation, and down to the lowest level of the product baseline. The information required

for comprehensive CSA includes:



Baseline name, version, and designation



Date and time at which the baseline was established



Date and time when each CI and change was included in the baseline



Description of each CI



Status of each change request



Description of each change.

7.5 Configuration Auditing

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 36

Configuration Auditing is a formal review of a project for the purpose of assessing compliance

with the CM plan. The purpose of Configuration Audits is to ensure that the functional

requirements have been met by the delivered CI and to ensure that all physical attributes listed in

the design requirements have been met by the CI to be delivered. Configuration audits shall be

performed for application software, COTS products, and customized products that satisfy a

functional requirement. The configuration audit is the responsibility of the system tester and the

project configuration manager.

All project and contractor personnel who are developing, acquiring, disposing, operating, or

maintaining project systems should use documented configuration management methodology to

ensure that system requirements are clearly defined and controlled throughout the life of the

system and that the operational system satisfies the needs of the project. To accomplish these

tasks, the following should be accomplished:



A project CMP must be developed as required in the Define System Requirements Phase

(Section 4.2.3.2) using the OPM CMP framework if available.



Configuration baselines must be established, documented and controlled using a formal

change control processes.



Fielded systems must be documented and software releases and system upgrades

documented and controlled using a formal process.

8. QUALITY ASSURANCE FRAMEWORK

Project Quality Assurance Management includes the processes required to ensure that the

project will satisfy the needs for which it was undertaken. It includes all activities of the overall

management function that determine the quality policy, objectives, and responsibilities and

implements them by means such as quality planning, quality control, quality assurance, and

quality improvement, within the quality system.

To be unbiased, quality assurance needs to have organizational freedom and authority from

persons directly responsible for developing the software product or executing the process in the

project. A quality product or service, by definition, meets or exceeds the need to which the

product or service is applied. This process consists of four activities:



Section 8.1: Process Implementation



Section 8.2: Product Assurance



Section 8.3: Process Assurance



Section 8.4: Assurance of Quality Systems

8.1 Process Implementation

The quality assurance process should be responsible for conducting ongoing evaluations of

software acquisition/initiation, design, development, evaluate, deploy, and supporting process

activities and the resulting software products to assure that each process, activity, and task

required or described in plans is being performed in accordance with those plans. It also assures

that each software product required by a relevant process exists and has undergone software

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 37

product evaluations, testing, and problem resolution, as required. A plan for conducting the

quality assurance process activities and tasks is developed, documented, implemented, and

maintained for the life of the project.

8.2 Product Assurance

Product assurance ensures that all the plans required are documented, comply with requirements,

are mutually consistent, and are being executed as required. All software products and related

documentation should adhere to the plans. Software products that have fully satisfied contractual

requirements may be assumed to be acceptable to the user. The quality assurance process is

performed to assure that all products exist, have undergone evaluations in accordance with the

plans for conducting quality assurance activities and tasks, and satisfy the acceptance criteria.

The results of verification, validation, and other processes to satisfy product assurance tasks may

be used.

8.3 Process Assurance

Process assurance ensures that those software life cycle processes (requirements, design, build,

evaluate, deploy, and supporting processes, including quality assurance) employed for the project

adheres to the plans. Internal software engineering practices, development environment, test

environment and libraries must comply with the requirements. The user needs the required

support and cooperation to carry out these processes. This means that the staff assigned to the

project has the skill and knowledge needed to meet the requirements and receive any necessary

training.

8.4 Assurance of Quality Systems

A quality product or service, by definition, meets or exceeds the need to which the product or

service is applied. With this as a framework, a few significant characteristics of a quality product

or service are:



Meets the user's need



Meets the user's requirements



Meets the user's expectations



Allows the user to accomplish a task to which the product or service applies



Is available to the user when the task to which the produce or services applies is

accomplished



For a continuing product or service, uniformly and consistently meeting the user's need,

requirement, and/or expectation allows the user to "trust" the continued use of the product

or service



Meets the user's affordability or other constraints

In summary, a quality product or service meets expectations and is useful, available, consistent,

and affordable when applied to a task.

9. RECORDS MANAGEMENT FRAMEWORK

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 38

The Records Management Profile recommends that agencies embed records management

requirements in the earliest stages of their SDLC. The Profile can be found by referring to

Federal Enterprise Records Management Profile, Sections 4.1.1 through 4.1.6;

http://www.archives.gov/records-mgmt/policy/rm-profile.html.

The document on the following page is a checklist to assist OPM program and project managers

integrate records management requirements into their IT system SDLC process. The checklist

identifies where in the SDLC process the records management review and approval should take

place to ensure that sound records management practices are incorporated into the development

of the proposed IT system.

The checklist provides two to six basic questions about records management and recordkeeping

for each phase of the OPM SDLC life cycle process. The checklist questions are intended to

begin a more detailed discussion with agency records managers, IT and Capital Planning and

Investment Control (CPIC) staff, and program managers and staffs that will help identify

recordkeeping requirements in each phase, with a great emphasis on identifying records

management requirements at the earliest stages of project planning, initiation and requirements

gathering.

The checklist is intended to become a part of the IT system documentation and will be used

throughout the system life cycle. Please use the comments field for any additional information.

Records Management Checklist

IT System: (Name of IT System)

OPM DIVISION: (Name of Division)

IT System Owner: (Name of IT System Owner)

All electronic records should be managed following the National Archives regulations, NARA

Records Management Guidance and Regulations, subchapter B, Record Management, Part 1234

at http://www.archives.gov/about/regulations/part-1234.html.

Phase 1: Determine System Need

Requirement

Met?

Indicate

FM = Fully

Met

PM = Partially

Met

NM = Not

Met)

Comments

CIO Records

Management

Approval

1) Is the OPM Records Officer

included from the beginning in the

system design process?

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 39

2) Are records identified that support

the business process?

3) a. Do current record schedules

apply to the new system?

b. Is a new record schedule

required because of changes in the

records?

4) Have you notified your division

Records Coordinator and the OPM

Records Officer, that this system

should be included as an update to the

division file plan?

5) Has the appropriate contract

language been inserted into all active

contracts and reviewed by the Records

Officer? (see

http://www.archives.gov/records-

mgmt/handbook/records-mgmt-

language.html)

Phase 2: Define System Requirements

Requirement

Met?

Indicate

FM = Fully

Met

PM = Partially

Met

NM = Not

Met)

Comments

CIO Records

Management

Approval

6) Are all records-related

requirements identified and

incorporated into the final CONOPS

Report or Business Requirements

Document?

7) Are new records schedules being

drafted, if needed?

8) Has the agency Records Officer

reviewed the requirements document?

Phase 3: Design System Components

Requirement

Met?

Indicate

FM = Fully

Met

PM = Partially

Met

NM = Not

Met)

Comments

CIO Records

Management

Approval

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 40

9) Are all records management

requirements incorporated into the

system design document?

10) Has the Records Officer reviewed

the system design document?

Phase 4: Build System Components

Requirement

Met?

Indicate

FM = Fully

Met

PM = Partially

Met

NM = Not

Met)

Comments

CIO Records

Management

Approval

11) Is the OPM records management

staff included in project status

meetings as needed?

12) Are proposed records schedules

submitted to the National Archives

and Records Administration (NARA)?

Phase 5: Evaluate System Readiness

Requirement

Met?

Indicate

FM = Fully

Met

PM = Partially

Met

NM = Not

Met)

Comments

CIO Records

Management

Approval

13) Are records management

requirements incorporated into the

system?

14) Has the agency Records Officer

reviewed any Test Reports to validate

the records requirement incorporation?

Phase 6: Deploy The System

Requirement

Met?

Indicate

FM = Fully

Met

PM = Partially

Met

NM = Not

Met)

Comments

CIO Records

Management

Approval

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 41

15) Is the agency records management

staff included in project status

meetings as needed?

16) Has the OPM Records Officer

been notified and granted approval of

deployment of the system?

17) Is the Mid-Cycle Review

complete? (Review to occur 3 years

after going to production to validate

records management requirements and

records schedules.)

18) Are disposition authorities being

implemented in accordance with

appropriate dispositions?

19) Has the Mid-Cycle Review report

been sent to the OPM records

management staff for review?

20) Is the OPM Records Officer

approval on the Mid-Cycle Review

certification document?

Phase 7: Decommission The System

Please reference NARA Code of

Federal Regulations - 36 CFR

1236.1 found at

http://www.archives.gov/about/regul

ations/part-1236.html#1236.14

Requirement

Met?

Indicate

FM = Fully

Met

PM = Partially

Met

NM = Not

Met)

Comments

CIO Records

Management

Approval

21) At the time of retirement or

rollover of the system, are records

preserved, retained, and fully

accessible for the full retentions in

accordance with appropriate

dispositions?

22) At the time of retirement or

rollover of the system, are temporary

records destroyed in accordance with

appropriate dispositions?

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 42

23) At the time of retirement or

rollover of the system, are permanent

records transferred to NARA in

accordance with the appropriate

dispositions?

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 43

APPENDIX A: ACRONYMS

Description: The following acronym list was created based on the acronyms found within the

OPM SDLC.

Group

Acronym

Description

ABL

Allocated Baseline

Authorizing Official

CASE

Computer Aided Software Engineering

CBA

Cost/Benefit Analysis

CBT

Computer-Based Training

CCB

Configuration Control Board

CFO

Chief Financial Officer

Configuration Item

CIO

Chief Information Officer

Configuration Management

CMMI

Capability Maturity Model Integration

CMP

Configuration Management Plan

Contracting Officer

COTS

Commercial Off-the-Shelf

CPIC

Capital Planning and Investment Control

CPU

Central Processing Unit

Change Request

CSA

Configuration Status Accounting

DBDD

Database Design Description

DBMS

Database Management System

DOC

Document

Data Specification

Discrepancy Report

Enterprise Architecture

ESC

Executive Steering Committee

FAI

Federal Acquisition Institute

FBL

Functional Baseline

FRD

Functional Requirements Document

Feasibility Study

GAO

Government Accountability Office

HDW

Hardware

IAW

In Accordance With

ICP

Installation and Conversion Plan

Identification (never “id”)

i.e.,

id est (Latin “that is”)

IPT

Integrated Project Team

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 44

Group

Acronym

Description

IRB

Investment Review Board

Information System

Information Technology

ITIAP

Information Technology Investment Analysis Package

JCL

Job Control Language

LAN

Local Area Network

LOE

Level of Effort

Needs Statement

OCIO

Office of Chief Information Officer

Operations Manual

OMB

Office of Management and Budget

OPM

U.S. Office of Personnel Management

Product Backlog

PBL

Product Baseline

PLN

Plan

Project Manager

PMBOK

Project Management Body of Knowledge

PMI

Project Management Institute

POC

Point of Contact

Project Plan

Quality Assurance

QAP

Quality Assurance Plan

REF

Reference

RFC

Request for Change

Requirements Management

ROM

Rough Order of Magnitude

RPT

Report

RTM

Requirements Traceability Matrix

SA&A

Security Assessment and Authorization

SDD

System Design Document

SEI

Software Engineering Institute

SFW

Software

SME

Subject Matter Expert

SPC

Specification

SQA

Software Quality Assurance

SRS

Software Requirements Specification

SSP

System Security Plan

STD

Standard

TMP

Templates

Test Plan

TRM

Technical Reference Model

TST

Test Scripts

URD

User Requirements Document

VDD

Version Description Document

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 45

Group

Acronym

Description

VV&T

Verification, Validation & Testing

WBS

Work Breakdown Structure

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 46

APPENDIX B: GLOSSARY

Word/Term

Definition

Acceptance

Testing

The final stage in the testing process before the system is commissioned for

operational use

Agile

SDLC methodology which implements of a number of phases that are

repeated in cycles, with a feedback loop after each cycle is completed.

Agile is characterized by:

 Direct involvement of the customer in product development

 Use of multiple development iterations to learn about and evolve the

product

 Customer willingness to share in the responsibility for decisions and

risk

Application

A system providing a set of services to solve some specific user problem.

Approval

Written notification by an authorized representative of the acquirer that the

developer’s plans, design, or other aspects of the project appear to be sound

and can be used as the basis for further work. Such approval does not shift

responsibility from the developer to meet contractual requirements.

Architecture

The structure of a computer system, either a part or the entire system; can

be hardware, software, or network

Audit

An independent examination of a work product to assess compliance with

specifications, standards, quality or security requirements, contractual

agreements, or other predetermined criteria

Automated Data

Processing

The processing of information by means of a computer.

Availability

The degree to which a system (or system component) is operational and

accessible when required for use

Backup

Verb. To copy software files onto a different media that can be sorted

separately from the original files and used to restore the original files, if

needed. The act of creating these files.

Noun. The set of copied files

Baseline

A work product (such as software or documentation) that has been formally

reviewed, approved, and delivered and can only be changed through formal

change control procedures

Baseline

Management

The processes for establishing cost and schedule and business-related

performance metric baselines for an IT investment and for managing and

reporting any subsequent changes to them

Build

(1) A version of software that meets a specified subset of the requirements

that the completed software will meet. (2) The period of time during which

such a version is developed. Note: The relationship of the terms "build"

and "version" is up to the developer; for example, it may take several

versions to reach a build, a build may be released in several parallel

versions (such as to different sites), or the terms may be used as synonyms.

Capability

A measure of the expected use of a system.

Central

Processing Unit

controls the operation of a computer by performing arithmetic and logical

operations and decoding and executing instructions

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 47

Word/Term

Definition

(CPU)

Change Request

(CR)

The formal documentation that is prepared for a request to change a

specification in accordance with the Software Configuration Management

Configuration Control Procedure

Client/Server

A network application in which the end-user interaction with the system

(server) is through a workstation (client) that executes some portion of the

application

Commercial Off-

The-Shelf

(COTS)

Software

Commercially purchased, third party software used to accomplish a specific

function such as spreadsheets, word processing, utilities, and graphics

Compatibility

The ability of two or more systems or components to perform required

functions while sharing the same hardware and software environment. Also,

the ability of two or more systems or components to exchange information

Computer Aided

Software

Engineering

(CASE)

The use of computers to aid in the software engineering activities that may

include but need not be limited to the application of software tools for

software design, requirements tracing, code production, testing, document

generation, and other software engineering activities.

Computer

Hardware

The physical part of a computer system; the machinery and equipment

Computer

Program

A combination of computer instructions and data definitions that enable

computer hardware to perform computational or control functions

Configuration

The way a computer is set up (functional and physical), which includes the

hardware (type of CPU, peripherals, etc.) and the software

Configuration

Audit

A review conducted to verify that the development of a configuration item

has been completed satisfactorily, that the item has achieved the

performance and functional characteristics specified in the functional and

allocated configuration identification, and that its operational and support

documents are complete and satisfactory

Configuration

Control

An element of configuration management consisting of the evaluation,

coordination, approval/disapproval and implementation of changes to

configuration items after formal establishment of their configuration

identification.

Configuration

Control Board

(CCB)

Evaluates scope, applicability, and effect of each requested change,

focusing on the items that affect cost, schedules, or compliance with

requirements and providing approval and disapproval based on business

objectives. The CCB has the authority to establish baselines, initiate or

change software, accept testing results, and approve the release of software

into production

Configuration

Identification

The process of identifying items to be placed under configuration control

Configuration

Management

Library

The tools and procedures to access the contents of the software baseline

library.

Configuration

Documents the plan for performing CM activities for a specific project or

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 48

Word/Term

Definition

Management

Plan

group of projects including resources, schedule, tools, and procedures

Configuration

Status

Accounting

An element of CM that focuses on recording and monitoring changes to

controlled system configurations and maintaining a controlled

documentation library

Code

To transform the system logic and data from design specifications into a

programming language. n. The computer program itself; pseudo-code is

code written in an English-like logical representation, source code is code

written in a programming language, object code is code written in machine

language.

CPIC

Capital Planning and Investment Control (CPIC): a management process for

ongoing identification, selection, control, and evaluation of investments in

information resources. The process links budget formulation and execution,

and is focused on agency missions and achieving specific program

outcomes. (See OMB Circular A-130, Section 6 at

http://www.whitehouse.gov/omb/Circulars_a130_a130trans4/#6.)

Data

Recorded information, regardless of medium or characteristics, of any

nature, including administrative, managerial, financial, and technical

Data Dictionary

A repository of information about data, such as its meaning, relationships to

other data, origin, usage and format

Data

Specification

(DS)

Describes the database organization and storage allocation and provides the

detailed data model of the logical and physical design, as well as other

necessary information

Database

A collection of logically related data stored together in one or more

computerized files; an electronic repository of information accessible via a

query language interface

Database

Management

System (DBMS)

A software system that controls storing, combining, updating, retrieving,

and displaying data records.

Developer

An organization that develops products ("develops" may include new

development, modification, reuse, reengineering, maintenance, or any other

activity that results in products) for itself or another organization

Documentation

Written and/or graphical information describing, defining, specifying,

reporting, or certifying activities, requirements, procedures, reviews, or

results

Earned Value

Management

A management technique which uses past performance to predict future

cost and schedule performance results. All work is planned, budgeted, and

scheduled in time-phased "planned value" increments constituting a cost

and schedule measurement baseline. (See OMB Circular A-11, Supplement

to Part 7, Capital Programming Guide.)

Enhancement

A change that makes a version of software or hardware better than the

previous version

Feasibility

The extent to which the benefits of a new or enhanced system will exceed

the total costs and also satisfies the business requirements

Feasibility Study

A formal study to determine the feasibility of a proposed system (new or

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 49

Word/Term

Definition

enhanced) in order to make a recommendation to proceed or to propose

alternative solutions

Function

A set of related actions, undertaken by individuals or tools that are

specifically assigned or fitted for their roles, to accomplish a set purpose or

end

Functional

Requirement

A requirement that specifies functions that a system must perform.

Functional

Requirements

Document

(FRD)

Documentation of initial definition of the system and the environment in

which it will operate

Functionality

The ability to perform all required functions

Goals

Signifies the scope, boundaries, and intent of each key process area.

Hardware

The hardware is the physical part of a computer system; the machinery and

equipment

Implementation

Installing and testing the final system, usually at the user (field) site; the

process of installing the system

Information

system

A discrete set of information resources organized for the collection,

processing, maintenance, transmission, and dissemination of information, in

accordance with defined procedures, whether automated or manual (per

OMB Circular A-130)

Information

system project

Temporary planned endeavor funded by an approved information

technology investment; thus achieving a specific goal and creating a unique

product, service, or result. A project has a defined start and end point with

specific objectives that, when attained signify completion

Information

Technology

Any equipment or interconnected system or subsystem of equipment, that is

used in the automatic acquisition, storage, manipulation, management,

movement, control, display, switching, interchange, transmission, or

reception of data or information by an executive agency. For purposes of

the preceding sentence, equipment is used by an executive agency if the

equipment is used by the executive agency directly or is used by a

contractor under a contract with the executive agency which (i) requires the

use of such equipment, or (ii) requires the use, to a significant extent, of

such equipment in the performance of a service or the furnishing of a

product. The term "information technology" includes computers, ancillary

equipment, software, firmware and similar procedures, services (including

support services), and related resources. The term "information technology"

does not include any equipment that is acquired by a Federal contractor

incidental to a Federal contract. The term "information technology" does

not include national security systems as defined in the Clinger-Cohen Act of

1996 (40 U.S.C. 1452). (See OMB Circular A-130, Section 6 at

http://www.whitehouse.gov/omb/Circulars_a130_a130trans4/#6.)

Integration Test

Testing in which software components, hardware components, or both are

combined and tested to evaluate the interaction between them

Integrity

The degree to which a system (or system component) prevents unauthorized

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 50

Word/Term

Definition

access to, or modification of, computer programs or data.

Interface

To interact or communicate with another system (or system component).

(verb)

An interface can be software and/or hardware (noun)

Interoperability

A measure of the ability of two or more systems (or system components) to

exchange information and use the information that has been exchanged

Investment

Spending by Program Office on information technology regardless of

amount or funding source. An IT investment may include a project or

projects for the development, modernization, enhancement, or maintenance

of a single IT asset or group of IT assets with related functionality and the

subsequent operation of those assets in a production environment. While

each asset or project would have a defined life-cycle, an investment that

covers a collection of assets intended to support an ongoing business

mission may not.

Lessons Learned

Any experiences discovered on previous activities that can be used to

expedite and/or improve future systems development

Level of Effort

Contract

A level of effort contract means that for a specific amount of money the

provider will produce as many deliverables as they can

Library

A configuration controlled repository for system components (for example,

documents and software)

Life Cycle

All the steps or phases a program or project passes through during its life;

from concept development to disposition

Maintainability

The ease with which a software system (or system component) can be

modified to correct faults, improve performance, or other attributes, or

adapt to a changed environment

Maintenance

Activities required to keep a software system operational after

implementation

Managed and

Controlled

The process of identifying and defining software work products that are not

part of a baseline and, therefore, are not placed under configuration

management but that must be controlled for the project to proceed in a

disciplined manner

Methodology

A set of methods, procedures, and standards that define the approach for

completing a system development or maintenance project

Metrics

A quantitative measure of the degree to which a system, component, or

process possesses a given attribute

Milestone

A scheduled event that is used to measure progress against a project

schedule and budget

Module

A software unit that is a logically separate part of the entire program

Needs Statement

Document describing the deficiency or justifying the exploration of

alternative solutions

Operations

Manual (OM)

Provides computer control personnel and computer operators in an

information processing center with a detailed operational description of the

system and its associated environment. Instructions for installation and

operation

Phase

A defined stage in the systems development life cycle; there are seven

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 51

Word/Term

Definition

phases in the OPM SDLC

Procedure

A series of steps (or instructions) required to perform an activity

Process

A finite series of activities as defined by its inputs, outputs, controls (for

example, policy and standards), and resources needed to complete the

activity

Product

General term for an item produced as the result of a process; can be a

system, subsystem, software component, or a document

Program

One or more major multi-year IT initiatives of such magnitude they must be

carried out through multiple related IT projects. A program encompasses

the missions, functions, operations, activities, laws, rules, and regulations

that an agency is authorized and funded by statute to administer and

enforce. It constitutes an ongoing operation.

Project

The complete set of activities associated with all life cycle phases needed to

complete a systems development or maintenance effort from start to finish

(may include hardware, software, and other components); the collective

name for this set of activities.

A project has a defined beginning and end. A project serves to develop,

modify, or enhance a product, service, or system and is constrained by the

relationships among scope, resources, and time. [Source: OPM (11/2011)

“IT Program Management Career Path Guide”, p. 3.]

Project

Management

The process of planning, organizing, staffing, directing, and controlling the

development and/or maintenance of a system

Project Plan

A plan that is updated, expanded and refined continually thought system

development; covers project scheduling, work breakdown structure (WBS),

staffing, resources, adjustments to the software development life cycle

structure, selection of tools and techniques, identification of applicable

reviews and approvals, CM methods, and other related topics

Project Team

Group of individuals associated with a specific project

Quality

The degree to which a system, component, product, or process meets

specified requirements.

Quality

Assurance

A discipline used by project management to objectively monitor, control,

and gain visibility into the development or maintenance process

Quality

Assurance Plan

A formal plan to ensure that delivered products satisfy contractual

agreements, meet or exceed quality standards, and comply with approved

systems development or maintenance processes

Regression

Testing

The rerunning of test cases that previously executed correctly in order to

detect errors introduced by the maintenance activity

Release

A configuration management activity wherein a specific version of software

is made available for use

Requirement

A capability needed by a user; a condition or capability that must be met or

possessed by a system (or system component) to satisfy a contract, standard,

specification, or other formally imposed documents

Requirements

Management

Establishes and controls the scope of system development efforts and

facilitates a common understanding of system capabilities between the

System Proponent, developers, and future users

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 52

Word/Term

Definition

Requirements

Traceability

Matrix

Provides a method for tracking the functional requirements and their

implementation through the development process

Resource

In management, the time, staff, capital and money available to perform a

service or build a product; also, an asset needed by a process step to be

performed

Reusability

A characteristic of some programming styles or languages (for example,

object-oriented programming) in which code written for one application can

be reused with different applications

Revision

A version that supersedes an earlier version to correct errors

Risk

A potential occurrence that would be detrimental to the project; risk is both

the likelihood of the occurrence and the consequence of the occurrence

Schedule

A list of tasks and activities, describing the past and/or future

accomplishments of a project/release, used to allocate work, specify

deadlines, and manage the project/release

Scope

The established boundary (or extent) of what must be accomplished; during

planning, this defines what the project will consist of (and just as important,

what the project will not consist of)

Scrum

Scrum is a popular Agile system development methodology. Scrum is

characterized by self‐directed development teams, operating in successive

iterations (typically 2 to 3 weeks as indicated by best practices), holds daily

team standup meetings of no longer than 15 minutes, continuously offers

the customer demos of the current solution, and adapts its development plan

at the end of each iteration.

Security

The establishment and application of safeguards to protect data, software,

and hardware from accidental or malicious modification, destruction, or

disclosure.

Software

Computer programs (code), procedures, documentation, and data pertaining

to the operation of a computer system

Software Design

Description

(SDD)

Documents the allocation of requirements, system/software designs, and

internal/external interfaces.

Software Process

A set of activities, methods, practices, and transformations that people use

to develop and maintain software and the associated products (e.g., project

plans, design documents, code, test cases, and user manuals).

Standard

An agreed-upon set of specifications for hardware or software

Stress Testing

Testing that determines the maximum capacity of the system, given user

requirements for response time and throughput

Subject Matter

Expert (SME)

An individual with a specific area of expertise.

Subsystem

A collection of components that meets the definition of a system, but is

considered part of a larger system.

System

A collection of components (hardware, software, interfaces) organized to

accomplish a specific function or set of functions; generally considered to

be a self-sufficient item in its intended operational use

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 53

Word/Term

Definition

System

Administrator

The person responsible for planning a system installation and use of the

system by other users.

Security

Assessment and

Authorization

Formerly known as the Certification and Accreditation (C&A) in the IT

Security and Privacy area.

System

Development

Life Cycle

(SDLC)

A consistent and repeatable process for planning, managing, and overseeing

IT programs and projects through all the steps or phases it passes through

during its life; from concept development to disposition.

System Security

Plan

A formal document that establishes the processes and procedures for

identifying all areas where security could be compromised within the

system (or subsystem).

Tailor

To modify a process, standard, or procedure to better match process or

product requirements.

Team

A collection of people, often drawn from diverse but related groups,

assigned to perform a well-defined function for an organization or a project.

Technical

Relating to agreements, conditions, and/or requirements affecting the

functionality and operation of a system. Compare to non-technical

Template

The outline or format for a document or memo. Defines what information

needs to be included in the document

Test

The process of exercising the product to identify differences between

expected and actual results and performance

Test Case

A specific set of test data and associated procedures developed for a

particular test.

Test Results and

Evaluation

Report

A compilation of test results and summary of the system’s readiness for

production.

Test Team

Individuals, independent of the software development organization, who are

designated by the project sponsor to test system’s readiness for production

Training

The formal process of depicting, simulating, or portraying the operational

characteristics of a system or system component in order to make someone

proficient in its use.

Training Plan

A formal document that outlines the objectives, needs, strategy, and

curriculum to be addressed for training users of the new or enhanced

system.

Unit

The smallest logical entity specified in the design of a software system;

must be of sufficient detail to allow the code to be developed and tested

independent of other units

Unit test

A test of one application to see if remediation efforts were successful. The

unit test does not test how well the application will work with other

applications

User Acceptance

Test

A formal test conducted by the end user of a system, to determine if the

system works according to specifications and should be accepted

User Manual

A formal document that contains all essential information for the user to

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 54

Word/Term

Definition

make full use of the new or upgraded system.

Verification,

Validation &

Testing Plan

Documentation of the testing strategy that provides acceptance testing for

all components of a system

Version

An initial release or re-release of a computer software configuration item,

associated with a complete compilation or recompilation of the computer

software configuration item; sometimes called a build

Version Control

A means to identify and manage configuration items as they change over

time, usually provided by a software tool designed for configuration

management

Version

Description

Document

A formal document that describes the exact version of a configuration item

and its interim changes. It is used to identify the current version; provides a

"packing list" of what is included in the release.

Work

Breakdown

Structure

A structure of well-defined work efforts and work elements that organizes

and defines the total scope of the project and provides for better planning,

scheduling and controlling of a project’s work efforts.

Version 1.1

April 2013 Page 55

APPENDIX C: REFERENCES

C.1 External and Internal Issuances Incorporated by Reference

C.1.1 External References

“25 POINT IMPLEMENTATION PLAN TO REFORM FEDERAL INFORMATION

TECHNOLOGY MANAGEMENT” by Vivek Kundra, U.S. Chief Information Officer,

December 9, 2010: http://www.whitehouse.gov/sites/default/files/omb/assets/egov_docs/25-

point-implementation-plan-to-reform-federal-it.pdf

Beck, Kent; et al. (2001). "Manifesto for Agile Software Development". Agile Alliance

Chief Financial Officers Council guidance documents: http://www.cfoc.gov/

Clinger-Cohen Act of 1996, February 10, 1996, Subtitle III of Title 40 United States Code

(U.S.C.)

Government Accountability Office (GAO) Cost Estimating and Assessment Guide,

http://www.gao.gov/new.items/d093sp.pdf.

NARA Code of Federal Regulations - 36 CFR 1236, Electronic Records Management,

http://www.gpo.gov/fdsys/pkg/CFR-2011-title36-vol3/pdf/CFR-2011-title36-vol3-part1236.pdf

Office of Management and Budget (OMB), Circular A-11, Supplement to Part 7, The Capital

Programming Guide, v2.0.

http://www.whitehouse.gov/sites/default/files/omb/assets/a11_current_year/part7.pdf

Office of Management and Budget (OMB) memorandum M-10-27 of June 28, 2010.

http://www.whitehouse.gov/sites/default/files/omb/assets/memoranda_2010/m10-27.pdf

Project Management Institute (2008), “Project Management Body of Knowledge”, 4

edition

Records Management policy defined within the Federal Enterprise Records Management Profile,

Sections 4.1.1 through 4.1.6

http://www.archives.gov/records-mgmt/policy/rm-profile.html

Section 508 of the Rehabilitation Act, August 7, 1998

http://www.section508.gov/index.cfm?fuseAction=1998Amend

Software Engineering Institute, Capability Maturity Model Integration (CMMI) for Development

version 1.3, at http://www.sei.cmu.edu/library/abstracts/reports/10tr033.cfm

The Federal Acquisition Reform Act (FASA) and the Federal Acquisition Regulations (FAR)

Implementation of the Federal Acquisition Streamlining Act. See reference library at GSA’s

Version 1.1

April 2013 Page 56

Acquisition Central at www.acquisition.gov

C.1.2 Internal OPM References

IT Baseline Management Policy, available on OPM website at

http://www.opm.gov/about-us/our-people-organization/support-functions/cio/information-

technology-baseline-management-policy.pdf

Policy on Information Technology (IT) Procurement, available on THEO at

http://theo.opm.gov/policies/ispp/it_procurement.pdf

Information Security & Privacy Policy and Supporting Documents, available on THEO at

http://theo.opm.gov/policies/ispp/

Policy on Electronic Signatures, available on THEO at

http://theo.opm.gov/policies/electronic signature policyv6.pdf

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 57

APPENDIX D : OPM SDLC PHASE ACTIVITIES

Appendix D.1: Determine System Needs Phase Activities

Step

Description of Activity

Inputs/Outputs

Lead

Participants

Determine type of development.

The Business Program Manager or Business Project Manager, with

assistance from a Technical Advisor, determines the type of development

needed to support the project.

The type of development is chosen from the following types:

 New - A system will be implemented where no system currently exists

with the intended functionality or will replace an existing system.

 COTS - A project that will implement a Commercial Off-the-Shelf

(COTS) product requiring integration or with modifications.

 Cloud – A project that will implement a Cloud solution requiring

integration or with modifications.

 Enhancement - A project that will require either changes to an existing

system’s architecture or interfaces.

 Maintenance - A project that will make changes to an existing system,

but not change the architecture or interfaces.

Inputs:

Identified need or

Change Request

(CR)

Outputs:

Type of project

development

selected

Business Program

Manager or

Business Project

Manager

Technical

Advisor

Determine a “Rough Order of Magnitude (ROM)” estimate of the cost of

the project.

The Business Program Manager or Business Project Manager determines

the initial estimated cost of the project with the assistance of a Technical

Advisor.

At this early stage, this cost is a high level estimate based on level of

effort (LOE), materials and equipment from development through

Inputs:

Identified need or

CR, Estimated IT

Security Resource

Hours/Cost

Outputs:

Estimated ROM

Business Program

Manager or

Business Project

Manager

Technical

Advisor

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 58

Step

Description of Activity

Inputs/Outputs

Lead

Participants

deployment. This cost can be derived using an automated estimating tool,

based on analogy, or other estimating method.

The estimated ROM cost is comprised of the following:

 Labor – Total estimated cost of labor

 Materials – Total estimated cost of materials (including purchased

software)

 Equipment – Total estimated cost of equipment (computers, facilities,

etc.)

cost

Determine project risks, project complexity, project duration and special

interests which affect the project.

 Project Risks: Low, Medium and High

 Project Complexity: Low, Medium and High

 Project Duration: Less than six months or greater than six months

 Special Interests affecting Project: Yes or No

Inputs:

Identified need or

Outputs:

Project Assessment

for Risk,

Complexity,

Duration and

Special Interest

Business Program

Manager or

Business Project

Manager

Technical

Advisor

Determine the project documentation level based on the selected type of

project development, estimated ROM cost and project assessment for

Risk, Complexity, Duration and Special Interest as outlined in Appendix

Inputs:

Estimated ROM

cost;

Selected Type of

Project

Development;

Project Assessment

for Risk,

Complexity,

Duration and

Special Interest

Business Program

Manager or

Business Project

Manager

Technical

Advisor

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 59

Step

Description of Activity

Inputs/Outputs

Lead

Participants

Outputs:

Project

Documentation

Level

Determine if the need requires the retirement of an existing system or part

of an existing system

Is the new need intended to replace an existing system?

Perform decommission if system or partial system exists.

Inputs:

Existing System,

Outputs:

Decision to

Decommission a

System

Business Program

Manager or

Business Project

Manager

Technical

Advisor

System Owner

Begin Phase Work

 Based on project category criteria from Appendix E:

- Project Documentation Level 1 and 2 – Proceed to step 8 in this

procedure.

- Project Documentation Level 3 – Proceed to the Build System

Components Phase or Develop System Design Phase. For some

minor changes to the system, the changes could be implemented

directly in the production environment.

- Project Documentation Level 4 – Proceed to step 7 in this

procedure.

- Project Documentation Level 5 – Proceed to step 7 in this

procedure

Inputs:

Decommissioned

System (if

applicable),

Project

Documentation

Level

Outputs:

Begin preparation

for Needs

Statement or

Begin preparation

for IT Investment

Analysis Package

Begin Build System

Components

Develop System

Design

Business Program

Manager or

Business Project

Manager

Technical

Advisor

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 60

Step

Description of Activity

Inputs/Outputs

Lead

Participants

Document the Need by developing a Needs Statement

 User/Business Program Manager or Business Project Manager

Develops Needs Statement (NS)

- Identify the benefits expected, existing and planned capabilities,

estimated costs, assessment of need.

 Review OPM’s Technical Reference Model found in the Enterprise

Architecture (EA) document. The EA document can be requested

from the CIO Enterprise Architect.

 Submit Needs Statement to the Executive Sponsor for internal review

 Executive Sponsor provides comments and feedback on the Needs

Statement

 Comments incorporated to the Final Needs Statement and Submitted

to CM for version control

Inputs:

Project

Documentation

Level,

Technical

Reference Model,

Needs Statement

Template,

Outputs:

Needs Statement

(versioned)

Business Program

Manager or

Business Project

Manager

Technical

Advisor

Executive

Sponsor,

Chief

Information

Officer (CIO),

Executive

Sponsor

CM Team,

SQA Team

Prepare Information Technology Investment Analysis Package (ITIAP)

by conducting a Feasibility Study (FS) using the template provided.

 Examine system objectives

- Analyze anticipated functions of the system, considering areas

such as:

 New services

 Increased capacity

 Legislative and policy requirements

 Privacy and security requirements

 Audit controls

- Identify major performance objectives, such as:

 Reduced staff and equipment costs

 Increased processing speed and productivity

 Improved management information services and controls over

automated decision making systems

Inputs:

Needs Statement

(versioned),

IT Investment

Analysis Package

Template,

Feasibility Study

Template,

Outputs:

IT Investment

Analysis Package

(draft),

Feasibility Study

(draft), Information

Business Program

Manager or

Business Project

Manager

Technical

Advisor, IT

Security Team

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 61

Step

Description of Activity

Inputs/Outputs

Lead

Participants

 Compliance with regulations

- Identify assumptions and constraints

 Operational life of the proposed system

 Period of time for comparison of system alternatives

 Input, output, and processing requirements

 Financial constraints

 Changing hardware, software and operating environment

 Evaluate Alternatives

- Determine criteria for evaluating alternatives such as:

 Cost

 Priority

 Development time

 Ease of system use

- Identify and summarize alternatives to be considered during the

study including:

 Use of one or more existing system

 Development of one or more new system

 The potential of purchasing an off-the-shelf system.

- Outline time and resource costs

 Include the time and funding required for all activities of the

life cycle from definition through operation.

 Use realistic estimates

 Include factors such as:

 The current workload of personnel

 Staff absences due to vacation and illness

 Lead time for procurement of equipment and software

 Staff training

 Identify preferred approach by weighing each alternative identified

during the evaluate alternatives process against the evaluation criteria

 Develop detailed FS

- Describe system objectives by including such information as:

Type Classification

(FIPS-199), Privacy

Threshold Analysis,

SORN, Special

Security

Requirements

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 62

Step

Description of Activity

Inputs/Outputs

Lead

Participants

 System output

 System input

 File descriptions

 Validation criteria

 Security, privacy, and control requirements, data storage and

retrieval

 Any interfacing systems

- Describe current functional procedures whether automated or

manual

- Describe proposed system including such information as:

 The overall system concept

 Improvements anticipated after successful implementation of

the proposed system

Prepare ITIAP by conducting the Cost/Benefit Analysis (CBA) using the

CBA template or any alternative template

 Identify the alternatives for development and operation

- Describe the technical and operational characteristics of current

system and identify the input to and output form the system

- Summarize the functional objectives of the system and describe

the expected input to and output form the system

- Describe the alternative system that was discussed in the FS.

 Determine the benefits per alternative

- Determine nonrecurring benefits for each system alternative

- Determine recurring benefits including:

 Equipment

 Software and data communications lease

 Rental and maintenance

- Determine non-quantitative benefits such as:

 Improved service

 Reduced risk of incorrect processing

 Improved information handling

 Enhanced organizational image

Inputs:

Needs Statement,

Investment

Analysis Package

Template,

Cost/Benefit

Analysis Template

Outputs:

IT Investment

Analysis Package

(draft),

Cost/Benefit

Analysis (draft)

Business Program

Manager or

Business Project

Manager

Technical

Advisor

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 63

Step

Description of Activity

Inputs/Outputs

Lead

Participants

 Determine the cost per alternative

- Development costs

- Operational costs

- Nonrecurring costs

- Recurring costs

 Develop a detailed CBA

10.

 Complete the ITIAP with the Needs Statement as the Appendix

 Chief Information Officer (CIO) reviews the package

 Submit package to Investment Review Board (IRB) and to CM to be

baselined.

Inputs:

IT Investment

Analysis Package

(draft)

Outputs:

Reviewed and

baselined IT

Investment

Analysis Package

Business Program

Manager or

Business Project

Manager

Technical

Advisor,

Chief

Information

Officer,

Investment

Review Board

11.

IRB conducts review of the IT Investment Analysis Package which

contains the Cost Benefit Analysis.

IRB renders decision to approve or disapprove.

For detailed steps on the IRB refer to the OPM IRB Charter

Inputs:

IT Investment

Analysis Package

Outputs:

Approved IT

Investment

Analysis Package

Investment Review

Board

CIO

12.

Charter the Project

 Formally establish the work as a Project

 Budget is established for the IT Project which is to be managed by the

Business Program Manager or Business Project Manager

 Assign a Technical Project Manager

Inputs:

Approved IT

Investment

Analysis Package

Outputs:

Technical Project

Manager is

CIO

Business

Program

Manager or

Business

Project

Manager

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 64

Step

Description of Activity

Inputs/Outputs

Lead

Participants

 A Technical Project Manager is assigned or transferred to the work

assigned

13.

Define High Level System Requirements

 Gather user requirements

 Determine functional requirements

- Identify the functional requirements

- Define current procedures including:

 Organizational and personnel responsibilities

 Equipment being used

 Input/output including volume, sources and frequency

 Deficiencies such as time delays

- Define proposed functions include:

 Information flows

 Business logic

 Manual procedures

 Security considerations

- Identify organizational, operational, and user impacts

 Define performance requirements. Determine:

- Acceptable online response time and batch turnaround time (as

applicable)

- Capacity limits (as applicable)

- Accuracy and validity requirements

 Identify and define applicable standards and guidelines:

Inputs:

IT Invest Analysis

Package,

User Requirements

Document

Template,

Applicable

Standards and

Guidelines

Outputs:

User Requirements

Document (draft),

Security Impact

Analysis document

Business Program

Manager or

Business Project

Manager

Technical

Advisor, IT

Security

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 65

Step

Description of Activity

Inputs/Outputs

Lead

Participants

- Review applicable program office standards

- Review the OPM Enterprise Architecture and Technical Reference

Model

- Review the OPM Information Security and Privacy Policy

- Review Section 508 standards

 Capture requirements in the User Requirements Document (URD)

- Review applicable documentation (Needs Statement, ITIAP)

- Define assumptions and constraints that will affect development

and operation of the system.

 The Technical Advisor provides input and advice for the URD

14.

Deliver the Final User Requirements Document

Staff the URD with users and the executive sponsor for comment and

approval

Incorporate user comments and deliver the final User Requirements

Document to Configuration Management to be placed under version

control.

Inputs:

Customer

comments on User

Requirements

Document

Outputs:

Final User

Requirements

Document

(versioned)

Business Program

Manager or

Business Project

Manager

Technical

Advisor

CM Team

Users and

Executive

Sponsor

15.

Conduct Phase Exit Review

 Business Program Manager, Business Project Manager or Product

Owner notify the project team and extended project team (users,

POCs, support areas) that a Phase Exit Review has been scheduled.

- Request that all approvers provide feedback at least one week

before the exit meeting is to be held. (This will allow the time to

Inputs:

Phase Deliverables

produced during

current phase,

New and existing

issues

Outputs:

Business Program

Manager or

Business Project

Manager

Technical

Advisor

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 66

Step

Description of Activity

Inputs/Outputs

Lead

Participants

work issues and develop action plans prior to the exit meeting)

- Invite participants to attend the exit meeting using the Phase Exit

Review Memo that is within the Phase Exit Review Package along

with the review material (any other material relevant to the exiting

stage which include but are not limited to known issues, and

unplanned deliverables)

- The participants should be familiar with planned deliverables since

it is standard procedure for them to review drafts as they are

developed.

 If this is not the case a list of the planned deliverables should

also be distributed at this time.

 Review the current outline (at a minimum, a detailed plan for the next

phase and high-level plans for the remainder of the project).

 Review other relevant materials to verify if they are in accordance

with OPM’s SDLC

 Receive position from the list of approvers (to include the Executive

Sponsor, CIO, Technical Advisor, Business Program Manager or

Business Project Manager) using the Phase Exit Position Response

Form within the Phase Exit Review Package. This position can be

concur, concur with qualifications, or non-concur. The implication of

each is as follows:

- Concur – Proceed with the project according to the current plan.

(Ex. The Approver is unaware of any issues for the current phase)

- Concur with qualifications – There are issues or concerns and the

project can proceed according to the current plan if an acceptable

action plan is developed for each issue or concern by the meeting.

(Ex. There is no plan for testing an interface to an existing system

that is being changed)

Plans for

addressing issues

and risks,

Concurrence that

all activities for this

phase is complete

and movement to

next phase has been

approved.

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 67

Step

Description of Activity

Inputs/Outputs

Lead

Participants

- Non-concur – There are very significant issues or concerns and the

project should not move to the next phase until those issues or

concerns are resolved. (Ex. Funding for the project has been

withdrawn)

 Prepare acceptable action plan to address each issue or concern

received.

 Conduct Exit Meeting

- Present positions from the Approvers, along with issues and/or

concerns, and any other issues that may be open

- Action plans must be presented for each issue or concern

 Document the meeting including positions, issues, concerns, action

plans, and follow-up activity

 Obtain concurrence on current stage deliverables, and begin the next

phase of development

 All items are to be controlled by CM.

Appendix D.2 : Define System Requirements Phase Activities

Step

Description of Activity

Inputs/Outputs

Lead

Participants

Scope the Project

 Estimate size, resources and schedule

Inputs:

Needs Statement,

User Requirements

Document

Outputs:

Project Estimates

Technical PM

Project Team

Identify, analyze, and document potential risks.

Inputs:

Technical PM

Business

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 68

Step

Description of Activity

Inputs/Outputs

Lead

Participants

 Identify Risks

- Risks may occur in the following areas:

 Budget

 Schedule

 Development

 Design

- Utilize Lessons-Learned from previous projects as a significant

source for identifying potential risks on a new project

- Categorize Risks as follows: (see Risk Types, Items and Cause of

Impact to help with the selection of category):

 Technical – Risks associated with creating a new capability or

capacity

 Supportability – Risks associated with implementing,

operating, and maintaining a new capability

 Cost – Risks associated with schedule estimates inaccuracy

 Schedule – Risks associated with planned activities

 Analyze Risks

- Characterize

 Determine the impact of the risk on the project if it occurs.

Rate as high, medium, or low.

 Determine the likelihood of the risk occurring. Rate as high,

medium, or low.

- Strategy

 Determine what needs to be done to prevent the risk from

becoming a reality or to minimize its impact.

 Develop strategies for eliminating or reducing the risks and

incorporate the strategies into project planning

- Monitoring

 Determine metrics to monitor the risk (or probability of risk) to

identify when it begins to become a problem

 Identify how tasks will be monitored to detect problems early.

This typically includes monitoring expenditures versus

Needs Statement,

Project Estimates,

User Requirements

Document,

Lessons Learned

from previous

projects as

applicable,

IT Security

Analysis,

Risk Matrix

Template

Outputs:

Project risks,

Security Analysis

Impact document,

Updated Risk

Matrix

Program

Manager or

Business

Project

Manager,

Project Team,

IT Security

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 69

Step

Description of Activity

Inputs/Outputs

Lead

Participants

progress for cost risk; scheduled progress versus actual

progress for schedule risk; requirements tracking for

operational and support risks, and perhaps technical

performance measurement plans for technical risks

- Management

 Manage the risk by monitoring and reporting on every open

risk as required.

 Document and review risks.

- Update the Risk Matrix

Develop Project Plan

Note: Because project planning is an iterative activity, detailed planning

of the subsequent phases can occur.

 Develop the Project Plan and include the Quality Assurance Plan

(QAP) and Configuration Management Plan (CMP) as appendices if

applicable.

- Review the scope of the work

 Ascertain the users’ requirements, constraints and

contributions from discussions with the user community and/or

Business Program Manager or Business Project Manager

 Record the understanding of the user’s goals and objectives

regarding overall cost schedule and product quality.

 Record the understanding of management’s risk tolerance level

 Record the understanding of products and their characteristics

to be delivered to the user

- Determine technical approach

 Select an appropriate life cycle model for performing required

activities and appropriate packaging techniques for required

products

 Refer to Methodologies for reference of various life cycle

models

 Incorporate the appropriate project activities into the Project

Plan

Inputs:

Updated Risk

Matrix,

Needs Statement,

Information

Technology (IT)

Investment

Analysis Package

(ITIAP) (if

applicable),

Project Estimates,

Methodologies

Outputs:

Draft Project Plan,

Draft QAP,

Draft CMP

Technical PM

Project Team,

Business

Program

Manager or

Business

Project

Manager

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 70

Step

Description of Activity

Inputs/Outputs

Lead

Participants

Note: Because project planning is an iterative activity, detailed planning

of the subsequent phases can occur.

 Develop the Project Plan and include the QAP and CMP as

appendices if applicable.

- Determine technical approach

 Determine the activities, methods, techniques, and products

that will help achieve the goals and objectives established for

the project.

- Define, schedule, and budget the work

- Organize the project team

 Identify the personnel that compose the project team. Clearly

state the responsibility for each critical function of the project

and establish lines of communication.

 Assign the key Roles & Responsibilities for each phase of the

life cycle.

- Determine resource requirements

- Address special project considerations

Create the Quality Assurance Plan (QAP)

Include the following:

 Quality objectives in measurable terms

 Responsibilities of the Software Quality Assurance (SQA) team

 Resource requirements for the SQA team

 SQA team participation in Project Plan and procedures

 Evaluations to be performed by SQA team

 Audits and reviews to be conducted by SQA team

 Documenting and tracking noncompliance issues and the escalation

procedures

 Documentation that SQA team is to produce

 Method, audience, and frequency of providing feedback on SQA

activities

Inputs:

Project Plan,

QAP Template

Outputs:

Draft QAP

SQA Team

Technical PM

Implement the SQA Plan

Inputs:

SQA Team

Technical PM

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 71

Step

Description of Activity

Inputs/Outputs

Lead

Participants

 The SQA team performs the SQA function as defined in the QAP

 Problems or non-conformances with requirements are documented

and reported to the Technical PM or appropriate authority

 Senior Management addresses noncompliance issues that cannot be

resolved within the project

QAP

Outputs:

Implemented QAP

Project Team

Create the Configuration Management Plan (CMP)

 Define CM activities and responsibilities and required resources

 Specifically address the following:

- Identify items that need to be placed under control which includes:

 Configuration Items (CIs) (software, hardware,

communications, and databases)

 Technical documentation or baselines describing the CIs

 Management documentation (describes the process used to

develop or manage the development of the CIs such as plans,

standards and procedures)

- System and software baselines

 Specifically address the following:

- Configuration control

 CCB – Decision making body for the program area projects.

Evaluates the scope, applicability, and effect of requests by

providing approval or disapproval based on defined strategic

initiatives, program business objectives, and budgetary

parameters with a focus on items that could affect cost,

schedules or compliance with technical requirements.

 Change Request (CRs) – A request to change technical

requirements approved for the project that may affect the

scope of the system or may have an impact on the overall cost,

schedule, and technical capability and are usually generated by

system user. They must be approved by the project CCB

before resources are assigned to implement the change.

 Discrepancy Reports (DRs) – Software problems requiring

corrective maintenance

Inputs:

Project Plan,

CMP Template

Outputs:

Draft CMP

CM Team

Technical PM

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 72

Step

Description of Activity

Inputs/Outputs

Lead

Participants

 Requests for Change (RFCs) – Generated by personnel within

OPM who wishes to initiate system enhancements, which are

usually activities that have been planned for future

implementation.

Specifically address the following:

- Configuration status accounting

 Focuses on recording and monitoring changes to controlled

system configurations and maintaining a controlled

documentation library.

- Configuration Audits

 Conduct audits on the Configuration Items identified in the

CMP

Prepare the System Architecture as outlined in the Enterprise Architecture

(EA) document. The EA document can be requested from the CIO

Enterprise Architect.

Inputs:

User Requirements

Document,

Needs Statement,

OPM Enterprise

Architecture and

associated

Reference Models

Outputs:

System

Architecture

Technical PM

Project Team,

Business

Program

Manager or

Business

Project

Manager, CIO

Enterprise

Architect

Review the System Architecture and provide comments

Review the System Architecture for approval.

Inputs:

System

Architecture

Outputs:

Reviewed and

approved System

Architecture

Technical PM

Project Team,

Business

Program

Manager or

Business

Project

Manager,

Other

Stakeholders,

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 73

Step

Description of Activity

Inputs/Outputs

Lead

Participants

CIO Enterprise

Architect

Deliver the Final System Architecture

Incorporate stakeholder comments and deliver the final System

Architecture to Configuration Management (CM) to be baselined.

Inputs:

Reviewed and

approved System

Architecture

Outputs:

Baselined System

Architecture

Technical PM

Business

Program

Manager or

Business

Project

Manager, CM

10.

Create a Software Requirements Specification (SRS)

 Document the requirements using the SRS Template

 Ensure all non-software requirements are documented

 If applicable, load the SRS into automated requirements management

tool, which assigns a unique tag number

 If an automated tool is not available, ensure that each requirement is

numbered and has attributes clearly associated with it (e.g.,

Requirements Traceability Matrix).

 Note: Trace software requirements through design, development, and

testing phases.

Inputs:

Validated

requirements list,

System

Architecture,

Requirements

Traceability

Matrix/Requiremen

ts Management

(RM) Tool

Outputs:

Updated draft SRS,

Draft RTM or

Updated RM Tool

Requirements Team

Project Team

11.

Review SRS and Provide Comments

Review the SRS for approval.

Inputs:

Internally

Approved SRS

Outputs:

Customer Review

comments and

approval

Requirements Team

Technical PM,

QA Team,

Business

Program

Manager or

Business

Project

Manager

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 74

Step

Description of Activity

Inputs/Outputs

Lead

Participants

12.

Deliver the Final SRS

Incorporate customer comments and deliver the final SRS to

Configuration Management (CM) to be baselined.

Inputs:

Customer Review

comments and

approval

Outputs:

Baselined SRS

Requirements Team

Technical PM,

CM Team,

QA Team,

Business

Program

Manager or

Business

Project

Manager

13.

Create the Data Specification

 Review the User Requirements Document

 Categorize and define the data

- Identify static and dynamic data requirements

- Identify internally generated data

 Define data constraints

- Identify source of input

- Identify input/output medium and device

- Identify data recipients

- Specify conversion factors

- Specify frequency of update and processing

 Identify input responsibilities

 Identify data collection requirements

- Describe detailed formats

- Identify data communication media

- Determine timing of input

 Document data requirements using the Data Specification (DS)

 Define assumptions and constraints that will affect development and

operation of the system.

Inputs:

Data Specification

Template,

User Requirements

Document, FIPS

199 Document

Outputs:

Data Specification,

Required Data

Security Controls

based on Data

Classification

Technical PM

Requirements

Management

Team,

Software

Development

Team,

Project Team,

IT Security

Team

14.

Review Data Specification and provide comments

Review the Data Specification for approval.

Inputs:

Internally

Approved Data

Specification

Technical PM,

QA Team

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 75

Step

Description of Activity

Inputs/Outputs

Lead

Participants

Outputs:

Customer Review

comments and

approval

15.

Deliver the final Data Specification

Incorporate customer comments and deliver the final Data Specification

to Configuration Management (CM) to place baselined.

Inputs:

Customer Review

comments and

approval

Outputs:

Baselined Data

Specification

Technical PM,

CM Team,

QA Team,

Business

Program

Manager or

Business

Project

Manager

16.

Create Test Plan (Unit & Integration)

 Review the baselined SRS

 Include Test Strategy

 Include Testing of security components (including Role based Access,

Data Restrictions, Audit Logging)

Note: This Test Plan (Unit & Integration) is a test plan that is an internal

testing plan for the software developers and does not replace the

Verification, Validation & Testing Plan that is to be done by an

Acceptance Team or the Business Program Manager or Business Project

Manager/User

Inputs:

Baselined SRS,

Test Plan (Unit &

Integration)

Template

Outputs:

Draft Test Plan

(Unit &

Integration)

Software

Development Lead

Software

Development

Team,

Requirements

Team, IT

Security

17.

Review Test Plan (Unit & Integration) and Provide Comments

Review the Test Plan (Unit & Integration) for approval.

Inputs:

Approved Test Plan

(Unit &

Integration)

Outputs:

Review comments

and approval

Software

Development Lead

Technical PM,

Software

Development

Lead,

QA Team, IT

Security

18.

Deliver the Test Plan (Unit & Integration) Document

Incorporate comments and deliver the final Test Plan to CM to place

Inputs:

Review comments

Software

Development Lead

Technical PM,

Software

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 76

Step

Description of Activity

Inputs/Outputs

Lead

Participants

under version control.

and approval

Outputs:

(baselined) Test

Plan (Unit &

Integration)

Development

Lead,

QA Team,

CM Team

19.

Create Training Plan

 Review the baselined SRS

 Identify Training Audience

 Include Training Approach

- Identify training methods, techniques, and tools

 Techniques include but are not limited to computer-based

training (CBT), self-paced written manual, peer training,

hands-on practical session, classroom lecture

 Tools include but are not limited to online terminal, training

manual, classroom, and computer center

- Identify training required for revised office procedures

- Develop curriculum

 Determine the job classifications of the individuals that will

need to be trained on the use of the system.

 Determine the system functions that each job class must be

familiar with to enable them to successfully interface with the

system.

Inputs:

Baselined SRS,

Training Plan

Template

Outputs:

Draft Training Plan

Training Team

Project Team

20.

Review Training Plan and Provide Comments

Review the Training Plan for approval.

Inputs:

Internally

Approved Training

Plan

Outputs:

Customer Review

comments and

approval

Training Team

Technical PM

Training Team,

Software

Development

Lead

SQA Team,

Business

Program

Manager or

Business

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 77

Step

Description of Activity

Inputs/Outputs

Lead

Participants

Project

Manager

21.

Deliver the Training Plan Document

Incorporate customer comments and deliver the final Training Plan to CM

to be baselined

Inputs:

Customer Review

comments and

approval

Outputs:

Final (baselined)

Training Plan

Training Team

Technical PM,

Software

Development

Lead

SQA Team,

Business

Program

Manager or

Business

Project

Manager

22.

SQA audits the process and products

Refer to the QAP for detailed schedules of the process and products to be

audited.

Inputs:

QAP,

Processes and

Procedures for

Requirements

Phase,

SQA Audit Report

Template

Outputs:

SQA Audit Reports

SQA Team

Project Team,

Business

Program

Manager or

Business

Project

Manager

23.

Update the Project Plan

 Develop Work Breakdown Structure (WBS)

 Track Project Activity

 Update plan with hardware and software purchases

 Update estimates

 Create project schedule

 Re-assess risks if necessary

 Project Plan is reviewed and placed under CM control to be version

Inputs:

Draft Project Plan,

WBS Task List,

WBS Task

Description

Outputs:

Version controlled

Project Plan

Technical PM

Project Team,

QA Team,

CM Team

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 78

Step

Description of Activity

Inputs/Outputs

Lead

Participants

controlled.

24.

Conduct Phase Exit Review

 Technical PM with assistance from Business Program Manager,

Business Project Manager or Product Owner notifies the project team

and extended project team (users, Points of Contact (POCs), support

areas) that a Phase Exit Review has been scheduled.

- Request that all approvers provide feedback at least one week

before the exit meeting is to be held. (This will allow the Project

manager time to work issues and develop action plans prior to the

exit meeting)

- Invite participants to attend the exit meeting using the Phase Exit

Review Memo along with the review material (Project Plan, and

any other material relevant to the exiting stage which include but

are not limited to known issues, and unplanned deliverables)

- The participants should be familiar with planned deliverables since

it is standard procedure for them to review drafts as they are

developed.

 If this is not the case a list of the planned deliverables should

also be distributed at this time.

 Review the current Project Plan (at a minimum, a detailed plan for the

next phase and high-level plans for the remainder of the project).

 Review other relevant materials to verify if they are in accordance

with OPM’s SDLC

 Receive position from the list of approvers (to include the Technical

PM, Chief Architect, IT Security, Business Program Manager or

Business Project Manager) using the Position Response Form. This

position can be concur, concur with qualifications, or non-concur.

The implication of each is as follows:

- Concur – Proceed with the project according to the current plan.

(Ex. The Approver is unaware of any issues for the current phase)

- Concur with qualifications – There are issues or concerns and the

project can proceed according to the current plan if an acceptable

Inputs:

Phase Deliverables

produced during

current phase,

Initial Project Plan

prior to updates for

next phase,

Latest version

controlled Project

Plan,

New and existing

issues,

Phase Exit Package

Template

Outputs:

Positions from the

approvers,

Issues/concerns (if

any) from review of

the deliverables,

Action plans to

resolve all

issues/concerns,

Risks,

Phase Exit Package

Technical PM

Business

Program

Manager or

Business

Project

Manager,

Project Team

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 79

Step

Description of Activity

Inputs/Outputs

Lead

Participants

action plan is developed for each issue or concern by the meeting.

(Ex. There is no plan for testing an interface to an existing system

that is being changed)

- Non-concur – There are very significant issues or concerns and the

project should not move to the next phase until those issues or

concerns are resolved. (Ex. Funding for the project has been

withdrawn)

 Prepare acceptable action plan to address each issue or concern

received. Note: Sometimes action plans extend beyond the Phase

Milestone and that is acceptable as long as it will not negatively

impact the current Project Plan. Project Plan is high priority for

successful management of the project.

 Conduct Exit Meeting

- Present positions from the Approvers, along with issues and/or

concerns, and any other issues that may be open

- Action plans must be presented for each issue or concern

 Document the meeting including positions, issues, concerns, action

plans, and follow-up activity

 Obtain concurrence on current stage deliverables, and begin the next

phase of development

Appendix D.3: Design System Components Phase Activities

Step

Description of Activity

Inputs/Outputs

Lead

Participants

Begin the system design activities

 Review the Software Requirements Specification (SRS) and the

Requirements Traceability Matrix (RTM) to get a clear understanding

of what the system should do and how the system should respond and

look.

- Gather user and/or customer input if necessary

 Design and document the following:

Inputs:

Change Request,

SRS,

RTM,

Software Design

Description (SDD)

Template,

Software

Development Lead

Project Team,

IT Security

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 80

Step

Description of Activity

Inputs/Outputs

Lead

Participants

- General system characteristics ensuring each unit has a unique

identifier (They may already be defined based on the

requirements.)

- User interface at the desktop layer

- Business rules layer or the application logic

- Interfaces from application to application

- Interfaces from application to database

- Process flow and module hierarchy

- Screen templates or prototypes that depict

- Menu structure and standard screen background

- Security Considerations based on System Security Categorization

 For a Change to an existing system, review the Change request and

update the system design as needed

OPM Naming

Conventions

Standard

Outputs:

Software design

units

Conceptual

understanding of

requirements,

draft SDD

Review the Software Design Description

Conduct a formal review of the SDD.

Include representatives from:

 Other development and maintenance teams whose programs interface

with the units being designed

 The acceptance test team (customer) staff if applicable

 User and sponsor organizations

Inputs:

draft SDD

Updated RTM,

Outputs:

Reviewed SDD

Software

Development Lead

Project Team,

Quality

Assurance (QA)

Team, IT

Security,

Other Subject

Matter Experts

(SMEs)

Review SDD and provide comments

Review the SDD for approval.

Inputs:

Reviewed SDD

Outputs:

Customer review

comments and

approval,

Updated SDD

Technical PM

Business

Program

Manager or

Business

Project

Manager

Deliver the Final SDD

Incorporate customer comments and deliver the final SDD to

Configuration Management (CM) to be baselined.

Inputs:

Customer review

comments and

approval,

Technical PM

Software

Development

Lead,

CM Team

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 81

Step

Description of Activity

Inputs/Outputs

Lead

Participants

Updated SDD

Outputs:

Final (baselined)

SDD

Create Database Design Description

 Review the SRS and the Data Specification (DS) to get a clear idea of

what the system should do and how the system should respond and

look.

- Gather user and/or customer input if necessary.

 Document the unique database names. Specify the:

- Code Name, tag, or label by which each database table or file will

be uniquely identified.

- Additional descriptive information whether or not it is implied in

the identification code such as system using the database, the

database status, and a physical description of the database table or

file.

- Database mappings and data model

 Document any special instructions for database usage.

- Security Implementation based on Data Categorization

 Reference all support software.

- Include 3

party, interfacing, and Commercial Off-the-Shelf

(COTS) software.

- Descriptions should include name, function, major operating

characteristics, and machine run instructions for using the support

software

- Cite the support software documentation by title, number, and

appropriate sections.

 Document the Database Management System (DBMS) Configuration.

Include:

- The operating system and storage device on which the DBMS is to

be located.

- Identification of the application software

Inputs:

Change Request

DBDD Template

SRS,

OPM Naming

Conventions

Standard,

OPM Enterprise

Architecture

Outputs:

Conceptual

understanding of

requirements

Draft DBDD

Software

Development Lead

Software

Development

Team

(Database

Lead),

Project Team,

IT Security

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 82

Step

Description of Activity

Inputs/Outputs

Lead

Participants

- All related computer programs that run the database

- The amount of online and offline storage required.

- Special hardware or software required to maintain backup copies

or archived files

- Identification of the Database Schema including the names of all

of database related application programs and data files, as well as

the file sizes of each and data record layouts and descriptions.

 For a Change to an existing system, update the database design as

needed

Review the Database Design Description

Conduct a formal review of the DBDD.

Include representatives from:

 Other development and maintenance teams whose programs interface

the units being designed

 The acceptance test team staff if applicable

 User and sponsor organizations

Inputs:

draft DBDD

Updated RTM

Outputs:

Reviewed DBDD

Software

Development Lead

Project Team,

Quality

Assurance (QA)

Team, IT

SecurityTeam,

Other Subject

Matter Experts

(SMEs)

(Database

Lead),

Review DBDD and provide comments

Review the DBDD for approval.

Inputs:

Internally

Approved DBDD

Outputs:

Customer Review

comments and

approval

Technical PM

Business

Program

Manager or

Business

Project

Manager

Deliver the Final DBDD

Incorporate customer comments and deliver the final DBDD to CM to be

baselined.

Inputs:

Customer Review

comments and

approval

Outputs:

Final (baselined)

Technical PM

Software

Development

Lead (Database

Lead),

CM Team

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 83

Step

Description of Activity

Inputs/Outputs

Lead

Participants

DBDD

Expand the Requirements Traceability Matrix (RTM) to reflect the design

units.

Note: Use an automated tool if applicable to update the RTM.

Ensure all requirements have been included in a design unit.

Inputs:

Software design

units,

SDD,

DBDD

baselined RTM

Outputs:

Expanded baselined

RTM

Requirements Team

Software

Development

Lead,

Project Team,

QA Team,

CM Team

10.

Create the System Security Plan (SSP) as directed in the Information

Security and Privacy Policy Web pages located at

http://theo.opm.gov/policies/ispp/

Input:

Applicable security

standards,

SRS

Output:

Understanding of

security standards,

draft SSP

Technical PM

IT Security

Team,

Project Team,

QA Team

11.

Review the SSP and provide comments

Review the SSP for approval.

Inputs:

Customer-ready

SSP

Internally

Approved SSP

Outputs:

Customer Review

comments and

approval

Technical PM

Business

Program

Manager or

Business

Project

Manager, IT

Security Team

12.

Deliver the Final SSP

Incorporate customer comments and deliver the final SSP to CM to be

placed under control.

Inputs:

Customer Review

comments and

approval

Outputs:

Technical PM

IT Security

Team,

CM Team

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 84

Step

Description of Activity

Inputs/Outputs

Lead

Participants

Final (baselined)

SSP

13.

Update Test Plan (Unit & Integration)

 Review test strategy to ensure it coincides with the designs

 Create test identifiers

 Update test execution

 Submit to CM to be version controlled.

Inputs:

Version controlled

Test Plan (Unit &

Integration)

Outputs:

Updated Test Plan

(Unit &

Integration)

Software

Development Lead

Software

Development

Team,

Project Team,

CM Team

14.

Review Training Plan

Provide comments and update the plan as applicable.

Review the Training Plan for approval.

Inputs:

Customer-ready

Training Plan

Outputs:

Customer Review

comments and

approval

Technical PM

Business

Program

Manager or

Business

Project

Manager

15.

Deliver the Training Plan Document

Incorporate customer comments and deliver the final Training Plan to CM

to be baselined.

Inputs:

Customer Review

comments and

approval

Outputs:

Final (baselined)

Training Plan

Project Manager

Training

Manager,

CM Team

16.

Develop Training Material as required.

 Review the Training Plan and SRS

 Develop the applicable training materials that are defined in the

Training Plan and SRS

 Examples of these materials include:

- Lesson Plans

- User Training Guides

- Computer-based Training (CBT)

Inputs:

Training Plan

SRS

Outputs:

Training Materials

Training Team

Project Team

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 85

Step

Description of Activity

Inputs/Outputs

Lead

Participants

- Web-based Training

- Pocket Guides

- System Support Guides

- Training Evaluations

Note: References for some of these training materials are listed in the

OPM SDLC

17.

Develop User Manual

 Review the SRS and the User Requirements Document (URD), as

needed

 Assign User Manual responsibility to Software Development team

member(s)

 Develop User Manual

 Review the SRS

 Refer to the SDD and the DBDD for pertinent information

 Ensure User Manual is consistent with the actual system operation, the

SDD, and the DBDD

 Conduct a formal review of the User Manual

 Approve (baseline) the User Manual

Inputs:

SRS

SDD

DBDD

URD

Outputs:

Approved and

baselined User

Manual

Software

Development Lead

Software

Development

Team

Project Team

18.

SQA audits the process and products

 Refer to the SQA Plan for detailed schedules of the processes and

products.

Inputs:

SQA Plan

Processes and

Procedures for

Design Phase

activities

Outputs:

SQA Audit Reports

SQA Team

Project Team

19.

Update Project Plan

 Track Project Activity

 Update estimates and risks

 Update project schedule

 Project Plan is reviewed and placed under CM control to be version

Inputs:

Project Plan,

WBS Task List,

WBS Task

Description

Outputs:

Technical PM

Project Team

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 86

Step

Description of Activity

Inputs/Outputs

Lead

Participants

controlled.

Version controlled

Project Plan

20.

Project Plan is reviewed and placed under CM control to be version

controlled.

Inputs:

Updated Project

Plan

CM Procedures

Outputs:

Version Controlled

Project Plan

Technical PM

CM Team

21.

Conduct Phase Exit Review

 Notify the project team and extended project team (users, POCs,

support areas) that a Phase Exit Review has been scheduled.

- Require that approvers provide feedback at least one week before

the exit meeting is to be held. (This will allow the Project

manager time to work issues and coordinate action plans prior to

the exit meeting)

- Invite participants to attend the exit meeting using the Phase Exit

Review Memo along with the review material (Project Plan, and

any other material relevant to the exiting stage which include but

are not limited to known issues, and unplanned deliverables)

- The participants should be familiar with planned deliverables since

it is standard procedure for them to review drafts as they are

developed.

 If this is not the case a list of the planned deliverables should

also be distributed at this time.

 Review the current Project Plan (at a minimum, a detailed plan for the

next phase and high-level plans for the remainder of the project).

 Review other relevant materials to verify if they are in accordance

with OPM’s SDLC

 Receive position from the list of approvers (to include the Technical

PM, Business Program Manager or Business Project Manager) using

the Position Response Form. This position can be concur, concur with

Inputs:

Phase Deliverables

produced during

current phase

Initial Project Plan

prior to updates for

next phase

Latest version

controlled Project

Plan

New and existing

issues,

Phase Exit Package

Template

Outputs:

Positions from the

approvers,

Issues/concerns (if

any) from the

review of the

deliverables,

Action plans to

resolve all

Technical PM

Project Team

Business

Program

Manager or

Business

Project

Manager,

QA Team

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 87

Step

Description of Activity

Inputs/Outputs

Lead

Participants

qualifications, or non-concur. The implication of each is as follows:

- Concur – Proceed with the project according to the current plan.

(Ex. The Approver is unaware of any issues for the current phase)

- Concur with qualifications – There are issues or concerns and the

project can proceed according to the current plan if an acceptable

action plan is developed for each issue or concern by the meeting.

(Ex. There is no plan for testing an interface to an existing system

that is being changed)

- Non-concur – There are very significant issues or concerns and the

project should not move to the next phase until those issues or

concerns are resolved. (Ex. Funding for the project has been

withdrawn)

 Prepare acceptable action plan to address each issue or concern

received. (Note: Sometimes action plans extend beyond the Phase

Milestone which is acceptable as long as it will not negatively impact

the current project schedule)

 Conduct Exit Meeting

- Present positions from the Approvers, along with issues and/or

concerns, and any other issues that may be open

- Action plans must be presented for each issue or concern

 Document the meeting including positions, issues, concerns, action

plans, and follow-up activity

 Obtain concurrence on current stage deliverables, and begin the next

phase of development

issues/concerns

Risks,

Phase Exit Package

Appendix D.4: Build System Components Phase Activities

Step

Description of Activity

Inputs/Outputs

Lead

Participants

Verify that the Development and Test environment has been

Inputs:

Software

Project Team,

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 88

Step

Description of Activity

Inputs/Outputs

Lead

Participants

installed properly

 Review the Segment Architecture

 Review the User Requirements Document (URD) and the

Software Requirements Specification (SRS)

 Assemble and install the hardware software,

communications equipment, databases, and other items

required to support the programming and testing effort.

Segment Architecture,

URD,

DS,

SRS

Outputs:

Development and test

environment in place,

Environment configured

appropriately for development

Development Lead

Network Team

Review and/or plan coding and testing activities

 Obtain training on coding and testing methodologies,

techniques and tools.

 Review the Project Plan for schedule of activities and for

any standards or tools that should be used during this phase.

 Verify objects included in the Software Design Description

and Database Design Description have been included in the

schedule and assigned to the appropriate members of the

development team

Inputs:

Project Plan,

Software Design Description,

Database Design Description

Outputs:

Training, Schedule of

activities for coding and

testing

Software

Development Lead

Project Team,

IT Security

Team

Code individual software units and database in the

programming language(s) selected for the project

Note 1: Regardless of the platform, development of code

should adhere to a consistent set of programming techniques

and error prevention procedures. This will promote reliable,

maintainable code, developed in the most efficient and cost

effective manner.

 Review the SDD/DBDD and the SRS

 Analyze reuse opportunities

- Reuse available source code assets found in the

Configuration Management Library (CML)

- Determine if source code requires classification or

security protection

- Reuse available test assets

Inputs:

Change Request, SDD,

DBDD,

SRS,

Project Plan,

Reusable source code assets

Outputs:

Developed units,

Code reviews

Software

Development Lead

Software

Development

Team

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 89

Step

Description of Activity

Inputs/Outputs

Lead

Participants

 Develop code

- If a Computer Aided Software Engineering (CASE) tool

is being used, use the tool to generate code from the

SDD and DBDD

- Generate source code and machine-readable modules.

- Generate the physical files and database structure.

- Generate video screens, report generation codes, and

plotting instructions as applicable.

- If conversion of an existing system or data is necessary,

generate the program(s) described in the Installation &

Conversion Plan (ICP).

 Write code instructions in the selected programming

language that will perform the logic documented in the

SDD/DBDD.

 Add comments into the code at appropriate locations to

provide clarifications of the function and logic being

performed.

 The types of software units and programs include but are

not limited to:

- Utility Programs – edit or sort routines, control of user

access to functions, or error message handling routines

- Input and Output Modules – anticipatory retrieval and

caching of data from the database for output, deferred

storage or data formatting

- Application Programs – performs actual business logic

- Command Language – written in operating system

command language or job control language and that are

used to execute batch jobs, compile programs, execute

programs, and control peripheral devices

 Update the SDD/DBDD to reflect any required deviations

from the documented design.

 For a Change to an existing system, implement the changes

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 90

Step

Description of Activity

Inputs/Outputs

Lead

Participants

as needed

Note 2: The developers should meet at scheduled intervals to

discuss problems encountered and to facilitate program

integration and uniformity

Note 3: Program uniformity should be achieved by using a

standardized set of naming conventions for programs, data

elements, variables, and files.

Note 4: All code should be backed up on a daily basis in the

CM Library. It should be stored in an offsite location to avoid

catastrophic loss if applicable. (See the Project Plan and

Configuration Management Plan (CMP) for code backup

details.)

 Review code

Compile individual code units and correct errors

 Compile the source code with error and syntax checking

 Identify error messages

 Modify the source code to correct the problem

 Recompile the program after the changes have been made

 Recheck the source code

 Repeat the process until no error messages are generated

Inputs:

Developed units,

Code reviews,

Reusable source code assets

Outputs:

Error free compiled code

Software

Development Lead

Software

Development

Team

Inspect and modify code

Note: The inspection team may include experts outside of the

project. Code inspections should be identified as milestones in

the Project Plan.

 Perform a review of code using the coding standards that

are referenced in the project plan

 Evaluate for:

- Traceability to the requirements and design of the

software item

- External consistency with the requirements and design

of the software item

- Test coverage of the units

Inputs:

Error free compiled code

Project Plan,

Outputs:

Reviewed code

Software

Development Lead

Software

Development

Team

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 91

Step

Description of Activity

Inputs/Outputs

Lead

Participants

- Appropriateness of coding methods and standards used

- Feasibility of the software integration, software testing,

operation and maintenance

 Provide feedback to developer of code

 Update code with comments received from code inspections

Expand the Requirements Traceability Matrix (RTM) to reflect

the code units and modules

Note: Use an automated tool if applicable to update the RTM.

Ensure all requirements have been included in a code unit or

module

Inputs:

Coded units and modules,

baselined RTM

Outputs:

Expanded baselined RTM

Requirements Team

Software

Development

Lead,

Project Team,

QA Team,

CM Team

Update/Develop Software Test Procedures in the Test Plan

(Unit & Integration)

 Review Test Plan (Unit & Integration)

 Review SDD, DBDD, and SRS as applicable

 Document a procedure for each unit test to be executed for

the program

 Examples of what each unit test should contain are as

follows:

- Name of the software module to be tested

- Description and objective of the test

- Any test stubs or drivers to be used in executing the test

- Test data to be used in the test

- Job control language to be executed

- Expected results

- Steps to be taken to execute the test

 Review the Test Plan (Unit & Integration)

 Version control software test procedures

Inputs:

SDD,

DBDD,

SRS,

Test Plan (Unit &

Integration),

Test Script Samples

Outputs:

Updated Test Plan (Unit &

Integration)

Software

Development Lead

Software

Development

Team

Execute unit tests and place tested code under configuration

control

 Unit test code

Inputs:

Code,

Test Result & Evaluation

Report Template,

Software

Development Lead

Software

Development

Team,

CM Team

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 92

Step

Description of Activity

Inputs/Outputs

Lead

Participants

 Test each unit and database ensuring it satisfies its

requirements.

 Correct any problems found and unit test code again

 Repeat this process until no problems are found

 Place code (units) under Configuration Management (CM)

control

 Report integration testing results using Test Results &

Evaluation Report Template

 Place Test Results & Evaluation Report Template under

CM control

Updated Test Plan (Unit &

Integration)

Outputs:

CM controlled and Unit tested

code,

Test Results & Evaluation

Report

Define Integration Tests

 Update the TP (Unit & Integration) as necessary

 It should identify the following:

- Each integration test to be executed

- System and program requirements to be tested

- Location of each test in the hierarchy of the testing to be

performed

- Software units and programs that are to be included in

the test

- Required test data, including database fields

- External (or existing) programs needed to support the

test

- Procedure for reporting errors, test results, and

reworking and retesting programs

- External APIs/interfaces

- Expected test results

 Review the Integration Test Procedures

 Approve (baseline) software test procedures

Inputs:

Updated Test Plan (Unit &

Integration)

SDD,

DBDD,

SRS,

Test Script Samples,

Unit tested code

Outputs:

Updated Test Plan (Unit &

Integration)

Software

Development Lead

Software

Development

Team,

CM Team

10.

Integrate software units and components and test as the

aggregates are developed in accordance with the TP (Unit &

Integration)

Inputs:

Test Plan (Unit &

Integration),

Software

Development Lead

Software

Development

Team

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 93

Step

Description of Activity

Inputs/Outputs

Lead

Participants

 Compile the source code with error and syntax checking

 Identify error messages

 Modify the source code to correct the problem

 Recompile the program after the changes have been made

 Recheck the source code

 Repeat the process until no error messages are generated

 Ensure each aggregate satisfies the requirements of the

software item and that the software item is integrated at the

conclusion of the integration activity.

Unit Tested code

Outputs:

Error free compiled code

11.

Inspect and modify code

 Perform a review of code using the coding standards that

are referenced in the project plan

 Provide feedback to the developer of code

 Evaluate the integration with the following criteria in mind:

- Traceability to the system requirements

- External consistency with the system requirements

- Internal consistency

- Test coverage of the requirements of the software item

- Appropriateness of test standards and methods used

- Conformance to expected results

 Update code with comments received from code inspections

Inputs:

Project Plan

Error free Compiled code,

Unit Tested Code

Outputs:

Reviewed code,

Modified code

Software

Development Lead

Software

Development

Team

12.

Execute Integration Tests and place code under CM control

 Create developmental baseline and Build Notification

 Conduct integration testing using the TP (Unit &

Integration).

 Correct any discrepancies and retest code until no

discrepancies are found

 (Optional) Report integration testing results using Test

Results & Evaluation Report Template (some customers

may require a report of the integration testing results)

 Place code under CM control

Inputs:

Make files/Job Control

Language (JCL),

Modified code

Build Notification Template

Test Plan (Unit & Integration)

Test Results & Evaluation

Report Template

Outputs:

Updated Make files/JCL,

Software

Development Lead

Software

Development

Team, CM

Team

OPM System Development Life Cycle Policy and Standards

Version 1.1

April 2013 Page 94

Step

Description of Activity

Inputs/Outputs

Lead

Participants

 Handoff instructions and code to CM for CM build

CM controlled and Integration

Tested Code,

Updated Test Results &

Evaluation Report,

Build Instructions

13.

Perform software build (establish baseline)

 Document the internal build procedures and results in the

Build Instructions

- Identify errors and describe the corrective action that

was taken

 Distribute Build Notification

 Handoff software to Software Test Team

Inputs:

CM controlled and Integration

Tested Code,

Build Instructions,

Make files or JCL used to

control the build

Outputs:

Updated Build Instructions,

Build Notification,

Software Build of code,

Updated make files or JCL

used to control the build

CM Team

Software

Development

Team

14.

Develop Version Description Document (VDD)

 Review FRD, SRS, SDD, DS, DBDD, and SSP, and source

code and related code documentation

 Receive input from Developers

 Draft the VDD plan

Inputs:

FRD,

SRS,

SDD,

DS,

DBDD,

SSP,

Source code,