J-1_PWS_2014_03_12.docx

Draft Performance Work Statement 12 March 2014

Air Mobility Command, Directorate of Communications, MAF Systems Division Mission Systems Support Branch, AMC/A6IS

Table of Contents

BACKGROUND

The Global Decision Support System (GDSS) is maintained/sustained by the United States Air Force (USAF), Headquarters (HQ) Air Mobility Command (AMC). In 2011 GDSS replaced multiple legacy systems with a single enhanced system; a modernized, fully integrated and enhanced Command and Control (C2) decision support system using open systems infrastructure and a shared relational database. GDSS supports the Defense Transportation System (DTS) and Distribution Process Owner (DPO) migration strategies. GDSS is designed around a client-server environment composed of web applications, server processes, Commercial Off-the-Shelf (COTS) relational database management system, database schema, and supporting utility scripts. The COTS supporting the current design include UNIX, Oracle, and Microsoft products. This environment runs on host infrastructures maintained by the Government. General network operations and maintenance (O&M) is handled by the Government, to include local network updates/patches as part of their security policies.

GDSS SITE PICTURE

At the highest level, GDSS users are mission operators from the military services, Department of Defense (DOD), and other Federal agencies. The capabilities required in the Command and Control of the Mobility Air Forces (MAF) include; Deployment and Distribution, Understand, Planning, Decide, Direct, and Execute. GDSS ties together these capabilities with the warfighter.

The following diagram illustrates the current interfaces that give GDSS a formidable and dynamic command and control capability; Situational awareness from strategic to finite details; Ability to direct or re-direct forces with accuracy, current data, integration with Air Traffic Control (ATC), weather, and in real or near real time.

Figure 1-2: GDSS and System Relationships The Contractor shall be required to understand these system relationships during the transition period (90 days after contract award); the nature of each interface in terms of the data it pulls from and/or pushes to GDSS and the purpose of that data, as well as a comprehensive technical understanding of each interface connected to GDSS. Figure 1-2 is for informational purposes only and subject to change as interfaces are modified.

GDSS STAKEHOLDER TEAM

The GDSS team consists of Government and contracted support working together to support the customer. Representing the customer is the Functional Manager (AMC/A3CS), contracting support is 763 SCONS working in concert with the Program Support Branch (AMC/A6IS), budget and other resources support comes from AMC/A6XR. The GDSS Program Management Office (PMO), under A6IM is the Office of Primary Responsibility for managing the system sustainment.

A6IS also manages the primary software systems support contract; Applications Infrastructure and Systems Support (AISS). AISS provides systems engineering, testing, training, technical and fielding support. The GDSS operational Systems Manager and software security support is provided by the 375th Airlift Wing. The Maine Air National Guard provides hardware logistics, and a separate contract provides GDSS level 2 Helpdesk.

CROSS UTILIZATION OF RESOURCES: The Contracting Officer’s Representative (COR) will not discourage any Contractor to take measures that may reduce overhead by way of sharing administrative resources within the company, however, the Government will not accept, as an excusable delay, that the Contractor’s engineers, database administrators, or other technicians have been assigned to other contracts.

OBJECTIVE and SCOPE OF WORK The tasks to be accomplished are in support of the HQ AMC/C2 System Branch (HQ AMC/A6I) GDSS PMO. The PMO manages the System of Record (GDSS). The term ‘GDSS’ includes several peripheral items: Interfaces and Information Services, a number of sub-applications, sub-systems, and projects that require support from the Contractor. Projects under the program may be added, transferred, or disbanded throughout the contract performance period. AMC/A6I programs utilize the Software Engineering Institute (SEI), Capability Maturity Model Integration for Acquisition (CMMI-ACQ) Level 3 as the model baseline in its efforts to improve overall program management of software releases and program support/integration.

SUSTAINMENT

GDSS is now in a sustainment phase. Development is required but limited to Corrective, Adaptive, Enhancement, or Perfective Maintenance (IEEE Std 1219):

Corrective - Diagnosis and correction of latent errors in the code.

Adaptive - Modification to keep software usable when running in a new system environment.

Enhancement - Deletion and addition of functions to sustain warfighter capabilities, the adaptation to changes in data requirements and operation environments, the improvement of performance, usability, or any other quality attribute.

Perfective - Modification of software after delivery to improve its performance or maintainability.

AMC/A6IM uses the International Organization for Standardization (ISO) definition for ‘maintenance’ for the same purpose: (paraphrased) “The maintenance process contains the activities and tasks of the maintainer. This process is activated when a system undergoes modifications to code and associated documentation due to an error, a deficiency, a problem, or the need for an improvement or adaptation. The objective is to modify an existing system while preserving its integrity.”

DESCRIPTION OF SERVICES

