Atch 20_NM ND STO_NetOps SB.doc

UNCLASSIFIED/DRAFT/FOR OFFICIAL USE ONLY

NETCENTS-2 NetOps and Infrastructure Solutions (Small Business Companion)

Subfactor 3 - Network Management/Network Defense (NM/ND) Cost Reimbursable Sample Task Order Remote Application Management System (RAMS)

1. INTRODUCTION

The competitive nature of this contract necessitates that each respondent propose a solution to a sample task that will assist the Source Selection Evaluation Team in its efforts to assess the depth and breadth of each contractor's capabilities. This sample task order will be evaluated as a “best value” competition and not solely as a “price” competition. The Government does not expect to receive any deliverable that is CDRL-driven in connection with this sample task order proposal.

The offeror shall use the information contained in this sample task order to prepare a proposal for the Government’s evaluation of meeting the stated requirements.

2. BACKGROUND

The Air Force requires a system to enable remote, centralized, standardized management of applications at base Network Control Centers (NCCs). The base NCCs include CONUS and OCONUS locations. Four Air Force (AF) Integrated Network Operations and Control Centers (I-NOSCs) will use this system to manage the applications, and to provide situational awareness to the AF Network Operations Center (AFNOC).

3. ASSUMPTIONS

The operational environment is assumed to be Government owned and managed. The sample task order is provided as a sample of a typical CITS NM/ND task order under the NETCENTS-2 NetOps and Infrastructure Solutions contract. As such, it contains a complete set of descriptive requirements for the purpose of helping to frame the Remote Application Management System (RAMS) requirements in a real-world context. For the purposes of the NETCENTS-2 NetOps Evaluation, within the Specific Requirements section of this sample task order (Section 9), only the paragraphs annotated with an asterisk need to be addressed for evaluation purposes.* Those marked pertain to the critical requirements that will be evaluated IAW Section L and M of the RFP: Management and Monitoring of a Service; RAMS Situational Awareness, RAMS Virtual Infrastructure, and Enterprise Requirements. If subparagraphs are marked as well, only those subparagraphs need to be addressed. Assume the following period of performance applies for the contract:

Period of Performance: While a typical task order will not exceed five years, the offeror is required to provide pricing information IAW Section J, Attachment 21, Price Proposal Workbook.

For pricing evaluation purposes, assume the following for RAMS installation and sustainment:

· 2 year base period for 24 month installation period

· 8 one year options for 96 month sustainment period, where the priority is supportability of RAMS. This involves focusing on the overall health of the RAMS system and being responsible for troubleshooting and/or debugging RAMS related problems.

· Maintenance/technical refreshes for hardware and COTS software will not be included

For price evaluation purposes, assume materials will be purchased from the NETCENTS-2 Products contract vendors. Since the NetCentric Products contract is not available at this time, for the purposes of this sample task order, any products required for the solution should be assumed to be a 10% reduction from GSA pricing.

In addition, portions of Section 8 0 General Requirements may need to be addressed by offerors since they describe the standard processes and work needed to accomplish development of the asterisked items in Section 9 – Specific Requirements. The offeror shall input the proposed cost/price for the NM/ND sample task order into the Cost Reimbursable Sample TO tab of the Price Proposal Workbook (Section J, Attachment 21) in the format prescribed, to include additional hardware and software.

3.1 Disaster Recovery

The offeror is to assume, if necessary, an appropriate disaster recovery plan that is in-line with commercially acceptable standards and matches data storage and application requirements listed within the sample task order.

3.2 I-NOSC Tools

For the purposes of this sample task order, the offeror is to assume the following:

· No current tools exist in the environment that fulfill the requirements listed in sections 9.2.X

· The current software is available within the environment is IBM Tivoli Netcool/Omnibus version 7.2.1. Assume all associated modules for this tool to be available for use.

· Assume that all I-NOSC related information is available within the IBM Netcool suite of tools and that public APIs for that tool should be used to provide data to the RAMS solution.

· Assume the information from the I-NOSC captured within the IBM Netcool suite of tools provides monitoring information about the status of the network and all network devices.

· Assume that an interface to the trouble ticketing system exists within Netcool.

Assume I-NOSC data is within IBM Netcool suite of tools. “Other resources” should be limited to the trouble ticketing system (which is already tied into Netcool) for purposes of this sample task order.

3.3 NCC Tools

For the NCC, assume there is a Microsoft set of software (AD, DC, etc) to support the listed products at each base although each base may have differing configurations and versions. Assume the Exchange versions to be supported include Exchange 2007, Exchange 2003, and Exchange 2000 and will support clustering where applicable. Assume the OS to be Microsoft Windows Server 2008 or Windows Server 2003. Assume Windows SharePoint Services (WSS), Microsoft Office SharePoint Service (MOSS) and Microsoft Search Server (MSS) of various versions including WSS versions 3.0, MOSS 2007, and MSS 2008. Assume a mixture of Microsoft and Unix based DNS and DHCP servers. Assume Microsoft Office Communicator Server (OCS) version 2007 and 2007 R2. Assume the Blackberry Enterprise Server (BES) for Microsoft Exchange to be version 5.0 and 4.1.

