Final_PWS_26_Jan_15.doc

Performance Work Statement

26 January 2015

Air Mobility Command, Directorate of Communications, MAF Systems Division

Mission Systems Support Branch, AMC/A6IS

1.0 Background

1.1 System Description

GDSS is a United States Transportation Command (USTRANSCOM)-funded system providing Mobility Air Forces (MAF) Command and Control (C2) information for the Defense Transportation System (DTS) to combatant commanders throughout the full spectrum of military operations. This system falls under the program management of Air Mobility Command, Directorate of Communications, C2 Mobility Systems Division (AMC/A6I). As the MAF's principal C2 system, the operational imperative is to deliver robust capabilities to C2 MAF forces using a net-centric environment, allowing access and information sharing across classified and unclassified domains. Direction given by the Secretary of Defense (SECDEF) assigning USTRANSCOM responsibility for Distribution Process Ownership increases the need for greater theater and strategic mobility operations and control. GDSS will interoperate with Air Force and Joint C2 systems, and is an integral part of USTRANSCOM's DTS. As the USTRANSCOM, Joint, and Air Force C2 architectures mature, GDSS will be consistent with the USTRANSCOM, Joint, and United States Air Force (USAF) C2 Communities of Interest (COI).

This C2 applications suite is used by MAF wings, units and enroutes to disseminate mobility mission plans, schedules and provide situational awareness through execution management. Units turn the mission plans into schedules by assigning aircrews and aircraft to the missions. Crews are assigned by considering factors such as mission requirements, training requirements (currency and qualification), and availability. As movement requirements, environment factors, resource statuses and operational priorities change, the planned missions or those in execution are re-planned. Units use the unit-level mission planning functionality to plan missions and to schedule aircraft and crews. Worldwide mobility users of GDSS manage their C2 tasks through a specified sequence of events and report their portion of the execution of the missions by reporting the status and movement of missions to all C2 users and, most importantly, to AMC’s 618th Air and Space Operations Center (AOC) (Tanker Airlift Control Center (TACC)), and to USTRANSCOM. All data is available to MAF users in the context of the role they perform in the C2 system, and to other users of the DTS. GDSS automates the majority of air mobility tracking procedures that were previously performed by multiple legacy systems. The latest technically refreshed version of GDSS contributes multiple information services in the Mobility Enterprise Information Services (MEIS) environment to enhance data sharing with multiple DoD C2 and In-transit Visibility (ITV) systems. These services are used to ensure data synchronization in the MAF, the DTS and the key Theater AOCs. The services directly linked to the AOC Weapons System are managed by AMC/A6. GDSS is a Microsoft Windows-based system with an Oracle database engine. Initiatives are underway that may change this to an enterprise solution.

1.2 Operational Environment

GDSS is the primary hub of the MAF’s C2 capabilities. It operates in an event-driven, scalable global architecture with near-real-time replication to multiple security domains. The newest version of GDSS extends the C2 capabilities of AMC Headquarters to individual AMC active, guard, and reserve units at fixed and deployed locations providing coordination with appropriate functional areas at Headquarters AMC, 618th Tanker Airlift Control Center (TACC), supporting commands, and deployed forces. GDSS exchanges C2 information from Air Force Major Command (MAJCOM) to MAJCOM and from MAJCOM to the unit level, as well as joint information sharing; GDSS provides integrated, automated support for visibility of air mobility assets. It fully supports the MAF’s centralized control, decentralized execution philosophy for C2 of its airlift and aerial refueling assets. GDSS is the critical MAF information link to the Falconer Air and Space Operations Centers (AOCs) for Air Tasking Order production. Additionally, GDSS is utilized by HQ Air Force Reserve Command (AFRC), HQ Air National Guard (ANG), and every MAJCOM and Unified Command for visibility of mobility assets, and, in some cases for execution. GDSS optimizes Mobility partnerships in Joint/Coalition C2. It provides C2 the ability to integrate and direct the execution of theater and strategic mobility forces operating in the Area of Responsibility (AOR)/Joint Operating Agreement (JOA). GDSS also provides training capabilities for operational organizations and for the U.S. Air Force Expeditionary Center (USAFEC).

1.3 Management Environment

The GDSS program operates as a team between the Government and multiple contractors (see Figure 1, below). The team consists of the Government and all contractors tasked to provide products and/or services during requirements analysis, design, development, implementation, operations, and maintenance of the GDSS system. Under this contract, HQ/AMC A6 will acquire the deliverables needed to sustain and technically refresh GDSS to meet the U.S. Air Force’s requirements. In addition to sustainment, the contractor will also be required to provide Level III application software support and, prior to contract end, phase-out support. The contractor shall provide the management, personnel, facilities, equipment, and supplies necessary to meet the terms and conditions of the contract. GDSS and GDSS-related applications are developed in traditional waterfall style of development, or in an Agile environment, or may be done in a composite mix of the two. It is the responsibility of the Program Management Office (PMO) to maintain a blend of development effort within the confines of the resources required, or to authorize additional resources based on priority of activity under development.

