J62A_DAI_SIG_v5.0_signed_2_Redacted.pdf

Defense Logistics Agency (DLA)

J62A Change and Configuration Management

SUPPLEMENTAL IMPLEMENTATION GUIDE (SIG)

for Defense Agencies Initiative (DAI)

Version 4.0

Supplemental Implementation Guide

Page | 2 SIG Template, Version 3.0

The effective date of the Supplemental Implementation Guide (SIG) is the date that all required approval signatures have been obtained as indicated below.

Page | 3

DOCUMENT CHANGE/VERSION CONTROL

Date Reason for Change

Version to be Released

Brief Description

Name of Person Making Change

8/12/15 Initial Document Creation

1.0 Baseline

10/8/15 Update to reflect

KPMG/ECMO

Comments

1.1 Update

1/11/17 Update to address new J62 SIG Template

2.0 Update

02/02/18 Annual Review 3.0 Update 01/28/19 Update to address new J62 SIG Template, date and revision of

CCWG Charter on page 8, Add

16.1.5, Maintenance

Release Types

4.0 Update

Page | 4

Table of Contents Introduction and Purpose Applications Covered by this SIG References Organizational Information Functional Stakeholder Forums/Boards

Requirements Review Board (RRB) Configuration Control Board (CCB)

Contractor Management Configuration/Change Management Tools Information Assurance

Certification and Accreditation Vulnerability Identification, Assessment, and Patch Management Security Logging

Configuration Items (CI) Baselines

9.1.1 Configuration Item Baselines

9.1.2 System Level Baselines

9.1.3 Functional Baseline (FBL)

9.1.4 Allocated Baseline (ABL)

9.1.5 Product Baseline (PBL)

9.1.6 Production Baseline (PB)

Version Control Naming Conventions

9.3.1 Baseline, Release and Release Package Naming Convention CM-Related Documentation and Records Interface Management

Software Development Lifecycle Change Request Process

Submission, Authorization, and Identification Change Request Technical Reviews and Approvals

Emergency Changes System Specifications Testing

Test Planning Test Results

ENVIRONMENTS

Access Approval, Control, and Segregation of Duties (SoD) Library Control

Release Management Types of Releases

16.1.1 Significant System Change

16.1.2 Major Release

16.1.3 Minor Release

16.1.4 Maintenance Release

Page | 5

Incident Management Access and Change Monitoring Post Implementation Change Review CM Validation, Audit, and reporting

ATTACHMENT A – APPLICATION COMPONENTS UNDER CONFIGURATION

CONTROL

Page | 6

TABLE OF TABLES

Table 1: Roles & Responsibilities Table 2: Contractor Support Table 3: Roles & Responsibilities Table 4: Configuration Items Table 5: Document Naming Convention Table 6: RICE-FW Naming Convention Table 7: Key CM Documents and Records Table 8: Systems Engineering Technical Review Summary Table 9: Hosting Environments Table 10: CM Tool User Roles – Request for Change Type = Problem Report (PR) Table 11: Change Management Request Types Table 12: Roles and Responsibilities – Request for Change (Type = PR) Table 13: Maintenance Release Types

TABLE OF FIGURES

Figure 1: Program Office Organizational Structure Figure 2: Governance Structure Figure 3: DAI Global Model (Oracle Application User Interface) Figure 4: Configuration Item Versioning Repository Figure 5: Change Control Lifecycle Management (Sample Request for Change) Figure 6: DAI Global Interface Architecture (SV/SvcV-1) Figure 7: OUM Project Phases Figure 8: Systems Engineering Technical Reviews Figure 9: High Level Production Support and Release Management Process Model Figure 10: Serena Dimensions CM Item Repository

Page | 7

INTRODUCTION AND PURPOSE

The Supplemental Implementation Guide (SIG) is a program-level supplement to the DLA J6 Enterprise Configuration Management Plan (ECMP). The SIG documents the J62 Program’s lower-level Configuration and Change Management (CM) processes, procedures and information that support, but are not defined in the ECMP.

DLA ECMP + SIG = Full CM Plan for a Program

The SIG is an auditable document, and is also required, along with the ECMP, to meet requirements for Certification and Accreditation (C&A). All J62 applications in development and sustainment must be covered by an approved SIG. J62 Program Managers (PMs) may create a SIG for one application or create a SIG that covers multiple applications (e.g., if the CM processes are similar). This document will be stored in the Document Automation and Content Services (DACS)-CM repository.

This SIG will be updated, as needed, to maintain focus on the Program’s updated requirements.

APPLICATIONS COVERED BY THIS SIG

This SIG applies to the Defense Agencies Initiative (DAI) application. The DAI mission is to deliver auditable, accurate, timely, authoritative financial data to support the Department of Defense (DoD) goal of standardizing financial management practices, improving financial decision support, and supporting audit readiness.

Currently, defense agencies use more than 10 different non-compliant financial management systems supporting diverse operational functions and the warfighter in decision making and financial reporting. These disparate, non-integrated systems do not meet Chief Financial Officer Act requirements to produce timely, auditable reports.

