Stryker-MTS-Phase-V-SOW_2016_11_08.docx

Statement of Work For STRYKER PHASE V Maintenance Training System

U.S. Army Program Executive Office for Simulation, Training, and Instrumentation (PEO STRI) 12350 Research Parkway Orlando, FL 32826-3276

Engineering

Acquisition Logistics

Program Management Submitted By: ____________________ Approved By: ____________________

Date: _________ Date: _________

Table of Contents

1. SCOPE

This Statement of Work (SOW) defines the effort required for designing, developing, integrating, testing, managing, documenting, and delivering the Stryker Phase V Training System. The Phase V is intended to provide the following at the Fort Lee, VA facility:

a. Five (5) high fidelity, fully instrumented, Hands-On Trainers (HOTs) for the Stryker Main Gun System (MGS) with associated individual training tasks.

b. Five (5) high fidelity, fully instrumented, Hands-On Trainers (HOTs) for the Anti-Tank Guided Missile (ATGM) with associated individual training tasks.

c. Five (5) high fidelity, fully instrumented, Hands-On Trainers (HOTs) for the Mortar Carrier (MC) with associated individual training tasks.

d. Five (5) high fidelity, fully instrumented, Hands-On Trainers (HOTs) for the Remote Weapon System (RWS) with associated individual training tasks.

e. One (1) Caterpillar C7 engine Part Task Trainer (PTT) with associated individual training tasks.

f. One (1) Caterpillar C9 engine Part Task Trainer (PTT) with associated individual training tasks.

g. One (1) full fidelity remove and replace C-9 engine PTT.

h. Conversion of two (2) existing Stryker Hull HOTs to the Stryker A1 configuration.

i. Technical Refresh of the remaining three (3) existing Stryker Hull HOTs due to obsolescence and/or supportability requirements.

j. A two year Interim Contractor Logistics Support (ICLS) effort will be included for the new devices fielded to the Ft Lee site until picked up by the current sustainment service.

The existing system architecture, software design, functionality, user interface, and instructor capabilities must be maintained. The existing Instructor and Operator interface must be maintained. When fielded, the instructor must have the capability to select the lessons from any Training Task List, with the same type of graphical user interface that is used in the trainer today. The remote Instructor/Operator capabilities previously migrated to a “Tablet” hardware solution must be maintained.

Additional enhancements include: Button tasks, Instructor Operator Station (IOS), Support Equipment, Remove and Replace, User Interface, Training Management System (TMS), and Projector Systems.. With the addition of new HOTs the existing uninterruptable power supplies must be upgraded for both the high bay area.

The existing Software Support Environment (SSE) will be provided as Government Furnished Equipment (GFE), and must be utilized to generate the new capabilities. The SSE currently provides the hardware, software, and documentation resources for performing Post Deployment Software Support (PDSS) activities including identifying, documenting, and correcting system software faults, implementing system upgrades, generating application programs, managing databases, and providing configuration management of the training system(s) software baseline. The existing Stryker MTS documentation and Software Support Package (SSP) must be updated as part of this effort and at the end of the contract must provide the resources (i.e., source code, executable code, maintenance software, data base and scenario generation tools, documentation, installation hardware, software installation disk, etc.) for the purpose of maintaining computational systems in a fully operational condition. The existing page based manuals and all new maintenance documentation must conform to the Interactive Electronic Technical Manual requirements.

The current operating system parameters and user interfaces for the Hull HOTs and RWS HOTs do not currently meet the Army Cyber Security requirements. During this effort, the current Windows XP and Windows 7 Operating System (OS) will be upgraded to the approved Secure Host Baseline-Army (SHB-A). Regardless, the entire systems design when fielded (including the software, and hardware as necessary), must be hardened to meet Army Cyber Security requirements. The accreditation boundary for cyber security will be the entire Stryker MTS.

Tactical hardware will be provided to the winning offeror as Government Furnished Equipment to be used to build the trainer. The following list indicates the GFE Hardware that will be available:

5 MGS for MGS HOTs 5 ATGM for ATGM HOTs 5 RWS for RWS HOTs 5 MC for MC HOTs 1 C7 Engine for PTT C7 Engine 1 C9 Engine for PTT C9 Engine 5 Stryker Hull HOTS for 2 HOT A1 Stryker and 3 Hull HOT Tech Refresh

First Article FY19Q2 Source code and technical manuals from the existing Stryker MTS family of maintenance trainers will be provided as Government Furnished Information (GFI). COTS software will not be provided.