Figure 1, Program Offices

2.0 Objectives

The Government requires continued support of system/software engineering services for the GDSS application suite to meet operational support performance requirements, sustainment, and continuous technical refreshment of the system in the most cost-effective manner over the total life cycle of the contract. The GDSS suite is an application infrastructure deployed on the planned 10 classified/unclassified enclaves, located in the Continental United States, Europe, and the Pacific theater, and is accessed from approximately 250 fixed and mobile locations supporting all Combatant Commands, Military Services, and other federal agencies. Performance and sustainment activities must support a minimum of 20,000 users, with a minimum of 7,000 log-ins/day, with a minimum of 2,000 concurrent events, processing no less than 2 mission updates per second and over 750,000 transactions/day. Installation of software releases must occur with no interruption to operations. The contract services provided must include system/software engineering and other related activities (e.g., requirements analysis, architecture, engineering diagrams, and documentation) that ensure GDSS adheres to applicable Government standards. The contractor may be required to assist the Government to interact with Government agencies (e.g., Joint Interoperability Test Center (JITC), Defense Information Systems Agency (DISA), 375 Communications Group (375CG), integration contractors, and designated activities) to ensure interoperability, system certification and accreditation are maintained. Software engineering, sustainment, and technical analysis for MAF C2 systems is performed in a collaborative environment with members of the Government operations community, architecture and engineering, other MAF C2 developers, the Air Operations (AO) COI, and other entities. The collaboration spans the entire life cycle of planning, requirement analysis, design, engineering, experimentation, exercise, testing, and fielding. The contractor will participate in these activities as a normal course of business, as directed by the Government. At the Government’s direction, the contractor shall also support advanced engineering activities, Joint and Air Force experiments and exercises requiring GDSS to further warfighter capabilities. The GDSS application suite must comply with applicable Information Technology (IT) standards contained in the Department of Defense Information Technology (DoDIT) Standards and Profile Registry (DISR) Online https://acc.dau.mil/CommunityBrowser.aspx?id=148577&lang=en-US. GDSS, as appropriate, must maintain extensible markup language (XML) tags for addition to the DoD XML Registry and Clearinghouse for all data that will be exchanged, or has the potential to be exchanged. GDSS, as a USTRANSCOM DTS, will refer to and maintain adherence to the USTRANSCOM Enterprise Architecture (EA) as appropriate during operations and maintenance activities. GDSS must also comply with all relevant DoD security requirements, such as Defense Information Assurance Certification and Accreditation Program (DIACAP), DISA Security Technical Implementation Guides (STIGs), Air Force Network Operations (AFNETOPS) Maintenance Tasking Orders (MTOs), and Information Assurance Vulnerability Alerts (IAVAs), and operate in the Standard Desktop Configuration (SDC) environment with Host-Based Security System (HBSS).

Figure 2, Software Sustainment Process

The contractor, using the software sustainment process highlighted in Figure 2, above, shall:

· Produce and deliver releases and patches to sustain GDSS capabilities. This will include the capacity to deliver no less than 20 out-of-cycle deliveries [Higher-headquarters downward-directed requirements, AF Network Operations (AFNETOPS) Maintenance Tasking Orders, security updates, Commercial-Off-The–Shelf (COTS) vendor patches, warm/hot fixes, etc.], and one maintenance releases in a year. The GDSS application suite includes:

· Globally distributed, event-driven, scalable architecture with near-real-time data replication (average performance < 25 sec between 4 enclaves)

· Thick and Thin client applications

· Host and database applications

· Data Management tools

· Coalition solutions (international partner solutions) – including applications and interfacing with cross-security domain products

· Exercise Management Console (EMC) client and server applications

· Disconnected operations application [e.g. Mobility Services Device (MSD)]

· Mobility Enterprise Information Services support (MEIS)

· Aviation Operations Risk Management (AvORM)

· Interoperability and data sharing with the Global Information Grid (GIG)

· Developer-to-developer factory test environment Mobility Enterprise Developer's Network (MOBNET)

· Air Operations Community of Interest services environment

· XML Security Gateway

· Interfaces to Enterprise Services Management

· Interfaces to Cross-security domain solutions

· All training environments (e.g. School House, Det 1) to include training console client and server applications

· Reports Generator

· History environment and supporting applications