The Contractor shall provide support to fielding and opeational maintenance.

The Contractor shall provide the GDSS PMO with administrative support to meet financial and programmatic reporting needs.

The Contractor shall implement agile development activities.

The Contractor shall comply with the appropriate DOD, Services, USTRANSCOM, and AMC architectures, programs, policies, standards and guidelines (e.g., Strategic Technical Guidance [STG], Net-Centric Enterprise Services [NCES], Defense and Information Systems Network [DISN]).

SPECIFIC SUPPORT SERVICES (TASKS)

SERVICE STATEMENT

GDSS Contractor responsibilities include: Responsiveness, cost control, schedule management, a cooperative teaming environment, quality, resource management, and a commitment to customer satisfaction. Except for those items specifically stated as Government-furnished, the Contractor shall furnish everything needed to perform this contract. In the absence of specific contract requirements, the Contractor shall use the software development industry standards and industry best practices for providing the products and services required by the contract.

Task 1 – Enterprise IT Policy and Planning Task 2 – Integrated Solutions Management Task 3 – Market Research and Prototyping Task 4 – Custom Application Development Task 5 – Asset Management Task 6 – Security Engineering Certification and Accreditation Task 7 – Operations Support Task 8 – Hardware TASK 1 – Enterprise IT Policy and Planning. In providing plans, reports and technical assistance, the Contractor shall accomplish the following:

Subtask 1 – Documents. The Contractor shall prepare, submit, and maintain the following documents:

Reports and Documents

Procedures & Descriptions

Change Requests (CRs)

Other

The Engineering Change Proposal, Requests for Deviation, Document Change Requests, SPRs (Software Problem Request - changes required to correct errors or code that is not working or does not meet expected functionality), and BCRs (Baseline Change Requests - changes requested by the COR to upgrade or change a function in the software) will often require input from the Contractor. Change Requests (CRs) shall be written in a clear concise manner. See Attachment 3 for examples of SPRs and BCRs.

Subtask 2 – Support and Attend Meetings and Conferences. This subtask addresses CDRLs A003, B001, B002, B003, B005, and B007. The Contractor shall attend the following meetings:

Contract and Program Status Review. The Contractor shall host this monthly meeting at an agreed upon location. The contractor shall prepare an agenda and provide written minutes (CDRL B007). The purpose of this meeting is to review and update the Contractor’s Technical & Management Work Plan (CDRL A003), brief the progress of each assigned task (CDRL B001), address schedule tracking concerns/impacts to the master schedule (CDRL B003), review financial status, and solicit input from the PMO to obtain concurrence of work performed by the Contractor.

Provide Contract Performance Report. The presentation of the CPR with slides or other presentation material provided to the Government meets the requirement for this report (CDRL B001).

Task Schedule Progress Review (TPR, bi-weekly) (CDRL B002) Other meetings routinely attended by the Contractor:

Program Management Review (PMR, monthly) CIO Program Review Process Preparation (CPRP, bi-annually) Support Ad Hoc Teams (historically bi-weekly) Security Working Group Performance Teams Accreditation Support (as required for releases) Document update meetings (as architecture changes or software releases dictate) Technical Working Group (TWG) Support (historically weekly)

3.2.2.3.9 GDSS Weekly Updates (GWU)

The Contractor shall generate presentation materials if required to aid in the discussion of meeting topics and shall support conferences, meetings, demonstrations, and Technical Interchange Meetings/Reviews (CDRL B005). For meetings that the Contractor is required to host, they shall provide agendas, meeting minutes, and track action items associated with the aforementioned meetings/reviews (CDRL B007).

Subtask 3 – Task Schedule Progress Review (TPR). This subtask addresses CDRLs A001, A003, and B003. The Contractor shall provide visibility/monitoring of task progress by accomplishing the following:

Maintain and annotate a project schedule of all Contractor activities associated with the efforts described in tasks 1 through 5 utilizing the tools identified by the Government. The format of the project schedule shall be as agreed with the COR to assure readability (CDRL B003).

Populate each schedule with sufficient task activities to ensure visibility of management and tracking for each milestone (CDRL A003).

Identify, within the schedule, the resources required to accomplish all task activities. Contractor may use generic resource identification (CDRL A001).

Determine and annotate appropriate milestones needed to ensure/monitor progress (CDRL A003).

Baseline all schedules with concurrence of the COR (CDRL B003).

Update schedule progress on a weekly basis using Government-provided tools (CDRL B003).

Provide schedule status, risks, issues and progress (CDRL A001).

TASK 2 - Integrated Solutions Management Subtask 1 – System Integration. This subtask addresses B005, B006, B007, C001 through C011, and E003. The Contractor shall support full system integration by ensuring that the software does not adversely affect the intended operational system, and by accomplishing the following tasks:

Prepare and deliver the end items of the intended operational system (CDRL C001, C009, and C010).

Ensure and demonstrate that the software is integrated into the intended system configuration.

Provide software application training for key technical personnel, functional help desk personnel, trainers, testers, and others if designated by the COR for each release. This has been referred to as “train the trainer”, the objective being that any software changes that affect the operating procedures shall be taught to the key personnel that support the program (CDRL E003).

DI-SESS-81523B, with the following deletions: paragraphs 2.2.2.ae. With the COR’s approval, the Contractor may deviate (add and delete) from the Training Conduct Support Document/Training Lesson (TCSD/TL) Data Item Description (DID) content requirements in order to further tailor the TCSD/TL to the Missions Systems training culture and the Contractor’s training strategy. However, the Contractor shall explain in an executive summary or an addendum to the TCSD/TL its rationale for adding or deleting a specific DID requirement. Nevertheless, the COR retains the right to require any part of or all of the Data Item Instructions to be adhered to by the Contractor. Each version release and some patches may require a TL. Outline TL due 30 days prior to each planned version release (CDRL E003).

Final TL due 30 days prior to version fielding (CDRL E003).

Provide GDSS technical remote and hands-on support to the teams installing and fielding the delivered system.

Prepare and deliver software releases and test results, including all required components and documentation (CDRLs B005, B006, B007, and C001 through C011).

Subtask 2 – Additional Integration Efforts. This task area includes management and technical support for research, analysis recommendation and documentation of integration issues and approaches. The issues and approaches considered under this area evolve from a variety of sources such as external audits, technical reports, Federal standards, operational policies and doctrines, technical guidelines and best practices. The Contractor shall perform the following activities for services required under this task area:

Examine functional and technical requirements and/or issues to provide effective solutions for integration efforts that include:

· Review technical solution(s) to operate within the AMC designated C2 and In-Transit Visibility (ITV) designed architecture and interoperate with other C2 and ITV systems

· Compliance with Legal and Regulatory Guidance

· Net-Centricity—Integrate data and business rules requirements with other DOD, Federal, USTRANSCOM or AMC data integration efforts

· Architectures – Provide technical drawings consisting of recommended solutions that may be used to develop AMC architectural products

· Security Compliance

· Benchmarking/Baselining

· Performance

· If directed, develop prototypes as proof of concepts Develop documentation resulting from studies, analyses, assessments, and engineering designs. Documentation may include subject matter originated by the Contractor as well as Government-provided topics. Document enhancements to existing system architecture to take advantage of the infrastructure environment proposed. Data items to be delivered under this optional subtask shall be identified in each task order.

TASK 3 – Market Research and Prototyping The Contractor shall evaluate COTS and other solutions to support GDSS applications, and other special equipment requirements. The Contractor shall actively evaluate the COTS and other solutions, such as features and functionalities, for opportunities to correct inefficiencies, errors, and recommend solutions. This includes established efforts to migrate the current software to an updated platform chosen by the COR. The Contractor shall assist the Government by testing Government chosen products and making recommendations (CDRL B005).

TASK 4 – Custom Application Development Primary Systems under this task: The primary systems are engineered and developed by the Contractor. The physical environments for the systems are engineered and maintained under a separate support contract. These include the operational environments housing the active applications the customers are using around the world. The Contractor shall provide written (CDRL B005) or verbal installation instructions and assistance when technical guidance is required. The Contractor shall adhere to industry best practices during development to include security engineering.

NOTE: The interdependencies of the following systems and subsystems shall be tracked by the Contractor to ensure the fielding of individual subsystems maintains uninterrupted service to the customer.

GDSS – This contract focuses on GDSS and its many sub-applications. The Contractor shall develop solutions to meet Government-directed changes and upgrades as required.

Sub-Applications: GDSS is a system of several sub-applications centered on different types of users.

Aviation Operational Risk Management (AvORM) – Sustainment is unique and limited to Corrective, Adaptive, Enhancement, or Perfective Maintenance (IEEE Std 1219).

GDSS Exercise Suites Exercise Management Console (EMC) GDSS Training Suites Secondary Projects and Systems: The actual systems and environments for the following projects and sub-systems are engineered, developed, and maintained under separate contracts. The Contractor shall provide assistance when technical guidance is required.

Projects:

Global Aircrew Scheduling/Global Aircrew Management (GAS/GAM) Dynamic Mission Re-planning (DMR)

3.5.2.1.3 Security patches and Time Compliant Network Order (TCNO)

3.5.2.1.4 Other – Other projects are expected to emerge

GDSS Sub-Systems:

GDSS Testing Suite GDSS Prototype Suites GDSS Training Suites Services:

Enterprise Services Management (ESM) Automated Cross Domain Solution (ACDS), to be replaced by the Mobility Automated Cross Domain (MAC-D).