Note* For the purpose of this sample task order, assume that hardware, virtual machine, and OS administration is in place and is not to be included in the response.

3.4 ESD/AFNOC Assumptions

For the ESD, the only relevant software is the trouble ticketing software also listed above.

For the AFNOC, the only relevant software is the IBM Tivoli software pieces and versions as listed above for the I-NOSC.

3.5 Network Design Assumptions

For the purpose of this sample task order, the offeror is to assume the following:

· Affectively ignore the boundaries at the base NCCs and RAMS locations by assuming nominal boundary effect on bandwidth and overall network performance

· Assume a logical out of band management (OOBM) network exists within the AF network for RAMS use

· Assume 1Gb active-active connection to the AF network at each base NCC with rate limits set to 100Mb for the logical management network being used by RAMS; assume 50 Gb active-active connection to the AF network at each RAMS locations with rate limits set to 40Gb for the logical management network being used by RAMS

· Assume 110 base NCC locations with 10% OCONUS and assume 1,000,000 mailbox users and 250,000 Blackberry users

· Assume 4 RAMS (I-NOSC) locations with 2 CONUS and 2 OCONUS

· Assume all servers at the base NCCs can support any additional CPU and storage requirements levied by the RAMS solution

3.6 VI Suite Assumptions

The offeror is to propose additional hardware to expand the existing hardware given the current hardware components. Exclude the chassis, filers, and rack in the proposal. Assume fiber channel adapters and tape library devices are in place.

Assume no facility requirements for this sample task order. However, the contractor is expected to install the additional hardware (blades and disk shelves/disks) into the in place VI structure.

All hardware resources are listed in table 2.0 Hardware Components. It should be assumed that no disk space or blade is available for this sample task order and that the offeror should propose additional hardware of this form factor. Additionally, all software (including Operating System and other system software items) has been provided for the associated hardware listed in Table 2.0.

4. SCOPE

The RAMS is an operations center concept that enables centralized monitoring, management, administration and configuration control of Network Control Centers (NCC) applications in a standardized fashion. NCC applications are defined by the Air Force IT community as central components and embody the seamless, secure, and reliable transport of timely and trusted information across the AF-GIG. Several RAMS will be instantiated to provide AF Network Situation Awareness (SA) to the Integrated Network Operations Security Center (I-NOSC) on the status of applications and have the capability to notify Major Commands (MAJCOM) of problems with services that could affect operational missions.

The four (4) proposed RAMS locations are listed below, in Table 0.1 (RAMS Deployment Sites)

Table 1.0 (RAMS Deployment Sites) The RAMS solution will consist of

a) RAMS tools that enable enterprise management of identified NCC applications located on specified fixed bases;

b) RAMS situational awareness of managed applications.

The RAMS solution and application management capability will be deployed on the NIPRNet. It will provide remote management of NCC mission assets at the same or better level of performance that these services are currently provided by local base NCCs. The RAMS solution will provide the actionable information needed to make critical support decisions and continuously improve support and availability of NCC applications. It will leverage the capability to administer applications and related resources based on the actionable information provided. It will leverage the existing systems and tools for centralized monitoring, management, and configuration control of NCCs. Some system hardware and touch maintenance will remain at the NCCs to maintain network integrity, but management will migrate to the RAMS locations.

5. APPLICABLE DOCUMENTS

a) Air Force Network Operations, Security Classification Guide, 20 April 2007

b) DoD Information Assurance Certification and Accreditation Process (DIACAP), DoDI 8510.01, November 28, 2007

c) Information Assurance (IA) Implementation, DoD Instruction 8500.2, February 6, 2003

d) Management of the Department of Defense Information Enterprise, DoD 8000.01, February 10, 2009

e) Air Force Technical Manual Contract Requirements (TMCR), TM-86-01M, 1 August 2006

f) Design Criteria Standard Human Engineering MIL-STD-1472F 23 August 1999

g) National Security Telecommunications and Information Systems Security Policy (NSTISSP) number 11, National Policy Governing the Acquisition of Information Assurance (IA) and IA-Enabled Information Technology Products, July 2003

h) EIA/TIA-569-A Pathways and Spaces Standard (EIA/TIA)-569A

i) Common Operating Environment User Interface Specification Version 4.3, December 2003

6. DEFINITIONS IN CONTEXT

· Leverage: Use of the word “leverage” indicates that the vendor should utilize assets and related functionality that exists within the Air Force if consistent with meeting the requirements outlined in this document

· Monitoring: The act of observing behavior and gathering related data to enhance the management and administration of systems.

· Management: The process and action that gathers resources and data and uses them to accomplish desired goals and objectives.

· Administration: The act of installing, supporting, and maintaining systems and assigned dependencies based on management objectives.

The term “application dependency” will be employed to mean all ancillary hardware and software components upon which a managed application is dependent.

6.1 Data Retention Tiers Description

Data retention is now an umbrella term applied to the two different types of ‘data storage’, backup and archival. Most companies now require some sort of data retention system which allows for both backup and archival, but often only have back up capability. This quick guide will help to clarify the three different tiers involved in a complete data retention environment. In this task order, only tier 1 and 2 requirements will apply.

6.1.1 Tier 1 (On-line storage)

