W15QKN-15-R-0161-0004.pdf

AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT 1. Contract ID Code Page Of

2. Amendment/Modification No.

3. Effective Date

4. Requisition/Purchase Req No.

5. Project No. (If applicable)

6. Issued By Code 7. Administered By (If other than Item 6) Code

8. Name And Address Of Contractor (No., Street, City, County, State and Zip Code)

9A. Amendment Of Solicitation No.

9B. Dated (See Item 11)

10A. Modification Of Contract/Order No.

10B. Dated (See Item 13) Code Facility Code

11. THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS

The above numbered solicitation is amended as set forth in item 14. The hour and date specified for receipt of Offers is extended, is not extended.

Offers must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended by one of the following methods:

(a) By completing items 8 and 15, and returning ____________ copies of the amendments: (b) By acknowledging receipt of this amendment on each copy of the offer submitted; or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOUR ACKNOWLEDGMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified.

12. Accounting And Appropriation Data (If required)

13. THIS ITEM ONLY APPLIES TO MODIFICATIONS OF CONTRACTS/ORDERS

It Modifies The Contract/Order No. As Described In Item 14.

A. This Change Order is Issued Pursuant To: The Changes Set Forth In Item 14 Are Made In

The Contract/Order No. In Item 10A.

B. The Above Numbered Contract/Order Is Modified To Reflect The Administrative Changes (such as changes in paying office, appropriation data, etc.) Set

Forth In Item 14, Pursuant To The Authority of FAR 43.103(b).

C. This Supplemental Agreement Is Entered Into Pursuant To Authority Of:

D. Other (Specify type of modification and authority)

E. IMPORTANT: Contractor is not, is required to sign this document and return _______________ copies to the Issuing Office.

14. Description Of Amendment/Modification (Organized by UCF section headings, including solicitation/contract subject matter where feasible.)

Except as provided herein, all terms and conditions of the document referenced in item 9A or 10A, as heretofore changed, remains unchanged and in full force and effect.

15A. Name And Title Of Signer (Type or print)

16A. Name And Title Of Contracting Officer (Type or print)

15B. Contractor/Offeror 15C. Date Signed 16B. United States Of America 16C. Date Signed

By (Signature of person authorized to sign) (Signature of Contracting Officer)

NSN 7540-01-152-8070

PREVIOUS EDITIONS UNUSABLE

30-105-02 STANDARD FORM 30 (REV. 10-83)

Prescribed by GSA FAR (48 CFR) 53.243

SEE SCHEDULE

X

Firm Fixed Price

0004 2015SEP28

W15QKN

ARMY CONTRACTING COMMAND - NJ

PICATINNY ARSENAL, NJ 07806-5000

NADINE SCHNEIDER

EMAIL: NADINE.K.SCHNEIDER.CIV@MAIL.MIL

W15QKN-15-R-0161

2015SEP15

X

X

/SIGNED/

2 signed

SEE SECOND PAGE FOR DESCRIPTION

1 23

CONTINUATION SHEET

Reference No. of Document Being Continued Page of

Name of Offeror or Contractor:

PIIN/SIIN MOD/AMD

SECTION A - SUPPLEMENTAL INFORMATION

Buyer Name: NADINE SCHNEIDER

Buyer Office Symbol/Telephone Number: ACC-NJ-JA/(973)724-4800

Type of Contract 1: Firm Fixed Price

Kind of Contract: Service Contracts

*** End of Narrative A0000 ***

The purpose of Amendment 0004 to Solicitation No. W15QKN-15-R-0161 is as follows:

1. Answer the following questions received from industry:

Question #1: Section 7.3 of the PWS is missing. Can the Government please confirm that there is no missing section in the PWS and the____________ numbering from 7.2 to 7.4 is a simple oversight?

Answer #1: The Performance Work Statement in Section C has been revised to include Section 7.3 to and states the following:__________

7.3 Information Disclosure: A Certificate of Non-Disclosure shall be signed by all contractor employees working under this effort and returned to the COR prior to contract award. The contractor shall not release any information or data without the approval of the

Government.

Question #2: Would the Government please consider putting the letters of commitment outside the 10 page per subfactor limit for resumes?____________

In order to adequately describe the evidence of knowledge, experience, and training/certifications for each proposed employee the

Offeror would prefer to utilize the full 10 pages per subfactor for personnel resume content.

Answer #2: The Letters of Commitment will not be included in the resume page count.__________

Question #3: Can the Government please clarify that fold-out pages only count as 2 against the 100 page limit for Volume I: Technical____________

Factor? Per the requirements in Section L, each fold of a fold-out page counts as an additional page. In order to facilitate proper fitting inside a standard 8.5" binder it is common practice to "Z" fold an 11x17 page, creating 3 folds. In this instance Offeror's foldout pages would count as 3, when actually only occupying the same page area as two 8.5x11 pages.

Answer #3: The fold out 11x17 pages will be counted as only 2 pages.__________

Question #4: Can the Government please clarify why CDR and PDR appear twice in list of deliverables in Section 4.3?____________