Subtask 1 – Configuration Management (CM). The Contractor shall provide a software configuration management plan/process with their proposal that incorporates the following:

Using MIL HDBK 61A, ISO 12207, and EIA 649 guidance, the Contractor shall institute and maintain a configuration management process to ensure engineering and administrative disciplines (which include configuration identification, configuration control, status accounting, and auditing) are implemented for all development activities. The Contractor shall identify the configuration of all work products (to mean multiple baselines as well as other supporting work products); systematically controls changes, and maintain the integrity and traceability of all work products throughout their lifecycle. The Contractor shall ensure configuration is identified, reliable, traceable, and repeatable, and that all relationships among work products, versions of work products, as well as auditing and reporting on the changes that are made are implemented throughout the development process. Authority: DI-CMAN-80858B. Finalize with the COR NLT 20 business days after award.

In addition, the Contractor shall accomplish the following:

Establish and employ internal configuration management of processes and procedures for all development work products.

Identify the configuration items (including COTS software), components, and related work products, to include baseline documentation, and place these items under configuration control.

Establish and maintain a configuration management and change control system for controlling configuration items, components, and work products.

Establish version control to ensure integrity and tracking of all work products.

Identify, track, and control change requests (including those changes intended to resolve identified problems) for the configuration items.

Establish configuration control of all supporting documentation, changes to the documentation, and version control of all documentation supporting work products, and ensure product documentation reflects all changes to a work product.

Provide backup controls to ensure work products are not lost or damaged due to resource, equipment, or power failures.

Establish and employ product CM processes and procedures to ensure the integrity of all delivered baselines and work products.

Establish and maintain records describing configuration items.

Ensure internal controls are in place supporting all baselines and work products.

Ensure configuration audits are available supporting the integrity of the configuration.

Ensure the internal configuration status accounting system records the tracking of baselines and work products and their modification history throughout the life cycle.

Configuration controls shall ascertain the content of any delivery, baseline or work product is accurate and complete, and unaltered upon delivery. In the case of code delivery a Government issued digital signature shall be affixed to code before delivery.

Record and present to the COR, the results of the configuration audit, to include action taken by the Contractor to correct deficiencies noted during the audit. The Contractor shall correct all deficiencies noted during the audit prior to presenting the deliverable for Government acceptance.

Coordinate closely with PMO or the designated Configuration Manager to ensure continuity of configuration management processes and practices are maintained and controlled.

Ensure development CM processes and procedures compliment the Government’s Configuration Management Plan (CMP).

Provide traceability of all CRs throughout the system lifecycle via a requirement traceability tracking tool.

CM of software shall include a comprehensive method of recording all COTS software purchase and warrantee dates, support and warrantee expiration dates, and a plan to provide adequate lead time to extend or replace warrantees or support as needed.

CM of software licenses shall include a comprehensive method of recording all software license purchases and their expiration dates, and a plan to provide adequate lead time to extend or replace licenses as needed.

Subtask 2 – Quality Control. Provide a Quality Control Program that incorporates the following:

The Contractor shall provide a single point of contact (POC), and alternate POC, for Government to Contractor, day to day business and quality control. This does not preclude routine contact between the COR and Contractor administration and technicians as required, but all official communications relating to contractual effort, cost, schedule, performance, and changes in resources shall include that POC. Customarily this will be the local site or business manager of the company, and/or the company representative to the Contracting Officer (CO).

The Contractor POC shall be the first line of communication in settling any minor issues not requiring intervention of the CO.

The Contractor shall establish and maintain a Quality Control Program in accordance with ISO IEC 26514:2008 and SEI CMMI Level 3-Defined requirements or equivalent processes approved in writing by the COR. In establishing and maintaining a Quality Control Program, the Contractor shall plan, develop, and implement procedures and practices to ensure that all requirements of the contract are complied with fully. The COR shall audit all processes and products as outlined in the Quality Control Program Plan. The Quality Control Program Plan shall also include a non-compliance reporting and tracking process.

The Contractor shall support Government reviews and audits of all services and support provided under this contract. The Government reserves the right to authorize an independent verification and validation of the Contractors’ procedures, methods, data, equipment, and other services provided at any time during the performance of this contract. At the COR’s discretion, registered ANSI/ANSQ Q9000 series suppliers may not be subjected to audit/assessment by the Government if they provide the COR with a copy of their registration certification issued by an approved ISO registrar.

Subtask 3 – Interoperability and Architecture Support. This subtask addresses CDRLs B005, C008, and E001. The Contractor shall provide interoperability and architecture support by accomplishing the following tasks:

Ensure that the technical designs and system elements comply with the Defense Information Technology Standard Registry (DISR) (CDRLs B005, C008, and E001).