Tier 1 is really meant to be for backup. The kind of data you would normally store here is information you need to access infrequently but may need to change, also data which needs to be kept for a short time and then deleted, e.g. if you’re backing up a database every day, you would normally not wish to keep hundreds of copies and would overwrite the previous days back up. Traditionally the best system to use for tier 1 is RAID (redundant array of independent discs), RAID being a collection of hard drives with different RAID levels being available (striping, parity, fault tolerance etc).

6.1.2 Tier 2 (Near-line Storage)

This tier is the first level of archival. Data held on tier 2 systems must be kept (for compliance reasons), but doesn’t need to be regularly accessed and shouldn’t be changed. This is usually financial records, transactions, CAD, company records and the like. Near-line storage has many benefits; less stress on the server, content held on tier 1 is moved and frees up more space, data can be quickly accessed among others. The preferred media of Near-line storage is either Tape or Optical.

6.1.3 Tier 3 (Off-line Storage)

Off-line storage is extremely important to any organization. Providing it is properly implemented, off-line storage will serve as your disaster recovery should you have a fire, flood or suffer any other disaster which results in data loss. This works very effectively when combined with a Near-line system which offers mirroring. When data is written to the Near-line system, a duplicate copy is created allowing the IT Manager (or whoever is managing the system) to remove the duplicate and store it off-site. Again many companies will only create one copy of data they need to keep and you can equate it to putting all your eggs in one basket. Having tiers 2 and 3 really is the best way of ensuring you have copies of your valuable data.

7. ASSUMPTIONS

The offeror must consider existing capabilities in its RAMS solution design. A virtual infrastructure (VI) already exists at the specified RAMS locations and is described below.

7.1 Virtual Infrastructure (VI) Description

Each RAMS Block or Spiral integration effort requires equipment and hardware upgrades to the established RAMS baseline architecture. In order to simplify the acquisition process, shorten system logistics and sustainment trails and shorten each project’s integration cycle, the RAMS PMO sought to create a common hardware platform which all RAMS projects could utilize and expand upon.

In addition to defining a unified hardware architecture, the Virtual Infrastructure (VI) system was designed to take advantage of key developments in the commercial market relative to system virtualization. The integration of virtualization technology into the VI system severs the link between system hardware and the software / applications which are installed on that hardware. This de-coupling of hardware and software, when combined with Storage Area Network technologies and systems, greatly expands the overall system’s high availability, disaster recovery, and dynamic resource scheduling capabilities.

The hardware components which make up the VI Spiral 1 architecture are defined in the Table 2.0 below. Spiral 1 VI locations/systems will be installed and configured using virtualization software. VI systems will be virtualized using VMWare Enterprise 3.5 which will create an abstraction layer that allows multiple virtual machines, with heterogeneous operating systems to run in isolation, side-by-side on the same physical machine.

HP MSL4048 -or- Sun L1400 Tape library (varies by location and storage requirement)

NetApp

FAS3070 & FAS6070

Storage Area Network (models / sizing varies by location & network)

Table 2.0 VI Hardware Components

8. GENERAL REQUIREMENTS

Portions of this section-General Requirements-may need to be addressed by offerors since they describe the standard processes and work needed to accomplish development of the asterisked items in Section 9 - Specific Requirements.

8.1 Preliminary Integration Review (PIR)

Upon Contract award, the Contractor shall host and lead a Preliminary Integration Review (PIR) meeting / presentation. The Contractor shall present the following at the PIR:

· Proposed system architecture with supporting drawings

· Traceability matrix indicating designs compliance with the Technical Requirements Document (TRD)

· Risks and opportunities associated with the RAMS management system

· Strategy for supporting Certification Test and Evaluation (CT&E), and Security Test and Evaluation (ST&E)

· Proposed training syllabus

· RAMS facility requirements (space, power, HVAC, etc.)

· Integrated Master Schedule

8.2 Critical Integration Review (CIR)

The Contractor shall host a Critical Integration Review (CIR) meeting / presentation. The Contractor shall present the following at the CIR:

· Final system architecture and designs in accordance with submitted design documentation

· Cross-Reference matrix indicating design compliance with the Technical Requirements Document (TRD)

· Risk mitigation and/or opportunities being leveraged in association with the RAMS design

· Complete testing plan

· Training syllabus

· Facilities requirements (space, power, HVAC, etc.)

· Integrated Master Schedule

8.3 Integration Environment

The Contractor shall provide a lab environment capable of testing the RAMS architecture agreed upon by the Government during the CIR. The lab should mirror the Air Force network environment to the maximum extent possible, to include the I-NOSC’s virtualized infrastructure. Material procured for the lab system environment will be used for the second RAMS installation.

8.4 Site Preparation

Upon contract award, the Contractor shall conduct site surveys of the I-NOSC locations in preparation for installs. In a System Installation Plan (SIP) for each site, the Contractor shall identify all site preparation work, to include labor categories, hours, and materials, and redline drawings reflecting the proposed system implementations in the existing facility / network drawing sets.

8.5 Install RAMS