Answer #4: Section 4.3 of the Performance Work Statement has been revised to remove the extra listings of Preliminary Design Review__________

(PDR) and Critical Design Review (CDR).

Question #5: Can the Government please confirm that Volume III, IV, and V should be packaged together on the separate CD? Volume IV will____________ contain the offeror's total evaluated price as it pertains to their SB goals and Volume V will also contain pricing in Section B and required attachment per Section J. If it is the Governments intent to keep any volumes containing cost or pricing data separated from the technical, then the electronic version of Volumes IV and V should be contained on the same CD as Volume III: Price Factor.

Answer #5: The Government confirms that proposal Volumes III, IV and V should be packaged together on a CD separate from Volume I:__________

Technical Factor.

2. Offerors are required to sign this amendment (SF30) and return two (2) copies to the issuing office with proposal submission.

3. The proposal submission date remains unchanged at October 22nd 2015 1500EST.

*** END OF NARRATIVE A0005 ***

2 23

W15QKN-15-R-0161 0004

Name of Offeror or Contractor:

PIIN/SIIN MOD/AMD

SECTION C - DESCRIPTION/SPECIFICATIONS/WORK STATEMENT

PERFORMANCE WORK STATEMENT (PWS)

for

Tactical Mission Command Applications (TMCA)

1. Background

2. Scope

3. Performance Requirements

4. General Information

5. Performance Requirements Summary (PRS) / Quality Assurance Surveillance Plan (QASP)

6. Accounting for Contract Service

7. Security

8. Homeland Security Presidential Directive (HSPD) - 12

1. Background ___________

The US Army Research, Development and Engineering Command (RDECOM), Armament Research Development, and Engineering Center (ARDEC) is responsible for the design, development, and integration of the Tactical Mission Command Applications (TMCA) software applications in support of Army Common Operating Environment (COE), Command Post Computing Environment (CP CE) objectives.

2. Scope _____

The contractor shall provide software and systems engineering lifecycle support including, but not limited to, TMCA design, development, software coding and implementation, and testing activities including unit and systems integration and fielding support. The contractor must provide competent personnel with the appropriate level of education and experience necessary to provide engineering support on the following scope requirements activities.

3. Performance Requirements ________________________

The contractor shall, as required, execute task orders in support of the following management, technical and logistics areas. The following requirements are representative of potential requirements that may be issued in accordance with this PWS paragraph under a specific task order.

3.1 TMCA GENERAL REQUIREMENTS

3.1.1 COLLABORATION

The contractor shall design, develop, and implement system and software improvements that enhance users ability to interact and collaborate within and between echelons of command and across boundaries. This may take the form of collaboration with other systems already present in the Army inventory through the coordination and development of new interfaces. These efforts shall include, but are not limited to:

- Design and implement collaboration solutions that span the dismounted, mounted, command post, garrison, and enterprise domains.

- Design and implement collaboration solutions that degrade gracefully in the presence of disconnected, intermittent, or latent communications.

- Design and implement collaboration solutions that provide "collaboration as a service" between TMCA and other systems.

- Design and implement collaboration solutions that enable collaboration between the TMCA and other thick-client, thin-client, Web-based, mounted, or handheld systems that have been or may be developed by the Government

- Design and implement collaboration enhancements as identified by the Government.

3.1.2 SUPPORT FOR DISPARATE COMMUNICATIONS

The contractor shall design, develop, and implement a capability to operate in a disparate, asynchronous communications environment.

The capability involves not only simultaneously operating across satellite, Mobile Subscriber Equipment (MSE) and tactical Frequency

Modulation (FM) communications, but also supporting new and emerging DoD and Army networks. These efforts shall include, but are not limited to:

3 23

Name of Offeror or Contractor:

PIIN/SIIN MOD/AMD

- Design and implement the TMCA to be compatible with WIN-T Increments.

- Design and implement the TMCA to support communications in messaging-based environments such as the Lower Tactical Internet.

- In concert with the network capabilities developed by the Government, design and implement TMCA capabilities that make the TMCA system more network-aware and able to report on the current status and configuration of network links.

- Design and implement collaboration solutions that are designed for low-bandwidth tactical networking environments

- Design and implement the TMCA to be compatible with other communications systems and protocols as specified by the Government

3.1.3 SCALABILITY

The contractor shall design, develop and implement system and software architectures that support distributed collaboration, data replication and synchronization, and data distribution among thousands of users in near-real-time. These efforts shall include, but are not limited to:

- Design and implement system and software architectures, software components and software functionality needed to support a robust, massively distributed, real-time collaboration system. The collaboration architecture shall be reliable, minimize bandwidth requirements, be supportable, maximize performance and support security regulations. All software development shall support new and changing requirements to the system and software architectures.

- Design and implement a capability to co-host a Command Post compliant Virtual Machines with a Command Post client in support of a battalion and below configuration. The purpose of this capability is to reduce bandwidth during collaboration between battalion and below units and higher echelons.

- Design and implement robust information filtering capabilities to enable users to declutter or otherwise simplify the information being displayed.