Design technical solutions to operate within the GDSS framework, and interoperate with other systems.

Ensure technical design and solutions are compatible with DOD infrastructure, e.g., Standard Desktop Configuration, and the operational environment.

Participate in developing and validating Department of Defense Architecture Framework (DoDAF) products. The Contractor shall use AMC Architecture Tool (AMCAT) for the source of all DoDAF compliant architectures.

Participate in supporting Air Force, Joint, and Federal agencies certifications.

Develop prototypes as proof of concepts.

Subtask 4 – Software Release Process. This subtask includes CDRL C009.

The Contractor shall provide the support necessary to maintain the GDSS software via the Government’s approval processes. Because GDSS software is in sustainment, traditional Waterfall software development coupled with the approval process, as depicted in figure 3-2, is appropriate. However, some future releases, (i.e. converting functionality into individual applications) may benefit from utilizing “Agile” principles, such as Sprint Planning, Sprints, Scrums, and Incremental deliveries. The Contractor shall provide recommendations on the optimum development process. GDSS produces a Requirements Specification Agreement (RSA) through its configuration control boards and Joint Functional Review Board creation of a prioritized requirements listing. The details for the individual requirements are maintained in a Clear Quest database. (Figure 3-2 depicts the software milestone review process. The details are addressed in the Performance Work Statement [PWS] paragraphs.)Establish: FBL Government Input

· Release Requirements Government Output

· Provide initial Release Specification Agreement (RSA) Government Approval

· Creates FBL Establish: ABL Developer Support

· Define System Req.

· Define Software Req.

· Trade-offs

· Cost, Schedule, Perf Risks, & Mitigations

· Interface Req. Specifications

· Software Req. Specifications Government Approval

· Creates ABL Establish: SDBL Developer Support

· Database Design Description

· Software Design Description

· System/Subsystem Design Description

· Interface Design Description

· Draft Software Version Description Government Output

· Provide Final Release Specification Agreement (RSA) Government Approval

· Creates SDBL Establish: TBL Developer Support

· Version Release Software (computer supply end items)

· Installation & Operations Document

· Difference Guide

· Test Cases & Procedures

· Software Test Description & Report

· Final SVD

· User’s Manual

· Test Readiness Review Report Government Approval

· Creates TBL

Release Planning Define & Analyze Design Develop & Validate Bug Fix

GAT

Functional Baseline (FBL) Allocated Baseline (ABL) Software Development Baseline (SDBL) Test Baseline (TBL) Initial RSA System/Software Requirements Review/Decision Design Review/Decision Release Delivery & Acceptance Decision Iterative Demos Government Test Readiness Review

Note: There may be times where the contractor will be required to provide software developed using an agile development, testing, and delivery process.

Figure 3-2: Software Milestone Reviews MAJOR RELEASE FREQUENCY. The Contractor shall deliver two major releases per year supporting GDSS (CDRL C009). Major releases include software modifications for COTS updates, security changes, and multiple functional updates as required due to changes in business rules, interface changes, or technical configuration changes. A major release is considered a roll-up of numerous CRs into a single package. The number of CRs will be determined and prioritized by the Government COR. If Agile development is utilized, multiple incremental deliveries will be rolled up to produce a single major release. Delivery dates and schedules are developed on a continuing basis based on requirements to develop, resources available to field and maintain them, and the interdependencies with other systems and their schedules. When external events create delays, the Contractor shall demonstrate the capacity to deliver these two major deliveries and may be required to deliver code that will have to be ‘shelved’ until fielding is possible.

MINOR RELEASE FREQUENCY. The Contractor shall deliver up to 40 minor releases per each period of performance (CDRL C009). Minor releases include patches, hot fixes, small scale changes to GDSS or any of the other systems/subsystems. While not always the case, minor releases are generally short in duration, small in effort, utilizing few engineering resources, focused on a single issue or lower in complexity, often unplanned, and have little or no impact to the major release schedule. Credit for a minor release is granted when the Contractor responds to operational issues and provides a solution.

Subtask 5 – Analyze. This subtask addresses CDRLs B005, C006, C012, D001, D002, D003, and E001. The Contractor shall provide analysis support by accomplishing the following tasks:

Analyze effort required to produce system ready software. This analysis addresses the efforts in the software development process leading to the 2nd milestone; System Software Requirements Review. Contractor shall analyze individual requirements and the collective content of a planned release and provide the COR with an estimate on a rough order of magnitude (ROM) of the effort required for development (B005, E001).

A ROM (B005) may be requested by the COR for any one or more CRs for the purpose of sequencing them into releases or other reasons. ROMs shall include total hours per CR. When a ROM is requested for a release the Contractor shall provide the total hours, proposed delivery schedule and cost for the release. These ROMs are generally expected to take 1-3 weeks to complete for a standard major release. Additional time will be coordinated if refining/defining of requirements are needed. An estimated 30 ROMs per year may be expected.