The Contractor shall install the RAMS at each I-NOSC, and perform configuration tasks at each base NCC necessary to cut-over control from local base resources to the I-NOSC using RAMS. Locations are defined in the TRD. The Contractor shall populate the CITS Asset Management Form which is provided as Government Furnished Information (GFI), to document the delivered system, including UID information where necessary (para 8.8). The Contractor shall deliver the completed form as part of the 1261 turnover process for each location.

8.6 Technical Orders (TOs)

The Contractor shall provide validated tech data, based on the Arbortext product from PTC and associated style sheets. The government will supply required Arbortext licenses as GFE. The CITS PMO will convert the Offeror-provided Arbortext product to AF Technical Order (TO) format, and conduct verification the TOs. The Contractor is responsible for the technical accuracy of the documentation developed, to include correcting errors identified during validation and verification, and ensuring the configuration baseline identified in the tech data matches the delivered system. The Contractor shall secure a copyright release for Government use, from the vendor, for the Government to reproduce and use any copyrighted information contained in the vendor's commercial data.

8.7 Training

The Contractor shall develop and provide training for personnel in accordance with the Government approved Training Plans. The object of the training is to introduce personnel to the systems and their functionality, and to provide designated personnel the knowledge necessary to support, manage, and operate the system’s hardware and software tools to perform their jobs. The Contractor shall provide initial training only at each I-NOSC, at the Air Force IT schoolhouse at Keesler AFB, MS, and at the AFNetOps Help Desk at Gunter Annex, AL. Training programs will be designed for an Administrator/Analyst skill level of 7-level and a Technician skill level of 5-level. Two classes will be taught at each location, for a total of twelve classes, with up to 20 people per class.

8.8 DoD Unique Identification

IAW DFARS 252.211-7003, the Contractor shall provide DoD Unique Item Identification (UID), or a DoD recognized unique identification equivalent, for: (i) all delivered items valued at $5,000 or more and (ii) all manufacturer-serialized items less than $5000 in value.

8.9 Management

8.9.1 Integrated Management Schedule (IMS)

The Contractor shall track, manage, and report on the schedule, cost, and performance status of this effort. The Contractor shall present this status at quarterly program management reviews. The Contractor shall provide daily situational reports via electronic mail whenever Contractor personnel are on-site for surveys, system implementation and/or sustainment efforts. Monthly Status reports will be provided to the Government.

8.9.2 Data Rights

The Contractor shall provide unlimited data rights to the Government, for all data prepared under this delivery order, In accordance with the Federal Acquisition Regulations Subpart 27.4 - Rights in Data and Copyrights.

8.9.3 Personnel Identification & Security Clearance Requirement

The Contractor shall ensure all personnel working under this Contract possess a valid and current SECRET, or higher, security clearance.

8.9.4 The Government will provide those personnel who require regular access to DoD facilities a Common Access Card (CAC) identification badge containing valid DoD PKI certificates. The Government will provide those personnel working tasks on this Contract, who do not require regular access to DoD facilities, with a Letter of Introduction (LOI). Access to DoD websites will not be considered an adequate reason for the issuance of a CAC if those sites accept ECA certificates in lieu of CAC based PKI certificates.

8.9.5 The Contractor shall procure Department of Defense (DoD) compliant subscriber certificates from approved External Certification Authorities (ECA) for those individuals working this task who do not require a CAC. Additional information regarding ECAs, including information on where to obtain certificates, can be found at http://iase.disa.mil/pki/eca/certificate.html.

8.10 Certification & Accreditation

Building upon the Contractor’s RAMS design developed during the CIR phase of the solicitation, the Contractor shall perform appropriate tasks to complete C&A through Phase III as defined in the following sections.

The Contractor shall implement Department of Defense Instruction (DoDI) 8510.01, DoD Information Assurance Certification and Accreditation Process (DIACAP) guidance as defined in the DIACAP knowledge service located at https://diacap.iaportal.navy.mil.

DIACAP Certification & Accreditation (C&A) documentation and processes are governed by the following reference documentation:

· DoDI 8510.01 – DIACAP

· DoDD 8500.01E - Information Assurance (IA)

· DoDI 8500.2 - IA Implementation

· AFPD 33-2 - IA Program

· CJCSI 6510.01D - IA and Computer Network Defense (CND)

· CJCSM 6510.01 - Defense-In-Depth: IA and CND

· CJCSI 6211.02B - Defense Information System Network (DISN): Policy, Responsibilities and Processes

The Contractor shall deliver the following artifact documentation as part of the C&A process:

· Certification Test & Evaluation Plan & Procedures

· DIACAP Information Security Plan

8.11 IT Lean / SISSU

The Contractor shall fulfill the “Producer” role, as defined in the Air Force IT Lean Guidebook, in support of the Security phase of the Security, Interoperability, Sustainability, Suitability, Usability (SISSU) based system Certification & Accreditation process for the systems deployed under this effort. In their role as the system “Producer” the Contractor shall input data relevant to the deployed system in the Enterprise Information Technology Data Repository (EITDR). The Contractor shall be responsible for ensuring the deployed systems under this effort gain full system Authority to Operate (ATO). Should an Interim Authority to Operate (IATO) or Interim Authority to Test (IATT) be required, the Contractor shall ensure all affected integration documentation is updated, as necessary, to resolve security vulnerabilities thus allowing a full ATO to be issued. The Government will provide assistance and/or documentation as required in order to support the Contractor’s IT Lean / SISSU activities. The Contractor shall complete Phase II of the EITDR SISSU process prior to the Critical Integration Review.

