Attach_1_-_PWS.pdf

RMS/LMDB FA8770-16-R-0002

Performance Work Statement RFP Attachment 1

AIR FORCE LIFE CYCLE MANAGEMENT CENTER (AFLCMC)

AFLCMC/HIAR

WRIGHT PATTERSON AFB, OH 45433-5006

PERFORMANCE WORK STATEMENT (PWS)

FOR

REQUIREMENTS MANAGEMENT SYSTEM

(D200, DD1000, D040, and D072)

AND

LOGISTICS MANAGEMENT DATA BANK

(LMDB D075)

SUSTAINMENT AND MODIFICATION

SOLICITATION NUMBER FA8770-16-R-0002

30 Mar 2016

Contents

1. SCOPE

1.1. SYSTEM DESCRIPTIONS

RMS D200 ............................................................................................................... 8 1.1.1.

RMS D040 ............................................................................................................... 9 1.1.2.

RMS D072 ............................................................................................................. 10 1.1.3.

RMS DD1000 ........................................................................................................ 10 1.1.4.

LMDB D075 .......................................................................................................... 11 1.1.5.

1.2. Program Management

Project Management Plan ...................................................................................... 12 1.2.1.

Transition Startup Plan .......................................................................................... 13 1.2.2.

Metrics and Status ................................................................................................. 13 1.2.3.

Program Management Reviews (PMRs) ............................................................... 14 1.2.4.

Weekly Status ........................................................................................................ 15 1.2.5.

Risk Management .................................................................................................. 15 1.2.6.

Program/Project Control ........................................................................................ 15 1.2.7.

Configuration Management ................................................................................... 16 1.2.8.

Integrated Master Schedule ................................................................................... 16 1.2.9.

Process Improvements ....................................................................................... 19 1.2.10.

1.3. Planning and Analysis

Communications Systems Requirement Documents (CSRDs) ............................. 19 1.3.1.

Technical Interchange Meeting (TIM) .................................................................. 23 1.3.2.

Joint Application Design (JAD) Meetings ............................................................ 24 1.3.3.

Change Request, TS/ROMs .................................................................................. 24 1.3.4.

Information Support Requests (ISRs) ................................................................... 24 1.3.5.

Operating System and Commercial Off-The-Shelf (COTS) Upgrades ................. 24 1.3.6.

1.4. Maintenance and Sustainment

Release Management ............................................................................................. 26 1.4.1.

Emergency Releases .............................................................................................. 26 1.4.2.

Information Support Requests (ISRs) ................................................................... 26 1.4.3.

Configuration Management ................................................................................... 27 1.4.4.

Life-Cycle Documentation .................................................................................... 28 1.4.5.

Integrated Test and Evaluation .............................................................................. 32 1.4.6.

Other Maintenance Considerations ....................................................................... 35 1.4.7.

1.5. System Surveillance

Interfaces ............................................................................................................... 36 1.5.1.

RMS D200 Processing .......................................................................................... 36 1.5.2.

Action Items .......................................................................................................... 37 1.5.4.

Data Analysis Support ........................................................................................... 37 1.5.5.

Database Management/Maintenance ..................................................................... 37 1.5.6.

User Account Management ................................................................................... 38 1.5.7.

DD1000 Support .................................................................................................... 38 1.5.8.

D040 WSSP and D072 OWRMR Support ............................................................ 39 1.5.9.

1.6. Transition Support

Transition - Contract Start Up ............................................................................... 40 1.6.1.

Transition - Contract Conclusion .......................................................................... 41 1.6.2.

1.7. Estimated Workload

1.8. System Revitalization Support

1.9. Environment Support

DD1000 Development/Test Support ..................................................................... 45 1.9.1.

Future Environment Support ................................................................................. 45 1.9.2.

2. SERVICES SUMMARY (SS)

3. GOVERNMENT FURNISHED PROPERTY AND SERVICES

3.1. Facilities and Working Environment

3.2. Personnel Access

3.3. Application of Government Processes and Tools

3.4. Physical Security

3.5. Government Furnished Equipment (GFE) and Government Furnished Information

(GFI) 52

Government Provided Equipment and Information .............................................. 52 3.5.1.

Obtaining Additional or Replacement Equipment ................................................ 53 3.5.2.

4. GENERAL

4.1. Place of Performance

4.2. Period of Performance

4.3. Hours of Work

4.4. Government Holiday

4.5. Travel

4.6. Sensitivity of Data

4.7. Security Requirements

Personnel Investigation, Clearances, and Computer and Network Access ........... 55 4.7.1.

Common Access Card (CAC) ............................................................................... 56 4.7.2.

Personnel Security Investigation (PSI) Requirements for Information Technology 4.7.3.

(IT) Level positions

Operations Security ............................................................................................... 57 4.7.4.

In-Processing ......................................................................................................... 57 4.7.5.

Sensitive Unclassified Processing ......................................................................... 58 4.7.6.

Remote Systems Administration ........................................................................... 58 4.7.7.

Systems Certification and Accreditation ............................................................... 58 4.7.8.

Malicious Logic Protection ................................................................................... 58 4.7.9.

Time Compliance Network Orders (TCNOs) .................................................... 59 4.7.10.

Client Services Administrators (CSAs) ............................................................. 59 4.7.11.

Security Reporting Responsibility ..................................................................... 59 4.7.12.