When a request for a ROM is made, the Contractor shall first provide an estimate of when the ROM will be complete. The ROM completion date shall be provided before the closing of the following working day.

When requested, propose refinements and analysis to use cases, CRs (BCRs and SPRs) (CRDLs D001, D002, D003), user stories, and backlog items in accordance with business practices, processes, procedures, systems, and performance measures. The Contractor shall be responsible for assuring they are completely understood by the engineer addressing them. See attachment 3 for standards for CRs.

NOTE: For the purpose of this PWS, ‘CRs’ and ‘Requirements’ are similar and used interchangeably in discussion. While a CR may be called a requirement, they emerge from several sources, and must be refined with all the aspects of a complete requirement before development is carried out on it.

Conduct version planning sessions to refine/define software requirements specifications (CDRLs B005, C006, and C012).

As a result of meetings or analysis, propose changes to business practices, processes, procedures, systems, and performance measures (CDRL B005).

Analyze and, if appropriate, provide recommended changes to version requirements documents/lists (CDRL C006, C012).

Analyze and, if appropriate, provide recommended changes to the requirements list test pass/fail criteria (CDRL B005).

Subtask 6 – Design. This subtask addresses CDRLs C002, C003, C004, C005, C006, and C008. The Contractor shall design software to meet requirements by completing the following tasks:

The Contractor shall meet the plans, specifications, and descriptions accepted by the COR under Task 1. The Contractor shall design and document software architecture, including incorporating business rules. Additionally, the Contractor shall prepare design products to support technical review and approval of the next steps the Contractor will take in the development phase (CDRLs C002, C003, C004, C005, C006, and C008).

Conduct design reviews.

Provide sustainment and configuration management of the system-centric Physical Data Model (PDM) and Data Dictionary.

Use Government reference data source, currently provided by USTRANSCOM Reference Data Management (TRDM) System, as the authoritative source of system reference data.

Participate in the Architecture Data Integration Group (ADIG) to assist the Government with the sustainment and configuration management of the Government-provided enterprise-level Logical Data Model (LDM) and the Data Dictionary.

Assist the Government in the sustainment and configuration management of the system-centric LDM and mapping of the PDM to the Government-provided Enterprise LDM.

Submit proposed Service Definition schemas to the COR for approval prior to establishing a system/service or interface.

Participate in working group assisting the Government in the sustainment and configuration management of the Government-provided enterprise-level and system centric Interface Design Documents and Services Definition Framework.

Assist the Government in the identification, creation, update and/or deletion, and documentation of reference data, e.g., port names.

Assist the Government in selecting the appropriate software development process, e.g., waterfall, spiral, agile.

Subtask 7 – Develop. This subtask addresses CDRLs B005, C001, C009, C010, and C011.

The Contractor shall develop software using an agile development method to sustain the GDSS capabilities as noted in paragraph 2.2. The scope/size of each release is based upon the Government requirements process that prioritizes the requirements before the Contractor estimates how many requirements can be included in the release based upon constraints such as time and funding. The COR then formalizes what requirements are officially included in the release. It should be understood that all requirements are not equal in level of effort required to implement and cost to implement.

NOTE: Development shall take place in a controlled Contractor environment or Government facilities, and shall not be accomplished outside of these environments.

The Contractor shall maintain the development environment to the most current operational configuration.

Validate the intended release environment configuration prior to commencing development of a software release.

Coordinate immediately with the COR when deviations to the intended environment configurations are necessary to support development and delivery of the software release.

The Contractor shall develop, test, document, and deliver software solutions, including implementation of business rules such that it performs satisfactorily on Government-provided equipment (CDRLs C001, C009, C010, and C011).

The Contractor shall ensure that developed software does not interfere with currently fielded hardware or Government-accepted software.

The Contractor shall conduct unit code and database reviews to include its own testing to ensure developed software meets design specifications and is ready for Government testing. The Government may require the Contractor to perform its “own” testing shall include testing on the Government testing suite.

The Contractor shall ensure a schedule is maintained to encompass all long lead items approved for development and associates each long lead item to a target release schedule. Manage development of each long lead item to ensure each item is ready to incorporate into its intended release.

The Contractor shall confirm vendor software patch compatibility with existing GDSS code.

The Contractor shall analyze and upgrade the database management system.

Opportune Fixes The Contractor will likely identify errors or inefficiencies in the code being worked for either changes or fixes. The Contractor shall make opportune fixes under the following guidelines:

The Contractor shall record errors identified in the code as they are discovered. Engineers shall not open code with the intent to seek opportune fixes as part of development of a scheduled release.