8.12 Information Assurance Personnel

The Contractor shall designate an individual as their Information Assurance (IA) lead. The Contractor’s IA lead will be knowledgeable in the DIACAP C&A process, will interact with Government assigned C&A personnel, and will participate in IA working groups / meetings. The Contractor’s IA lead will have 3-7 years of IA related experience and will, at the least, be IAT Level II certified in accordance with (IAW) Table C3T4 of DoD manual 8570.01-M.

The Contractor’s IA lead will serve as the Point of Contact for all C&A test events such as vulnerability assessments and penetration tests. The Offeror’s IA lead will also act as the Point of Contact for Information Assurance compliance and security validation events such as Certification Test & Evaluation (CT&E) and Security Test & Evaluation (ST&E). The Contractor’s IA lead will address all aspects of IA control implementation during these events.

The CITS Program Management Office (PMO) will provide IA personnel to assist and participate in the DIACAP C&A process with the role of “SISSU Reviewer.” The Contractor shall work with and accept input and feedback from the PMO C&A team during the execution of this DO. The Contractor shall retain final responsibility to gain an ATO for the deployed systems under this effort IAW paragraph 8.11.

8.13 IA Control/Requirement Validation (CT&E)

The Contractor shall utilize the completed system installation in the CITS lab at Hanscom AFB to conduct a Certification Test & Evaluation (CT&E) event using the Government Approved CT&E Plan & Procedures. The Contractor shall document the results of the CT&E evaluation in a formal IA Validation Test Report. All vulnerabilities discovered during CT&E, as well as all actions taken to resolve those vulnerabilities, will be recorded in the Contractor’s Validation Test Report. The Contractor shall update relevant systems integration documentation to reflect changes necessitated by vulnerability remediation activities. These activities will be in direct support of the DIACAP C&A package and will, at a minimum, address all relevant DIACAP IA controls.

The Contractor shall ensure all Category I vulnerabilities are resolved or mitigated as required. The Contractor shall work to resolve or mitigate all Class II and III vulnerabilities. Class II and III vulnerabilities which cannot be mitigated must be approved by the Government. The Contractor shall develop a Plan of Action and Milestones (POA&M) to document residual vulnerabilities present in the system which are accepted by the Government and the plan to mitigate or eliminate those vulnerabilities in the future.

In the case where final test results are classified, the Contractor shall not update EITDR with the results but will instead use manual or automated method to document the findings / vulnerabilities on SIPRNET in order to generate a POA&M.

8.14 IA Control/Requirement Verification (ST&E)

The Government will execute an independent ST&E event using the Contractor supplied CT&E test plan and procedures to verify the Contractor’s CT&E test results. The Contractor shall support the Government in its IA Control verification ST&E efforts by providing systems engineering and documentation support. Should the results of the CT&E and ST&E not match, the Contractor shall work with the Government to identify where the differences were generated and perform documentation, resolution, and POA&M generation steps in order to resolve the discrepancy.

8.15 Government Furnished Items

8.15.1 Government Furnished Information (GFI)

The Government will provide the following information:

a. Asset Management Form(s)

b. Memo of available GFI/GFE software

8.15.2 Government Furnished Equipment (GFE)

The Government will provide Software licenses and/or access to the following products as GFE, if required:

a. ArborText Licenses

b. Government owned licenses to support CIR approved system architecture

c. Virtualized infrastructure (VI) at the I-NOSCs, excluding hardware (blades, storage) required to scale the VI for RAMS

8.16 Field Service Evaluation (FSE)

The Contractor shall conduct FSE testing consisting of complete installation of the first RAMS system to manage the required core services at 11 CONUS bases. FSE will test the system in an integrated, operationally relevant environment to verify the system meets the requirements specified in the Sample Task Order (TO). The Contractor shall develop draft test plans to test for the requirements contained in the TO to be presented to and reviewed by the government for approval during the PIR (A022). Final Test Plans are to be developed and approved by the government by CIR. The Contractor shall conduct a Test Readiness Review 5 days prior to the start of FSE. Test Procedures are to be developed and approved by the government by the Test Readiness Review. The Contractor shall complete and submit a test report to the Government no later than 30 days after the completion of FSE. All deficiencies discovered during FSE, as well as all actions taken to resolve those deficiencies, will be recorded by the Contractor in the test report.

8.17 Qualification Test (QT)

The Government will conduct a Qualification Test at the first RAMS location and 11 CONUS bases based on Government developed test plans and procedures to evaluate compliance with the TO; compliance with system specification requirements; measure progress in system development; gauge operational performance of the system; and to identify system problems or deficiencies prior to operational use. The Contractor shall support the Government conducted Qualification test events to include engineering support, test readiness reviews, and the resolution of deficiencies

8.18 Operation Test (OT)