Security Training ............................................................................................... 59 4.7.13.

Data Handling and Public Key Infrastructure (PKI) ......................................... 60 4.7.14.

Internet Protocol version 6 ................................................................................. 60 4.7.15.

RMS Technical Data Disclosure ....................................................................... 60 4.7.16.

4.8. Combating Trafficking in Persons

Combatting Trafficking in Persons Awareness Program ...................................... 60 4.8.1.

Combatting Trafficking in Persons Awareness Program Training ....................... 61 4.8.2.

Combatting Trafficking in Persons Mitigation Plan ............................................. 61 4.8.3.

4.9. Associate Contractors

4.10. Successor Contractor

4.11. Organizational Conflict of Interest (OCI)

4.12. Prohibitions

4.13. Performance Evaluation

4.14. Contract Performance Assessment Report (CPAR) Applicability

4.15. Continuation Of Essential DOD Contractor Services During Crisis

4.16. Section 508 of the Rehabilitation Act

5. DATA RIGHTS

6. APPLICABLE STANDARDS AND GUIDANCE

7. POINTS OF CONTACT

APPENDIX A: TERMS AND DEFINITIONS

APPENDIX B: ACRONYMS

APPENDIX C: RMS AND LMDB DESCRIPTIONS

APPENDIX D: RMS AND LMDB CONTRACT DATA REQUIREMENTS LIST (CDRLS) 75

List of Figures and Tables

Figure 1 – Generic Release Phases Figure 2 - Generic Release Schedule Figure 3 - Estimated Workload

Table 1 – RMS Subsystems and Components Table 2 – DR Priority Thresholds Table 3 - System/Subsystem Documentation Table 4 - Functional Baseline Documents Table 5 – Hosting Environments

1. SCOPE

This effort is for non-personal technical maintenance, sustainment, and development services for the Requirements Management System (RMS) and the Logistics Management Data Bank (LMDB) (D075) programs. RMS refers to the collection of Data System Designators (DSDs) of D200, DD1000, D040 and D072 and all their related subsystems and components. Under this effort the contractor shall perform all Program Management, Planning and Analysis, Maintenance and Sustainment (including system modification), Integrated Test and Evaluation, System Surveillance, and associated Life Cycle documentation of the RMS and LMDB systems.

The Contractor must fully understand the functional and technical aspects of the major system components specified in this PWS so that sustainment and modification tasks can be accomplished successfully. This involves:

Functional expertise consists of a thorough understanding of the Air Force logistics business processes and collateral business processes as a whole and as they relate to RMS and LMDB.

System/computational expertise, a thorough understanding of the environments, platforms, languages, databases and techniques applied to RMS and LMDB.

To facilitate understanding, “Terms and Definitions” are listed in APPENDIX A: TERMS AND DEFINITIONS, and “Acronyms” in APPENDIX B: ACRONYMS.

1.1. SYSTEM DESCRIPTIONS

This PWS covers multiple application systems of the RMS and LMDB program offices. These application systems are described below.

RMS encompasses the automated and manual functions involved in the Air Force Materiel Command’s (AFMC) Materiel Requirements Process. This process forecasts and controls procurement and repair requirements of materiel needed for logistics support of weapons systems operated by the Air Force. AFMC manages and determines requirements for recoverable spares, consumable spares, and equipment items. The items involved are in direct support of Air Force weapons systems and have significant impact on the Air Force’s ability to carry out its mission requirements. The RMS system supports over 1,500 end-users primarily at three Air Logistics Complexes (ALCs), Headquarters AFMC (HQ AFMC), Wright-Patterson Air Force Base (WPAFB), Ohio, the Air Force Sustainment Center (AFSC), and Headquarters United States Air Force (HQ USAF), Washington DC. RMS interfaces with other AF Major Commands, Department of Defense (DoD), and other Government agencies in exchanging logistics historical and planning data.

LMDB supports over 450 end-users at three ALCs, HQ AFMC, and HQ USAF. LMDB has interfaces with RMS and other systems. LMDB computes the buy and repair budget data and provides reason code information for termination actions. Logistics Reassignment (LR) is another function LMDB performs to transfer selected items to the Defense Logistics Agency or other services.

RMS D200 1.1.1.

The D200 system supports the warfighter by computing procurement requirements for spares and determining depot level maintenance repair needs for the Air Force. RMS D200 encompasses the automated and manual functions involved in the materiel requirements process. This process forecasts and controls procurement and repair requirements of materiel needed for logistics support of weapon systems operated by the Air Force. The maintainer of the warfighter aircraft benefits by having available to them the correct mix of spare parts needed to satisfy planned weapon system availability needs. The materiel involved are in direct support of the Air Force weapon systems and have a significant impact on the Air Force's ability to carry out its mission. RMS D200 addresses one of the Air Force Materiel Command's (AFMC) nine top-level Mission Essential Tasks and Objectives, that of Supply Management: Provide and deliver repairable and consumable items (right product -- right place -- right time -- right price).

RMS D200 gives the Air Force the capability to make logistics resource programming decisions based upon weapon system readiness and sustainability goals; allows the Air Force to tie planned and forecasted requirements to weapon system goals; and, provides the capability to implement budget execution decisions needed to achieve programmed weapon system readiness and sustainability objectives.

RMS (D200) includes multiple subsystems and components listed in Table 1 – RMS Subsystems and Components.