The delivered systems must be capable of maintaining concurrencies with latest Interactive Electronic Technical Manual (IETM).

Deliveries will be to Fort Lee VA. (Building 18030).

1.1 BACKGROUND

The Stryker Maintenance Training System (Stryker MTS) mission statement is ‘The Institutional Maintenance Training System (MTS) will support the Stryker Additional Skill Identifier (ASI) R4 and 91S Skill Based Training courses.’ This capability is in support for the Ordnance Schools located at Fort Lee, Virginia with the capability to train the Army’s Military Occupational Specialty (MOS) 91S and provide skill level development training for maintenance personnel covering system operation, symptom verification, troubleshooting, fault isolation, adjustment, servicing, and remove/replace of Line Replaceable Units (LRUs).

The Stryker MTS has provided current fielded types of specialized training:

a. Diagnostic Troubleshooting Trainers (DTTs): A beginning stage of training to allow trainees to utilize a desktop trainer system to troubleshoot, go through maintenance lessons following the fielded Interactive Electronic Technical Manual (IETM) in a 3 Dimensional virtual world. The instructor can monitor and track each student’s performance in the independent virtual environment.

b. Part Task Trainers (PTTs): A next step in training utilizing a high fidelity replica of the actual vehicle sub-systems with normal and faulted behavior. Again following through a lesson plan, the student uses an IETM and now applies the DTT skills on to actual replicated hardware monitoring the steps the trainees take.

c. Hands On Trainer (HOT): A parallel next step in training utilizing a high fidelity replica of the actual vehicle with normal and faulted behavior. Again following through a lesson plan, the student uses an IETM and now applies the DTT skills on to actual replicated vehicle hardware monitoring the steps the trainees take.

The Stryker MTS at Fort Lee currently consist of two (2) twenty (20) student classrooms which utilize Diagnostic Troubleshooting Trainers (DTT’s), Training Management System (TMS), a Software Support Environment (SSE), and a series of Hands On Trainers (HOT) and Part Task Trainers (PTT). The training system provides maintenance training capability for the Army’s 91S Military Occupational Specialty (MOS). This capability supports familiarization, institutional and unit training. The MTS provides training for maintenance personnel in system operation, symptom verification, troubleshooting, fault isolation, adjustment, servicing, and removal/replacement of Line Replaceable Units (LRUs). The training system provides an automatic capability to record, score, and store the performance of students on all tasks, as well as, evaluate the student’s knowledge of the appropriate vehicle system’s functioning theory. The training system provides real-time feedback and scoring capability, which displays and records all the information necessary to evaluate the student’s performance and understanding of the training task. The general areas of scoring include as a minimum the management of switches and controls, response to malfunctions, and actions required by the tasks identified in the Training Task List (TTL). The training system also provides real time display of errors generated by student(s) as they occur during real-time scenario execution.

Training is separated into two distinct categories: the Stryker automotive components and the Stryker weapon components. The DTTs include weapons modules which support the Remote Weapon System (RWS), the Anti-Tank Guided Missile (ATGM) Main Gun System (MGS), and Mortar Carrier (MC) variants. Training on the automotive system utilizes a Hull HOT, and Brake, and Engine PTTs.

The trainer operates in or supports various modes. The modes include Lesson Selection, Lecture, Demonstration, Training, and Diagnostics. The Lesson Selection and Diagnostics modes are operator selectable. The Lecture, Demonstration, and Training modes are a common mode of execution but differ in how the instructor makes use of each mode.

A separate Training Management System (TMS) maintains a library of lessons that can be selected for training. From the Instructor Operator Station (IOS), the instructor can select an appropriate lesson from that library to use for training. The TMS also provides the capability for the instructor to record, score, store, and retrieve the performance of students on all tasks.

2. APPLICABLE DOCUMENTS.

The following document is applicable to this SOW to the extent specified herein.

2.1 Department of Defense Specifications.

2.2 Availability of Department of Defense Specifications.

Copies are available on the WWW at URL: http://assist.daps.dla.mil/quicksearch

2.3 Department of Defense Standards.

2.4 Availability of Department of Defense Standards.

Copies are available on the WWW at URL: http://assist.daps.dla.mil/quicksearch/

2.5 Department of Defense Directives.

DODD 8570.01 Information Assurance (IA) Training, Certification, and Workforce Management

2.6 Availability of Department of Defense Directives.