DAI program modernizes the defense agencies’ financial management processes by streamlining financial management capabilities, addressing financial reporting material weaknesses, and supporting financial statement auditability for the majority of agencies and field activities across the DoD. DAI will support a transformation of budget, finance, and accounting processes across participating defense agencies to help improve the quality of financial information, supporting financial auditability and decision making. DAI business solution, as implemented, provides a near real-time, web-based system of integrated business processes and enables defense agency financial managers, program managers, auditors, and Defense Finance and Accounting Service (DFAS) representatives to make sound financial business decisions.

REFERENCES

(a) DLA Instruction (DLAI) 8250.01, Enterprise Configuration Management, September 11, 2017

Page | 8

(b) DLA Enterprise Configuration Management Plan (ECMP), version 6.0, July

(c) DLA Change and Configuration Management Standard Operating Procedure (SOP); Non-classified Internet Protocol Router Network (NIPRNet) and Secret Internet Protocol Router Network (SIPRNet), 8250.01-01, November 2018

(d) Configuration Control Steering Group (CCSG) Charter, version 3.0, July 2017

(e) Configuration Control Working Group (CCWG) Charter, version 5.0, November

(f) ECM Acronyms and Glossary

(g) Federal Information System Controls Audit Manual (FISCAM), February 2009

(h) National Institute of Standards and Technology (NIST) Special Publication 800-

53, Security and Privacy Controls for Federal Information Systems and Organizations, August 2017

ORGANIZATIONAL INFORMATION

The DAI program is managed by the DAI Program Management Office (PMO) as organized below.

Figure 1: Program Office Organizational Structure

DAI Program Management Office (PMO) organizational roles identified in the table below define the specific responsibility and authority for CM and categorize the

Page | 9 relationships and integration of CM within and between organizations, for appropriate

CM.

Specific goals and responsibilities of the DAI CM process are identified as follows:

Ensure all CM activities are planned Establish and maintain DAI baselines of identified work products Ensure all configuration items are identified, controlled and made available to appropriate personnel Track and control changes to the work products under configuration management Maintain integrity of the baselines Ensure fulfillment of the DAI capabilities defined by the Office of the Under

Secretary of Defense – Comptroller (OUSD(C)) Establish and maintain a historical reference for the overall DAI design, system components and associated work products Reduce program risks that may compromise the attainment of project integrity.

DAI PMO Team Responsibilities

Program Manager

(PM)

Responsible and accountable for oversight of DAI throughout the lifecycle to include cost, schedule, and performance.

Responsible for compliance with this CM policy, its review processes, and documentation requirements for DAI Program initiatives.

Deputy Program Manager (DPM)

Responsible and accountable for the daily organizational and acquisition activities associated with the entire program throughout the lifecycle.

Responsible and accountable to accomplish PM duties in the event of PM absence.

Advises the PM on all issues relating to entire program.

Configuration Management

Coordinates and facilitates CM Activities Administers the CM Tool Suite and manages changes to the database library Maintains CM processes, configuration item (CI) version management, Change Request management, baseline management, and release management activities

Audits and Publishes Configuration Status Accounting Reports Performs Configuration Audits and Verifications of Baseline

Release activity

Solution Strategy Applies broad knowledge of all modules of Oracle EBS. This knowledge allows for the review of proposed solutions and impacts to determine the best possible solution to implement requirements within core COTS functionality

Helpdesk Manages service requests and incidents related to DAI and submitted by Agency Tier 1 helpdesk users

Resolves Tier 2/3 operational issues

Page | 10

DAI PMO Team Responsibilities

Defines solutions for problems.

Manages the knowledge management database

Product Support Assesses all proposed change requests documented in the CM library

Refines functional requirements with customers for COTS and

RICEFW

Documents the functional design for Sustainment Documents and maintains the configurations for Sustainment Performs development integration testing, and test validation for

Sustainment.

Development Documents the functional design Documents and maintains the EBS configurations Performs functional unit testing Develops the technical requirement to support the functional requirement for RICEFW objects Performs unit and development integration testing.

Infrastructure Performs migrations of release packages within the Development, Test and Production environments.

Performs assessment of EBS patches provided by Oracle and applies patches to Test & Development environments

Creates new instances at the direction of the Systems Engineer Performs backups of Production to support the cloning of instances

Program Protection

Conducts security analyses and reviews all Test and Development application access requests and validates cybersecurity posture for all proposed changes to Production environment to ensure that new development and changes to existing systems do not introduce vulnerabilities to the Production environment.

Advises the PMO on all areas relating to Information Assurance/Cybersecurity, e.g., Mission Assurance, compliance with Federal Information Security Management Act, Personally Identifiable Information, and Health Insurance Portability and Accountability Act.

Systems Engineer

(SE)

Provides consultation on business process design, database administration functions for project implementation teams, maintenance & enhancement teams, and training teams

Ensures application software/hardware is consistent with technical environment & standards

Designs the architecture and support hardware / software components required by system implementation (servers, network printers, operating system, databases, user security, and network connectivity).

Page | 11

DAI PMO Team Responsibilities

Agency Support

Provides overall program administration functions on behalf of the deploying Agencies inclusive of responding to data calls, administrative support, establishing and maintaining agreements with interfacing systems, and defining resource/funding requirements to support and sustain the system.

Support internal/external audit functions.

Develops and maintains DAI training materials and user guides Provides for Classroom Train the Trainer Events and Online training