DSD Acronym Name D200A SIRS Secondary Item Requirements System D200C EIP Equipment Item Process D200E RIID Requirements Item Identification Process D200F API Applications Program Indenture Process D200H IRD Initial Requirements Determination D200N CSIS Central Secondary Item Stratification D200X A&S Administration and Support Additional Components in D200 CSWS DE File Contractor Supported Weapon Systems Data

Exchange embedded code and file support AAM VB Aircraft Availability Model in Visual Basic D200 GUI Screens

Table 1 – RMS Subsystems and Components

The D200 components are housed at the Defense Information Systems Agency (DISA) DoD Enterprise Computing Center (DECC) in Ogden UT. The operating environment is IBM Mainframe, utilizing CA-DATACOM DB and COBOL. For a complete description of the technical products for D200, see APPENDIX C: RMS AND LMDB DESCRIPTIONS.

Contractor Supported Weapon Systems Data Exchange (CSWS DE) 1.1.1.1.

Support of D200A and D200N includes coding to sustain a portion of the Contractor Supported Weapon Systems Data Exchange (CSWS DE, D375). This sustainment also covers an interface between the D200A and D200N subsystems and CSWS DE.

Aircraft Availability Model (AAM) 1.1.1.2.

The D200A the Secondary Item Requirements System (SIRS) subsystem includes the Aircraft Availability Model (AAM) and a Visual Basic Aircraft Availability Model (AAM VB) Prototype. SIRS computes the worldwide buy, repair, termination and disposal requirements for Air Force recoverable and consumable items. It provides on-line file maintenance and display capability, "for real" and "what if" item re-computations, and group re-computations.

AAM is an analytical safety level model based on probabilistic and economic concepts. It relates expenditures for the procurement of recoverable spares to aircraft availability rates, simultaneously producing curves of expenditure versus availability rates for many different aircraft types. AAM uses a marginal analysis technique, i.e., it ranks the candidates for procurement in decreasing order of benefit per cost to form an ordered "shopping list". Buying from this list in the order indicated assures that items which give the greater increase in availability rate per dollar will be acquired earlier. Thus, AAM optimizes aircraft availability for any funding constraint and produces optimum shopping lists by component, for each funding level. AAM is considered a multi-indenture, multi- echelon optimization inventory model that optimizes inventory requirements based upon weapons system availability and/or operational goals.

Multi-Echelon – Multi-echelon optimization is over two or more echelons. For the Air Force the “echelons” are base and depot level supply. Multi-Indenture – Multi-indenture optimization is over the indenture system. The Air Force performs component versus subcomponent trade-offs through 99 levels of indenture. Optimization Inventory Model – This is a more general term indicating that inventory levels are optimally determined against some objective. The Air Force maximizes aircraft availability given a budget constraint or minimizes cost for a given fill rate goal.

Visual Basic (VB) Aircraft Availability Model (AAM) Prototype 1.1.1.3.

AAM exists in both the RMS Production (COBOL) environment and as a PC-based, Visual Basic implementation. The latter is commonly referred to as the VB AAM. The intended purpose of VB AAM is to provide an analysis environment that supports:

• Enhancements, modifications, and parameter changes to the AAM as implemented within the SIRS (D200A) production environment

• Analyses of the RMS computational results

The mathematical modeling capability of the COBOL and VB implementations is the same. The amount of data that can be processed at any one point in time is different between the COBOL and VB implementations. AAM Production (COBOL) processes 38 quarters of data. VB AAM processes fewer, specific key quarters of data.

RMS D040 1.1.2.

D040 has two components: D040 RSSL, War Reserve Material Lists Requirements and Spares Support Lists, and D040 WSSP, Weapon System Support Program. RSSL provides computations regarding quantities of consumable items of War Reserve Materiel (WRM) required for support of forces, missions, and activations cited in USAF war plans. WSSP is an Air Force managed program which provides DLA with the visibility of the DLA-managed National Stock Numbers (NSNs) requiring special management to ensure continued on-the-shelf stock support for items used on selected weapon systems.

D040 RSSL is hosted at DISA DECC Ogden on an IBM Mainframe, utilizing COBOL and JCL for batch processing. For a complete description of the technical products for D040 RSSL, see

APPENDIX C: RMS AND LMDB DESCRIPTIONS.

D040 WSSP utilizes Java, Oracle 11g WebLogic Application Server and Oracle 11g database, and is hosted at GCSS-AF, DISA Montgomery. For a complete description of the technical products for D040 WSSP, see APPENDIX C: RMS AND LMDB DESCRIPTIONS.

RMS D072 1.1.3.

D072 is the Other War Reserve Material Requirements (OWRMR) program. This system computes other war reserve material requirements the Defense Logistics Agency (DLA), the General Services Administration (GSA), and other service managed budget code-nine (9) hardware items used by the Air Force. D072 OWRMR utilizes Java, Oracle 11g WebLogic Application Server and Oracle 11g database, and is hosted at GCSS-AF, DISA Montgomery.

For a complete description of the technical products for D072 OWRMR, see APPENDIX C:

RMS AND LMDB DESCRIPTIONS.

RMS DD1000 1.1.4.