Copies are available on the WWW at URL: http://www.dtic.mil/whs/directives/

2.7 Department of Defense Instructions.

2.8 Availability of Department of Instructions.

Copies are available on the WWW at URL: http://www.dtic.mil/whs/directives/

2.9 Other Government Documents, Drawings and Publications.

Copies are available on the WWW at URL http://jtaonline.disa.mil/VJTA/index.jsp

National Security Telecommunications and Information Systems Security Policy (NSTISSP) No. 11, Subject: National Policy Governing the Acquisition of Information Assurance (IA) and IA-Enabled Information Technology (IT) Products.

09-EC-M-0010 Army Cybersecurity Directorate IA Best Business Practice Wireless Security Standards Copies of the above Best Practice may be obtained from:

https://www.milsuite.mil/wiki/Portal:Army_Information_Assurance/Best_Business_Practices

AR 380.5 Marking and Labeling Copies are available on the WWW at URL http://www.apd.army.mil/pdffiles/r380_5.pdf AR 25-2 Information Assurance Copies are available on the WWW at URL http://www.apd.army.mil/pdffiles/r25_2.pdf

AR 25-2 BBP 08-CO-M-0001, Information Technology Contingency Plans and Testing.

Copies of the above documents are available at PEO STRI, ATTN:XXXX, 12350 Research Parkway, Orlando, FL 32826-3276

AR 700-127 Integrated Product Support Copies are available on the WWW at URL http://www.apd.army.mil/pdffiles/r700_127.pdf TRADOC Reg. 350-70 Army Learning Policy and Systems. Copies are available on the WWW at URL http://www.tradoc.army.mil/tpubs/regs/TR350-70.pdf

TRADOC Pamphlets are available on the WWW at URL http://www.tradoc.army.mil/tpubs/pamndx.htm

DA PAM 25-1-2, Information Technology Contingency Planning, Copies are available on the WWW at URL http://armypubs.army.mil/epubs/pdf/p25_1_2.pdf

2.10 Availability of Other Government Documents and Publications.

Copies of the above documents are available at PEO STRI, ATTN:PM TRADE, 12350 Research Parkway, Orlando, FL 32826-3276

2.11 Availability of Non-Government Standards and Other Publications.

Copies are available on the WWW at URL: http://www.nssn.org/search.html

3. REQUIREMENTS

3.1 Program Management

The Contractor shall provide the overall management and administrative effort necessary to ensure that the requirements of this contract are accomplished. The Contractor shall track program progress utilizing metrics. The Contractor shall plan, implement, and maintain a Life Cycle Cost (LCC) management process to minimize the system cost and use LCC to conduct trade studies, evaluate design and support alternatives, and select the resource support requirements. The Contractor shall define and monitor metrics and Technical Performance Measures (TPMs) to evaluate the performance of each critical technical and management process and conformance of the evolving products with contract requirements and objectives.

(DI-MGMT-80227) Contractor’s Progress, Status Management Report

3.1.1 Integrated Master Plan (IMP)

The Contractor shall implement, manage to, update, and maintain the contract IMP. The Contractor shall develop the system IAW the IMP. The IMP shall be used throughout the contract as a management tool to assess progress and determine success in achieving program requirements. The Contractor shall report on work in progress IAW the IMP at each program review, at selected technical reviews and at Government discretion. The IMP shall depict the contract work breakdown structure.

3.1.2 Integrated Master Schedule (IMS)

The Contractor shall develop, implement, manage to, update, and maintain the contract IMS. All contract schedule information delivered or presented at program reviews shall originate from the IMS, shall be traceable to the IMP, and shall contain all critical events and exit criteria, accomplishments, predecessors and successors events, and their dependencies. The IMS shall address total program activities including activities performed by major subcontractors. The Contractor shall develop the logic resource network that accurately portrays the sequence and relationship of activities defining the total development and production program. These network activities shall be keyed to the Contract Work Breakdown Structure (CWBS). The network shall be implemented on a computer based program management control system which utilizes critical path method network analysis, accepts parametric data input, and can be utilized to determine a probabilistic estimate of the program schedules. The network activities time shall be updated to reflect accomplished activities and any changes in activity time. The Contractor shall conduct critical path analysis of the tasks and identify problem areas and corrective actions required to eliminate or reduce schedule impacts.

3.1.3 Financial Management