Testing Responsible and accountable for all test documents and test oversight. Serves in an advisory role to the PM and DPM for any items pertaining to test and operational evaluation.

Develop & execute comprehensive System Test Plans, Scenarios and Scripts

Facilitates testing across multiple process teams Ensures all functional requirements and specifications are met and testable.

Table 1: Roles & Responsibilities

FUNCTIONAL STAKEHOLDER FORUMS/BOARDS

This section of the document describes any forums for the DAI Program to discuss system requirements, development priorities, and resource requirements with functional stakeholders.

Requirements Review Board (RRB)

The primary mission of the DAI RRB is to provide oversight of recommended changes to the DAI financial management system in the form of prioritized requirements and implementation guidance to the DAI Program Manager (PM) to meet the needs of DAI stakeholders. The DAI RRB ensures that all DAI proposed enhancements or changes initiated by the functional sponsor, stakeholder community, and the DAI Program Management Office (PMO) are validated and dispositioned for approval prior to solution scoping. The RRB Board composition is as follows:

Chairperson: DAI Functional Sponsor – Office of the Undersecretary of Defense (Comptroller)

Facilitator: DAI Program Manager Participants: Representatives from each Agency and DFAS (Defense Finance and Accounting Service).

Page | 12

Configuration Control Board (CCB)

The mission of the DAI CCB is to ensure that proposed requirements are adequately defined, dispositioned, prioritized and release planned to maintain an effective enterprise financial management system.

The diagram in Figure 2 depicts the DAI Governance structure and shows the relationship of the DAI RRB and CCB to this structure. Detailed information on RRB functions, governance, Board composition, and member responsibilities is outlined in the Requirements Management Plan. Detailed information on CCB functions, governance, Board composition, and member responsibilities is outlined in the DAI CCB Charter.

Figure 2: Governance Structure

CONTRACTOR MANAGEMENT

The DAI CCWG achieves the primary goal of the configuration management process by ensuring that standardized methods and procedures are used by PMO’s government and contractor staff for efficient and prompt handling of all changes in order to minimize the impact of change-related incidents upon service quality and consequently improve the day-to-day operations of the organization through the lifetime of the working group.

Contractor Name Contractor Role(s)

Program Support Services, Acquisition, Cybersecurity, Internal Audit, Financial Management, Cost Modeling, Earned Value Management, Internal Review, and Development testing

Page | 13

Contractor Name Contractor Role(s) Development A2R, CA, T&L, Compliance, Infrastructure, Implementation Support and Product Support (Sustainment)

Development P2P, O2C, B2R & CAD

Help Desk Support

Interface Management

Table 2: Contractor Support

CONFIGURATION/CHANGE MANAGEMENT TOOLS

The DAI program utilizes various Serena tools to support configuration and change management efforts. Serena Dimensions CM is the application’s approved Configuration Management tool. The table below identifies the tools used by the DAI project and their role capacity in support of configuration and change management.

Tool Name Role of Tool Hosting Location and Version Number (optional)

DACS-CM

Repository for enterprise CM documents to include CCWG Charter and CCWG meeting minutes

DLA

SharePoint Online

(SPO)

Repository used for CM documents DLA

Serena Dimensions

RM

Development & Test (Requirements Management) DISA

Serena Dimensions

CM

Software Change Management Release, Change and Configuration Management Application

DISA

Serena Business Manager (SBM)

Workflow Application & Help Desk Support DISA

Attachmate Reflection Secure IT File Transfer v7.2

Table 3: Roles & Responsibilities

Page | 14

INFORMATION ASSURANCE

Certification and Accreditation

The DAI application is hosted at the DISA Data Center Ogden and Columbus. Physical security considerations to include network infrastructure and hardware operation system will be supported by the hosting service provider (DISA Data Center), whereas the application and database security will be provided by the DAI PMO Cybersecurity team that follows the Risk Management Framework (RMF) Assessment and Authorization (A&A) process. The RMF manages the life-cycle cybersecurity risk to DoD IT in accordance with National Institute of Standards and Technology Special Publication 800-53A, “Guide for Assessing the Security Controls in Federal Information Systems and Organizations: Building Effective Security Assessment Plans,” June 2010, as amended and DoD Directive 8000.01, “Management of the Department of Defense Information Enterprise (DoD IE),” March 17, 2016.

The status of DAI’s Authority to Operate (ATO) is based on our application and not as part of an enclave. Our ATO expires 21 August 2019 and the ATO documentation is stored and maintained in the Enterprise Mission Assurance Support Service (eMASS) system.

User access to DAI for DoD agency users will be Common Access Card (CAC) enabled and browser based via the Non-classified Internet Protocol Router Network (NIPRNet).

DAI production environment resides in DISA Ogden, Utah and the development, Continuity of Operations Plan/Disaster Recovery (COOP/DR), and test environments are in DISA Data Center Columbus, Ohio.

The DAI application’s system-level technical certification requirements are defined in DAI Systems Engineering Plan.

Vulnerability Identification, Assessment, and Patch Management

DAI Cybersecurity is responsible for conducting security impact analyses. As a voting member of the DAI CCWG, the IA lead reviews Test and Development application access requests and validates Cybersecurity posture for all proposed changes to Production to ensure that new development and changes to existing systems do not lead to decreased data security. DAI Cybersecurity procedures include a security analysis of changes in a separate test environment before implementation into the production environment, which consists of evaluating security impacts due to flaws, weaknesses, incompatibility or intentional malice.