· User Account Management System, existing interfaces between GDSS and previous versions

· Logbook applications

· Without impacting approved release schedules, perform and document requirements analysis with Government working groups to provide rough order of magnitude (ROM) development level of effort for all priority 2 & 3 Change Requests (CRs).

· Develop task activity schedules supporting each release or task using Government furnished processes and tools and provide these schedules to the Government with associated resources annotated to support each task and milestone.

· Manage concurrent releases for multiple deliveries. Maintain configuration control by applying patches/fixes to problems identified in the field or from Government testing to all applicable baselines within the GDSS applications suite, whether in development or testing, to prevent recurrence in future releases. Perform technical requirements analyses by evaluating COTS and Government off-the-shelf (GOTS) products for applicability to the GDSS environment and provide analyses, pros/cons, and recommendations to the Government.

· Participate in enhancing system integration within the GDSS application suite as requested by the Government.

· Develop a comprehensive testing environment which allows Government oversight in designated timeframes in-factory prior to Test Readiness Review, and provide capability to participate in Government acceptance testing activities as required.

· Provide 24/7 Level III GDSS, MEIS/MGOP, and AvORM application support.

· Provide release training, such as difference training, to the MAF C2 training team and testers, which includes opportunities for training team to have “early look” at software under development, and observation at developer test events.

· At the direction of the Government, participate in mobility enterprise and mission-partner working groups, engineering and design meetings, testing activities, and fielding planning and execution meeting.

3.0 Scope

· Task Area 1 - Enterprise IT Policy and Planning

· Task Area 2 - Custom Application Development

· Task Area 3 - Operations Support

· Task Area 4 – Reserved

· Task Area 5 – Reserved

· Task Area 6 – Reserved

· Task Area 7 - Transition/Phase Out

· Task Area 8 – Other Direct Costs (ODCs)/Travel

4.0 Performance Requirements

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. The Contractor shall accomplish the following tasks:

4.1 Task Area 1 - Enterprise IT Policy and Planning

This task area provides technical and programmatic support to assist departments and agencies with all aspects of planning, engineering, fielding, and operating IT systems and resources. It provides technical and programmatic support for review, analysis and coordination of processes, policy, doctrine, directives, regulations and implementation of instructions. The Contractor shall accomplish the following tasks:

4.1.1 Subtask 1-1 – Documents

Prepare, submit, and/or maintain the following documents [Contract Data Requirements List (CDRL) references provided]:

Plans and agreements:

· Technical & Management Work Plan

(A001)

· Phase-Out Plan

(A006)

· Software Development Plan

(B003)

· Quality Program Plan

(B015)

· Configuration Management Plan

(B016)

· Memoranda of Agreements

Management reports:

· Funds & Labor Hour Expenditure Report

(A003)

· Agenda and Minutes

(A004)

· Equipment Inventory Records

(A007)

· Scientific and Technical Reports

(A008)

· Software Test Report/Software Test Description

(B001)

Procedures & descriptions:

· Test Procedures/Cases

(B002)

· Interface Requirements Specification

(B004)

· Database Design Description

(B007)

· Software Design Description

(B008)

· Software Version Description

(B009)

· System/Subsystem Design Description

(B011)

· Computer Software End Items

(B014)

· Baseline Change Request (BCR)

(B024S)

· Software Problem Report (SPR)

(B019)

· Installation and Operations Document

(B020)

· Software Requirements Specification

(B018)

· Other:

· Engineering Change Proposal

(B012)

· Request for Deviation

(B013)

4.1.2 Subtask 1-3 – Program and Project Management

(A003, A004, B003, B015, B016 )

· The contractor shall support Technical Interchange Meetings/Reviews (including conferences, program meetings and other workgroup meetings) and will generate presentation materials as requested in order to aid in the discussion of technical issues. For meetings the contractor hosts, the contractor will provide agendas, meeting minutes, and track action items associated with the aforementioned meetings/reviews.

· The contractor shall support Agile Development/ Sprint, and other Agile related meetings. The contractor will host demonstrations and may be required to host customer testing.

· The contractor shall also provide agendas, meeting minutes, and track action items associated with the aforementioned meetings/reviews.

· Host and attend meetings as requested,

· Contract and Program Status Review to review and update Contractor’s Technical Management Work Plan (A001), brief progress of each assigned task, address schedule tracking concerns, and to solicit input and concurrence of work being performed by the Contractor

· Task Management Review

· Program Management Review

· Support preparation for USTRANSCOM Corporate Governance Process (CGP)

· Support ad hoc teams as directed by the PMO

· Support requirements clarification meetings

· Support program metrics development, capture, and reporting

· DoD Information Assurance Certification and Accreditation Process (DIACAP) support