The DD1000 Report provides the annual Office of Secretary of Defense (OSD) reports to Congress DoD its on-hand inventory as of each 30 September. This report is called the Stratification Report of Principal and Secondary Items (RCD: DD-P&L(A)1000), commonly known as the DD1000 Report, also known as the Supply System Inventory Report (SSIR). It is constructed from input received from each DoD component (Air Force, Navy, etc.) and an extract from D200N (CSIS).

Headquarters AFMC/Logistics Items Requirements (AFSC/LGPS) is the Air Force focal point to gather data for the DD1000 report. AFSC/LGPS previously accomplished this by distributing information in a series of Microsoft Excel spreadsheets to Item Managers at the Air Logistics Complexes (ALCs) and other Major Commands. The Item Managers entered their data according to AFSC/LGPS direction, and then sent the Excel spreadsheets back to AFSC/LGPS with supporting narrative as appropriate. AFMC/LGPS ran Statistical Analysis Software (SAS) programs on a mainframe system to produce item reports from data files received from the Central Secondary Item Stratification D200N system (CSIS) part of the Requirements Management System (RMS). These were emailed to Recoverables Item Managers to aid them in composing narratives that explained variances in inventory within a Budget Program (BP) from the previous year. AFSC/LGPS then accumulated the data into a consolidated DD1000 report to be provided to the OSD.

The DD1000 system automates this process. The DD1000 System encompasses the tailored spreadsheets, the SAS algorithms, reports, and narratives comprising the legacy DD1000 process.

The DD1000 application is a web-based, n- tier application that utilizes the Global Combat Support System-Air Force (GCSS-AF) single sign-on capability and security services layer. Up to 10 years of reports are stored, along with narratives, on the DD1000 Oracle database The primary application language is JAVA, and the system also includes elements of Oracle Forms and Reports. Version 8.8 runs in the Air Force Equipment Management System (AFEMS) production environment at WPAFB. Version 8.8.1 will run in the DISA CCE environment and is targeted to field in 2016. For a complete description of the technical products for DD1000, see APPENDIX C: RMS AND LMDB DESCRIPTIONS.

LMDB D075 1.1.5.

LMDB is comprised of two sub-systems: Automated Budget Compilation System (ABCS) and Logistics Reassignment (LR). ABCS collects, organizes, and integrates data from Air Force legacy systems to provide Financial Management reports for the Secretary of the Air Force (SAF). ABCS provides a system to adjust and track spares requirements regarding buy and repair budgets. Termination actions are provided a reason code and reports are provided.

ABCS functionality supports Consolidated Support Activity Group (CSAG) - Supply (S) budget formation, depot maintenance workload planning, tracking of on-order excess, and Performance Based Logistics (PBL) contractual requirements definition for weapon systems. LMDB manages approximately 75,000 items with an estimated buy and repair budget of 5 billion.

Logistics Reassignment (LR) capabilities include the generation of the cataloging transactions and data required to transfer items management responsibility to the Defense Logistics Agency (DLA). LR provided transactions enable DLA to register items, delete obsolete records, maintain existing records, identify exceptions, and monitor engineering support of weapon system items. LMDB provides formal interfaces to the legacy systems and maintains Interface Control Documents (ICDs).

LMDB is hosted at the DISA DECC in Ogden UT. The operating environment is IBM Mainframe, utilizing CA-DATACOM DB and COBOL. For a complete description of the technical products for LMDB, see APPENDIX C: RMS AND LMDB DESCRIPTIONS. The ABCS contains a Buy Load process that uses an SQL server hosted by the 88CG at Wright- Patterson AFB, OH.

TASK DESCRIPTIONS

1.2. Program Management

The Contractor shall establish and maintain management and oversight functions necessary to plan, monitor, and control the execution of this PWS. The Prime Contractor shall demonstrate mature process management abilities, by holding a Capability Maturity Model Integration (CMMI) Level II or higher appraisal or similar credential. The Contractor must demonstrate an understanding of the Air Force Logistics and budgeting processes as they relate to RMS and

LMDB.

Project Management Plan 1.2.1.

The Contractor shall prepare a Project Management Plan (CDRL A001) describing the approach for conducting and providing analysis, maintenance, testing and surveillance support for this PWS. An acceptable Management Plan shall be delivered 45 days after contract award (DAC) and updates shall be periodically submitted throughout the life of the contract as required. The Management Plan, at a minimum, will address:

• Staffing Plan, Roles and Responsibilities

• Knowledge Transfer approaches and Internal Training

• Performance Measurement and Critical Success Factors

• Risk Management approach

• Workload Management

• Quality Assurance

• Configuration Management, including the use of Life Cycle Manager (LCM) and/or other CM tools

• Software Maintenance processes, including documentation update and processing, and management and oversight;

o Processes and methods used o Approach(es) followed o Tools used for monitoring, controlling, and reporting o Testing is covered in the Integrated Test Plan, see Paragraph 1.4.6.3

• Development and update of project schedules and performance reporting

• Approach and processes for execution of program surveillance activities

• Outbound Transition Plan to Government or future contract resources, including:

• Approach to be used to train resources

• Transition of surveillance tasks and responsibilities

• Transition of maintenance tasks and responsibilities

• Transition of all source code, documentation, equipment, and support files and plans.

Note: the Startup Transition Plan includes many of these same items as applies to the inbound transition, while this Management Plan will refine and expand on the items as applied to the whole task.

Deliverable: Project Management Plan (Management Plan) (CDRL A001)

Transition Startup Plan 1.2.2.