Following Qualification Test, as defined above, the Government's Operational Test Organization will determine the sites at which they will conduct an Operational Test event to verify the systems operational suitability and effectiveness. The Contractor shall support the Government conducted operational test events to include engineering support. Additionally, any base used during OT that was not a QT site will be included in OT support.

8.19 System Acceptance Test

The Contractor shall conduct an FSE test event at each of the remaining RAMS installation sites using the Test Plan and procedures described in the FSE section above to demonstrate the installation at the remaining RAMS locations meets the requirements specified in the Task Order. The Contractor shall conduct a Test Readiness Review 5 days prior to the start of each FSE. The Contractor shall complete and submit a test report to the Government no later than 30 days after the completion of FSE.

8.20 Transition

The Contractor shall provide support to ensure a smooth transition of the system to local operators. The Contractor shall provide on-site support for thirty (30) calendar days following the installation of each RAMS location. The Contractor shall provide a "turn-over package" to include an inventory of any newly-installed equipment and software, test results, site-specific "as-built" engineering drawings, and a summary of any open items. The Contractor shall also provide proof that all equipment is registered with the OEM and ownership title has been transferred, and shall ensure the USAF has access to all service or support as the owner of the item.

8.21 Sustainment (Maintenance)

For purposes of the NETCENTS-2 NetOps Evaluation, sustainment/maintenance will consist solely of contractor support for Help Desk support of the fielded RAMS solution.

9. SPECIFIC REQUIREMENTS

9.1 The RAMS solution COTS components shall be Common Criteria evaluated.

9.1.1 Architecture

9.1.1.1 The RAMS solution shall have a common, standardized, open architecture that shall be utilized to distribute managed application monitoring, management, and administration over multiple RAMS locations.

9.1.1.2 The RAMS solution architecture shall be interoperable with the RAMS architecture, RAMS tools, and systems managed under RAMS programs.

9.1.2 The RAMS locations shall operate 24 hours a day/7 days a week, and perform troubleshooting procedures to restore faults and provide managed applications support to the NCCs.

9.1.3 The RAMS solution shall provide a Central Management User Interface for all aspects of remotely managing servers and workloads that will allow for management of 100% of managed applications without requirement to log into each service individually.

9.1.4 Each RAMS shall be capable of monitoring, managing and administering all managed applications of its designated bases within the AF as managed by the RAMS solution.

9.1.5 Each RAMS shall be capable of monitoring, managing and administering all managed applications of all bases within the AF as managed by the RAMS solution.

9.1.6 The RAMS solution shall remotely monitor, manage and administer managed applications leveraging standard AF tools and government-owned equipment.

9.1.7 The RAMS solution shall identify and incorporate proven alternative technology solutions to enable the monitoring, management and administration of managed applications.

9.1.8 The RAMS shall provide management of managed applications on Non-Classified Internet Protocol Router Network (NIPRNet).

9.1.9 The RAMS solution shall be capable of operating within the various network availabilities and bandwidth limitations.

9.1.10 Migration of managed application management, monitoring, and administration from NCC to RAMS

9.1.10.1 Management, monitoring, and administration of AFLUC listed managed applications shall be transferred to the RAMS from the base NCCs as part of the RAMS migration schedule.

9.1.10.2 The RAMS shall be able to manage, monitor, and administer the services located at the NCCs before, during and after the services have been migrated into APCs from the base NCCs as part of the APC/service migration schedule.

9.1.10.3 At the end state, the RAMS shall provide management, monitoring, and administration of managed applications, as required, remaining at the NCCs on the NIPRNet.

9.1.10.4 The RAMS shall be able to manage, monitor and administer the applications located at the NCCs.

9.1.11 RAMS Solution Design

9.1.11.1 The RAMS solution shall consider a phased execution with rollback procedures that are reviewed and approved by authorized government personnel prior to implementation.

9.1.11.2 The RAMS solution shall include, gather and prepare information about managed applications tasks, procedures, business rules, and policies to include associated operational architectural drawings – operational views (OVs), managed applications equipment, and managed applications architecture.

*9.2 Management and Monitoring of a Service.

Managed applications are defined by the Air Force IT community as central components and embody the seamless, secure, and reliable transport of timely and trusted information across the AF-GIG. The following Air Force managed applications will be remotely monitored, managed and administered by each RAMS:

*9.2.1 The RAMS solution shall monitor, manage and administer Microsoft Exchange.

*9.2.2 The RAMS solution shall monitor, manage and administer the Blackberry Services.

*9.2.3 The RAMS solution shall monitor, manage and administer Microsoft Office Communicator.

*9.2.4 The RAMS solution shall monitor, manage and administer SharePoint Enterprise Content/Information Management.

9.3 User Interface Characteristics

9.3.1 The RAMS solution GUIs, including the Central Management User Interface and the RAMS Situation Awareness (SA) View shall be designed in accordance with all applicable government and industry user interface design standards, style guides, and guideline documents, including, but not limited to:

9.3.1.1 Common Operating Environment Operator Interface Specification, Version 4.3 or the latest applicable DoD user interface standard MIL-STD-1472F, “Human Engineering Design Criteria for Military Systems” (physical and environmental components) MIL-STD-46855, “Human Engineering Requirements for Military Systems” (human engineering process).

9.3.2 Human Factors Engineering

