705-28c Information Technology Systems Development Life Cycle Policy.pdf

ORIGINATING OFFICE

Agency Information Technology Services

EFFECTIVE DATE

June 6, 2025

GPO Directive 705.28C June 6, 2025

Information Technology Systems Development Life Cycle Policy

1. Purpose. This Directive establishes the Government Publishing Office (GPO) System

Development Life Cycle (SDLC) policy for information system activities, in support of GPO programs and projects. This policy shall help assure that proper discipline and industry recognized best practices are used in support of information technology programs and projects at the agency and that major applications and information system initiatives at GPO follow this SDLC process. Recently, with the introduction of new tools and technologies, various newer system development and service delivery models and methodologies have evolved. GPO’s policy is being revised to provide additional guidance relating to the use of new SDLC methods.

2. Scope. The process set forth in this Directive is applicable to authorized persons in all GPO organizations and includes all contractors working on information technology projects on behalf of the GPO. The activities set forth in this document are applicable to any program or project resulting in a GPO information system located at a GPO or externally hosted facility, and meeting any of the following criteria:

a. Introduction of a new technology, a new information system, or a new service.

b. Custom development of a new information system or service.

c. Tailoring, configuration, and integration of an enterprise Commercial Off The Shelf

(COTS)/Government Off The Shelf (GOTS) product.

d. Reengineering of a critical existing system or service within the GPO IT EA.

e. Significant change to an existing system or service that requires alterations of baseline

Configuration Item (CI) code or integration.

3. Authority. This Directive establishes GPO’s System Development Life Cycle policy in compliance with the intent of public laws, Federal Regulations, and GPO policies that provide direction and guidance concerning information technology management and software engineering. In addition, all documentation must comply with GPO’s CM, EA, and

IT Security Policies that bolster and support the processes described in this SDLC Policy.

Further, all software promotions to production shall be coordinated through Configuration

Management guidelines.

4. Cancellation. This Directive supersedes GPO Directive 705.28B, Subject: Information

Technology Systems Development Life Cycle Policy, dated October 22, 2019.

5. Background. The Office of the Chief Information Officer (OCIO) is chartered to provide secure, effective, reliable, and robust Information Technology (IT) services in support of

GPO’s mission. The OCIO provides best-in-class infrastructure, networking and telecommunications; information security; systems development and support services; and

705.28C

06/06/2025 automation of work processes. An SDLC process is a guide that facilitates all system life cycle activities, including capturing business area requirements and delivering, supporting, and retiring the information.

6. Objectives. The objectives of this SDLC process are:

a. Introduce a disciplined approach to facilitate software development and integration processes from initiation and capturing business requirements to implementation under

OCIO’s governance and compliance guidelines as specified under Enterprise

Architecture’s (EA) Architecture Review process, Technical Change Control Board

(TCCB) process, Configuration Management process, and supporting SDLC documentation artifacts.

b. Ensure that sufficient planning has been undertaken before acquisition and/or design and development activities are started.

c. Establish project-level accountability and transparency.

d. Establish appropriate scope of efforts in order to minimize risks and cost overruns.

e. Follow clearly established requirements to meet cost, schedule, and performance baselines.

f. Establish guidelines applicable to traditional and new development methodologies including but not limited to Cloud or Hosting Service, including: Infrastructure as a

Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS), and other no-code, low-code development approaches. For any Cloud or Hosting Service, full life cycle cost must be estimated and evaluated by EA.

g. Choose the most cost and time-effective SDLC process strategy that results in a system solution that is delivered timely and easy to support and sustain.

h. Require execution of programs or projects within the selected SDLC approach and framework of identified phases and tracking to reflect the status of projects at any given time. The SLDC framework ensures that projects are managed and tracked with regular reviews of project status.

i. Monitor and react to variances from established baselines to reduce the risk of cost overruns, schedule delays, and scope creep.

j. Provide support to GPO’s management in approvals of technology initiatives through

TCCB and successful execution through SDLC.

k. Promote an effective way of conducting system development activities that includes meeting all related GPO IT policies and Directives, including IT Security requirements.

a. Enforce the Configuration Management (CM) provided Change Management discipline to ensure all versions of officially released SDLC artifacts promoted to production are maintained in the appropriate CM Repository and/or Code Repository.