The DAI PMO in collaboration and partnership with DISA Data Center (Ogden and Columbus) perform ongoing vulnerability assessment on the DAI application on a monthly basis using the Assured Compliance Assessment Solution (ACAS) tool. ACAS identifies potential vulnerabilities by automated network vulnerability scanning, configuration assessment, application vulnerability scanning, device configuration assessment, and network discovery. The responsibility to update the ACAS assessment tool with the latest signatures and patches belongs to DISA and the National Security Agency (NSA).

Page | 15

The primary mechanism for the release of fixes for security vulnerabilities in DAI Oracle product is the quarterly Critical Patch Update (CPU) program. CPUs are released on dates announced a year in advance and published on the CPU and Security Alerts page.

The patches address significant security vulnerabilities and include prerequisite code fixes to security fixes. CPUs are available to customers with valid support contracts.

CPUs are released quarterly on the Tuesday closest to the 17th day of the month.

Critical Patch Update, security fixes for Java SE are released under the normal Critical Patch Update schedule. A pre-release announcement will be published on the Thursday preceding each Critical Patch Update release. Once the Patches are implemented they are tested by DISA to verify that the patches were properly installed and the IAs assess if the patches resulted in any negative effects to security posture.

DAI’s vulnerability scans are conduct by the DISA Data Center, DISA JITC and DLA Computer Emergency Response Team (CERT). DISA Data Center conducts monthly ACAS vulnerability scans. DISA JITC conducts the Cooperative Vulnerability and Penetration Assessment (CVPA) annually, conducts Red Team Coordination (Adversarial Assessment) annually, and conducts Cybersecurity Economic Vulnerability Assessment (CEVA) work stream one and two annually. DLA CERT conducts application scans annually and when there is a major release.

The DAI PMO Cybersecurity conducts security analyses and reviews all Test and Development application access requests and validates cybersecurity posture for all proposed changes to Production environment to ensure that new development and changes to existing systems do not introduce vulnerabilities to the Production environment. The DAI PMO Cybersecurity performs security analysis as needed and document all analyses and reviews in Serena CM, the DAI’s Configuration Management tool.

Security Logging

The DAI PMO and DISA share audit logging responsibilities for the DAI application. The DAI PMO is responsible for all application related logs including database, DAI application, and web logs. DISA is responsible for all server, OS, network, and firewall logs. The DAI PMO implements audit logging in accordance with the DLA Auditing Implementation Guide, January 19 2018, and DISA Security Technical Implementation Guides.

DAI Production audit currently consists of Oracle database audit logs. This will be expanded to include other services such as Apache, DAI application, and WebLogic when the capability exists for log transfer to the DLA ArcSight audit reduction and reporting tool. The audit data, including the SQL statement, is stored in the database for a period of 30 days. It is then exported to the Network Attached Storage (NAS) and stored over a period of 13 months. The data is then purged from the database. The audit data is also copied to the DLA ArcSight tool in near real time. The DLA ArcSight tool allows pre-configured and ad-hoc audit searches to support discovery of anomalous and security related events. The DAI production database administrators are responsible to support audit configuration changes based on DLA requirements or incident response support.

Page | 16

The DAI PMO Cybersecurity Team is responsible for conducting weekly audit log reviews using the ArcSight audit log reduction and reporting tool. These audit log reviews are documented using the DLA Audit Log Evaluation Checklist. The checklist is then loaded to the Document Automation Content Services, Records Management system (DACS-RM) to comply with audit log review evidential matter requirements.

Anomalous events are recorded in the Audit Log Evaluation Checklist and reported to the DAI DBA Production Support Team for technical analysis and the DAI Information System Secuirty Manager (ISSM) for possible elevation to incident status. Formally declared incidents are reported to the DLA CERT for action and coordination with DISA.

CONFIGURATION ITEMS (CI)

CI identification within the DAI CM program focuses on identifying those work products and configuration objects that are critical to the design or operation of the system, and are subject to change during the system lifecycle. It includes various activities, such as identification of CIs, naming of CIs, and describing the physical and functional characteristics of CIs. Considerations include the categories of CIs, the methods used to store CI information, and the times at which specific CIs will be placed under CM.

application specific CIs are physically placed under CM control in the application’s approved CM repository Serena Dimensions CM, to allow for proper security, storage, retrieval, and reproduction of the CI. CIs are listed below in Table 4 Configurations.

CIs physically placed under CM control in Serena Dimensions CM, the application’s approved item repository for proper security, storage, retrieval, and reproduction of the

CI.

Assign unique identifiers to project requirements’ statements, design elements, software and test integration hardware components, system documentation, all process assets, and other deliverable system artifacts.

Store the CI and supporting documentation describing the CI’s configuration in the projects’ process-driven CM System, Dimensions CM.

Specify relationships between Change Requests and the affected CIs within the process-driven CM System, Serena Dimensions CM.

Provide a Version Description Document (VDD), which is documentation that describes the contents of the released deliverable or package.

DAI CI identification activities result in approved configuration documentation, establishment of baselines for configuration control, creation of records in a status accounting database, and documentation to support configuration item verification and audit.