The Contractor shall proceed with any fix with no further coordination if the Time Factor and either of the Test Factors are applicable.

Time Factor: The fix to the error is easy, and can be accomplished without any impact to delivery schedule.

Test Factor 1: The fix will not need to be tested in Government Test and Evaluation (GT&E) because it is a simple error or change that cannot have any impact on system operation. An example of this is to remove the ‘2’ from GDSS2, in a field or graphic that has zero interaction with other fields or computations.

Test Factor 2: The fix will not add to the expected duration of GT&E.

If any fix will push the code delivery date by only one working day and GT&E testing will not need more than one additional day, the Contractor shall proceed with the fix. In this case the Contractor shall inform the PMO before the end of the following working day after the discovery.

If any fix will drive the code delivery date by more than one working day or GT&E testing of that fix will require more than one additional day, the Contractor shall coordinate with the PMO and provide an expected impact on schedule or testing. The decision to proceed in this case shall be at the discretion of the Program Manager (PM).

If any accumulation of minor fixes result in delays as described in (the previous paragraph) above, the Contractor shall notify the PMO and provide estimates; any further opportune fixes that will impact the schedule shall cease until approval is granted by the PM.

Note: The Contractor shall advise the PMO as soon as practical of any changes made so that GT&E can be prepared for additional items to be tested.

The GDSS PMO may identify specific items to be fixed or enhanced as opportunity arises. During normal duty hours the GDSS PMO shall respond with Government approval or disapproval within an hour of any request for opportune fixes (when required).

Innovations The Contractor shall provide a short summary (B005) describing opportunities for incorporating innovations into GDSS every six months. Include with each summary a ROM, schedule, and impact to existing work cost and schedule. Innovations for the purpose of this paragraph are similar to the ‘opportune fixes’ noted in the previous paragraph, but larger in scope. The Contractor shall propose innovations that improve performance, functionality, or maintenance. If the innovation is approved by the COR, the Contractor shall submit a technical proposal (CDRL B005/E001) identifying the tasks to be performed, in process reviews to be conducted, testing to accomplished, event schedule, acceptance criteria, and Service Summary requirements. Included with the technical proposal, is a Technical Management Work Plan (Authority: DI-MGMT-81117), cost proposal crossed reference to the technical proposal and the Work Plan. These proposals shall be limited to major changes or several smaller related changes. The innovations may apply to software or hardware or a combination.

Subtask 8 – Emerging Technology Integration The Contractor shall integrate emerging technology into the software/firmware/hardware solutions supporting GDSS.

Subtask 9 – Test. This subtask addresses CDRLs B006, B008, and C001. The Contractor shall conduct testing and complete the following tasks:

Produce and maintain test cases and software test descriptions (CDRL C001).

Perform testing (e.g. unit, system, regression, security, performance) to verify that the software meets test pass/fail criteria for each requirement contained in the RSA (CDRL B008).

Verify that the software does not interfere with currently fielded hardware or Government accepted software.

Conduct and participate with the COR on integrated testing, to include regression testing, to ensure the developed capability is suitable for delivery to the COR as the test baseline (as defined in the Defense Acquisition Guidebook).

Participate and document with the COR to complete any DOD, Joint, Air Force or other governing body certification or accreditation testing for all security classification domains.

Contractor shall host collaborative testing (Government contracted testing of pre-release software). A Memorandum of Agreement will be established between the Contractor, the COR, and the System Support Contractor (currently known as ‘AISS’), within 90 days of contract award.

Provide to the COR all testing artifacts (e.g. test results, Software Test Descriptions, Test Readiness Review Report) required to complete all Government acceptance testing (CDRL B006).

Subtask 10 – Create the “What’s New Document.” See sample document of Attachment 1. This subtask addresses CDRL C011. The Contractor shall provide a “What’s New Document” describing the changes made for the applicable release. This document shall be written in language understandable to the functional community.

Subtask 11 – Deliver. This subtask addresses CDRLs C007, C009 and C010.

Deliverable is disk copies of code developed, to include source code and executables and all tools necessary (CDRL C009). The Contractor shall include with each version release and patch, an installation plan, a programmer’s reference guide providing text description of the Application Programming Interface (API) data structure and algorithms, and the Software Users Manual (SUM), which shall include the GDSS User’s Manual (GUM) (CDRL C007). It is important for the code documents/reference guides to be thorough, but not so verbose that it becomes difficult to maintain them.

The Contractor shall prepare two copies on CD/DVD (or electronically), the executable software to be transitioned to the support site, including any batch files, command files, data files, environment group policy, or other software files needed to install and operate the software on the target computer(s).