7. Policy. System development in the GPO environment is a specific effort to optimize GPO business processes by using hardware, software, people, and procedures. This Directive is intended to establish the requirement for using reasonable engineering objectives and management controls in pursuing information technology solutions in order to ensure required functionality and minimize associated costs and risks. The project team will have the option to choose from the listed SDLC approaches, the most suitable approach and process model for the system or service delivery under consideration. The project team will comply with the TCCB provided Phases and Gates process. In addition, all versions of officially released SDLC artifacts promoted to production are submitted to Configuration

Management to be maintained in the CM Repository. If a project team chooses an SDLC approach not listed in this document, it must provide a waiver request to the CIO along with the justification and associated documentation artifact templates supporting the SDLC approach.

8. SDLC Process. A step-by-step approach a system team follows from the inception to retirement of a system, including the SDLC steps to implement off-the-shelf software as well as maintenance activities while the system is in use.

9. SDLC Phases. This section discusses the overall generic structure of SDLC phases.

These activities also apply to Agile developments.

A phase within the SDLC process is a certain segment of a process, defined by the progress and completion of deliverables, governance reviews, and milestones. However, execution of these phases will vary depending upon the SDLC process model selected. Additionally, documentation to be produced from the effort will vary based on methodology and solution.

Attached to this Directive are industry-practiced standard SDLC approaches along with a list of SDLC artifacts. The models prescribed in this policy currently revolve around the

Waterfall, Agile, and Hybrid SDLC methodologies. Project Teams can choose one of these approaches. In addition, the mandatory documents for each SDLC methodology are also required and are to be provided to CM when the solution is promoted to a production environment. Selection of SDLC artifacts, based upon technical complexity and development approach, should be agreed upon prior to commencement of the project. See

Attachment for appendices providing guidance and sample SDLC artifacts. Agile processes and artifacts will be managed utilizing designated GPO tools.

Regardless of the chosen SDLC development methodology, the TCCB Master Request for

Change (RFC) creation, initial EA Analysis, and the following activities are considered essential and must be executed for each information system Project activity, prior to

Strategic Investment Committee (SIC) Funding Approval:

a. Business Need Analysis. This phase begins when a business need or opportunity is identified. Sponsors and/or their representatives, also called stakeholder(s), develop a candidate fact sheet describing the problem statement and/or perceived opportunity. The candidate fact sheet is presented in the TCCB meeting. Upon TCCB review, the business case is developed for CIO and/or GPO management’s approval.

b. Basic Concept. Project Team and/or Business Area subject matter experts (may include

IT Architectural Advisor) in collaboration with the stakeholders develop a vision document to further explore the scope, feasibility, cost, and utility of the proposed system. A Project Manager is appointed, and a Project Charter is initiated.

c. Planning/Project Definition. During this phase, the Project Manager collaborates with the

Business Unit (BU) to develop a Concept of Operations (CONOPS) document, user requirements, a Project Management Plan (PMP), and if required, an Acquisitions &

Procurement Plan. The CONOPS is baselined, and overall project schedules are established.

d. Functional Requirements. During this phase, the Project Team collaborates with the BU to create a list of functional requirements covering all IT aspects of the information system, including IT Security requirements. The requirements capture activity will depend upon the SDLC process model selected. A Project Plan is then created. As required, technology alternatives analysis is conducted. The changes introduced in this phase may require revision of Business Case, CONOPS, and PMP. If required, a proposed funding document is prepared. Where GPO is considering an off-the-shelf package solution, the Project Team may use the vanilla functionality as the base requirements for the system, and then identify the additional Business Unit requirements to be incorporated into the vanilla requirements.

e. Analysis and Design. The extent and approach of effort in this phase will depend upon the selected SDLC process model. The gathered functional requirements are transformed into detailed specifications called the system design. The Architecture

Review Board (ARB) approves any new required technology. ARB activity generally occurs within TCCB; however, there could be instances where a GPO management decision is sought at an early stage, thus requiring ARB activity to occur outside TCCB.

Operations and Application Support monitor the design and technology selection activities. For COTS products, the required documentation may be supplied by the vendor. Any changes introduced in this phase may require revising the Business Case, CONOPS, and PMP.

f. Development and Testing. This phase encompasses transformation of the system design into a single or multiple modules or a complete in-house developed or COTS customized information system, unit testing, interface validation, placement of the required infrastructure and networking, system testing by the project team testing group which includes IT security testing, and User Acceptance Testing (UAT). Operations and

Application Support monitor the development and test activities.

g. Deployment/Implementation. Configuration Management establishes the production baseline. The production system is delivered to users. The user training is conducted.

The extent of software functionality delivered will depend upon the SDLC process model.