· C4/IPS support

· Technical Working Group (TWG) support

· The Contractor shall utilize MIL HDBK 61A and EIA 649 guidance to institute and maintain a Configuration Management (CM) process to ensure engineering and administrative disciplines (which include configuration identification, control, status accounting, and auditing) are implemented for all development activities. The Contractor shall identify the configuration of all work products (to mean baselines as well as other supporting work products); systematically control changes and maintains 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. In addition to the general requirements described above, the Contractor shall accomplish the following:

· Initially, assume responsibility for management of incumbent developer’s configuration management documentation and, process and maintain a “ready for phase-out” copy

· Establish and employ internal configuration management oversight, processes, and procedures for all sustainment work products

· Identify the configuration items, 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 controls 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; 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 to support the integrity of the configuration baselines

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

· Perform a configuration audit prior to delivery of any baseline or work product to ensure accuracy and completeness of the deliverable

· Coordinate closely with Government CM team to ensure continuity of configuration management processes and practices are maintained and controlled

· Provide documentation and control measures to ensure that all systems are properly documented in accordance with approved Federal and DoD standards. The contractor shall ensure that the inventory and use of system documentation is correct and up-to-date, including identification of missing, outdated, or invalid documentation.

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

· The Contractor shall provide a Quality Control Program. 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.

· The Contractor shall establish, integrate, and report the program-wide Work Breakdown Structure (WBS) to lower-level WBS as depicted in Table 6.1.3-1. The WBS shall align with the tasks described in this Performance Work Statement (PWS) and as described in MIL-HDBK-881, Department of Defense Handbook Work Breakdown Structure, which may be further defined or modified by the Program.

Table 1. Work Breakdown Structure:

GDSS

Enterprise IT Policy and Planning (4.1)

Documents (4.1.1)

Program and Project Management (4.1.3)

Custom Application Development (4.2)

Application Development (4.2.1)

Requirements Analysis (4.2.1.1)

Application Software Design (4.2.1.2)

Traditional Software Maintenance (4.2.1.3)

Support For GDSS 3.0.3, 3.0.4 and MEIS 3.3.3 (4.2.1.4)

Product Testing (4.2.1.5)

Product Integration and Support (4.2.1.6)

Technical Support (4.2.2)

Agile Application Development (4.2.3)

Requirements Definition/User Stories, and the Envisioning Process (4.2.3.1)

Collaborate to Develop User Stories (4.2.3.2)

Iterations (4.2.3.3)

Releases (4.2.3.4)

Product testing (4.2.3.5)

Operations Support (4.3)

Transition (4.7)

4.2 Task 2 - Custom Application

As part of sustainment, and in response to changes in business practices, new technology, security requirements, commercial product obsolescence, mission partner requirements, customer requirements, faulty functionality, or other driving factor, the contractor shall design, develop, document and test custom applications and their infrastructures including but not limited to the items listed below.

· Develop and document software architecture and design, including business rules for the capacity to deliver no less than 20 out-of-cycle deliveries (Higher-headquarters downward-directed requirements, AFNETOPS Maintenance Tasking Orders, security updates, Commercial-Off-The–Shelf (COTS) vendor patches, warm/hot fixes, etc.), and one maintenance releases in a year.

· Conduct initial and final capabilities design reviews (includes data exchanges and services) – in progress reviews maybe required depending on risk assessments

1. Initial reviews include formal requirements reviews

2. Final reviews include deployment/implementation requirements (e.g., additional hardware)

· Design database and file structures and develop Data Model (PDM) products in accordance with (IAW) AMC A67 Pamphlet 33-1 and USTRANSCOM Data Management Handbook

· Design code, test, and document solutions

· Refine and document business rules as required

· Finalize test, conversion, and implementation plans

· Prepare and deliver software releases including all required components to kit, compile, install and configure all software deliverables to the Government. This includes, software release kits, Component Usage Procedures CUPs, Component Installation Procedures CIPs and software code

· Provide documentation and control measures to ensure that all systems are properly documented in accordance with approved Federal and DoD standards. The contractor shall ensure that the inventory of system documentation and use is correct and up-to-date, including identification of missing, outdated or invalid documentation.

· When requested, provide preliminary design engineering and coding on planned future and advanced software releases concurrently with releases in various stages of coding, testing, and delivery.

4.2.1 Subtask 2-1 Application Development

(, A008, B001, B002, B003, B004, , B007, B008, B009, , B011, B014, B018, B019, B020, B024)

The following breakdown identifies the services required to sustain the GDSS application suite environment:

4.2.1.1 Requirements Analysis

The contractor shall perform the following required activities for this service under this task area:

· Refine use cases/user stories and exit criteria provided for functional requirements by the Government. Create when directed.

· Coordinate and cost Release Specification Agreements (RSA) in accordance with PMO change management procedures; no requirement can be added to the Version Release List (RSA) that has not been vetted through the requirements analysis without Government approval.

· Propose (when necessary) refinements and analysis to use cases, BCR and SPR in accordance with business practices, processes, procedures, systems, and performance measures; provide recommended changes to the requirements list exit criteria.

· Recommend system architecture changes, hardware and/or software, to take advantage of the infrastructure environment provided.

· Assist the Government with the development of schedules and implementation plans with definable deliverables, including parallel operations where required.

· The contractor shall provide a rough order of magnitude (ROM) development level of effort for all priority 2 & 3 Change Requests (CRs), estimated at 1,154 total (251 Priority 2, 903 Priority 3). Each CR ROM will be assigned one of six levels of development effort, as follows: Very Small < 16 hours, Small = 16-40 hours, Medium = 41-80 hours, Large = 81-160 hours, XLarge = 161-320 hours, XXLarge > 320 hours.

4.2.1.2 Application Software Design

Design software to meet requirements by meeting the plans, specifications, and descriptions accepted by the Government under Task 1; and the Government-approved analysis conducted by the contractor. The contractor shall perform the following required activities for this service under this task area:

· Design and document software architecture, including incorporating business rules for no less than 20 out-of-cycle deliveries (Higher-headquarters downward-directed requirements, AFNETOPS Maintenance Tasking Orders, security updates, COTS vendor patches, warm/hot fixes, etc.), one maintenance, releases in a year.

· Refine and document business rules as required. Integrate data and business rules with other AMC data integration efforts.

· Prepare software design products to support technical review and approval of software direction and decisions to include versioning of GOTS- and COTS-embedded software.

· Conduct initial and final capabilities design reviews (database, file structures, software architecture, data exchanges and services, web). In progress reviews may be required depending on risk assessments.

· Initial reviews include formal requirements reviews

· Final reviews include deployment/implementation requirements (e.g. additional hardware)

· Use Government reference data source (currently provided by USTRANSCOM Reference Data Management (TRDM) System) as the authoritative source of system reference data. Contractor shall assist the Government in identification and documentation for creation, update, and/or deletion of reference data requirements.

· Assist the Government in the sustainment and configuration management of the system-centric LDM and mapping of the physical data model (PDM) to the AMC Enterprise LDM thru correspondence and meetings; as directed by the PMO.

· Review Government-provided Service Definition schemas/ web-service description language (WSDL) and proposed changes for approval to the Government prior to establishing a System/Service or Interface.

· Engineer the MAF history system as a knowledge warehouse, cleansing information to support operational and trend analysis, metrics and other related information engineering activities

· Participate in the Systems/Services Development Working Group to assist the Government in the sustainment and configuration management of the AMC enterprise-level and system-centric Interface Design Documents, Services Definition Framework; and other documents as directed by the Government.

· Support implementation of multi-threaded enterprise services architecture using standard service schema [XML schema definitions (XSDs)] and web-service description language (WSDLs)

· Identify methodologies for centralized management of distributed database environments

· When directed by the Government, evaluate other functional areas and their associated standard/common/migration systems to identify opportunities for cross-functional data integration and data sharing.

· Design technical solutions to operate within the GDSS framework, and interoperate with other systems as directed by the GDSS PMO

· Define technical design and solutions updates are compatible with DoD infrastructure, e.g., Standard Desktop Configuration, compatible with operational environment

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

· Ensure that the technical designs and system elements comply with the Defense Information Technology Standard Registry (DISR)

· Design software solutions with security engineering included from initial high-level design through testing and delivery. Use government-directed application security standards and security testing and validation tools, and in the absence of government direction, use equivalent industry best practice testing and validation and tools.

· Public Key Infrastructure (PKI) for users, clients and servers; Single sign-on for MAF C2 environment (including role management)

· Code that meets or exceeds best practices for secure code development

· Best practices and Defense Information Systems Agency STIGs, AFNETOPS MTOs, Joint Task Force Global Network Operations (JTF-GNO) Information Assurance Vulnerability Alerts (IAVAs), and security testing and assessment requirements.

· Integrate with mandated security requirements, such as Host-Based Security System (HBSS) and auditing

· Design human-machine interfaces in accordance with Government-provided or directed human engineering standards.

4.2.1.3 Traditional Software Maintenance and Source Code Delivery:

Sustain GDSS capabilities described in existing system or software documentation and implement downward-directed, requirements identified in the approved Version Control Document; confirm vendor software patch compatibility with existing GDSS applications. The contractor shall perform the following required activities for this service under this task area:

· Maintain development environment to the most current operational environment configuration:

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

· Coordinate immediately with the Government-designated representatives when deviations to the intended environment configurations are necessary to support development and delivery of release software

· Plan, design, implement, and maintain ad hoc reporting capability (e.g., Reports Information Database Library (RIDL).

· Develop, test, and document software solutions, including implementation of business rules such that it performs satisfactorily in accordance with the design criteria specifications.

· Develop, test, and document software solutions with security engineering included from initial high-level design through testing and delivery. Use Government-directed application security standards and security testing and validation tools, and in the absence of Government direction, use equivalent industry best-practice testing and validation and tools.

· Develop human-machine interfaces in accordance with Government-provided or directed human engineering standards.

· Ensure that developed software does not negatively impact currently fielded Government-accepted software. Build solutions to ensure software solutions can be integrated into the intended system configuration without interruption of services or shutdown of the MAF C2 environment (e.g. enclaves) – this is sometimes known as non-service interruption (NSI).

· Provide sustainment and configuration management of multiple software release baselines by rolling updates/patches/fixes in Government testing forward to baselines in coding or contractor testing.

· Provide sustainment and configuration management of the system-centric Physical Data Model and Data Dictionary, utilizing the Government-provided AMC Logical Data Model and AMC Data Dictionary.

· Maintain databases that are compliant with AMC data/vocabulary standards or recommend changes.

· Conduct unit code and database reviews to ensure developed software meets design specifications and is ready for developer testing.

· Ensure a schedule is maintained to encompass all long-lead items approved for development and associate each long-lead item to a target release. Manage development of each long-lead item to ensure each item is ready to incorporate into its intended release.

· Maintain and support a developer-to-developer factory-testing environment hosted outside the .mil domain and available to other vendors and agencies for interoperability and validation testing of information services and interface.

· Prepare and deliver software releases including all required components to kit, compile, install and configure all software deliverables to the Government. This includes: software release kits, CUPs, CIPS and software (source) code.

4.2.1.4 Support For GDSS v3.0.1, 3.0.2, 3.0.3, 3.0.4, AvORM v2.9.6p2 & MEIS v3.3.1, 3.3.3

Complete the GDSS and MEIS application modifications necessary for successful fielding of GDSS 3.x. Completing the required task includes successfully accomplishing the following:

· Correct any additional items identified as “must haves”* during any of the final testing activities to include continuous ad-hoc testing.

· Correct any additional items identified as must haves during final fielding preparations.

· Provide the AISS II contract with advice on or suggested modifications to the Release Transition Procedure (RTP) and “must fix”** support to ensure the successful fielding of GDSS baseline and any additional items identified as pre-fielding must haves. Provide the AISS contract with advice on or suggested modifications to the Release Transition Procedure (RTP) and must fix support to ensure the successful fielding of MEIS baseline and any additional items identified as pre-fielding must haves.

· Correct any additional items identified during actual fielding process of any system, application, function, or program required for the successful operation of GDSS and MEIS or actual fielded baseline within 0-5 days.

· Develop, test and deliver all items required for a successful fielding (must haves) prior to fielding. Develop, test and roll into the fielding those items that surface during the fielding process and are identified as must haves. Items not deemed as must haves for the successful fielding of GDSS and MEIS are not required to be delivered during the final testing and/or actual fielding process.

*Note: A “must have” means that there are work-around but the software is not functioning exactly as intended and this presents a difficulty that is unacceptable to the customer because it makes his day to day work much more difficult.

** Note: A “must fix” means that the software will not work as intended.

4.2.1.4.1 Provide support for the MEIS environment

Support GDSS Object Processor (GOP) and the MOBNET environment sustainment without adverse effect to GDSS sustainment. Releases for MEIS and GOP will be managed, developed and delivered separate from the GDSS sustainment effort unless otherwise identified by the Government.

On-going Agile Transportation for the 21st Century (AT21), Integrated Data Environment-Global Transportation Network Convergence (IGC), Mobility Analysis Processing (MODSS), Command and Control Messaging, AMC History System, Dynamic Mission Replanning (DMR), Global Aircrew Management (GAM) and Global Aircrew Scheduling (GAS) initiatives will not require the development of new enterprise information services and will be limited to security and hot/warm fixes services). GDSS may not be the system of record for all information that will be stored in the MEIS environment; however, that does not mean GDSS will not become a consumer of that same information.

Contractor will produce MEIS and GOP patches as required by the Government with coordinated delivers over three months. Below describes high-level concept features for planning the work required for MEIS and GOP support during the GDSS contract.

· Service Enterprise Master Test Plan and Procedures