- Design and implement system and architecture enhancements that enable disparate TMCA enclaves to discover and connect with each other with minimal manual assistance.

3.1.4 WEB/THIN-CLIENT CAPABILITY

The following are representative of the task requriments that may be issued in accordance with this PWS paragraph under a specific Task

Order: These efforts shall include, but are not limited to:

- Design and implement a robust, secure application capability to support hundreds of "edge" users simultaneously. "Edge" users are those who do not have access to the Command Post Thick client. The application based capability shall provide secure access to Command

Post data along with the capability to query and map such data. Iterative development shall be based upon new and emerging requirements.

- Design and implement the capability for thin-client users to be able to view briefings conducted in the TMCA CIAS.

- Design, develop, implement and/or manage an "application store" that shall serve as a central repository of thin client applications or widgets for PM Mission Command or other functional domains

- Design and implement widgets and/or thin client applications that extend or interface to the Command Post server infrastructure.

3.1.5 SUPPORTABILITY

The contractor shall incrementally improve the supportability of the TMCA and server components with the objective of minimizing the support staff and support costs necessary to effectively maintain the TMCA in operation. The contractor shall optimize the TMCA to maximize supportability by soldiers. The following are representative of the task requriments that may be issued in accordance with this PWS paragraph under a specific Task Order: These efforts shall include, but are not limited to:

- Design and implement solutions that minimize the length of time and simplify the process required to back-up and maintain the data repository. Solutions should also reduce or remove disruptions to users during scheduled and unscheduled back-ups.

- Design and implement cost-effective solutions to improve the garbage collection process on the data repository. Garbage collection removes unreachable data within the Repository. Viable solutions shall produce efficiencies in the time required to perform necessary garbage collection on the data repository while minimizing hardware requirements. Solutions should also reduce or remove disruptions to the data availability during scheduled and unscheduled garbage collection.

4 23

Name of Offeror or Contractor:

PIIN/SIIN MOD/AMD

- Automate routine collaboration and application server maintenance tasks, such as repository back-up, repository garbage collection, restoration of back-ups and databridge support.

- Design and implement software solutions that minimize the need for on-site field support.

- Automate the deployment of new software versions, patches, and hot-fixes. Installations and upgrades shall minimize the user actions required successfully complete the installation or upgrade. Maximize use of standard Windows installation programs.

- Provide engineering support for new and emerging requirements that support a smaller logistics footprint and increased system supportability.

- Design and implement software that supports new and emerging requirements that reduce the logistics footprint and/or increase system supportability.

- Design and implement tools that eliminate the need for users or field support engineers to use the "u-form browser" to administer the system.

- Design and implement tools and capabilities that allow for remote administration and maintenance of CIAS enclaves to the greatest extent practicable, including administration and troubleshooting of OCONUS enclaves from CONUS locations.

- Provide an installation that requires minimal user intervention and automates configuration settings, including security settings, to the largest extent possible.

- Provide a start-up capability that minimizes the number of actions a user must take to access all functionality.

- Provide Remote Admin tools that are able to manage both TMCA, CIAS, and other environment capabilities.

- Design and implement diagnostic and prognostic maintenance capabilities.

- Develop other supportability improvements as directed by the Government.

3.1.6 STABILITY

The contractor shall maintain and improve the stability of TMCA to enhance the users experience.

- Design and implement software that has increased fault tolerance for network instability.

- Design and implement functionality to react appropriately to degraded network connectivity.

- Design and implement software that automatically detects incompatible versions of the TMCA application on the network and reacts accordingly.

3.1.7 SERVER INFRASTRUCTURE IMPROVEMENTS

The contractor shall make improvements to the server infrastructure of the TMCA covering the repository, interoperability, data replication, distribution, and synchronization, remote administration and monitoring, and search capabilities.

- Evaluate the advantages of implementing new repository architectures. Specifically evaluate solutions that could enhance query and sorting capabilities and simplify repository maintenance.

- Design and implement a capability to quickly and easily discover data patterns in the TMCA repository.

- Design and implement a capability to discover and create dynamic temporary connections between disparate TMCA enclaves within the same network and/or security domain. These connections shall permit collaboration between enclaves without manual setup/reconfiguration.

- Design and implement a collaboration architecture that shall allow multiple points for data to be ingested into the system. Each echelon shall be able to connect its standard data feeds into the system. Allow the system to accept nonstandard data feeds that are on-the-fly definable into a recognizable schema (such as XML Schema). Allow for system data to be exported from the system at the same echelons for ingestion by other systems.

- Evaluate the benefits and drawbacks of moving away from the current embedded database architecture for the repository.

- Design and implement a system solution that allows both management and merges of multiple, separate repositories to support disconnected operations in theatre.

5 23

Name of Offeror or Contractor:

PIIN/SIIN MOD/AMD

- Design and implement solutions that maximize the efficient use of server resources in the operation of the TMCA system.

- Other server infrastructure improvements as directed by the Government

3.1.8 HARDWARE CONFIGURATIONS

The contractor shall, based on the operational environment where the TMCA shall operate, provide solutions that allow the TMCA client and/or server software to operate on various hardware platforms (both ruggedized and non-ruggedized), to include, but not be limited to, workstations, laptops, tablets, PDAs, etc.