Within the context of the Startup Transition Plan (STP) (CDRL A001), the Contractor shall address the specifics required to satisfy all aspects associated with the inbound transition to take over the tasks and subtasks described in this PWS from the previous contractor. This plan shall be delivered 10 DAC. Startup Transition Plan shall include:

• Staffing Plan, Roles and Responsibilities

• Knowledge Transfer approaches and Internal Training

• Performance Measurement and Critical Success Factors

• Risk Management Assessment, including mitigation plans

See Paragraph 1.6.1 Transition – Contract Start Up for specifics on this plan.

Deliverable: Startup Transition Plan (STP) (CDRL A001)

Metrics and Status 1.2.3.

The Contractor shall provide a Monthly Status Report (Status Report) (CDRL A002), delivered on fifth business day of the month, covering the previous month. The report shall address for each system/subsystem, the status of:

Developmental metrics for each active release, to include:

• Requirements stability (change over system/sub-system baseline, stability within release)

• Development status against schedule

• Product quality

• Interface development status

• Summary of Activities from Weekly Status Report (WSR) Paragraph 1.2.5.

• Current project risks and risk mitigation plans and activities

• Work planned or scheduled for the ensuing month(s)

• Project resource levels and explanation of resource changes

• Status of all assigned action items

• Status of contractor’s monitoring of quality assurance, configuration management, and security management

• Status of any identified process improvement activities

• Status of deliverables, including required delivery dates and the dates the products are actually delivered

Summary description of travel and/or other services provided during the reporting period, not described elsewhere in the report.

The MSR shall include comprehensive status of scheduled release work, Communications Systems Requirement Documents (CSRDs) – which include Baseline Change Requests (BCRs), Technical Communications Systems Requirement Documents (TCSRDs) and Deficiency Reports (DRs); Information Support Requests (ISRs), and Software Problem Reports (SPRs).

Status includes an ongoing log of the above items by priority, for reporting period and from contract award through reporting period, to include:

• Opened and Closed

• Total Opened and Closed for contract period

• Schedule Compliance - on-time, returned for re-work, late

• Total Schedule Compliance for the contract period

The Contractor shall develop a metric performance baseline against the agreed upon metrics on which the actual performance shall be compared. All metric performance baselines shall be subject to PMO approval, and, once approved, shall not be changed without prior PMO approval. The Contractor shall present and discuss the status of performance metrics at the Contractor PMR. Examples of such metrics are:

• Database volume and usage by system/sub-system

• CPU usage/utilization

• System/Sub-System performance (Errors, ABENDs, re-runs, scheduled and ad-hoc job performance, status of interface jobs)

• User Account Statistics (e.g., Counts, pending suspension, pending deletion, prod/pre-prod/test mismatch)

Deliverable: Monthly Status Report (Status Report) (CDRL A002)

Program Management Reviews (PMRs) 1.2.4.

The Contractor shall provide monthly Program Management Reviews (PMRs) as required at the direction of the Government. The PMR Briefing (Presentation) (CDRL A029) shall be delivered on fifth business day of the month, and shall include but not be limited to:

• Integrated Master Schedule and Release Detail Schedule information (paragraph 1.2.9) to identify status of all scheduled tasks, critical path, explanation of deviations from the baseline schedule and changes in the critical path, and forecasted schedule impacts.

• Developmental metrics as reported in MSR (paragraph 1.2.3).

• Planned accomplishments for the next reporting period as reported in MSR (paragraph

1.2.3).

• Current project risks and risk mitigation plans and activities as reported in MSR

(paragraph 1.2.3) .

• Resources, Action Items, Process Monitoring, deliverable status, travel or other services, as reported in MSR (paragraph 1.2.3) .

In addition, the contractor shall:

• Arrange for the attendance of appropriate contractor personnel to address project issues;

• Record minutes including but not limited to action items and responsible parties.

Deliverables: PMR Briefing (Presentation) (CDRL A029) PMR Meeting Minutes (Minutes) (CDRL A003)

Weekly Status 1.2.5.

The Contractor shall participate at weekly status meetings with the PMO at the PMO facility unless otherwise determined by the PMO. The Weekly Status Report (Status Report) (CDRL A002) shall be delivered weekly 24 hours before the scheduled status meetings, and is intended to be a focusing tool for these weekly meetings and shall include, but not be limited to:

• Report of Activities o Schedule status updates o Release Activities status o DRs and ISRs and programs impacted identified or updated o System/Sub-system Operational Status and Surveillance Status o TCNO and other security notices evaluation and resolution status o Risks identified or updated

• Issues and Concerns

• Action Items

Deliverable: Weekly Status Report (Status Report) (CDRL A002)

Risk Management 1.2.6.

The Contractor shall establish and maintain a risk management process, complementary to the Government risk management processes detailed in the Business Enterprise Systems (BES) Business Process Directory (BPD). Details pertaining to risk management shall be incorporated into the Project Management Plan (CDRL A001) identified in paragraph 1.2.1.

Contractor shall report on identified risks and their status in the Monthly Status Report (CDRL A002) as identified in paragraph.

Monthly Status Report (Status Report) (CDRL A002)

Program/Project Control 1.2.7.

The Contractor shall establish and maintain a program/project control function designed to ensure complete and accurate monitoring/reporting of financial information related to the execution of this PWS. Details pertaining to program/project control shall be incorporated into the Project Management Plan (CDRL A001) identified in paragraph 1.2.1.