DAI CI Type Example Oracle Design Documentation

Configuration Guide FS – Application Extensions Functional Specification Design for RICEFW objects TS – Application Extensions Technical Specification Design for RICEFW objects

RICEFW Source Code for Reports, Interfaces, Conversions, Extensions, Forms, Workflows

Page | 17

DAI CI Type Example Datafix Datafix Scripts

Patches Patch Checklists

Design Documentation

High Level Release Management Workflow and process descriptions, CM Process Flows and descriptions, Lifecycle Charts, Training Materials, User Guides

SE Documentation SOPs, Checklists, Hardware Configurations

PMO Documentation Acquisition Documentation, Program Briefings, SOPs

Table 4: Configuration Items

Baselines

The DAI CCWG is established to manage the process of change to the technical baseline of the DAI application, while maintaining integrity of product CIs as they evolve through their lifecycle. The CCWG is empowered to manage only those CIs which pertain to their system/application or infrastructure area of responsibility. CIs with cross-system impact, and/or cross-infrastructure impact, are managed in accordance with enterprise Configuration Control Steering Group (CCSG) coordination. DAI Baselines provide reference points that define the configuration for each critical component of system configuration. Configuration baselines are established for individual components, such as an interface or source code file, and for groups of components, such as the set of components that define a specific system release. Functional requirements, design specifications, source code files, system configuration settings, and user documentation that have been allocated to a unique identifier are examples of System Level baseline components that define a formal release of the system.

Baselines also document the orderly development of the system from initial performance specifications through detailed design documentation and finally to the actual production system software components. In the case of a system level baseline, many CIs may be identified as components of the baseline, and the baseline may be identified as a unique release or version of the system. The levels, types, and timing of the DAI application baselines are discussed in the following sections.

9.1.1 Configuration Item Baselines

A baseline for a CI is normally a document, or a set of documents, that fully define the characteristics of the CI and at a specific point in time during the CI life cycle. In some cases, such as source code files, the baseline may include an archived instance of the CI. Specifications, drawings, naming conventions, version identification, physical markings, and other methods are used to establish and define the unique characteristics of a baselined item. These documents and archives are formally designated using defined naming conventions.

Baselining DAI CIs is the act of placing a work product, or set of work products, under configuration control such that all changes are made through a defined and managed change control process. This involves assembling the necessary documentation to describe the CI and subsequent processing in accordance with the approval procedures established in the CCWG charter.

Page | 18

Initial CI baselines are established at the time a specific type of CI is inducted into formal configuration control. This event occurs at different times during system definition, development, deployment, and support. This logical progression in the level of configuration control is dependent upon the type of item and the level of system maturity.

9.1.2 System Level Baselines

The DAI application’s baseline was established in October 2008. System level baselines ensure effective management of future deployments and program execution.

System level baselines are composed functional requirements, CI baselines (design specifications, source code files and the associated executable code, build files), and user documentation and assigned a unique identifier that defines a formal release or version of the production system. Additionally, multiple baselines are used to define an evolving product during its development cycle. The DAI Program will use a method of identifying system level baselines that is based on the differences between system-level requirements identification, functional specifications, and the as-built product design specifications. These baselines are identified as the Functional, Requirements, Allocated, Product and Production baselines.

9.1.3 Functional Baseline (FBL)

The application baseline of DAI has been established by its imperative to rely on COTS functionality of the selected software, Oracle e-Business Suite, minimized customization, and focused on core functionality established by the DAI application’s scope. The DAI application implementation has required the development of custom code for RICEFW to provide the suite of full financial capabilities to Deployed Agencies. The outcome of this design is the creation of the “Global Model” as illustrated in Figure 3.

Figure 3: DAI Global Model (Oracle Application User Interface)

Budget to Report (B2R)

• Enter funds from Treasury

• Allocate funds to organizations

• Update general ledger

• Revolving Fund Acctg

• DWCF

Order to Cash (O2C)

• Set up agreements

• Collect cost & calculate bill

• Billing & collection

• Update general ledger

• Revolving Fund Accounting

• Revenue Accrual & Accounting

• DWCF

Procure to Pay (P2P)

• Create commitment

• Create obligation

• Perform receipt & acceptance

• Update general ledger

• P2P efficiencies

• Revolving Fund Acctg

• Treasury Direct Disbursing

• DWCF

Acquire to Retire (A2R)

• Define asset

• Determine in service date

• Update general ledger

• Update reports

• Retirement of asset

• CIP Reporting

• Determine depreciation

• Operating Material & Supplies

(OM&S) Accounting

• WIP Reporting

Cost Management (CM) (Cost Accounting)

• Collection of all costs such as: Activity Based Cost, Job Order

Number, Process costs and Standard costs

• Allocation of indirect costs

• Update general ledger

• Revolving Fund Acctg

• DWCF

Hire to Retire (H2R) (Time & Labor)

• Automated individual or timekeeper input into system

• Time allocation for Cost Accounting purposes

• Automatic generation of time cards

• Automated Absence Management

Proposal to Reward (P2R) (Grants Financial Management

Accounting)

• Apportion & allotment funding

• Track & close grant

• Oversight & reporting

Budget Formulation (additional B2R process capabilities)