- Design and implement TMCA and/or server software in the following hardware environments:

- Mounted Battle Command on the Move (MBCOTM)

- Army Airborne Command and Control System (A2C2S)

- 1, 2 or 3 screen display configurations

- tablet configurations

- smartphone configurations

- other mobile or hand-held configurations

- large screen display configurations

- ruggedized hardware configurations

- standalone laptop configurations

- other emerging hardware configurations, including integration with mounted vehicle computing hardware

- Design and implement TMCA and/or server software in the following dismounted/mobile software environments:

- Linux/Unix

- Android

- Apple iOS

- Microsoft Windows (mobile variants)

- Other operating systems as directed by the Government

- Provide heuristics and usability studies to develop a TMCA software/user interface design that provides for effective operation and collaboration on different hardware variants.

- Support touch-screen capabilities on all hardware configurations where touch-screens are provided.

- Support voice recognition and transcription capabilities.

- Support "soft" keyboards and pointing devices where device capabilities permit.

- Support other technologies and/or capabilities that are embedded with available device hardware, including Geospatial Positioning

System (GPS), accelerometers, cameras, microphones, etc.

3.1.9 WIRELESS MAN-PORTABLE OPERATIONS

The contractor shall develop a man-portable version of the TMCA to include, but not limited to:.

- Design and implement a secure, wireless, man-portable TMCA capability that provides real-time collaboration and C2 capabilities.

Based upon heuristics, usability studies and the user feedback process, a subset of TMCA capabilities may be provided via the secure, wireless, man-portable client. System and software design must be IAW with Paragraph 3.2.2.1, "System and Software Design Objectives."

- Develop a TMCA design that provides for effective operation and collaboration in a single screen display.

- Design and implement a wireless, dismounted TMCA capability based upon an approved system and software design. Support new and emerging wireless, man-portable capabilities.

3.1.10 MISSION COMMAND ON-THE-MOVE

The contractor shall develop a system and software design that supports a ruggedized Mission Command on the Move (MCOTM) capability in a variety of potential hardware/vehicle platforms.

- Design and implement secure real-time collaboration and C2 capabilities.

- Integrate TMCA with existing mounted hardware environments and support a more limited screen capability while providing effective operations and collaboration.

6 23

Name of Offeror or Contractor:

PIIN/SIIN MOD/AMD

- Design and implement a ruggedized MCOTM capability that supports the approved system and software design. Support new and emerging requirements.

3.1.11 DISCONNECTED OPERATIONS

The contractor shall develop and/or enhance the capability for individual TMCA or groups of TMCA to operate while disconnected from the network and/or server environment and effectively reconnect and synchronize all required data. Operational scenarios include (1)

Network outages or hardware failures affecting one or multiple machines (2) Unit Task Re-organization of an individual TMCA or enclave from one TMCA enclave to another.

- Design and implement a TMCA standalone capability. A TMCA standalone capability shall allow an operator to use TMCA command and control capabilities while disconnected from the network. Once network connectivity is re-established, a bi-directional exchange of all relevant data will occur between TMCA clients and the TMCA repository.

- Design and implement the capability for standalone TMCA networks/enclaves to connect to other enclaves and initiate a bi-directional exchange of all relevant data until both networks are fully synchronized.

3.1.12 PLANNING AND REHEARSAL

The contractor shall implement military planning and/or rehearsal capabilities into the TMCA. The following are representative of the task requriments that may be issued in accordance with this PWS paragraph under a specific Task Order:

These efforts shall include, but are not limited to:

- Design and implement a military orders data architecture and solution for the TMCA.

- Design and implement course of action (COA) development capabilities for use by military planners.

- Design and implement wargaming capabilities.

- Design and implement mission rehearsal capabilities.

- Design and implement tools that enable the commander to track actual versus expected progress against an operations plan.

- Design and implement tools that support the Military Decision-Making Process while not locking users into a single way of approaching the "art" of planning.

- Design and implement solutions that provide for change management and tracking of planning and orders products.

- Design and implement solutions that provide the ability to digitally sign and disseminate orders.

- Design and implement solutions that support intelligence preparation of the battlefield.

- Design and implement other military planning and/or rehearsal capabilities as specified by the Government.

3.1.13 DEVELOPMENT KIT AND APIS

TMCA is intended to be a common point for integration of capability across warfighting function domains. To achieve this, the contractor may be required to enhance existing and/or develop (DI-IPSC-81441A) new Developer Kits or Application Programming Interfaces

(APIs) to allow third-party developers to write applications, tools, utilities, etc. for the TMCA infrastructure utilizing the TMCA GUI or server components. The following are representative of the task requriments that may be issued in accordance with this PWS paragraph under a specific Task Order: These efforts shall include, but are not limited to:

- Design, develop, implement, and make available to third party developers, a set of open and standard Application Program Interfaces

(APIs) that would allow for a plug in set of functionality to be developed.