Contractor shall report on program/project control function in the Monthly Status Report (CDRL A002) as identified in paragraph.

Configuration Management 1.2.8.

The contractor shall be responsible for all configuration management activities associated with creating, maintaining, controlling, documenting, tracking and reporting the application software and documentation baselines for RMS and LMDB. The methodology followed shall be documented in the Project Management Plan (CDRL A001) identified in paragraph 1.2.1.

Activities shall include, but may not be limited to, creating, updating, revising and maintaining technical specifications, databases, software and manuals as a result of DRs, BCRs, and TCSRDs. Such changes shall be accomplished and documented in accordance with the BES Business Process Directory (BPD). The contractor shall make every effort to group DRs, BCRs and TCSRDs into logical functional releases.

The contractor shall be certified at a minimum of Capability Maturity Model Integration (CMMI) Level II or equivalent.

Contractor shall report on configuration management activities in the Monthly Status Report (CDRL A002) as identified in paragraph.

Integrated Master Schedule 1.2.9.

The Contractor shall develop, maintain and adhere to an Integrated Master Schedule (IMS) for all work identified in the PWS in accordance with Integrated Master Schedule (IMS) (CDRL A005). The schedule must incorporate the detailed schedules for the RMS and LMDB computational cycles provided by the Government. The IMS shall also incorporate schedule for a release when that work is authorized by Configuration Control Directive (CCD).

The schedule shall be constructed as a logic-network employing Critical Path Methodology (CPM) and shall identify all proposed activities, constraints, milestones, CDRL deliverables and resource requirements for the entire project period of performance.

Each release shall have a detailed release schedule, with the release's milestone events reflected in the IMS. Releases shall follow the guidance of phases and milestones in the BES Business Process Directory (BPD).

Release schedules will follow the sample shown in Figure 2 - Generic Release Schedule. The schedules shall extend to a sufficient level of detail below the events shown in the sample to mitigate risk and measure performance and shall ensure vertical and horizontal trace ability is maintained at all times.

Baselines shall not be changed without prior Government authorization. In addition, the Government will provide the dates and durations of the following phases and Government activities for each planned release, for inclusion in the IMS:

• Define Need, Design, and Build and Test Phases

• Systems Requirement Review (SRR)

• Preliminary Design Review (PDR)

• Critical Design Review (CDR)

• Test Readiness Review (TRR) 1

• Qualification Test & Evaluation (QT&E)

• Fielding Readiness Review (FRR)

• Release to Production/Full Operational Capability (FOC)

Figure 1 – Generic Release Phases

For these events the contractor shall participate to include the following:

• System Requirements Reviews (SRRs) to demonstrate an understanding of the release requirements.

• Preliminary Design Reviews (PDRs) to demonstrate the software solution to satisfy the requirements for each release.

• Critical Design Reviews (CDRs) to demonstrate the software design to satisfy the requirements for each release.

• Other design discussions and lower level working groups and Integrated Product Teams

(IPTs) that contend with production problems; especially troubleshooting production errors, performance problems, installation issues, and various network shops that control the network.

Figure 2 - Generic Release Schedule

Deliverable: Integrated Master Schedule (IMS) (CDRL A005)

Milestone Task Name Requirements Phase Requirements Identif ication (ISMT Entry)

Requirements Refinement (JAD/TIM if required)

TCP/ROM (Requested from contractor, entered into ISMT)

Requirements Approval