· Work with the Enterprise Testing Working Group to improve overall testing procedures and validation processes.

· Consolidate testing procedures from various sources (ex. PMOs, developers, test team, COIs, etc.) for master test plan.

· Evaluate and integrate the Exercise Management Console as a service testing tool.

The above sustainment efforts will be worked through the agile requirements backlog based on priorities. Features may be worked across a given service, not necessarily the environment. Effectively, MEIS 4.0 will be a ‘plug and play’ environment where additional services can be added to the framework and inherit features like replication, journaling, transaction monitoring, notification processing. The GOP 4.0 environment will go through the next evolution of decoupling from the MEIS 4.0 – GOP 4.0 will become a standard Services Oriented Architecture (SOA) producer and consumer.

4.2.1.4.2 Aviation Operational Risk Management (AvORM)

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

4.2.1.5 Product Testing

Test GDSS capabilities described in existing system or software documentation to ensure the solutions for the downward-directed, requirements identified in the approved version control documents are compatible with existing GDSS applications. The contractor shall perform the following required activities for this service under this task area:

· Provide technical support to early operational assessments, developmental, security, performance, interoperability, acceptance and operational testing. Produce a test management strategy for developmental testing (includes development, security, interoperability and performance) based on the RSA and the impacts to the products and capabilities being effective during the development process.

· Produce a detailed test plan for development, security, interoperability and performance which:

· Identifies interdependences of application software, data management, COTS components, Government-Furnished Equipment (GFE), or any other related components

· Validates the exit criteria identified for each requirement on the RSA

· Produce and maintain test cases and software test descriptions that references the RSA and:

· Verifies that the software matches the RSA

· Verify that the delivered software operates according to specifications to include any modification identified in the RSA

· Verifies that the delivered software does not break/interfere with currently fielded Government software

· Verifies that delivered software meets the exit criteria (pass/fail criteria) for each requirement contained in a RSA

· Identifies interdependences of application software, data management, COTS components, GFE, or any other related components

· Perform internal testing (e.g., unit, system, regression, security, performance) and submit results along with recommendations for improvements or fielding.

· Conduct Collaborative Testing (ColT) with the Government’s testing organizations prior to delivery of code to the Government.

· Perform regression testing upon porting the software to the Government-provided prototype environment.

· Conduct and participate with Government representative in integrated testing to ensure the developed capability is suitable for delivery to the Government as the test baseline (as defined in the Defense Acquisition Guidebook) ) to include unit, system, regression security, and performance testing in an environment representative of fielded operations provided by the Government. System load and number of missions and transactions will be representative of actual field operations.

· Develop Security Test and Evaluation (ST&E) plans for every release to ensure compliance with security directives and requirements

· Participate with Government representatives in validating a software release.

· Allow participants from members of the Government or Government representatives during system, performance, and regression testing to assist in determining the readiness of the identified deliverable prior to delivery to the Government.

· The testing of software releases can be integrated into the intended system configuration without interruption of services or shutdown the MAF C2 environment (e.g. enclaves) – this is sometimes known as non-service interruption (NSI).

· Participate and document with the Government as required to complete any DoD, Joint, Air Force, or other Governing body certification or accreditation testing for all security classification domains. This will include, the existing requirements for Government acceptance testing, AMC System Integration testing, DIACAP accreditation, security test and evaluations, Air Operations Center weapon system certification process, and JITC.

· Provide to the government all testing artifacts (e.g., simulators, models, data, test results, Software Test Descriptions) required to complete all Government acceptance testing.

4.2.1.6 Product Integration and Support

The contractor shall perform the following required activities for this service under this task area:

· Port the intended release to the Government-provided environment to ensure compatibility with the existing and/or production MAF C2 infrastructure and services.

· Ensure and demonstrate that the software is integrated into the intended system configuration without interruption of services or shutdown of the MAF C2 environment (e.g. enclaves) – this is sometimes referred to as non-service interruption (NSI).

· Support the Government in the installation and fielding of the delivered system.

· Prepare and deliver software end items and test results, including all required components and documentation.

4.2.2 Subtask 2-2 Technical Support

The contractor shall perform the following required activities for this service under this task area:

· Provide a separate Requirement Analysis core that can assist the Government in analysis of all identified functional requirements (whether destined for a RSA or not) and identify technical approaches, and provide a description of anticipated prototype results; all with no impact to the development processes underway.

· Define (where necessary), consolidate, analyze , refine and document requirements using data collection tools, surveys, technical interchange meetings and other agreed upon methods.

· Provide capability to handle no less than 50 requirements a month ranging in complexity from new capability to simple documentation changes.

· Document application/capability architecture in format mutually agreed between PMO and contractor.