- Design and implement a 3rd Party Development Toolkit (3PDK) that would enable a third party to develop a application "plug in" using the tools provided within the TMCA CIAS client and server, without software code.

- Design and implement the TMCA CIAS data repository to enable third-party developers to extend and/or tailor the base TMCA CIAS data model.

- Design and implement new and/or enhanced interfaces using commercially-open standards and technologies.

7 23

Name of Offeror or Contractor:

PIIN/SIIN MOD/AMD

- Design and implement new and/or enhanced system capabilities using commercial standards and technologies, minimizing the use of proprietary, custom, or infrequently-used technologies.

- Design and implement APIs and software components that permit non-TMCA and capabilities to collaborate natively with the TMCA through the integration of the developed APIs and/or software components into the non-TMCA systems or capabilities.

- Other development kit and/or API capabilities as directed by the Government

3.1.14 PRIVILEGES AND PERMISSIONS

The contractor shall provide a robust, secure, and user-friendly permissions scheme within the TMCA environment by:

- Design and implement a secure, robust, user permissions scheme that supports both current and new requirements. Designs should provide permission "rules" that are easy for the operator to understand and use.

- Design and implement improved permissions to view data and products in addition to permissions for changing items.

- Design and implement the capability to authenticate users and services against emerging Army technologies/systems for authentication, such as Active Directory, Web Services Security, and Public Key Infrastructure (PKI)

- Design and implement solutions for access to tools, capabilities, and data within the TMCA environment based upon the role of the user logging in.

- Other privileges and permissions improvements as directed by the Government

3.1.15 INFORMATION ASSURANCE

TMCA is a key component of Army Mission Command and must meet applicable DoD and Army security requirements. The following are representative of the task requriments that may be issued in accordance with this PWS paragraph under a specific Task Order: These efforts shall include, but are not limited to:

- Perform a security assessment of the TMCA.

- Design and implement new capabilities that address TMCA security weaknesses.

- Support the government in responding to emerging changes in the platform environment, including but not limited to operating system or other patches, changes to security guidance, and implementation of new security tools.

- Design and implement the ability for the TMCA to take advantage of multiple-level security systems and technologies

- Enhance or modify existing classification and releasability marking capabilities

- Work with the Government to implement a Cross-Domain Guard solution where applicable for TMCA.

- Other information assurance improvements as directed by the Government

3.2 ARCHITECTURE AND SYSTEMS ENGINEERING

3.2.1 SYSTEM ARCHITECTURE

The contractor shall develop a final architecture and system design that will achieve the capabilities set forth in the approved CDD and/or CPD. The final architecture must ultimately comply with the following Government initiatives, i.e. Network Centric Enterprise

Services (NCES), GIG Information Assurance architecture, Net Centric Implementation Documents, and evolving Network Centric Operations and Warfare Reference Model (NCOW RM) versions. The contractor shall monitor these evolving requirements for applicability and conformance. Architecture design trades shall not be made by the contractor which conflict with or degrade the migration to final compliance with these requirements.

The architecture shall consist of the following DoD Architecture Framework (DoDAF) products:

- OV-1, OV-4, OV-5, OV-7, SV-1, SV-2, SV-4, SV-5, SV-6, SV-10c, SV-11

The System Design shall include a conformance analysis to the GIG standards such as:

- NCOW RM, NCES, NCIDS

8 23

Name of Offeror or Contractor:

PIIN/SIIN MOD/AMD

The contractor shall produce CADM compliant SML architecture products in accordance with the requirements specified in CJCSI 6212.01 D.

The contractor shall integrate the government provided operational views into the TMCA architecture and produce integrated CADM conformant XML architecture products. constituent architecture data elements used to represent the same information are specified in a consistent manner such that architecture data elements defined in one view are the same (i.e. same names, definitions, and values) as architecture data elements referenced in another.

3.2.2 SYSTEM ENGINEERING

The contractor shall perform system engineering activities, to include but not be limited to, system architecture and design;

requirements definition and analysis; interface with external agencies; quantitative and qualitative analysis of system performance and reliability; and support of Army and Joint Interoperability.

The contractor shall provide (DI-IPSC-81435A) detailed system design and engineering support to all other functional areas of contract activity (i.e. software design/development/integration, test, Integrated Logistics Support (ILS), safety, security, etc,), as required, to ensure that program objectives are met.

The contractor shall provide System Engineering services to support Army exercises such as preparing and verifying data loads and post exercise analysis of issues and enhancements to the TMCA. The contractor shall support architecture evaluations by the government through the system lifecycle.

3.2.2.1 System and Software Design Objectives

The following are the system and software design objectives for the TMCA.

a. Throughout TMCA, industry-accepted design objectives for systems and software shall be employed.

b. The system and software design to support network operations must be secure, extensible, responsive, and supportable.

c. System and software designs to support edge users (i.e., web portal) must emphasize performance, flexibility, supportability, security and extensibility.

d. Interfaces must be designed with a focus on maintainability, extensibility, supportability, performance, reuse, and system security.

e. All software shall be designed with an emphasis on reliability, availability, modifiability and supportability.