• Develop budget for out year and

POM

• Support forecasting, & “what if” scenarios

• Support standard rates development

• Generate required documents

Re-Sale Accounting (DeCA Unique)

• Re-sale Accounting (Perform accounting for DeCA inventory & any other Agencies that have inventory for sale)

Legend:

• Inc 1 capabilities

• Inc 2 capabilities

• Inc 3 capabilities Updated 10 Jul 2018

Governance, Risk & Compliance

(GRC)

• Manage risk

• Manage Controls: access, SOD, transactional, & preventative

• Reporting

Initial General Fund Capability

Telecom

Working Capital of Revolving Funds

Budget Formulation

General Fund Accounting

Defense Working

Capital Fund

(DWCF)

Accounting Capabilities

Page | 19

The Global Model defines the functional baseline as established and described in the DAI Capability Development Document (CDD) dated September 2010. The Global Model design is governed by the CCB and documented in a series of functional and technical documents under the control of the DAI PMO CM Team. While the DAI application’s functional baseline would not deviate from the Global Model, the process for functional baseline changes is two-fold. Being the DAI application is a COTS implementation, configuration changes occur via patches, system updates and release of updated RICEFW objects. The CM Team packages the patch, system, and RICEFW object updates, the Infrastructure Team deploys the package, and the Enterprise Solution (ES) Team applies configuration changes to each Oracle instance.

9.1.4 Allocated Baseline (ABL)

The ABL is defined as the initially approved documentation describing an item’s functionality, interoperability, and interfacing characteristics that are allocated from those of a system or a higher level configuration item, interface requirements, additional design constraints, and the verification required to demonstrate the achievement of those specified characteristics.

The Allocated Baseline CIs will be stored in the Dimensions CM repository.

9.1.5 Product Baseline (PBL)

The PBL is defined as the initially approved documentation describing all of the necessary functional and physical characteristics of the system. For maintenance releases (monthly, data fix and emergency) it is established at the CCWG. For major releases (annual, major) it is established at the Test Readiness Review (TRR) once a CM verification of the baseline contents has been successfully completed. A PBL may be subsequently subject to a Functional Configuration Audit (FCA) and/or Physical Configuration Audit (PCA) per audit process specifications. It includes the CIs and the selected functional and physical characteristics designated for production acceptance testing and tests necessary for support of the CI.

9.1.6 Production Baseline (PB)

A Production baseline (PB) is established upon successful completion of the test phase, specifically in support of the Production Readiness Review (PRR). A PB may be subsequently subject to a Functional Configuration Audit (FCA) and/or Physical Configuration Audit (PCA) per audit process specifications. The PB baseline includes the configured Oracle system, custom source code developed in accordance with technical design specifications, configured bolt-on applications, the culmination of the data conversion activities including migration of existing agency legacy system data to the system, training documentation, interface configurations, and other configuration items that are critical to the operation or security of the production system.

Version Control

Version control is applied to all documents and code, including the application’s operating system and supporting software, hardware, and any other infrastructure components resident in the Serena Dimensions CM repository. Control is accomplished through the activities of the application’s CCWG or CCB.

Page | 20

Serena Dimensions CM manages the system development processes defined by DAI PMO by integrating and automating Process Management, Version Control, Change Management, Baseline Management, and Release Management activities.

Figure 4: Configuration Item Versioning Repository

Configuration control is implemented within an integrated CM environment, which will provide collaborative testing, tracking, version control, and documentation. Control functions and processes outlined below identify, control, audit, and account for all configurable items within the CM tool.

Version management is the process of storing and tracking changes to application components over time. In Serena Dimensions CM, versions are managed by the authorizing Change requests and organized by parallel development work areas or projects that indicate the type of release activity, whether major or incremental. Within each project, the CM application automatically assigns a new version number each time a CI is checked out for modification in response to an approved Request for Change.

Page | 21

Figure 5: Change Control Lifecycle Management (Sample Request for Change)

Page | 22

Naming Conventions

DAI CI identification activities result in approved configuration documentation, establishment of baselines for configuration control, creation of records in a status accounting database, and documentation to support configuration verification and audit.

The naming convention will identify the type of document (Functional Specifications, Technical Specifications, Configuration Guides, and Conversion Templates) and Object ID number: Document Type + ID Object Number.

The convention standard for RICE-FW document types is provided below.

Document Type Convention Standard Functional Specification (formerly MD50) FS Technical Specification (formerly MD70) TS Conversion Template CV Configuration Guide CFG

Table 5: Document Naming Convention

For RICE-FW, the Object Number ID is unique to each capability and is enforced by the Integrated Master Schedule (IMS) and audited by the FCA and PCA for compliance. A sample is provided below:

Capability Area Object Object Number

ID Object Number

1002-Report BR RPT 0003 BR-RPT-0003-1002

1099-Reporting PP RPT 0001 PP-RPT-0001-1099 Reporting

Accelerated Payments

(FPDS)

PP EXT 0002 PP-EXT-0002-Accelerated Payments (FPDS)

Account Generator CA EXT 0019 CA-EXT-0019-Account Generator

Table 6: RICE-FW Naming Convention