The Contractor shall plan, budget, schedule, and control the resources allocated to meet the requirements of the contract. The Contractor shall document and track the status of all appropriated funds associated with the contract to include payments, cancellations and invoices against each contract line item and subline item. The Contractor shall extend the Government-provided Program Work Breakdown Structure (PWBS) to lower levels in the Contractor’s CWBS. It defines the lower level components of what is to be procured and includes all the product elements (hardware, software, data, or services), which are defined by the Contractor and are the Contractor’s responsibility. The extended CWBS shall serve as the framework for contract planning, budgeting, and schedule status. The Contractor shall identify major elements of subcontracted work in the extended CWBS . The Contractor may propose changes to the CWBS to enhance its effectiveness in satisfying program objectives. The Contractor shall continually update an integrated database during contract performance with pertinent records and data that underlie and support the schedule data reported.

(DI-MGMT-81651) Contract Invoicing and Payment Report

3.1.3.1 Integrated Baseline Review

The Contractor shall participate with the Government in the assessment of program risk and the degree to which the following have been established:

a. Technical scope of work is fully included and is consistent with authorizing documents.

b. Project schedule key milestones are identified and supporting schedules reflect a logical flow to accomplish the work.

c. Resources (budget, facilities, personnel, skills, etc.) are available and are adequate for the assigned tasks.

d. Tasks are planned and can be measured objectively relative to the technical progress.

e. Rationales underlying the review are reasonable.

f. Management processes support successful execution of the project.

3.1.3.2 Contractor Manpower Reporting Application (CMRA)

The Contractor shall report ALL contractor labor hours (including subcontractor labor hours) required for performance of services under this contract via a secure data collection site. The Contractor is required to completely fill in all required data fields using the following web address: http://www.ecmra.mil/. Reporting inputs will be for labor executed during the period of performance during each Government Fiscal Year (FY) which runs October 1 through 30 September. While inputs may be reported any time during the FY, all data shall be reported no later than October 31 of each calendar year. Contractors can find User Guides, Frequently Asked Questions and may direct questions to the help desk at http://www.ecmra.mil/.

3.1.4 Configuration Management (CM)

The Contractor shall use an automated internal configuration management process to monitor, update, and control all configuration documentation, physical media, and physical parts representing or comprising the system configuration items (CIs). The Contractor shall plan and implement an automated configuration management function to perform configuration control, configuration identification, audits, and status accounting in a system engineering environment. The Contractor shall develop, maintain, and update configuration management procedures and processes for control of all hardware and software baselines. The process shall allow simultaneous access to the common product data model coupled with the ability to coordinate and update immediate changes to the product definition data. The configuration management process must handle all levels of product and process integration to build and support the product as well as manage the sequence of significant events. The Government will maintain control of the functional baseline (FBL) defined by the system performance specification, interface control documents, and software requirement specifications.

3.1.4.1 Configuration Management Planning and Management

The Contractor shall establish processes and tools to establish and maintain consistency between system requirements, system configuration information, and all relevant information about the system. The configuration management process shall include changes made to the IA configuration and associated documentation. Failure to include IA considerations in the configuration management and engineering change control processes could adversely affect the program’s ability to integrate and maintain IA in the functional design of the system. This will affect the system's ability to obtain IA accreditation. It may also increase the system's susceptibility to computer network attack from information operation activities. The Contractor shall:

0. Plan implementation of the CM functions for the context and environment in which they are to be performed and manage in accordance with the planning.

0. Determine the specific CM value-adding functions and levels of emphasis.

0. Document how your organization will implement CM functions to provide the consistency between the system’s attributes, system definition information and the system’s configuration information, throughout the applicable phases of the life cycle.

0. Identify resources required to implement the CM functions and ensure they are applied throughout the system’s life cycle.

0. Assess the effectiveness of CM plan implementation and performance of the configuration management functions with performance measurements.

0. Flow down responsibility for CM performance to sub-contractors.

0. Plan and identify information status levels for managing system configuration information and ensure that transmitted data products are usable.

3.1.4.2 Configuration Identification

The Contractor shall identify unique identifiers for selected system attributes, system information and components to be used as the basis for configuration management. The Contractor shall:

0. Define the functional, performance, interface and physical attributes of the system and components.

0. Determine the systems composition using its product definition information.

0. Assign unique identifiers to configuration items so that they can be distinguished from other items, one configuration of the system can be distinguished from another, the source of a component can be determined, and the correct system definition information can be retrieved.

0. Assign unique unit identifiers to individual components of the system.