For Major applications at GPO, the system must undergo certification and accreditation activities, which include Security Assessment and Designated Accreditation Authority

(DAA) Sign-Off processes. All other non-major application information systems that are deployed in production on the GPO network are also subject to Security Assessment and DAA Sign-Off process, with the level of effort for that assessment/sign-off process dependent on the amount of functionality delivered. Upon completion of the DAA sign-off process, the system or functionality receives an Authority to Operate (ATO) or an Interim

(Conditional) ATO and is approved and accepted by the users.

h. Support and Operations. This is an ongoing process whereby customer satisfaction, efficiency, and effectiveness are monitored. The system is periodically assessed and maintained to satisfy user and operational requirements. If new requirements are presented, the incremental release development process is initiated. All changes are managed through the TCCB, and all revisions to baseline artifacts are submitted to CM and are maintained in the CM repository.

i. Retirement Disposition Phase. Upon determination that the system is no longer needed, it is removed from the operational environment. The retirement options include the orderly transition to a new system or termination of the system and preservation of the vital information. A post-retirement audit is conducted, and report findings are presented to management. The report includes a way to use feedback for continuous improvement of processes and systems.

Note: Throughout the defined activities – noted in this section and elsewhere – all relevant documentation (Deliverables) pertinent to that activity must be forwarded to CM

(and attached to RFC/baselined), e.g., Requirements, Design docs, Test plan, etc. The same also holds true for all activities, whether a Waterfall, Agile, or hybrid approach is taken.

10. Responsibilities.

a. Business Area Management. Business Area Management plays a key role in providing overall strategic direction for guiding and introducing initiatives that help GPO meet its mission. Business area management activities include, but are not limited to:

(1) Sponsoring new programs that will promote automation, productivity, operational, and economic improvements in the Business Area;

(2) Collaborating with GPO management, IT, and especially the Chief Financial Officer

(CFO) in the Capital Planning Investment Portfolio for funding;

(3) Reviewing and approving program and project charter;

(4) Emphasizing management sponsorship and commitment to a program and project’s success to the organization;

(5) Approving criteria by which program and project success will be measured; and

(6) Serving as owners and Gatekeepers for agency programs and projects and supporting the agency’s long-term goals and vision.

b. Chief Information Officer (CIO). The CIO is the Designated Accreditation Authority, as defined in GPO Directive 825.33E, for all GPO information systems and is responsible for reviewing and issuing management approval to operate these systems. The CIO may delegate this responsibility as warranted. The CIO is responsible for the overall management of IT resources and for establishing specific procedures and methodologies for conducting information system development and ongoing support in the GPO environment.

c. Division Chief, Application Management and Development Division (AMD). Chief, AMD as a Chief Architect, establishes Technology, Applications, and Development Standards;

and monitors and coordinates Technology Implementations via Architecture Review

Board (ARB) process. The TCCB in conjunction with IT, EA and CM Staff, will conduct the Initial and Final Technical Review to evaluate approaches, assess methods and described deliverables, quality, and completeness. These Initial and Final Phase reviews provide an important checkpoint with key stakeholders in the organization. Upon compliance approval, the project is allowed to move to execution with ongoing monitoring of CM deliverables as the effort progresses. CM group is responsible for maintaining and monitoring the official record of SDLC documentation or check-ins to appropriate Agile Repositories, and artifacts that have been promoted to the production environment.

d. IT Stakeholder. The IT stakeholder (individual or group) represents the Business Area requesting the information system solution and conducts the support processes or uses the information system solution to produce a product or service. These stakeholders play a key role in identifying business processes and areas for potential automation (new system) or enhancements (existing system or support process) to meet agency goals. In addition, projects under Stakeholder (Business Area) direction will be required to produce approved artifacts in order to gain TCCB and SIC Approvals.

e. Program Manager. The Program Manager is responsible for managing overall program activities and is appointed by the OCIO. The Program Manager facilitates cross-functional teams that oversee the cost, schedule, performance, status, and success of the program. The Program Manager ensures that project managers are in place as required and ensures that business process dialog occurs between the users and system designers. The Program Manager coordinates any activity with other programs having an impact or relation to the program activity and provides deliverables as specified by the GPO Program Management Office. This includes, but is not limited to:

(1) Setting and managing expectations of the programs and subordinate projects and communicating them to top management of affected business units.

(2) Setting priorities and scope for the program consistent with the direction of the GPO

Agency Leadership via the SIC and TCCB.

(3) Analyzing and making timely decisions on changes proposed by the project team(s).