9.3.1 Baseline, Release and Release Package Naming Convention The baselines, releases, and release packages (RPG) will follow the same naming convention. The baselines, releases, and RPG name will include the RPG number, the release number, the type of release and whether it is configuration or a code change.

<RPG_###>_<Release number>_<code or configuration>

R12_RPG_475_REL4.0.3.10_FIREWALL

R12_RPG_470_REL4.0.3.3_RICE_FW

Page | 23

CM-Related Documentation and Records

DAI PMO maintains key CM-related documentation and records in Program approved storage locations identified in Table 7 below.

CM-Related Documentation or Record Name

Documentation or Record Storage Location

CCWG Charter, Application SIG DACS-CM

CCWG Meeting Agenda DACS-CM

CCWG Meeting Minutes DACS-CM

Change Request Records (e.g., RFCs) Serena Dimensions CM

Customer Requirements (Functional) Serena Dimensions RM

Solution Specifications (Technical) Serena Dimensions CM

Test Plans, Test Results, Defect Resolution Serena Dimensions CM and HPQC

Table 7: Key CM Documents and Records

Interface Management

As required by the solution, DAI exchanges information with various third party business applications in multiple formats as required by these applications. Legacy systems, feeder systems, target systems, and Commercial Off-the-Shelf (COTS) solutions will exchange data with the DAI through the Defense Automatic Addressing System (DAAS) and an Application Program Interface. The basic flow of data and information from business area applications through the DAI is demonstrated in Figure 6 below, the DAI Systems Interface Description (SV/SvcV-1). The SV/SvcV-1 addresses the composition and interaction of Systems and links together the operational and systems architecture models by depicting how Resources are structured and interact to realize the logical architecture.

Page | 24

Figure 6: DAI Global Interface Architecture (SV/SvcV-1)

SOFTWARE DEVELOPMENT LIFECYCLE

Software Release Methodology used by the DAI Program is a fusion of the Oracle® Unified Method (OUM), which is Oracle’s standards-based method that enables the entire Enterprise Information Technology (IT) lifecycle and the DoD 5000.75/5000.02.

OUM leverages one of the de facto industry standards, Unified Software Development Process (UP). UP is an iterative and incremental approach to developing and implementing software systems.

Page | 25

Figure 7: OUM Project Phases

1. BUSINESS REQUIREMENTS [RD] – Objective of the Business Requirements process is to identify, refine, and prioritize the business requirements for the proposed system

2. REQUIREMENTS ANALYSIS [RA] – Objective of the Requirements Analysis process is to further analyze the requirements identified during the Business Requirements process as the basis for analysis and design.

3. ANALYSIS [AN] – Objective of the Analysis process is to analyze, refine, and structure the system requirements via the Analysis Model.

4. DESIGN [DS] – Objective of the Design process is to translate requirements into a system design that meets all functional and supplemental requirements.

5. IMPLEMENTATION [IM] – Objective of the Implementation process is to develop the final system, through a number of iterative steps.

6. TESTING [TE] – The Testing process is an integrated approach to testing the quality and conformance of all elements of the new system.

7. PERFORMANCE MANAGEMENT [PT] – Objective of the Performance Management process is to define, construct, and execute an effective approach to managing performance throughout the project life cycle.

Page | 26

8. TECHNICAL ARCHITECTURE [TA] – Objective of the Technical Architecture process is to design an information system architecture that realizes the business vision.

9. DATA ACQUISITION AND CONVERSION [CV] – Objective of the Data Acquisition and Conversion process is to convert all legacy data necessary for the operation of the new system.

10. DOCUMENTATION [DO] – Objective of the Documentation process is to develop documentation that augments product manuals with information about custom software and business procedures.

11. ORGANIZATIONAL CHANGE MANAGEMENT [OCM] – Objective of the Organizational Change Management process is to identify the human and organizational challenges of the project in order to mitigate risk.

12. TRAINING [TR] – Objective of the Training process is to adequately train the project team to begin the project and train the users to run the new system.

13. TRANSITION [TS] – Objective of the Transition process is to install the system and go production.

14. OPERATIONS AND SUPPORT [PS] – Objective of the Operations and Support process is to monitor and respond to system problems to fix errors and performance problems and plan enhancements.

The DAI Program applies this recommended methodology for both sustainment and major application development, to the existing DoD framework for systems development under the DoD 5000.02 and DoD 5000.75.

Figure 8: Systems Engineering Technical Reviews

As part of Category 1 Priority Defense Business System, DAI system engineering modeling, verification and integration processes are enforced through technical reviews, which are the primary means of assessing the program’s technical progress. DAI technical reviews are planned and communicated well in advance of when the reviews

Page | 27 are scheduled to occur, to ensure the program can support the establishment of high-quality baselines. The table below identifies each review and provides a summary of each review's occurrence timing, purpose, and the party responsible for conducting the review and to whom the review results are reported.

DoD 5000.75

OUM When Occurs

Summary Description Conducted by / Reported to

SRR Inception Business

After completion of Requirements Definition;

Prior to PDR (see below)

The System Requirements Review (SRR) is a multi-disciplined technical review to ensure that the system under review is ready to proceed with the initial design. This review assesses whether the system requirements as captured in the system performance specification:

• Are defined and consistent with cost, schedule, risk, technology readiness and other system constraints.

• Are consistent with DAI Business Case.