0. Update component identifiers when a system is modified reflecting the new configuration without altering the system identifier and model identifier.

0. Uniquely identify information so that it can be correctly associated with the applicable configuration of the system.

0. Apply information identification rules to maintain representation and version relationships.

0. Maintain relationships between information, information requirements, and the related system configuration to ensure accurate information retrieval.

0. Establish complete, valid, and suitable for use agreed-to descriptions of the attributes of the system and components at a point in time and provide a known configuration to which changes can be addressed.

0. Identify interfaces and establish mutually agreed-to control of common attributes for system or component boundaries that interface to the system or within the system.

3.1.4.3 Configuration Change Management

The Contractor shall establish a systematic and measurable configuration change management process for managing product configuration changes and variances. Once the system requirements have been approved by an authorized management activity, the Contractor shall effect changes to the baseline requirements only after the proposed change has been approved using the change process. The Contractor shall:

1. Document and uniquely identify each change.

1. Classify requested changes to aid in determining the levels of review and approval.

1. Clearly and completely document request for change.

1. Consider the technical, support, schedule, and cost impacts of a requested change before making a judgment to approve the change for implementation and incorporation in the system and its documentation.

1. Determine potential effects of a change and coordinate impacts with the impacted areas of responsibility.

1. Determine the effectivity for each change and identify which units of the system are to be changed, the point of production break-in, and which units will be included in a retrofit.

1. Verify implementation of a change to ensure consistency between the system, its documentation, and its support elements.

1. Document variances, when authorized by the appropriate level of authority.

3.1.4.4 Configuration Status Accounting

The Contractor shall provide access to accurate, timely information about the system and its documentation through the integrated database. The Contractor shall correlate, store, maintain, and provide readily available views and information of system configuration information including pending, current and historical data. The Contractor shall:

0. Systematically record, safeguard, validate, and disseminate system information.

0. Establish methods, processes and procedures to provide controlled access to system information.

0. Capture configuration information as it evolves.

3.1.4.5 Configuration Verification and Audit

The Contractor shall verify and audit the system configuration information to ensure that requirement attributes are met and accurately documented. The Contractor shall;

a. Verify the system attributes through a systematic comparison with the associated results of system tests, analyses, inspections, demonstrations or simulation models.

b. Maintain surveillance over the configuration management process to ensure it is being followed and remains in compliance with requirements.

3.1.4.5.1 Government Sample Audit to verify Product Baseline

After completion of acceptance testing and any required design modifications, but prior to formal acceptance, the final product baseline shall be verified by the government by reviewing a representative number of drawings, associated technical manuals, logistics management information and manufacturing instructions to determine their accuracy in accordance with the final product configuration design.

3.1.4.6 Software Configuration Management Database

The Contractor shall establish and maintain a software configuration management database IAW the software development process plan. A schema shall be developed for identification of software items and their versions. The Contractor shall perform the following: identification and recording of change request, analysis and evaluation of the changes; approval or disapproval of the request, and implementation, verification, and release of the modified software item. The database shall contain an audit trail whereby each modification, the reason for the modification, and authorization of the modification can be traced.

3.1.4.7 System Engineering Interface

The process shall allow simultaneous access to the common product data model coupled with the ability to coordinate and update immediate changes to the product definition data. The configuration management system must handle all levels of product and process integration to build and support the product as well as manage the sequence of significant events. The information architecture must permit capture of change information and notify affected team members.

3.1.4.8 Engineering Change Proposals (ECP)

The Contractor shall document and the IPT shall review all changes to established baselines and all changes to the requirements (other than the functional baseline), including changes to the statement of work, contract data requirements list (CDRL), the contract schedule, and the general provisions of the contract.

(DI-SESS-81880) Engineering Change Proposal (ECP) (DI-SESS-81881) Notice of Revision (NOR) (DI-SESS-81882) Engineering Release Record (ERR)

3.1.4.9 Engineering and Contract Change Proposal Review

In coordination with the government, the Contractor shall hold a requirements review on all proposed changes prior to the submittal of the engineering change proposal in order to clarify requirements, format, and content. Depending upon the criticality of the proposed changes, this review may take the form of a teleconference, a video-teleconference, a formal meeting at PEO STRI, or a formal meeting at the Contractor’s facility. All appropriate parties shall be in attendance in order to conduct a thorough, effective review. Minutes shall be a historical record to allay any miscommunications.

3.1.4.10 Variances