f. All software shall be designed in such a manner as to minimize or eliminate the usage of proprietary or non-commercial technologies except where specifically directed or authorized by the Government.

g. The system architecture shall be flexible to ensure successful implementation of changing requirements and emerging technologies.

h. The contractor should place a special system engineering emphasis pertaining to the design, integration, interoperability, standardization, use, location and display of all of the data processed by the system.

i. The TMCA shall continue to be a platform for the integration of capabilities developed by other WfFs. Software designs should strive to minimize the impact of changes upon the 3rd-party developers that will use the system.

j. The system should always be designed and implemented to provide maximum backwards compatibility and backwards interoperability.

3.2.2.2 Systems Engineering Deliverables

3.2.2.2.1 Software Requirements Specification (SRS)

The contractor shall develop (DI-IPSC-81433A) a Software Requirements Specification IAW this PWS. At a minimum, the SRS shall be updated at the conclusion of each Development Release Cycle. The SRS shall be available to the government on the contractor's website.

An updated SRS shall be provided to the Government for each software release/version. The updated SRS shall contain the detailed specifications for the complete requirements (functional, interface, performance, qualifications, security, etc.) of all software functionality that was added to the software baseline during the release/version.

3.2.2.2.2 System/Subsystem Design Document (SSDD)

9 23

Name of Offeror or Contractor:

PIIN/SIIN MOD/AMD

The contractor shall prepare (DI-IPSC-81432A) a System/Subsystem Design Document IAW this PWS. It must describe the operational and support environment under which the system will execute. The SSDD must be updated and provided to the Government for each new, major software release specified by the government, and for other major developments as needed. The SSDD shall include:

- Computer Software Configuration Items/Computer Software Component (CSCI/CSC) descriptions

- System and Software Architecture/Design

- Test Cases

- Story Boards

- Event Trace Diagrams

Additionally, the SSDD shall be maintained on the contractors development website and shall be available to the government throughout the development cycle.

3.3 SOFTWARE DESIGN

3.3.1 DESIGN PRINCIPLES

Each Release effort shall include iterative cycles of planning, design, coding, integrating, and testing. Because of the evolutionary nature of this program the contractor may be developing different software Release or Versions concurrently. The contractor shall evolve the process as agreed by the Government. At a minimum a Release/Version development shall include:

a. Functionality defined for the Release as defined by the Release Objectives.

b. A maximization of reuse of GOTS/COTS products.

Each Release and Version shall consist of field installable, and field de-installable segments. Each segment shall be developed to allow the government the capability to prototype/test/field the independent segments individually as they are completed if required.

Every software release, version and segment shall be submitted IAW this paragraph and delivered IAW this PWS.

The following is a summary of the TMCA Development Model and Control mechanisms that shall be implemented by the Contractor.

a. Each product release is intended to build upon the foundation and functionality of the prior release. These releases are built as planned or in response to events.

b. The requirements for a release are defined in the Task Order.

c. The contractor shall work with the Government to allocate product release objectives into the lower level development cycles.

d. The requirements of each cycle are defined by the contractor at the planning session at the start of the cycle. The contractor shall record the requirements defined at the planning sessions in the form of Release Objectives and send the requirements to the government for tracking. Problem report corrections and patch development cycles are conducted

IAW the Software Development Methodology.

e. Human Factors Engineering, Heuristics and Usability Studies shall be regularly performed on TMCA.

3.3.2 DESIGN DELIVERABLES

3.3.2.1 Design Reviews

Design reviews are an important part of the software development process. They permit multiple opportunities for the developer/contractor and the customer to meet and interact over the materials presented. Design reviews are an opportunity for the contractor and customer to align expectations and make course corrections in the design and/or implementation of the software.

3.3.2.1.1 Preliminary Design Reviews

The contractor shall hold one or more Preliminary Design Reviews (DI-MISC-80711A) for each release of CPC software developed. The purpose of the PDR is to demonstrate that the preliminary design meets all specified system requirements within the cost and schedule constraints of the contract. The PDR should enumerate the system requirements, any requirements that have been derived from the system requirements, the initial design choices that have been made, interfaces that have been identified and verification methods that will be used to verify the design and or software developed from the design.

One or more PDRs may be scheduled in consultation with the Government to align the timing of the PDRs with the needs of the design and development schedule. Schedules shall be mutually agreed between the contractor and the Government.

Successful completion of a PDR is required before entrance into the detailed design for the scope of work covered by the PDR.

10 23

Name of Offeror or Contractor:

PIIN/SIIN MOD/AMD

3.3.2.1.2 Critical Design Reviews

The contractor shall hold one or more Critical Design Reviews (DI-MISC-80711A) for each release of CPC software developed. The purpose of the CDR is to demonstrate that maturity of the design is appropriate to begin and/or continue with software development, integration, and test. The CDR determines that efforts are on track to meet requirements within the cost and schedule constraints of the contract.

The CDR is typically the final review before implementation and is the last opportunity for the Government to make course corrections prior to implementation.

One or more CDRs may be scheduled in consultation with the Government to align the timing of the CDRs with the needs of the design and development schedule. Schedules shall be mutually agreed between the contractor and the Government.