9.3.2.1 The RAMS SA view and the Central Management User Interface shall apply Human Factors Engineering (HFE) in user interface design to minimize frequent or critical errors.

9.3.2.2 The RAMS SA view and the Central Management User Interface shall provide default values where user input is required.

9.3.2.3 The RAMS SA view and the Central Management User Interface shall comply with 1472 paragraph 5.2.1.3.3 format: information shall be presented to the operator in a directly usable form. Requirements for transposing, computing, interpolating, or mentally translating into other units shall be avoided.

9.3.2.4 The RAMS SA view and the Central Management User Interface shall require an additional confirmation step from the human operator for commands with mission critical impact, destructive impact, or unrecoverable actions.

9.3.2.5 The RAMS SA view and the Central Management User Interface shall minimize user workload, fatigue and discomfort as determined by task and workload analysis.

9.3.3 User Interface Performance

9.3.3.1 The user interface performance characteristics refer to the speed at which the graphical user interface and/or views refresh completely following an operation or user or default defined automated screen refresh.

9.3.3.2 Individual tool GUIs within the RAMS solution, including the Central Management User Interface and the RAMS Situational Awareness (SA) view shall meet the requirement for response times to user initiated actions as specified by MIL-STD-1472F paragraph 5.14.9, including responding to user input within one tenth (0.1) of a second.

9.3.3.3 The RAMS solution SA view shall have a user configurable update rate as specified by MIL-STD-1472F paragraph 5.14.3.4.2, with a default update rate between 2 and 5 seconds.

9.3.3.4 The RAMS solution SA view shall support manual (i.e., user initiated) refresh.

9.3.3.5 Individual tool GUIs within the RAMS solution shall fully open within ten (10) seconds following instantiation. For longer delays, a progress indicator must be provided.

9.4 Monitoring

The following requirements pertain to the monitoring of attributes, performance metrics and alerts that are useful in the management of managed applications and related troubleshooting of problems in managed application availability. Unless specified, any reference to “server” in this section may indicate a physical server or a virtual machine (VM) hosted server.

9.4.1 The RAMS solution shall have the capability to receive automated alerts on all monitored devices, operating systems, VM’s and applications.

9.4.2 Alerts and Polling of devices within the AFNet as managed by RAMS

9.4.2.1 The RAMS solution shall be capable of setting a unique, defined polling interval on each device, storage, disk, server and software package (application or application dependency) monitored by the RAMS solution.

9.4.2.2 The RAMS solution shall be capable of setting static alert limits for managed hardware and software devices including server memory, disk, configurations, CPU, storage, and applications.

9.4.2.3 The RAMS solution shall be capable of setting rate of change alert limits for managed hardware and software devices including server memory, disk, configurations, CPU, storage, and applications.

9.4.2.4 The RAMS solution shall be able to receive automated alerts on defined static thresholds within the user specified polling interval for server, disk, server CPU, disk, configuration and storage.

9.4.2.5 The RAMS solution shall be able to receive automated alerts on defined rate of change thresholds within the user specified polling interval for server, disk, server CPU, and storage.

9.4.2.6 The RAMS solution shall receive 99% of alarms and alerts by the fifth poll for all servers on which a managed application or application dependency is hosted.

9.4.2.7 The RAMS solution shall receive 99% of alarms and alerts by the fifth poll for all storage systems and appliances on a managed application or application dependency utilizes.

9.4.2.8 The RAMS solution shall be capable of prioritizing all alerts.

9.4.4 Storage (disk and other media) monitoring within the AF as managed by RAMS

9.4.4.1 The RAMS solution shall be capable of centralized monitoring and collection of attributes, performance metrics, storage utilization and alerts for each storage platform that is utilized by any application or application dependency within the AF managed by the RAMS.

9.4.4.2 The RAMS solution shall perform centralized monitoring of all storage utilized by the RAMS.

9.4.4.3 The RAMS solution shall perform centralized monitoring of all storage levels that the managed applications utilize within the AF managed by the RAMS.

9.4.5 Backup monitoring within the AF as managed by RAMS

9.4.5.1 The RAMS solution shall be capable of centralized monitoring and collecting attributes, performance metrics, storage utilization and alerts for each storage platform that is utilized by any application or application dependency.

9.4.6 Server monitoring within the AF as managed by RAMS

9.4.6.1 The RAMS solution shall be capable of remotely monitoring the server.

9.4.6.2 The RAMS solution shall be capable of monitoring and reporting on the number of jobs running on a server on which a managed application resides.

9.4.6.3 The RAMS solution shall be capable of monitoring and reporting metrics for scheduled and unscheduled jobs running on a server on which a managed application resides.

9.4.6.4 The RAMS solution shall be capable of monitoring and reporting metrics for scheduled and unscheduled jobs running on a server on which any managed application dependencies reside.

9.4.6.5 The RAMS solution shall be able to monitor the availability of any server on which managed applications and managed application dependencies reside.

9.4.6.6 The RAMS solution shall be capable of monitoring and collecting attributes, performance metrics and alerts for each server on which any managed application is hosted.

9.4.6.7 The RAMS solution shall be capable of monitoring and collecting attributes, performance metrics and alerts for each server on which any application dependency is hosted.