The Contractor shall document the rationale and the potential impact of any deviation. The Contractor shall obtain approval before deviating from any Government controlled baseline.

3.1.5 Technical Performance Measures (TPM)

The Contractor shall select technical performance parameters that reflect key indicators of program success. TPM parameter inter-relationships shall be depicted through construction of tiered dependency trees similar to the specification tree. Each parameter shall be correlated with a specific CWBS element. Parameters to be reported at each management review shall be selected from the total parameters tracked and shall be identified in the integrated master plan. As the design and development activity progresses, the achievement to data shall be tracked continually for each of the selected technical performance parameters. If the data falls outside the tolerance band a new profile or current estimate shall be developed immediately. The current estimate shall be determined from the “achievement to date” and the remaining time budgeted. An analysis shall be accomplished on the variation to determine the causes and to assess the impact on higher level parameters and on interface requirements.

3.1.6 Risk Management

The Contractor shall prepare, implement, and maintain a risk management process that includes identification, analysis, mitigation planning, mitigation plan implementation, and tracking. The Contractor shall develop and implement CS risk management, which will include security safeguards. These safeguards shall include but are not limited to local policy and guidance, identifies threats, problems and requirements, and adequately plan for the required resources. The Contractor’s risk management process shall measure future uncertainties in achieving program goals within schedule and performance constraints. The CS risk shall be addressed across the risk management process and can be addressed in multiple areas.

3.1.7 Management Reviews

3.1.7.1 Start of Work Meeting

A start to work meeting shall be held at the Contractor’s facility within 30 days after contract award. The start to work meeting shall be limited to the Contractor’s key team members identified in the proposal, and will be a two-day session with emphasis on the System Requirements Review (SRR), top level management of the program, agreement on metrics that will be used as management indicators during the program and partnering approach to implement.

3.1.7.2 Post Award Conference.

A post award conference shall be held at the contractor’s facility at a mutually agree to date after the start of work meeting. The conference shall introduce the key IPT participants, identify points of contact and discuss both parties understanding of the scope of work and other contract issues.

3.1.7.3 Program Management Reviews

The Contractor shall conduct formal program management reviews on an average of one every four months IAW the integrated master plan. The location of the reviews shall be mutually agreed upon. The program management review shall provide a program overview and a detailed discussion of pre-selected topics. Status and information at the review shall reflect currency since the previous review.

3.1.8 CS Control Review/RMF Implementation Plan Review (RIPR).

The contractor shall support a CS Control Review / RMF Implementation Plan Review (RIPR) held as part of the Preliminary Design Review (PDR). The CS Control Review/RIPR shall address at a minimum:

· Update on RMF Implementation Plan (RIP)

· Update Preliminary Data Flow and Accreditation Boundary Diagram

· Update on the hardware/software lists and procurement action

· Update on contractor CS training as applicable and the use of CS Scanning tools

· Update on design and system integration schedule

3.1.8.1 Technical Interchange Meetings (TIMs)

The Contractor shall conduct and participate in technical interchange meetings to be held at both contractor and Government facilities. The meetings shall be co-chaired by a Government and contractor representative. The Contractor shall be prepared to explain the reasoning, assumption, and methodologies in arriving at particular conclusions, recommendations, or alternatives in the accomplishment of the tasks required by the contract. The Contractor shall prepare drawings and other data, as required, to aid in the presentations. The Contractor shall have all the required personnel and resources present. The Contractor shall make available facilities for Government only meetings. These Government meeting facilities shall include direct internet access for Government personnel laptops. The Contractor shall prepare the meeting agendas and document the meeting results. Except where noted herein, meetings shall be considered fulfilled when all of the following items are completed:

· A formal review meeting has been conducted.

· All action items requiring contractor response have been documented and posted.

· Submittal of TIM minutes.

3.1.9 Visitor Support

The Contractor shall host very important person visits and arrange for and provide demonstrations of system performance, program progress, and other system characteristics when notified by the procurement contractor officer.

3.1.10 Integrated Digital Environment (IDE)

The Contractor shall establish, maintain and manage an interactive, online, protected, and access controlled IDE, such that the Government and contractor team members can contribute their ideas, comments and suggestions, exchange program information and collaborate in a distributed environment. The Contractor shall include software applications and data base services for the generation, integration, storage, indexing, distribution, simultaneous on-line sharing of digital data among all Government and contractor team members, and delivery of technical data products with associated contractors, subcontractors and Government organizations. The Contractor shall maximize the use and capabilities of existing open source software products as the Contractor defines the IDE components. Specifically, integrated automated databases are required which shall allow technical data sharing at the data base lever, rather than at the physical file level, with multiple formats of the same data from a common, configuration-controlled source available to different users. The IDE shall provide program personnel complete visibility into the system at every stage of development, regardless of data location. The Contractor shall ensure that everyone associated with this project has access to information they need to properly perform their duties.