At the Critical Design Review the contractor shall present final user interface designs for approval by the Government. No changes to the UI designs shall be permitted after the CDR without prior approval from the Government.

3.4 SOFTWARE DEVELOPMENT

The contractor shall conduct all software development activities for contractor-developed components IAW the Capability Maturity Model

Integration (CMMI) level 5 practices. TMCA Software Development Methodology and this PWS.

3.5 SYSTEMS INTEGRATION

The contractor shall be responsible for all areas of system integration, with exception to hardware procurement. The following paragraphs are representative of the overall scope of the hardware production requirements. Specific tasks shall be issued under this contract for the execution of these requirements.

3.5.1 PRODUCTION INTEGRATION

The contractor shall load TMCA software configurations onto Government GFE hardware. Testing of software and TMCA hardware shall be performed by the contractor prior to any deliveries. Testing shall insure the integrated TMCA solution meets the users operational needs and both hardware and software perform correctly. The contractor shall be prepared to support any software testing at the Armys test facilities at Picatinny Arsenal NJ, Ft. Hood, TX, Ft. Bliss, TX, or Aberdeen Proving Ground, MD, and other locations as required. The contractor shall load required operating software on hardware. Specified software required includes the TMCA software, operating system, Microsoft Office Versions, antivirus, etc., as defined in the software architecture as specified in the applicable Task Orders.

The Government shall procure software licenses and the contractor shall maintain records of software licenses utilized for specific deliveries. This information shall be provided to the Government upon delivery of TMCA.

3.5.2 INTEGRATION WITH ABCS AND ARMY SYSTEMS

The contractor shall ensure a smooth and fully integrated system of software, target hardware and peripherals, ABCS, Standardized

Integrated Command Post Systems, Communication Systems, Enterprise Systems, and Local Area Networks. The contractor shall develop system software and provide client and server hardware. The system shall leverage existing Army communication systems.

3.6 TEST AND EVALUATION

3.6.1 SOFTWARE TEST AND EVALUATION

The contractor shall conduct a tailored software test and evaluation program IAW this PWS. The contractor shall make all necessary revisions to the contractor-developed code and documentation, conduct all necessary re-testing and shall update Software Development

Folders (SDFs) of all software units that undergo design or coding changes based on results of various software tests and evaluations.

The Government reserves the right to witness all tests.

3.6.2 COTS/GOTS SOFTWARE TESTING

The contractor shall perform integration and testing of Commercial-Off-The-Shelf (COTS) and Government-Off-The-Shelf (GOTS) software to ensure that it satisfies the TMCA requirements for which it was selected.

The Contractor shall notify the Government as soon as they determine that a directed GOTS and/or COTS component is defective or will otherwise not meet the desired requirements.

3.6.3 INTEGRATION TESTING

The contractor shall provide technical support (DI-IPSC-81441A) for the Integration and Test Efforts conducted at Picatinny Arsenal and other locations, as required, to independently verify functionality, performance, and gain user feedback on system software Builds, Patches, Hotfixes, Technical Bulletins, Releases, Versions, and/or other software updates.

11 23

Name of Offeror or Contractor:

PIIN/SIIN MOD/AMD

3.6.4 SOFTWARE IMPLEMENTATION AND UNIT TESTING

The contractor shall code and test each software unit ensuring that the algorithms and logic employed by each software unit are correct and that the proposed testing exercises all logical paths and demonstrates that the software unit satisfies its intended design.

The contractor shall make all necessary revisions to the contractor-developed design documentation and code, perform all necessary re-testing and update the SDFs of all software units that undergo design or coding changes based on software unit tests. The contractor shall provide source materials for code and test as requested by the Government. The contractor shall not be required to perform unit level test on Government directed GOTS or COTS.

3.6.5 CSC AND CSCI INTEGRATION AND TESTING

The contractor shall perform integration and testing on software that has successfully undergone unit testing. Integration and testing at this level shall include testing of interfaces within a module and progress to integration and testing between modules. Target hardware shall be used as early as possible in the conduct of these tests. The contractor shall develop test procedures/checklists during this phase of testing. The contractor shall record the test results of all integration and testing in each corresponding individual software CSC/CSCI SDF along with the expected results and evaluation criteria for each test. The contractor shall make all necessary revisions to the contractor-developed design documentation and code, perform all necessary re-testing and update the SDFs of all software components that undergo design or coding changes based on results of all testing performed. As a minimum the contractor shall make the following products available for Government review and use:

- Storyboards

- Test Cases

- SDFs

Metrics shall be provided, at a minimum, in the following areas:

a. Depth of Testing. Depth of Testing measures the amount of testing achieved on the software architecture. That is, the extent and success of testing the possible control and data paths and conditions within the software. This testing is often described as white box testing, since there is visibility into how the software is constructed. The depth of testing metric provides information on the integrity of the software design, including the relationship between the paths, statements, inputs, and decision points of the software.

b. Complexity. The complexity metric provides a means to measure and evaluate the structure of software units. Software that is more complex is harder to understand, test adequately and maintain.