Each CD/DVD shall contain the contract number, order number (if applicable), the title “GDSS”, version release number (patch number, if applicable), date the CD was populated, and the number of CDs (e.g., 1 of 6, 2 of 6) for each copy of the CD. Each CD shall contain, either on the CD or in a Read Me file, the following statement: “The Government has unlimited rights to use, modify, reproduce, perform, display, release, or disclose the software delivered herein, in whole or in part, in any manner, and for any purpose whatsoever, and to have or authorize others to do so.”

Format – Executable and operational within GDSS operating system.

Computer compatibility requirement – Meets GDSS system approved baseline configuration for acceptance testing.

The GDSS Installation Plan (CDRL C010) shall at a minimum include the events/installation schedule (with site POC), site preparation procedures, installation procedures (including corrective actions if a problem arises), coordination plan (detailing how functional and site communications will be done and what outages are required), installation checklist, and notification plan (advertising that the installation is happening, who the POCs are, explaining the sequencing as to when, where, and how installs will be performed).

TASK 5 – Asset Management. The Contractor shall provide asset management for the Government Furnished Property (GFP) provided under this contract. GFP includes Government Furnished Equipment (GFE), and software provided by the Government. Meeting this task requires the following per DOD guidance:

Subtask 1 – Government Furnished Equipment (GFE). This subtask addresses CDRL B004.

Maintain equipment, ship and receive equipment, and maintain shipping, receiving, and accounting documentation (CDRL B004). Includes:

Prototype suite – rough description of the equipment, spell out purpose so it is clear what the GDSS PMO buys and what the using unit buys. Add in a ROM what the refresh rate is, who does the maintenance on it, and how the GFE is purchased.

Laptops and/or desktop computers – rough description of the equipment, to include make, model, characteristics, and purpose.

Provide inventory tracking, planning, and maintenance coordination.

Track maintenance and warranty status of GDSS equipment.

Maintain Government equipment accounts, Automated Data Processing Equipment (ADPE), in the Assets Inventory Management (AIM) in accordance with Air Force Instruction (AFI) 23-111 Management of Government Property in Possession of the Air Force, 7 Jan 2011 and Air Force Manual (AFMAN) 23-220 Reports of Survey for Air Force Property, 1 Jul 1996.

Individuals appointed to manage hardware shall comply with AFI33-11, Information Technology Hardware Asset Management, 27 Jan 2011.

Coordinate and maintain GDSS equipment.

Conduct Government property inventory annually or as requested by the COR.

Maintain familiarity with the Information Technology Asset Management (ITAM) Handbook.

Implement Asset Inventory methods to assist the COR in maintaining asset tracking and compliance with policy (CDRL B004).

Subtask 2 – Software. This subtask addresses CDRL B004.

The Contractor shall maintain software furnished by the Government, ship and receive software when required, and maintain software documentation, licenses, and copies. The Contractor shall maintain a comprehensive and readily available list of all software furnished by the Government to include license numbers, product keys, and track all expirations if applicable (CDRL B004).

TASK 6 – Security Engineering Certification and Accreditation. The Contractor shall provide security engineering certification and accreditation by accomplishing the following tasks:

Subtask 1 – Certification and Accreditation Support. The Contractor shall provide security certification and accreditation support to GDSS PMO by providing the following services:

Provide the GDSS PMO inputs necessary to obtain and maintain the Authority to Operate (AtO), Authorization to Connect (AtC), Certificate of Networthiness (CoN), and Defense Information Accreditation and Certification Approval Process (DIACAP) processes.

Advise and consult with the Program Manager on matters of information and system security.

Provide a mitigation recommendation to the COR within 24 hours after the DIACAP non-compliance became apparent to the Contractor.

Provide a recommendation to the COR to correct DIACAP non-compliance within 10 working days.

Subtask 2 – Vulnerability Management The Contractor shall support PMO in responding to the United States Cyber Command (USCYBERCOM) Information Assurance Vulnerability Alert (IAVA);, and keep abreast of Air Force Network Operations (AFNETOPS) Network Tasking Orders (NTO), and Notices to Airmen (NOTAM).

The Contractor shall support the development and maintenance of the GDSS Ports, Protocols and Services (PPS) Matrix to ensure proper registration with the Department of Defense and AFNETOPS.

Subtask 3 – GDSS Security and Documentation Support. This subtask addresses CDRL B005.

The Contractor shall provide to the COR reviews and reports on proposed changes to system hardware, software, or environment for impacts to the GDSS security posture and ensure changes do not violate the criteria for system accreditation (CDRL B005).

TASK 7 – Operations Support Subtask 1 – Fielding Support. This task addresses CDRL A006. The Contractor shall provide the following (some of these subtasks must be accomplished in advance of fielding):

Research for new equipment specifications for upgrade efforts.

Inputs related to the GDSS installed sites and coordination of logistical support for existing and new…