3.1.10.1 The IDE Development and Installation

The Contractor shall provide a IDE with the following capabilities:

a. Ability to capture information as it's created.

b. Ability to manage product and program management structures.

c. Real-time information sharing and work flow implementation.

d. Team access to the most current information.

e. Ability to assign rules regarding information access.

f. Common information architecture that is distributed geographically.

g. Electronic notification of changes to program and product information.

h. Ability to present a single interface to the entirety of the Contractor’s and the Contractor’s subcontractors' data creation activities.

i. Ability to recover from unexpected loss of program data due to environmental disasters, operator error, equipment failure, and hostile intruders.

j. Ability to provide access to program data using standards defined in section 2.3 of the Joint Technical Architecture-Army as defined in the DISR, or through an open systems approach.

3.1.10.2 IDE Administration

The Contractor shall provide a World Wide Web based electronic data management system to facilitate the electronic data interchange of non-classified data. Except where noted specifically on the DD Form 1423, The Contractor shall provide this service for items on the data accession list, management data, and technical data generated and maintained in digital format. The Contractor shall provide the Government and contractor team members with the capabilities for on-line review, and comment of deliverable data. The Contractor shall include these comments, approvals and acceptances in the database as well as mechanisms to establish appropriate audit trails to identify the sources of these additions and to maintain configuration control. The Contractor shall develop and implement procedures for establishing and administering user accounts for the IDE.

3.1.10.3 IDE Data Management

The Contractor shall provide an Internet based IDE to facilitate the electronic data interchange of all program data. All management, technical, cost, and schedule data (including all internal documents produced to design, develop, test and manage the program) shall be made available to all Government and contractor team members in an integrated, electronic, and query capable database, accessible via the Internet. The Contractor shall provide the capabilities for on-line review, comment, acceptance and approval of all deliverable data. The Contractor shall establish a disaster recovery process to ensure that appropriate information systems and data are available when needed after a natural or human disaster.

3.2 Systems Engineering

The Contractor shall implement a system engineering process that will transform all system and IA requirements into a set of lower level performance requirements that define the system. The process shall accomplish planning, identify and allocate functional requirements, identify participation in trade studies, provide inputs to documentation, and include design reviews. The system engineering effort shall integrate all elements of a multifunctional engineering effort to meet system requirements. The Contractor shall insure the timely integration of engineering specialties such as reliability, maintainability, security engineering, logistics engineering, human factors engineering, safety, value engineering, standardization, and transportability into design and development. The Contractor shall develop and complete all planned integrated master schedule (IMS) tasks for each milestone. The Contractor shall as part of the systems engineering effort update and maintain the Systems Engineering Management Plan (SEMP) as a living document. The Contractor shall use the SEMP to identify and assure control of the overall technical management process. The Contractor shall coordinate the contents of the Government SEP with the contractor‘s SEMP.

3.2.1 System Design

The Contractor shall use PRF-PT-684 as the basis for development of all lower level specifications. The Contractor shall perform trade off studies and then finalize the system design. The design concept shall include incorporate an open systems approach which shall be based on an engineering and business strategy to choose specifications and standards adopted by industry standards bodies or de facto standards (set by the market place) for selected system interfaces, products, practices and tools. Selected designs and specifications shall be based on performance, cost, CS, industry acceptance, long term availability and supportability, and upgrade potential. Using PRF-PT-684 the contractor shall analyze the existing path against the current Interactive Electronic Technical Manual (IETM).

3.2.1.1 System Definition Stage

The Contractor shall establish the definition of the system with a focus on system products The Contractor shall establish the definition of the system with a focus on system products required to satisfy operational capabilities defined in the end user requirements documents (e.g., ICD, CCD, TSRD). The Contractor shall complete the system, subsystems, and interface requirements and verification definition. The Contractor shall establish a system baseline and complete technical reviews. The documentation generated during system definition shall be used to guide subsystem development. A systems definition review shall be completed at the completion of the systems definition stage for the purpose of determining whether the system definition is sufficiently mature to progress to subsystem definition. The system definition shall be reviewed to ensure that:

a. The design is sufficiently mature to meet systems engineering criteria.

b. System functional requirements and system non-functional requirements (e.g., performance, design goals (e.g., modular open system approach (MOSA)) are identified.

c. System-level risks have been adequately addressed to justify continued development.

d. Trade-study data are adequate to substantiate that system requirements are achievable.

e. Interface requirements between human and products or subsystems have been identified, including performance, workloads, design constraints, and usability.

f. Selected Information Assurance products that are NIAP-validated or on the DoD Unified Capability (UC) Approved Products List (APL) (https://aplits.disa.mil/processAPList.do).

g. Decisions made in arriving at the system definition configuration are well supported by analysis, test, and other technical data, including estimation of the manpower required to operate and maintain the system, the skills and abilities of the personnel required to operate and maintain the system, the training plan for operators and maintainers, and safety and health hazard considerations associated with the system.

(DI-IPSC-81465A) System/Subsystem Specification (SSS)

3.2.1.2 Preliminary Design Stage

The Contractor shall initiate subsystem design and create subsystem-level definition and design-to baselines to guide component development. The Contractor shall ensure that the design considerations include systems functional requirements, systems non-functional requirements (e.g., performance, design goals (e.g., modular open system approach (MOSA)), and Human System Interfaces. The Contractor shall ensure that functional design considerations integrate IA functional requirements and that these requirements are included throughout the development process. The Contractor shall decompose identified subsystem functions into lower-level functions and allocate functional and performance requirements to component-level functional and physical architectures. Each preliminary subsystem requirements and verification definition and preliminary design-to baseline shall be evolved into a subsystem requirement and verification definition and design-to baseline. Preliminary component requirements and verification definition and build-to baselines shall be defined for the components and the subsystem being developed. Final subsystem definition shall include identification of recommended components and interfaces; resolution of subsystem-level risks; assessment of component risks; and design for quality factors to include producibility, verifiability, usability, IA, supportability, trainability and disposability for each subsystem. Subsystem reviews shall be completed for each subsystem at the completion of its preliminary design stage. The results of the evaluation shall be documented. The purpose of each review is to assure that:

a. The subsystem definition is sufficiently mature to meet systems engineering criteria.

b. The subsystem functional requirements and non-functional requirements (e.g., performance, design goals (e.g., modular open system approach (MOSA)) are identified in the subsystem design and are traceable to the system functional and non-functional requirements.

c. Component allocations and preliminary component specifications are reasonable and provide a sound subsystem concept.

d. Software architecture is described using three views: 1) software module view; 2) software runtime view, and 3) software deployment view.

e. Subsystem risks have been assessed and mitigated to a level appropriate to continue development.

f. Trade-study data are adequate to substantiate that subsystem requirements are achievable.

g. Human system interfaces are identified and described in the subsystem design and are traceable to design requirements.

h. Decisions made in arriving at the subsystem configuration definition are well supported by analysis and technical data, including estimation of the manpower required to operate and maintain the system, the skills and abilities of the personnel required to operate and maintain the system, the training plan for operators and maintainers, and safety and health hazard considerations associated with the system.

i. Security engineering processes are integrated into the design to achieve an integrated secure solution

3.2.1.3 Detailed Design Stage

The Contractor shall complete subsystem design down to the lowest component level, and create a component requirements and verification definition and build-to component baseline for each component. Final component definition shall include identification of recommended parts and interfaces; resolution of component-level risks and for each component, down to the lowest sub-component, the design for quality factors to include producibility, verifiability, usability, IA, supportability, trainability and disposability. Component reviews shall be completed for each component at the completion of the detailed design stage. The Contractor shall integrate security engineering processes into the design to achieve an integrated secure solution. The results of the evaluation shall be documented. The purpose of this review shall be to ensure that:

a. Each detailed component definition is sufficiently mature to meet measure of effectiveness and measure of performance criteria.

b. Component specifications are reasonable and provide a sound component concept.

c. Component and related life cycle process risks have been assessed and mitigated to a level appropriate to support the fabrication, assembly, integration and test phases.

d. Trade-study data are adequate to substantiate that detailed component requirements are achievable.

e. Software architecture is described using three views: 1) software module view; 2) software runtime view, and 3) software deployment view.

f. Human system interfaces are identified and described in the detailed design and are traceable to design requirements.

g. The detailed software design (to include COTS/GOTS product name and version number) is described in terms of the satisfaction of…