Pre-Release Release Identif ication (PMO and customer determine go-ahead w ith release

Contracting Action (if required for additional w ork)

Enter Define Need Phase Conduct Configuration Control Board (CCB)

Project Management (DEFINE NEED PHASE) AF Provide Authorization to begin Release (CCD to CTR for Release

Conduct Systems Requirements Review (SRR) Release Schedule Document

AF Review and Approval of Draft Preliminary Schedule Information Assurance (Memo from IAM)

Exit Define Need Phase Define Need Review (Memo from Engineering) Enter Design Phase System Engineering (Design)

Technical Analysis (SRR to PDR)

Preliminary Design and Requirements Documents

PDR Conduct PDR (Milestone at completion) DESIGN PHASE (PDR to CDR) Final Design and Requirements Documents

Preliminary Test Documents

CDR Conduct CDR (Milestone at completion) Exit Design Review Design Review (Memo from Engineering)

Enter Build/Test Phase Construction and CV&I Testing (CDR to CV&I) Build based on design documentation

Test and Evaluation (CV&I to TRR) Component Validation and Integration (CV&I)

Build and Test Documents

Enter Government Test Conduct TRR I (Milestone at completion) Final Deliverables

QUALIFICATION TEST AND EVALUATION (QT&E to FRR) Qualification Testing & Evaluation (QT&E) Roundtable Discussion (Pre-FRR) Final Engineering Go (Memo from Engineering)

Fielding Documents

FRR FRR with HIAR (Milestone at completion) Exit B&T Signed FDM (Fielding Decision Memo)

Enter Release&Support RELEASE AND SUPPORT PHASE

FOC Deployment (FOC Milestone)

Process Improvements 1.2.10.

The Contractor shall document and implement process improvements, complementary to the Government Process and Product Quality Assurance as detailed in the BES Business Process Directory (BPD).

Details pertaining to process improvement procedures shall be incorporated into the Program Management Plan (CDRL A001) identified in paragraph 1.2.1.

1.3. Planning and Analysis

Planning and analysis is the creation of Technical Solution and Rough Order of Magnitude (TS/ROM) for each requirement identified. The RMS or LMDB PMO uses Information System Management Tool (ISMT) as the requirements management and tracking system of record for requirements. Requirements include the following as defined in ISMT: Baseline Change Requests (BCRs), Discrepancy Reports (DRs), Information Support Requests (ISRs), Communications Systems Requirements Documents (CSRDs), Technical Communications Systems Requirements Documents (TCSRDs).

The Government will conduct a Functional Review Board (FRB), a Configuration Control Board (CCB), and Integrated Requirements Review Board (IRRB) to review, approve, and prioritize all requirements. The contractor shall provide Technical Solution and Rough Order of Magnitude (TS/ROM) for each requirement when requested by the Government as part of the review board processes. TS/ROMs are expected in 15 business days from request date, unless otherwise specified. The Contractor shall notify the PMO in advance if an extension is required for a scheduled need date. A minimum of 2 business days’ notice and supporting rationale should accompany the request.

All decisions resulting from these boards will be documented on a Configuration Control Directive (CCD), which will authorize the contractor to undertake the work directed. Contractor activities regarding implementation decisions are covered in paragraph 1.4, Maintenance and Sustainment.

Deliverable: Technical Cost Proposal (TS/ROM) (CDRL A025)

Communications Systems Requirement Documents (CSRDs) 1.3.1.

A CSRD is a collection of one or more change requests (BCRs, DRs or TCSRDs) that has been identified in ISMT. The Government will generate a change request whenever a change in requirements is identified.

The contractor provides a Technical Solution and Rough Order of Magnitude (TS/ROM) for each requirement. The Government CCB will review and prioritize all change requests for inclusion in a release to the RMS or LMDB systems. All releases shall be prioritized and approved by the Government CCB. The Contractor shall maintain the status of CCB approved releases as specified in the paragraph 1.4 Maintenance and Sustainment.

Baseline Change Requests (BCRs) 1.3.1.1.

A Baseline Change Request (BCR) is a change request in logic and/or functionality of the information system generated by the customer organization. BCRs cover updates to functionality (such as a regulatory or policy change that necessitates a system update), or the addition of new functionality to the system. The BCRs which update functionality are considered maintenance BCRs, and are part of the expected workload volume described in paragraph 1.7 Estimated Workload. BCRs which add new functionality to the system are generally larger in scope, and can require a Change Proposal and amendment to add the work to this effort. The contractor shall perform analysis and planning for tasks for all BCRs.

(Note: While a CSRD can be a collection of one or more BCRs, many times a CSRD will only contain one baseline change. In some cases the requirement is recorded directly in the CSRD rather than creating a BCR and then attaching/repeating the identical information in the CSRD.

In this document, the reference to BCR applies to this type of single baseline change CSRD the same as if it were recorded as a BCR attached to a CSRD.)

When the RMS or LMDB PMO receives a BCR requesting a TS/ROM estimate, the Government will task the contractor to accomplish the activities detailed below within 15 work days.

• The contractor shall provide an analysis translating the functional requirements documented on the BCR into a full, descriptive TS/ROM report (CDRL A025). Analysis of data passage requirements shall include considerations as to the applicability and viability of the Enterprise Service Bus (ESB) as critical component to the solution. This solution needs to include all parts of the affected systems such as but not limited to: GUI screens, RoboHelp screens and VB AAM.

• The contractor shall include all database changes (DBCRs), JCL changes, and all other changes needed to accomplish the requirement.

• Identify and discuss any programmatic risk related to the completion of the BCR. For each risk, describe the mitigation strategy, how it will be accomplished and how it will be reported.

• The contractor shall provide a Rough Order of Magnitude (ROM) estimate, with supporting rationale, reflecting the level of effort required to complete the BCR.

• The contractor shall develop a preliminary schedule detailing the activities and milestones required to complete the BCR. The solution work schedule, at a minimum, shall include milestones for and activities related to Preliminary Design Review (PDR), Critical Design Review (CDR), and Test Readiness Review (TRR). For more details see the BES Business Process Directory (BPD).

Technical Communications Systems Requirement Documents 1.3.1.2.

(TCSRDs)

A Technical CSRD is a technical requirement performed under sustainment for the purposes of making operational environment changes to sustain operations. TCSRDs are attached to a CSRD for implementation. For example, upgrade of a COTS product to remain current with vendor support. A TCSRD can also be generated to accomplish technical software changes that do not change the functionality of the application but change the technical approach used. For example, changing code to improve run-time performance of a specific function or changing a device usage characteristic, or changing a process to accomplish the same result such as the use of a different COTS product. Routine TCSRDs that support continued operation of the systems are part of the expected workload volume described in paragraph 1.7 Estimated Workload.

When the RMS or LMDB PMO receives a TCSRD requesting a Technical Solution and Rough Order of Magnitude estimate, the Government will task the contractor to accomplish the activities detailed below within 15 work days.

• The contractor shall provide an analysis translating the functional requirements documented on the TCSRD into a full, descriptive TS/ROM report (CDRL A025).

Analysis of data passage requirements shall include considerations as to the applicability and viability of the Enterprise Service Bus (ESB) as critical component to the solution.

This solution needs to include all parts of the affected systems such as but not limited to:

GUI screens, RoboHelp screens and VB AAM.

• The contractor shall include all database changes (DBCRs), JCL changes, and all other changes needed to accomplish the requirement.

• Identify and discuss any programmatic risk related to the completion of the TCSRD. For each risk, describe the mitigation strategy, how it will be accomplished and how it will be reported.

• The contractor shall provide a Rough Order of Magnitude (ROM) estimate, with supporting rationale, reflecting the level of effort required to complete the TCSRD.

• The contractor shall develop a preliminary schedule detailing the activities and milestones required to complete the TCSRD. The solution work schedule, at a minimum, shall include milestones for and activities related to Preliminary Design Review (PDR), Critical Design Review (CDR), and Test Readiness Review (TRR). For more details see the BES Business Process Directory (BPD).

Deficiency Reports (DRs) 1.3.1.3.

A Discrepancy Report (DR) identifies problems requiring documentation, coding, or programmatic changes for fielded systems and is resolved as part of system sustainment. A DR shall be generated whenever a Deficiency or problem is discovered in production. The Government will review and assign a Priority all DRs. The Contractor shall be responsible to resolve all DRs approved by the CCB. All DRs for the systems are part of the expected workload volume described in paragraph 1.7 Estimated Workload. The contractor shall perform analysis and planning for tasks for all DRs.

All releases shall be prioritized and approved by the Government CCB. The Contractor shall maintain the status of CCB approved DRs.

Priority Definitions Priority 1 – Prevent the accomplishment of an operational or mission essential capability or jeopardizes safety, security, or other designated "critical".

Priority 2 – Adversely affect accomplishment of operational/mission essential capability and no work-around solution is known or adversely affect technical, cost or schedule risks to the project/life cycle support of the system, and no work-around is known.

Priority 3 – Adversely affect accomplishment of operational/mission essential capability, but a work around solution is known or adversely affects technical, cost or schedule risks to the project/life cycle support of the system, but a work around solution is known.

Priority 4 – Operator inconvenience/annoyance, but does not affect a required operational or mission essential capability. Inconvenience/annoyance for development or support personnel, but does not prevent the accomplishment of those responsibilities.

Priority 5 –This priority denotes any other condition.

Priority Time Limits Priority 1 – The Contractor shall provide a valid fix or work around within 48 hours of the DR creation date. (Note: The DR CCD notification is the designating event for the contractor, with a maximum of 7 calendar days for the fix to be released to production. An emergency release may bypass documentation to meet deployment, incorporating documentation in a later scheduled release.)

Priority 2 – The Contractor shall provide a valid fix or work around, ready for shipment to the field within 45 calendar days of the DR creation date, in a scheduled release or emergency release if no release is scheduled. (Note: The DR CCD notification is the designating event for the contractor. An emergency release may bypass documentation to meet deployment, incorporating documentation in a later scheduled release.)

Priority 3 – The Contractor shall provide a valid fix or work around, ready for release to field users, within 120 calendar days of the DR creation date. (Note: The DR CCD notification is the designating event for the contractor.)

Priority 4 – The Contractor shall provide a valid fix or work around, ready for shipment to the field within 180 calendar days of DR creation date. (Note: The DR CCD notification is the designating event for the contractor.)

Priority 5 –The Contractor shall provide a valid fix or workaround, ready for release to the field, within 180 calendar days of DR creation date. (Note: The DR CCD notification is the designating event for the contractor.)

DR PRIORITY TECH SOLUTION/ROM FIELD RELEASE

1 48 hours 7 calendar days 2 5 work days 45 calendar days 3 10 work days 120 calendar days 4 10 work days 180 calendar days 5 10 work days 180 calendar days

Table 2 – DR Priority Thresholds

When the RMS or LMDB program office receives a DR requesting a Technical Solution/Rough Order Magnitude report (CDRL A025), the Government will task the contractor to accomplish the activities detailed below:

• The contractor shall provide an analysis translating the functional requirements into a detailed Technical Solution/Rough Order Magnitude report (CDRL A025). This solution needs to include all parts of the affected systems such as but not limited to: GUI screens, RoboHelp screens and VB AAM. For Emergency DRs, the TS/ROM report may be abbreviated for the sake of expediency in meeting the required timeframes to accomplish identified in Table 2 – DR Priority Thresholds.

• The contractor shall include all database changes (DBCRs), JCL changes, and all other changes needed to accomplish the requirement.

• Identify and discuss any programmatic risk related to the completion of the DR. For each risk, describe the mitigation strategy, how it will be accomplished and how it will be reported.

• The contractor shall provide a Rough Order of Magnitude (ROM) estimate, with supporting rationale, reflecting the level of effort required to complete the DR.

• The contractor shall develop a preliminary schedule detailing the activities and milestones required to complete the DR. The solution work schedule, at a minimum, shall include milestones for and activities related to Preliminary Design Review (PDR), Critical Design Review (CDR), and Test Readiness Review (TRR). For more details see the BES Business Process Directory (BPD).

• The Contractor shall implement the approved technical solution by the Table 2 – DR Priority Thresholds or the next scheduled release as specified by the Government in the CCD, See paragraph 1.4.1 and Release Management. 1.4.2 Emergency Releases.

Technical Interchange Meeting (TIM) 1.3.2.

The contractor shall…