• Adequately consider the maturity of interdependent systems.

DAI

Requirements and SE Teams/ Milestone Decision Authority

(MDA)

PDR/Technic al Workshop

Elaboration

At completion of Preliminary Design

The Preliminary Design Review (PDR) is a multi-disciplined product and process assessment that ensures a system under review can proceed into detailed design and can meet the stated performance requirements within cost, schedule, risk, and other system constraints.

It assesses the system preliminary design as captured in performance specifications for each configuration item in the system (allocated baseline).

It also ensures each function in the functional baseline is allocated to one or more system configuration items (which may consist of hardware and/or software elements). DAI made a decision to execute PDRs as a separate event (it will be delivered as a series of

DAI

Development and SE Teams/

MDA

Page | 28

DoD 5000.75

OUM When Occurs

Summary Description Conducted by / Reported to workshops with the user community).

CDR Construction

Detailed Design Completed

The Critical Design Review (CDR) is a multi-disciplined product and process assessment to ensure that the system final design under review can proceed into software coding, demonstration and test and can meet the stated performance requirements within cost, schedule, risk and other system constraints. CDR shall be conducted for release to ensure that the system has a reasonable expectation of satisfying the requirements of the system performance specification. It focuses on the following functions:

• To assess the system final design as captured in product specifications for each configuration item in the system (product baseline), and ensure that each product in the initial product baseline has been captured in the detailed design documentation.

• To ensure that the “detailed design" contains a Technical Data Package of hardware and software specifications that can meet functional and performance requirements.

• To ensure that the design has been satisfactorily audited by production, verification, operations, and other specialty engineering organizations.

• To verify that the final design fulfills the specifications established at PDR.

DAI

Development and SE Teams/

Page | 29

DoD 5000.75

OUM When Occurs

Summary Description Conducted by / Reported to

TRR Construction Prior to Increment Development, Testing and Evaluation

(DT&E)

A Test Readiness Review (TRR) is a multi-disciplined technical review designed to ensure that the system under review is ready to proceed into formal testing. It assesses test objectives, methods, procedures, and scope, and confirms that required resources have been properly identified and coordinated to support planned tests. It also verifies the traceability of planned tests to program requirements and user needs. Two TRRs are executed for each release:

• Prior to the System Integration Test (SIT)

• Prior to the User Acceptance Test (UAT)

DAI

Development Testing and SE Teams/

MDA

FCA Transition After completion of CDR and

DT&E

A Functional Configuration Audit (FCA) consists of a multi-disciplinary examination of the tested characteristics of the Configuration Items that constitute the solution, to validate that the actual performance complies with the design requirements.

DAI

Configuration Management Team/

MDA

PRR Transition Prior to Increment Production Deployment and Operational Testing (Limited Fielding)

The Production Readiness Review (PRR) reviews the DAI Program to determine if the solution is ready for production and if the program has accomplished adequate software migration planning without incurring unacceptable risks that will breach thresholds of schedule, performance, cost, or other established criteria. It evaluates the full, production-configured DAI system to determine if it correctly and completely implements all system requirements. PRR determines whether the traceability of final system requirements to the final

DAI Enterprise Solutions, Testing and SE Teams /

Page | 30

DoD 5000.75

OUM When Occurs

Summary Description Conducted by / Reported to production system is maintained. It also confirms a successful completion of UAT, verifying that expectations set were satisfactorily met.

PCA Production After completion of PRR (and configuration items already in production)

The Physical Configuration Audit (PCA) is intended to examine the actual configuration of the system to verify that the related design documentation matches the system as specified.

DAI

Configuration Management Team

Table 8: Systems Engineering Technical Review Summary

The lack of a desired piece of functionality, or the failure of an item to perform in accordance with specifications, represent examples of issues that can result in a request to change a CI. Whenever a CI change request is identified, the change is controlled in accordance with the CCWG or CCB charters. Throughout the lifecycle of the system, formal configuration control will be employed to ensure the correct version and compatibility of components are maintained and changes are formally authorized.

The act of establishing formal configuration control for a specific type of CI marks the point DAI team members must adhere to established configuration and change control procedures. This includes prescribed change control processes for the justification, evaluation, coordination, approval (or disapproval), and implementation of changes as authorized through the DAI CCWG or CCB governance boards.

CHANGE REQUEST PROCESS

Submission, Authorization, and Identification

The Program manages customer specific requirements for new capabilities through the DAI RRB and CCB. The DAI CCWG manages the process of change to the application or infrastructure technical baseline ensuring impact analysis is complete and accurate for all requests for change presented for review; and maintaining integrity of product CIs as they evolve through their lifecycle. Further information may be found in the DAI CCWG Charter.

Page | 31

Figure 9: High Level Production Support and Release Management Process

Model

Page | 32

Figure 10: Serena Dimensions CM Item Repository

Analysis, recommendations and approvals regarding changes to technical configuration baselines are disseminated to the DAI community; stored in the application’s Configuration Management tool, Serena Dimensions CM and uploaded to the DLA Enterprise CM repository DACS, for distribution to the broader CCWG community.

Change Request Technical Reviews and Approvals

All change requests undergo appropriate technical reviews and approvals across the lifecycle of the change as defined in the DAI CCWG Charter or CCB Charter.

EMERGE…