(4) Working with functional managers to ensure required resources are committed to the project.

(5) Making timely decisions to resolve escalated issues.

(6) Reviewing and approving project work plans and program progress through key milestones.

(7) Taking the initiative to identify and mitigate program issues proactively.

(8) Setting appropriate financial and professional incentives for key roles on the program.

(9) Holding ultimate responsibility for the success of the program.

f. Project Manager or Lead.

(1) Ensures the project request has been submitted to TCCB.

(2) Engages with project team members to oversee in-scope activities performed by the team.

(3) Clarifies any ambiguity with stakeholders or contract resources within project scope or activities.

(4) Specifies, requests, and manages the required resources for the project.

(5) Produces/reviews project work plans and tracks project progress through key milestones in accordance with required SDLC deliverables.

(6) Sets appropriate priorities for key activities and roles in the project.

(7) Directs project activities and makes timely decisions to resolve issues.

(8) Takes initiative to proactively identify and mitigate project risks and, if necessary, obtain assistance from the Program Manager.

(9) Holds ultimate responsibility for ensuring the success of the assigned project and ensuring GPO objectives for the project are met, and all project deliverables are accepted by end users.

g. Office of Inspector General (OIG). The OIG conducts periodic reviews of major GPO IT

Systems and GPO management processes for adherence to GPO Directives and standards related to IT system controls to minimize or eliminate incidents that involve waste, fraud, and abuse.

11. References. Relevant references include, but are not limited to, the E-Government Act of

2002 and Government Paperwork Elimination Act (these two Acts are not binding but recommended by the GAO for conformance by the Legislative Branch.), NIST Standards, the IEEE System and Software Engineering Standards, and other laws, regulations, Directives, and best practices applied to IT project management and system engineering. In addition, it refers to the following GPO Directives, or as amended, and charters:

a. GPO Directive 825.33E, Subject: Information Technology (IT) Security Program

Statement of Policy, dated June 5, 2025.

b. GPO Directive 705.31B, Enterprise Architecture (EA) Policy, dated June 5, 2019.

c. GPO Architecture Review Board Charter.

d. GPO Directive 825.8B, Subject: Information Technology (IT) Configuration Management

(CM) Policy, dated October 2, 2024.

e. GPO Technical Change Control Board Charter.

12. Inquiries. Inquiries regarding this Directive should be directed to the Chief, Application

Management and Development Division on 202-512-2001.

13. Effective Date. Immediately upon issuance.

HUGH NATHANIAL HALPERN

Director

Attachment

705.28C Attachment

Appendices

Control-Click to follow the link:

Appendices (Available in SharePoint – Teamwork>IT Main> Enterprise Architecture> Policy and

Planning > Shared Documents>SDLC Artifacts)

Appendix A – Agile Software Development Guidelines

Appendix B – Agile Phases and Deliverables

Appendix C – Agile List of Documents

Appendix D – Agile Project Vision Document Template

Appendix E – Agile Product Backlog Process Guidelines

Appendix F – Agile Product Roadmap Guidelines

Appendix G – Agile High Level Design Guidelines

Appendix H – Agile Sprint Backlog Planning Guidelines

Appendix I – Agile Release Planning Guidelines

Appendix J – PMP Waterfall Phases and Gates Deliverables https://gpo.sharepoint.com/teams/CIO/GPOEA/Policy/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2Fteams%2FCIO%2FGPOEA%2FPolicy%2FShared%20Documents%2FSDLC%20Artifacts&FolderCTID=0x012000076A18685D9F0744947DFB7B79A89501&View=%7B5AB6E466%2D20BA%2D47B5%2D9F56%2D0282E9A9DA5F%7D https://gpo.sharepoint.com/teams/CIO/GPOEA/Policy/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2Fteams%2FCIO%2FGPOEA%2FPolicy%2FShared%20Documents%2FSDLC%20Artifacts&FolderCTID=0x012000076A18685D9F0744947DFB7B79A89501&View=%7B5AB6E466%2D20BA%2D47B5%2D9F56%2D0282E9A9DA5F%7D https://gpo.sharepoint.com/teams/CIO/GPOEA/Policy/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2Fteams%2FCIO%2FGPOEA%2FPolicy%2FShared%20Documents%2FSDLC%20Artifacts&FolderCTID=0x012000076A18685D9F0744947DFB7B79A89501&View=%7B5AB6E466%2D20BA%2D47B5%2D9F56%2D0282E9A9DA5F%7D