3.6.6 PRODUCT TESTING (PT)

The contractor shall conduct the PT on target hardware, which may be located at multiple facilities in order to meet test objectives.

The PT shall verify compliance of TMCA(Server & Client) with Task Order requirements in terms of Performance Testing, Interoperability, MANPRINT/Safety and operational threads allocated to the current release and shall also conduct regression testing on requirements from previous releases. The contractor shall verify data and messaging exchanges for TMCAare achieved according to the TMCA Task Order interoperability requirements. The contractor shall ensure this occurs through interoperability testing. Identified problems shall be configuration managed and forwarded to the respective software development organization for resolution.

PT testing for contractor developed code for each Release shall also verify the extent to which each Task Order requirement assigned to the Release has been satisfied (acceptance testing). PT shall also include Boundary Testing. All operational computer programs shall be tested as a completely integrated system; i.e., hardware, software, support equipment, communications, cryptographic devices, support documentation and personnel. The report shall contain the pass/fail status of the requirements and all issues found during the PT.

As required the contractor shall modify the procedures developed during the Integration and Test Phase to perform the PT.

3.6.7 GOVERNMENT TESTING

The Government may conduct and independently evaluate each version's technical functionality/performance via a variety of test events.

The contractor shall provide technical support for each of these tests.

3.6.8 CONFIGURATION AUDITS

The Government may conduct Functional Configuration Audits (FCA) and Physical Configuration Audits (PCA). The contractor shall provide technical support for these audits as deemed appropriate by the Government. An FCA and PCA are completed on each major release version by the Government prior to CTSF testing.

3.6.9 TEST AND EVALUATION DELIVERABLES

12 23

Name of Offeror or Contractor:

PIIN/SIIN MOD/AMD

3.6.9.1 Software Test Description (STD)

The contractor shall prepare the Software Test Description (DI-IPSC-81439A) IAW this PWS to identify and describe the test preparations and plans, test cases and test procedures to be used for the tests identified in this PWS, including those for the security related and human engineering related tests.

STD is to be developed for each release and updated with subsequent releases. The STD shall be used for Product Testing and should insure that all the requirements specified in the Product Testing PWS Paragraph 3.6.6, "Product Testing" shall be satisfied.

3.6.9.2 Software Trouble Report (STR)

The contractor shall collect, analyze and use Software Trouble Reports (DI-MISC-80711A) IAW this PWS. For the purposes of this PWS, Software Trouble Reports shall include those software defects found during internal system testing, software defects found by external testing organizations, such as the CTSF and ATEC, user submitted software defects, software defects encountered by field support personnel and requests for system enhancements. All Software Trouble Reports shall be made available to the government via the TMCA

Developers website.

Software Trouble Reports shall be used by the contractor, the TMCA SMEs, and the Government as input into TMCA planning process.

Analysis of Software Trouble Reports will partially determine which defects and enhancements are included in the current and future development iterations.

3.6.9.3 Test Management Metrics

As a minimum, the supplier shall provide simple to understand yet statistically meaningful measurements of product test status relative for the following test management reporting objectives:

- Completeness of product testing.

- Readiness for deployment or certification

- Where software defects are being found in the product by capability/feature

- Status and timely resolution of Priority 1 & 2 defects during acceptance testing

The exact content of this report shall be agreed between PdM Tactical Mission Command and the contractor. During covered test periods, the metrics shall be updated and submitted to the Government weekly. Contractor format is acceptable, but the data shall be presented as a series of graphs or charts along with accompanying descriptive narrative.

3.6.10 FAILURE ANALYSIS

The contractor shall perform (DI-ILSS-81495) an analysis of all test failures on contractor-developed code. The Government reserves the right to prioritize the failure analysis and/or corrective actions. Results of this analysis shall be documented in the appropriate test report.

3.6.11 TEST AND EVALUATION SUPPORT

The Government will conduct tests and evaluations of TMCA to support acquisition decisions, material release and fieldings. The contractor shall be prepared to support these tests as identified in the TMCA test documentation. This support shall include test planning, system setup, and verification of the integration of the system. These tests include, but are not limited to, Army

Interoperability Certification (AIC) testing, testing at the Central Technical Support Facility (CTSF), Ft Hood, TX; the series of Army

Network Integration Events (NIE) at Ft Bliss, TX; integration events at Aberdeen Proving Ground, MD, and ad-hoc tests and evaluations held at other locations.

The contractor shall review and analyze the current and subsequent versions of the TMCA test documentation with revisions for consistency, program impacts, and conformity to guidance policy, etc.

3.6.12 TECHNICAL EVALUATIONS

The prime contractor and all sub-contractors shall participate in joint Technical Evaluations with the government. The contractor may perform internal Technical Evaluations, independent of the joint Technical Evaluations. Both out-of-process (unplanned but necessary)

Technical Evaluations and in-process (planned) Technical Evaluations may be used. In-process Technical Evaluations shall typically be performed prior to milestone reviews and/or as work products are produced.

The primary purpose of Technical Evaluations is to assess the technical quality of work products to determine…