· Assist the Government with identifying and migrating existing business processes utilizing current GOTS, COTS and by leveraging new technologies in support of net-centric services.

· Participate in the development and validation of DoD Architecture Framework operational products, Integrated Support Plans (ISP), and DIACAP documents.

· Support and provide input to sharing data (services architecture) and business rules with other DoD, AF, AMC or USTRANSCOM capabilities and/or integration efforts.

· Assist the Government with the development of schedules and implementation plans with definable deliverables, including parallel operations where required.

· Support proactive security and performance testing outside the normal release process to evaluate current posture of operational environment to find and recommend improvements to the security and performance posture.

4.2.3 Subtask 2-3 Agile Development

Agile Development differs from the traditional waterfall development that has been applied to GDSS to date. Many of the procedures, deliverables, etc., are the same in both environments, but the following breakdown identifies Agile Development and the unique activities that differ from traditional development in support of GDSS sustainment.

4.2.3.1 Requirements Definition/ User Stories, and the Envisioning Process

This phase of Agile Development involves the users and process owners, but products may be shared with the developer for review.

4.2.3.2 Collaborate to Develop User Stories

The contractor shall participate in Agile teams to provide technical guidance, and assist with the refinement of user stories. The contractor shall also provide expected progress from iteration to iteration based on the user stories and complexity of features to be developed. This estimate is expected within five working days of establishing the features of that iteration.

4.2.3.3 Iterations

Iterations are “interim deliveries” of software, not releases that are fielded to the operational community. The time required to create an iteration is dependent on planning, complexity of features, or other influences. Iterations may also be based on a fixed time cycle, but with variances in the amount of features developed. The contractor shall provide a demonstration of iterations (results of software updates) on the projected dates. The contractor shall provide facilities and hardware for demonstrating iterations.

4.2.3.4 Releases

Based on a plan for each Agile project, releases will be completed, delivered, and fielded. Most Agile projects call for 3-4 iterations followed by a release every four months. Every project will be tailored to the scope of the project, driving longer or shorter iteration and release schedules. The contractor will provide comprehensive fielding instructions. Fielding of releases shall be supported by the contractor as required.

4.2.3.5 Product Testing

Product testing in the Agile development process requires frequent involvement of the customer and/or contracted testers. The contractor shall provide facilities and hardware for testing all iterations.

4.3 Task 3 - Operations Support

Under this task area, the Contractor shall provide sustainment support services for software previously delivered to the Government prior to 1 Jan 2014 for the following:

· Provide a Level III customer, technical, and functional cell support. This function supports problems of a technical nature beyond the capabilities of Levels I and II Operations or Level III Engineering. The support shall be 24-hour on-call support, 7-days a week, with response time within 30 minutes of first contact.

· Monitor Remedy Trouble Ticket System and coordinate all program system problem/outage resolutions with appropriate agencies and/or activities.

· Provide system administration (SA) support in the development environment to include security and system administration, communications processor operation, and node maintenance for GDSS. Provide temporary support to nodes at other locations, if requested by the Government.

· Maintain the GDSS, AvORM, and MEIS development environments and staff this effort in order to support problem resolution on software delivered to the Government. This includes engineering, database administration, configuration management and system administration support.

· Conduct “train the trainer” events to train system administrators, MAF C2 trainers, and help desk staff on new or revised configurations, functions, and features prior to Government testing and fielding of new software versions.

· MEIS Service Concepts:

1. Provide patch support for the following:

a. Application services will include multiple Get, Add, Update and Delete methods with filtering, parsing and sorting capabilities. These services will be supported by a rules engine to implement validation and process policies based on defined business processes.

b. Aggregate/Composite services will include multiple Get, Add, Update and Delete methods with filtering, parsing and sorting capabilities. These services will use existing Application services to inherit/fuse information to form new business objects to support defined business processes. Most Add, Update, and Delete methods will be used for backwards capability.

c. Information services (includes Aggregate/Composite) will include multiple Get methods with filtering, parsing and sorting capabilities. These services will be strictly to support the retrieval of information by consumers.

· MOBNET Support

1. MOBNET shall continue to be used as a third-party tool for evaluating and discovering Mobility services both fielded and in development. Additionally, MOBNET will be used to demonstrate/evaluate agile sprint releases as coordinated between Government and developer.

2. Access Controls to MOBNET as approved by the Government (new accounts, account modifications, account deletions, password resets).

3. Test harness(es) to evaluate services.

4. Forum(s) and Frequently Asked Questions (FAQ) capabilities to support feedback between Government, developers, and other third-party developers

· Service Definition Framework (Documentation)

1. Sustain service definition framework (SDF)…