9.4.6.8 The RAMS solution shall monitor and capture server CPU utilization statistics for each server on which any application dependency is hosted.

9.4.6.9 The RAMS solution shall monitor and capture server I/O Loads for each server on which any application dependency is hosted.

9.4.6.10 The RAMS solution shall monitor and capture server memory utilization statistics for each server on which any application dependency is hosted.

9.4.6.11 The RAMS solution shall monitor and capture server disk utilization statistics for each server on which any application dependency is hosted.

9.4.6.12 The RAMS solution shall monitor and capture server utilization statistics for each server on which any application dependency is hosted.

9.4.7 Virtualized Server monitoring within the AF as managed by RAMS

9.4.7.1 For each managed application or application dependency that is hosted on a virtualized server, the RAMS solution shall monitor and capture: CPU queue length.

9.4.7.2 For each managed application or application dependency that is hosted on a virtualized server, the RAMS solution shall monitor and capture: memory utilization of VM vs. allocation.

9.4.7.3 For each managed application or application dependency that is hosted on a virtualized server, the RAMS solution shall monitor and capture: Service Console Root file system size.

9.4.7.4 For each managed application or application dependency that is hosted on a virtualized server, the RAMS solution shall monitor and capture: VMkernel health.

9.4.7.5 For each managed application or application dependency that is hosted on a virtualized server, the RAMS solution shall monitor and capture: Virtual Machine File System (VMFS) health.

9.4.7.6 For each managed application or application dependency that is hosted on a virtualized server, the RAMS solution shall monitor and capture: VM alerts.

9.4.7.7 If a managed application or application dependency is hosted on a hypervisor (virtual machine monitor), the RAMS solution shall monitor and correlate performance and server characteristics of all VM’s hosted on that hypervisor and server.

9.4.7.8 If a managed application or application dependency is hosted on a VM, the RAMS solution shall monitor and correlate the performance characteristics and server attributes of the physical server on which hypervisor is hosted.

9.4.8 Managed application monitoring within the AF as managed by RAMS

9.4.8.1 The RAMS solution shall be capable of monitoring and collecting attributes, performance metrics and alerts for each instance of a managed application.

9.4.8.2 The RAMS solution shall be capable of monitoring and collecting attributes, performance metrics and alerts for each instance of an application dependency.

9.4.9 Configuration Monitoring within the AF as managed by RAMS

9.4.9.1 The RAMS solution shall be capable of monitoring and collecting configuration attributes of all devices and applications within the AF as managed by RAMS.

9.5 Application Management

Application Management is a process focused customer centric philosophy of managing information systems. The RAMS solution will provide the following application management capabilities:

9.5.1 9.5.1 The RAMS solution Central Management User Interface shall appear as a homogenous system as opposed to a collection of COTS tools.

9.5.2 The RAMS solution shall integrate the tools required to remotely manage and administer each managed application and managed application dependencies.

9.5.3 Managed Application Enterprise Management Interface

9.5.3.1 Each managed application shall have an enterprise tool that allows management and administration of all managed application instances remotely. .

9.5.3.2 There management interface shall include remote management, administration, log access, hardware security auditing, access control, and failover.

9.5.4 The RAMS solution shall provide the capability to enable remote access of servers hosting managed applications and managed application dependencies for maintenance that does not require physical contact with the system.

9.5.5 The RAMS solution shall provide the capability to enable remote access of servers hosting managed applications and managed application dependencies for crash recovery that does not require physical contact with the system.

9.5.6 The RAMS solution architecture shall be extensible in order to support one or more additional managed applications in the future.

9.5.7 The RAMS solution Central Management User Interface shall provide the capability to comply with MIL-STD-1472F paragraph 4.12 on automation: system and task design shall ensure that the human operator is appropriately informed and has situational awareness regarding the status of automated functions, enable the operator to specify parameters to modify the behavior of automated functions, and allow the operator to override automated functions.

9.5.8 The RAMS solution shall provide Course of Action (COA) options for events (problems) that originate from the managed applications and base-level VI contextually from alerts, reports, and within the framework of the RAMS Central Management User Interface and SA View..

9.5.9 The RAMS solution shall provide the capability of opening administration tools contextually from alerts, reports, and within the framework of the RAMS Central Management User Interface and SA View.

9.5.10 The RAMS solution Central Management User Interface COA mechanism shall identify the following: the problem, the cause of the problem (i.e., as much diagnostic information as can be inferred reliably), location of the problem, what the problem is affecting (what missions are impacted and what customers are impacted) what can be done to correct the problem (i.e., as much remedial direction as can be inferred reliably, where clear inference is not possible, probably helpful inference(s) may be offered as per MIL-STD-1472F paragraph 5.14.8.7), and potential negative consequences of the COA.

9.5.11 The RAMS solution Central Management User Interface shall provide the RAMS operators the capability to reconfigure affected assets and devices to remediate problems with the network, security or systems and to create tickets to request (remote, local, or touch) remediation when access to affected devices and assets is not possible.

*9.6 RAMS Situational Awareness (SA) SA enables operators to understand the current situation and how changes will impact the mission. RAMS is not monitoring network devices, only the stated applications.