RFI_14_0004_IMDS_CDB_Modernization_Assessement_PWS_27Nov13.pdf

- 1 -

Integrated Maintenance Data System (IMDS) Performance Work Statement (PWS)

Name: Mr. Jason Hale, Mr. Raheem (Ray) McCormick

Organization:

AFLCMC/BES HIAM

Address:

200 E. Moore Drive Bldg 888, Maxwell AFB-Gunter Annex, AL 36114

EXECUTIVE SUMMARY

The Integrated maintenance Data System (IMDS) Central Database (CDB) is an enterprise AF automated maintenance information system providing wartime readiness data and operational support to USAF weapons systems. The program management office (PMO) is seeking a vendor to commission a study assessment and analysis that will allow unravel all of the system’s technical complexities and highlight opportunities that will enable decision makers to consider future system modernization efforts.

This Document is Unclassified

WARNING: PROCUREMENT SENSITIVE INFORMATION. This Document May Not Be Disclosed To Anyone Without The Prior Approval of The Contracting Officer.

1. BACKGROUND

The Integrated Maintenance Data System (IMDS) Central Database (CDB) is the Air Force’s base-level automated maintenance information management system. IMDS CDB provides peacetime and wartime readiness and operational support of aircraft, missiles, Unmanned Aerospace Systems (UAS), trainers, vehicles, simulators, communications-electronics, and support equipment for maintenance activities. The system is used primarily to assist managers in making decisions by presenting data that provides effective scheduling of equipment usage, work, and the labor force. The system collects data necessary to support local manager's requirements, mechanize the record keeping function, and produce reports required by off-base agencies or by local management. The system supports 239,000 users across 82 AFSCs spanning the Active Duty force, Air National Guard/AF Reserve units, and Royal Netherlands Air Force (RNLAF) locations.

IMDS CDB is designed to operate on the Unisys Dorado 780 mainframe. PCs with either terminal emulation software and/or standard web browsers are used by users to communicate directly to the system. The system has 16 interfaces and 17 subsystems (see attached ISP for details). The IMDS CDB system leverages a dual database structure consisting of a hierarchical and Relational Database Management System (RDBMS) database. The system’s code base consists of over 3.11M lines of code, 45,000 function points, and 4,000 configuration managed items. The bulk of IMDS is written in COBOL 85, but includes a number of other programming languages including JAVA, JavaScript, Extensible Mark-up Language (XML), and Hyper Text Mark-up Language (HTML), Cascading Style Sheets (CSS), and Extensible Stylesheet Language Transformation

(XSLT).

IMDS CDB grew from its predecessor, the Core Automated Maintenance System (CAMS), and reached full operational capability (FOC) in 2005. In 2007, the decision was made to keep IMDS CDB in barebones sustainment in anticipation and expectation of the Expeditionary Combat Support System (ECSS) to subsume capability within IMDS. Since then, the PMO remained resourced to fix critical Warfighter deficiencies and delay major updates and modifications to the system. In the interim, the sustainment footprint continued to grow as new users were added to the system.

In recent years, the cost to maintain and sustain IMDS CDB has been steadily increasing. These costs can be attributed to the following factors:

Costs associated with maintaining and operating the systems infrastructures and the manpower needed to maintain the legacy code

An accumulating technical debt due to the difficulty and cost of sourcing experienced COBOL programmers, poor legacy documentation, inadequate resources to leverage preventative and preemptive software engineering best practices (i.e. refactoring), and an aging infrastructure and code base less adaptable to new requirements and technologies

An unsustainable cost and pricing model for the existing infrastructure based on a cost per use coupled with a steadily growing user base

The need to implement new regulatory and statutory requirements in the system like Federal Information System Controls Audit Manual (FISCAM)/ Financial Improvement and Audit Readiness (FIAR), Internet Protocol Version 6 (IPV6), and Item Unique Identification (IUID), and Public Key Infrastructure (PKI).

The existing sustainment trajectory is incompatible with recent fiscal realities and functional user needs within the government, and given this environment, modernizing IMDS CDB has become an economic imperative.

2. PURPOSE

Existing research has shown that all legacy modernizations for large information technology systems are inherently risky. The larger the scale, scope, and time it takes to complete the project, the higher the risk to cost, schedule, and capability. With these factors in mind, our approach to modernizing IMDS CDB consisted on the following strategic goals:

1. Complete a comprehensive assessment of the system and analyze its various domains (business, technical, functional, financial) to extract the assets and semantic knowledge from years of barebones sustainment

2. Use the gained knowledge to assess the technical trade-space between existing and competing mature technologies that will be employed in a larger modernization effort

3. Uncover cost drivers, cost reduction, and cost avoidance opportunities, by understanding the system at the application, code, functional, architectural, data, and infrastructure levels

4. Position the program office to meet the AT&L Better Buying Power Initiatives by decomposing the existing system, obtaining open architecture artifacts, and reusing those artifacts in future solicitations for each phase of the modernization effort; this will in turn achieve affordable programs, promoting effective competition, and incentivize productivity and innovation in industry and government

5. Make the modernization effort as invisible to the system’s users to the extent practicable and ensure that IMDS CDB users maintain existing levels of security, performance, and reliability while the system moves through transition states

6. Minimize and reduce overall modernization risk by leveraging a reduced risk modernization roadmap that will be agile and adaptable to changing environmental cost and schedule priorities

With these goals in mind, the project objectives for the IMDS CDB Modernization Assessment and Study consist of the following:

1. Obtain Open and Reusable Artifacts & Deliverables to meet AT&L Better Buying Power objectives of achieving affordable programs while promoting effective competition in industry

2. Completed project with all associated deliverables and artifacts in under 4 months to position PMO for

FY15 modernization

3. Obtain a business case with associated financials that illustrates the case to modernize (or not to modernize) based on existing and future sustainment costs

4. Obtain Recommended COAs that will provide a starting point for the government to chart and finalize a modernization strategy

To meet these goals and objectives, the IMDS CDB PMO will leverage industry best practices in legacy modernization by using tenets of an Architecture Driven Modernization approach. This begins with a comprehensive system assessment with the intent of unraveling the deep layers of accumulated legacy code, data dependencies, deep system behaviors, semantic meaning, and other complexities buried in the system from years of sustainment and extract that knowledge and information into supporting reports and models.

The final deliverables will consist of financial metrics, deep system modeling based, and several vendor COAs with a recommendation and explanation on why those conclusions were reached in the technical trade-space.

3. SCOPE

The Air Force Lifecycle Management Center Program Element Office Business Enterprise Systems, Logistics

Legacy Division Maintenance Branch located in Maxwell AFB-Gunter Annex, AL is the Program Management

Office responsible for the assessment of IMDS CDB. The scope of this contract includes obtaining specialized expertise in legacy information technology modernization. This expertise will be used to conduct an as-is analysis and assessment of the existing system and its subsystems, a business assessment with associated costs, models, views, and abstractions, and a vendor recommended COA with a roadmap by project. The contractor shall be responsible for a number of deliverables including project reports, models, and system artifacts. This requirement is strictly for assessment of the IMDS CDB. No modernization effort of the existing system or subsystem components shall take place.

4. REQUIREMENT(S)/DESCRIPTION OF SERVICE(S)

The following is a list of expected activities that will occur throughout the contract period of performance:

Facilitate emergent discovery through expert analysis that reveals technological opportunities that could be exploited in future projects

Expose and untangle inherent applications and data architecture abstractions and complexities via system modeling

Build a basis of understanding of existing application and data architectures to will establish intelligent and deliberate system modernization planning

Provide recommendations that incrementally deploy business requirements by aligning to-be technical architectures with business capabilities within existing cost constraints

Identify drivers to lifecycle costs, total cost of ownership, and ROI from the existing system and subsystems

Identify and provide recommendations on the elimination of unwanted, non-standard, and obsolete technologies in a manner aligned with business and technical requirements

Provide recommend COAs that chart a path of low risk incremental projects that yield immediate incremental degrees of value with each release

Provide high fidelity invertible models and representations of code, data, infrastructure, code behaviors, and other system assets that are machine readable into various modernization parsers and integrated development environment (IDE) tools and frameworks

The requirements listed in section 3 of this document use descriptions and tenets consistent with the

“Horseshoe Model” within software architectural driven modernizations. The horseshoe model specifies three levels of abstraction consisting of a code level representation, functional level representation, and architectural representation. As such, the PWS and respective WBS follows a similar format that describes the work to be performed within each of those respective levels of abstraction. The objective is to assess the system at each level of abstraction with all of the complimentary artifacts such that the government maintains the flexibility to make choices on the modernization path and target which modernizations will occur at which abstracted level. The post assessment deliverables and artifacts in the aggregate enable the system to be reconstructed and described in models.

Figure: Horseshoe Model

4.1 DESCRIPTION OF SERVICES

4.1.1 Project Management (WBS 1.1)

The contractor shall identify a Project Manager who shall be the primary representative responsible for all work awarded under the resultant task order, participating in Program Management

Reviews and ensure all standards referenced herein are adhered to.

4.1.1.1 Project Plan

The project manager shall create a project plan. The project plan shall include but is not limited to the overall project scope, project schedule, objectives, stakeholders, roles and responsibilities, deliverables, Risk, and success criteria. The project plan will be delivered to the Government no later than 15 business days from task order award (CDRL AXXX).

CDRL A00X – Project Plan, Integrated Master Schedule, Monthly Status Report, Monthly Funds

Expenditure Report, Risks

4.1.2 Legacy System Analysis (WBS 1.2)

4.1.2.1 System and Subsystem Assessment (WBS 1.2.1)

The contractor shall perform a thorough and comprehensive assessment and analysis of the existing system based on the principals and tenets of architecture driven modernization, to gain an understanding of the underlying system, its respective subsystems, its structure, application semantics, respective code syntax, infrastructure components, runtime, and data dependencies.

4.1.2.1.1 Analyze, Capture, Inventory Existing Assets

The contractor shall inventory existing system assets. This may include, but is not limited to business processes, functional subsystems, application code (classes, procs, etc), databases, middleware, network architecture, operating system, and data. The contractor shall use automated tools to ensure that all assets have been captured in their entirety. The contractor shall inventory and summarize these assets in a summary report.

CDRL A00X: IMDS CDB Asset Summary

4.1.2.1.2 Assess, Reverse Engineer, Model, and Reconstruct

The contractor shall leverage assessed system assets and use them to model and reconstruct the existing system such that there is visibility into increasing levels of system abstractions. These derived models will follow tenets of architecture driven modernization and provide views at the code level, the functional level, and the architecture level. The models shall provide a multifaceted view and understanding of the system, subsystems, respective architectures, and their respective semantics. This may include, but is not limited to detailed model abstractions and their corresponding semantics and definitions of the raw source code text, lexical tokens, syntax trees, control and data flow graphs, entity relationship diagrams, architectural descriptions, and conceptual models at the code.

CDRL A00X: Comprehensive Technical Assessment Report *note: PWS elements in section 3.1.2.1.2.1 through 3.1.2.2.5 may be included in CDRL A00X

Comprehensive Business Assessment Report

4.1.2.1.2.1 Low Level Detail - Code-structure Representation

The contractor shall reconstruct and model existing legacy code into code-structure representations. This may include but is not limited to manual code readings, artifact extraction including the extraction of elements and relationships among those elements, static analysis using automated code parser tools, dynamic analysis where code can be observed during runtime/execution, and slicing where logic can be analyzed affecting a set of variables.

CDRL A00X: Detailed Code Model Abstractions

4.1.2.1.2.2 Mid-Level Detail - Functional Representation

The contractor shall model the system to obtain a functional representation of the system and the relationships between functional components (i.e.

function and subsystem calls, interfaces, data, files, and their corresponding relationships). This may include, but is not limited to semantic and behavioral pattern matching (i.e. patterns that enable the discovery dynamic behaviors), re-documentation of missing or incomplete legacy documentation, plan recognition where similar code fragments in other subsystems are identified

(to be consolidated at a later point), aggregation hierarchies from legacy code groupings, or code refactoring.

CDRL A00X: Functional Model Abstractions

4.1.2.1.2.3 High-Level Architectural Representation

The contractor shall assess existing government DoDAF architectural models and existing system use cases to create new high level architectural abstractions of the system. The architectural representations shall be traceable lower level detailed functional level and code level models and artifacts within the systems. This may include, but is not limited to structural pattern matching where design patterns recognized from existing code structures revealing module dependencies, concept assignment where understanding is gained by relating programs to operational contexts, and architecture and structure identification where all bottom up assets (i.e. UML views, use cases, modules, sequence diagrams, component-and-connector views, deployment views, hybrids, etc) are aggregated that enable the generation of various architectural views beyond existing DoDAF structures.

CDRL A00X: Functional Model Abstractions

4.1.2.2 Strategic and Business Assessment (WBS 1.2.2)

The contractor shall apply the gained semantic understandings of the existing as is system and its respective subsystems and present the findings with visual illustrations in a comprehensive assessment report. The report shall explain the overall strategic fit of the system within the portfolio against its mission threads, the functional and technical adequacy of the system, the financial costs to maintain and operating the system, and a overall risk assessment. This report will enable the government to build a business case to modernize and which areas of opportunities exist, which areas are the low hanging fruit, and which areas will be the most complex.

CDRL A00X: Comprehensive Business Assessment Report *note: PWS elements in section 3.2.2.2.1 through 3.1.2.2.5 may be included in CDRL A00X Comprehensive

Business Assessment Report

4.1.2.2.1 Strategic Alignment and Fit

The contractor shall present, with visual representations, the degree of strategic fit and alignment IMDS CDB has to its existing mission thread within the portfolio. This may include but is not limited to visually explaining subsystem redundancy, PMO resource supportability, risks, alignment to organizational objectives, reviewing the business strategy via stakeholder interviews, cost avoidance opportunities, cost reduction opportunities, subsystem decommissioning opportunities, and how it’s positioned to the LogIT way ahead.

CDRL A00X: Visual Strategic Alignment Assessment

4.1.2.2.2 Functional Adequacy/Quality

The contractor shall assess and present visually how well the system meets functional user’s needs. This shall include, but is not limited to, the gap in requirements versus what’s currently implemented (completeness), how well the system is positioned to meet outstanding requirements, the system flexibility to change, relative cost to change, ease of use, performance, etc. The assessment shall include a scoring model that use a color risk rating of red (high), orange

(mod-high), yellow (moderate), lime (mod-low), and forest green (low). The analysis shall also provide time horizons (i.e. next 12 months, next 24 months, etc) and how that changes the assessment.

CDRL A00X: Visual Functional Alignment Assessment

4.1.2.2.3 Technical Adequacy/Quality

The contractor shall assess and present in a visal chart the degree to which the system is suited to implement future requirements.. This shall include, but is not limited to system scalability (additional users), system reliability, maintainability, adaptability, supportability, interoperability, cost, and risks to the existing technology stack. The assessment shall include a scoring model that use a color risk rating of red (high), orange (mod-high), yellow (moderate), lime (mod-low), and green (low) and be scored by subsystem.

CDRL A00X: Visual Technical Sufficiency Assessment

4.1.2.2.4 Financial, Business Case

The contractor shall leverage the extracted system knowledge and create financial metrics that provide insight into the cost of sustaining the as is system, cost reduction opportunities, cost avoidance opportunities, projected costs for the next 5 years, and the projected benefits gained based on modernization paths. These metrics shall also include, but is not limited to, return on investment (ROI), payback period, cost/benefit ratio, and net present value (all financial measures shall relate to system costs, not profits).

CDRL A00X: Financial Business Assessment

4.1.2.2.5 Overarching As-Is System Risk Assessment

The contractor shall provide an overall system risk assessment of the existing as is system based on all knowledge extracted and information gained. The risk assessment shall include a text description in addition to a visual risk representation using a scoring model.

CDRL A00X: As-Is System Risk Assessment

4.1.3 Vendor Future State Recommendations (WBS 1.3)

The contractor shall leverage all extracted knowledge, business metrics, and models and provide their recommended approach to modernization in a comprehensive report. The contract shall include, but not be limited to, at minimum 3 risk rated courses of action (COAs) with a recommendation, target technology opportunities, suggested modernization strategies and the relative cost/risk/timeframe, system change opportunities, Gant chart and roadmap by project, initial investment costs, respective pay-back period and ROI, and projected risk and cost delta post modernization.

CDRL A00X: Comprehensive Vendor “To-be” Report *note: PWS elements in section 3.1.3.1 through 3.1.3.6 may be included in CDRL A00X Comprehensive Vendor “To-

Be” Report

4.1.3.1 Recommended Target Architectures and Technologies

The contractor shall leverage models created and knowledge extracted and provide a recommended to-be architecture. The contractor shall factor in costs, maintainability, supportability, sustainment footprint, security, etc when evaluating target architectures, COTS, middleware, languages, and technologies.

CDRL A00X: Recommended Target Architectures and Technologies

4.1.3.2 Summary of Recommended Changes

The contractor shall explain what recommended changes should be made to the system, data, code, business rules, and interfaces and why they should be changed with any necessary pros, cons, and risks.

CDRL A00X: Recommended Change Options and Opportunities

4.1.3.3 Risk Rated Courses Of Action (COAs) and Recommended Selection

The contractor shall create no fewer than three risk assessed COAs with a selection of a recommended COA to execute with an explanation and basis of COA selection.

CDRL A00X: Risk Rated COA Analysis

4.1.3.4 Future State Roadmap

The contractor shall use the recommended COA and create a project plan. The project plan shall include, at a minimum, a breakout of each incremental modernization release, associated costs, legacy system decommissioning costs, timeframe for realized benefits, risk/reward or pain/gain chart for each modernization release, each project’s attributes

(quick implementation versus major initiative against high priority versus low priority), the government value gained from each release, the recommended order of release, and a high level Gant chart schedule. The information will be used to create the business case for the initial and long term investment.

CDRL A00X: Future State Project and COA analysis

4.1.3.5 Project Plan Financials

The contractor shall produce a financial summary that outlines the IT benefits gained for each modernization release, a breakout of those benefits and savings in labor, hardware, and software, and the cost per release, investment costs, and estimated savings. The financial breakout shall include the financial assumptions and overarching investment timeframe calculated against the benefits.

CDRL A00X: Project Plan Financials Report

4.1.3.6 To Be & Future State Risk Assessment

The contractor shall provide an estimated risk assessment of the “to-be” system based on the vendor recommended COA and extracted and information gained. The risk assessment shall include a text description, in addition to a visual risk representation using a scoring model.

CDRL A00X: To Be & Future State Risk Assessment Report

4.1.4 Object Management Group Architectural Abstractions & Artifacts (WBS 1.4)

The contractor shall deliver the “as-is” system architectural models according to OMG specification format. Deliverables shall be machine readable and be consistent with all of the information in each specification package.

4.1.4.1 Knowledge Discovery Metamodel (KDM) Specification (WBS 1.4.1)

The contractor shall create and deliver a machine readable OMG KDM v1.1 or later specification based on the extracted knowledge including all of its layers and sub-packages.

CDRL A00X: KDM Specification and Supported Packages

4.1.4.2 Abstract Syntax Tree Metamodel (ASTM) Specification (WBS 1.4.2)

The contractor shall create and deliver a machine-readable OMG ASTM specification to include all of its views and sub-components. The deliverable shall be delivered both in

Reference CDRL A000X for details.

CDRL A00X: ASTM Specification and Supported Packages

4.1.4.3 OPTIONAL TASK--Semantics of Business Vocabulary and Rules (SBVR) (WBS 1.4.3)

The contractor shall create and deliver a machine-readable SVBR specification to include all of its views and sub-components. Reference CDRL A000X for details

CDRL A00X: SBVR Specification and Supported Packages

4.2 Dependencies

The IMDS CDB system is distributed across multiple environments. The core application is hosted on a Unisys Dorado 780 mainframe server and is located at Oklahoma City, OK. There is also a web services presence on the GCSS-AF and Capabilities Integration Environment (CIE). The contractor’s team may need to gather additional information about the respective test and/or production environments. As DISA OKC maintains the infrastructure the PMO will coordinate and assist the contractor in obtaining the additional information needed.

4.3 System Details

Code and Data Complexity Summary

Factor Data

Stability Scheduled Downtime -- less than 5 minutes per year Unscheduled Downtime --

Number of concurrent users 239,000+

Application age Since 2005

Function Points Inputs

External Inputs

External Outputs

Logical Internal Files

External Interfaces 16

External Inquiries

Initial response time 3-5 seconds

Operating system Dorado 780 Mainframe

Platform .Unisys

Programming Languages Java, CSS, HTML, JavaScript, XML, XSLT, COBOL

Programs

Database Two Tier: Hierarchical DMS and RDMS

COTS NA

Avg. transactions per day 2.8 Million transactions per day

Interfaces CEMS, SBSS,TBMCS-UL, EMOC, AFDS, C-130 IMIS, CV-22 (Osprey), DRRS, F-15 IMIS, F-22

IMIS, JPATS, LCOM, POMX, RAMPOD, REMIS

(see appendix)

Upgrades

Average help desk call volume 15000+ per year (Tier I, II, III)

Figure: IMDS CDB SV-1/2 (New Diagram without PPS)

4. CONTRACTUAL REQUIREMENTS

4.1 Contractors Use of NETCENTS-2 Products Contract

The contractor shall obtain all products and associated peripheral equipment required from the NETCENTS-2 Products contract.

4.2 Place of Performance

The contractor may choose to work on Maxwell-Gunter Annex or offsite at a remote location. The contractor shall attend all scheduled telephone conferences and meetings to meet project objectives, scope, and deliverables.

4.3 Normal Hours of Operation

The standard workweek for Government Offices and Employees is 40 hours, with an average 8 hour workday. The Government’s established core hours are 9:00am to 4:00pm each day. Government Offices and Facilities where work will be performed are open between 0630 and 1730, Monday through Friday, except for Federal holidays (New Year’s Day, Martin Luther King Day, President’s Day, Memorial Day, July 4th, Labor Day, Columbus Day, Veteran’s Day, Thanksgiving, and Christmas). The contractor shall align work hours of its staff to ensure the Government receives full support during Government’s core hours. This

Global Information Grid (GIG)

Tinker

DISA Oklahoma

Gunter

Unisys Server (Mainframe)

DISA Montgomery

GCSS-AF IF

WingBase

User Assistance/Collaboration

Services

Wright-Patterson

P o rt

/2

I

M D

S -C

D B

D a ta

Security Services

«Port 20/21» REMIS Data

«Port 251» Supply Part

Maintenance Data

IMDS-CDB Data

Messaging

Services

«Port 443»

IMDS-CDB Data

«Port 20/21»

Aircraft Status Data

Storage Services

P o rt

F

D a ta a n d S u p p ly

D a ta

IMDS-CDB Data

IMDS-CDB Data

«Port 443» Base CAMEO Data

IMDS-CDB Data

«Port 443» Application Data

IMDS-CDB Data

«Port 443» User Data / Application Data

POMX Data

«Port 20/21»

POMX Data

«Port 443»

RAMPOD Data

«Port 443» User Data / Application Data

Aircraft Engine Maintenance Data

«Port 20/21» Aircraft Engine

Maintenance Data

Aircraft Engine Maintenance Data

P o rt

/2

T ra in in g a n d

S q u a d ro n L e v e l

A ir c ra ft D a ta

«Port 20/21»

JDD Data

«FTP»

Scheduled Maintenance Data

«Port 20/21» F-22 Data

P o rt 2

/2

R E

M

IS

E q u ip m e n t In v e n to ry D a ta

«Port 20/21» IMDS-CDB

Data

«Port 20/21»

IMDS-CDB

Data

«Port 443» IMDS-CDB Data

IMDS-CDB Data

«HTTPS» IMDS-CDB Data

IMDS-CDB Data

«Port 251» F-22 Data

IMDS-CDB Data

W e b sp he re Ap p l i ca t i o n

Se r ve r

TAM

REMIS /

Interfacing

Systems

Enterprise

Service Bus

RAMPOD

MSAT

AFDS

ADRRS

DRRS

LCOM

CV22 -

CAMEO

IMDS

CDB

Web

Service

SBSS

TBMCS

EMOC

POMX

«Port 443» IMDS-CDB Data

IMDS-CDB Data

«Port 20/21» IMDS-CDB Data

IMDS CDB

Database

Server

ESB

Adapters

«Port 20/21»

EMOC Status

Update Data «Port 443» IMDS-CDB Data

IMDS-CDB Data

F22-IMIS

F15-IMIS

«Port 443» User Data / Application Data

EMOC Status Update Data

IMDS CDB

Web

TS

IMDS

CDB

Client

CEMS

ICI

«Port

20/21»

Maintenanc e Data requirement does not provide for overtime; however, the Contracting Officer may authorize approval for extended hours based on special circumstances (i.e., system problems, testing and implementation, etc). During implementation of an application, AFLCMC PEO BES/HIAM may have unanticipated operational base level system problems or other emergency that may require contractor support. In the event of an unscheduled emergency and system problems occur outside the normal work day, the contractor shall provide support upon the Contracting Officer approval of extended hours. The Contracting Officer will specify the parameters for which contractor support during extended hours will be provided (i.e., which program requires extended hours support, government point of contact, hours for which support is required, etc.).

4.4 Government Furnished Property

The Government will furnish or make available working space, network access, and equipment to include:

Windows PC with Microsoft Office Suite (Word, Excel, PowerPoint, etc.)

Telephone (local/long distance calls authorized as dictated by Task Order performance requirements)

Facsimile

Copier

Printer

Copies of required Government furnished materials cited in the solicitation, PWS, DD Form 254, and/or in the resultant contract will be provided to the contractor in hard copy or soft copy. All materials will remain the property of the Government and will be returned to the responsible Government QAP upon request or at the end of the Task Order period of performance.

Equipment purchased by the contractor with the approval of the Government and directly charged to the resu l tant Task Order shall be considered government owned-contractor operated equipment. The contractor shall conduct a joint inventory and turn in this equipment to the COR upon request or completion of the contract.

4.5 Billable Hours

In order for man-hours to be billed, deliverable services must have been performed in direct support of a requirement in this PWS. In the course of business, situations may arise where Government facilities may not be available for performance of the PWS requirements (i.e., base closure due to weather, Force Protection conditions, etc.). When the base is officially closed no contractor services s h a l l b e p r o v i d e d a t a n r e m o t e l o c a t i o n d e s i g n a t e d b y t h e c o n t r a c t o r s m a n a g e m e n t and no a d d i t i o n a l charges will be incurred and billed to to the resultant contract. There may also be occasions when support contractors are invited to participate in morale and recreational activities (i.e., holiday parties, golf outings, sports days and other various social events). Contractor employees shall not be directed to attend such events by the Government.

Since a contract employee is not a government employee, the contract employee cannot be granted the same duty time activities as Government employees. Participation in such events is not billable to the r e s u l t a n t c o n t r a c t and contractor employee participation should be IAW the employees, company’s policies and compensation system.

4.6 Non-Personal Services

The Government will neither supervise contractor employees nor control the method by which the contractor performs the required tasks. It shall be the responsibility of the contractor to manage its employees and to guard against any actions that are of the nature of personal services, or give the perception of personal services. If the contractor feels that any actions constitute, or are perceived to constitute personal services, it shall be the contractor’s responsibility to notify the C o n t r a c t i n g Officers ( CO) or Contracting Officer Representative (COR) immediately. These services shall not be used to perform work of a policy/decision making or management nature, i.e., inherently Governmental functions. All decisions relative to programs supported by the contractor shall be the sole responsibility of the Government. These operating procedures may be superseded by Theater Commander’s direction during deployments.

4.7 Contractor Identification

All contractor/subcontractor personnel shall be required to wear AF-approved or provided picture identification badges so as to distinguish themselves from Government employees. When conversing with Government personnel during business meetings, over the telephone or via electronic mail, contractor/subcontractor personnel shall identify themselves as such to avoid situations arising where sensitive topics might be better discussed solely between Government employees.

Contractors/subcontractors shall identify themselves on any attendance sheet or any coordination documents they may review. Electronic mail signature blocks shall identify their company affiliation. Where practicable, contractor/subcontractors occupying collocated space with their Government program customer should identify their work space area with their name and company affiliation.

4.8 Performance Reporting

The contractor’s performance will be monitored by the Government and reported in Contractor Performance Assessment Reporting (CPARs). Performance standards shall include the contractor’s ability to provide or satisfy the following:

Provide quality products, incidentals, and customer support

Meet customer’s agreed-upon timelines for scheduled delivery of items, warranty, and/or incidental services: Emergency/critical, Maintenance/Warranty – 24 x 7 x 365, and remote OCONUS, OCONUS vs. CONUS response times

Timely and accurate reports

Responsive proposals

Configuration assistance as identified in each delivery order

4.9 Program Management / Project Management

The contractor shall identify a Program Manager or a Project Manager who shall be the primary representative responsible for all work awarded under this task order, participating in

Program/Project Management Reviews and ensuring all standards referenced herein are adhered to.

4.9.1 Services Delivery Summary

Reference Section 6, Services Delivery Summary, of this Task Order PWS for specific performance objectives.

The contractor’s performance at the contract level will be assessed quarterly by a process that measures success towards achieving defined performance objectives. The Services Delivery Summary will be in accordance with AFI 63-124, Performance Based Services Acquisition and FAR Subpart 37.6, Performance-Based Acquisition.

4.9.2 Contract Management

The contractor shall establish and provide a qualified workforce capable of performing the required tasks. The workforce may include a project/task order manager who will oversee all aspects of the task order. The contractor shall use key performance parameters to monitor work performance, measure results, ensure delivery of contracted product deliverables and solutions, support management and decision-making and facilitate communications. The contractor shall identify risks, resolve problems and verify effectiveness of corrective actions. The contractor shall institute and maintain a process that ensures problems and action items discussed with the Government are tracked through resolution and shall provide timely status reporting. Results of contractor actions taken to improve performance shall be tracked, and lessons learned incorporated into applicable processes. The contractor shall establish and maintain a documented set of disciplined, mature, and continuously improving processes for administering all contract and Task Order efforts with an emphasis on cost-efficiency, schedule, performance, responsiveness, and consistently high-quality delivery. The contractor shall provide transition plans as required.

4.9.3 Documentation and Data Management

The contractor shall establish, maintain, and administer an integrated data management system for collection, control, publishing, and delivery of all program documents. The data management system shall include but not be limited to the following types of documents: CDRLs, White Papers, Status Reports, Audit Reports, Agendas, Presentation Materials, Minutes, Contract Letters, and Task Order Proposals. The contractor shall provide the Government with electronic access to this data, including access to printable reports.

4.9.4 Records, Files, and Documents

All physical records, files, documents, and work papers, provided and/or generated by the Government and/or generated for the Government in performance of this PWS, maintained by the contractor which are to be transferred or released to the Government or successor contractor, shall become and remain Government property and shall be maintained and disposed of IAW AFMAN 33-363, Management of Records; AFI 33-364, Records Disposition – Procedures and Responsibilities; the Federal Acquisition Regulation, and/or the Defense Federal Acquisition Regulation Supplement, as applicable. Nothing in this section alters the rights of the Government or the contractor with respect to patents, data rights, copyrights, or any other intellectual property or proprietary information as set forth in any other part of this PWS or the Application Services contract of which this PWS is a part (including all clauses that are or shall be included or incorporated by reference into that contract).

4.9.5 Security

Individuals performing work under the resultant contract shall comply with applicable program security requirements as stated in the task order. NETCENTS-2 will support the following levels of security: Unclassified; Unclassified, But Sensitive; Secret (S); Secret Sensitive Compartmented Information (S/SCI); Top Secret (TS); and Top Secret Sensitive Compartmented Information (TS/SCI).

Contracts may require personnel security clearances up to and including Top Secret, and may require all employees to be United States citizens. The security clearance requirements will depend on the security level required by the proposed task order. The task orders may also require access to sensitive compartmented information (SCI) for which SCI eligibility will be required. Contractors shall be able to obtain adequate security clearances prior to performing services under the task order. The Contract Security Classification Specification (DD Form 254) will be at the basic contract and task order level and will encompass all security requirements. All contractors located on military installations shall also comply with Operations Security (OPSEC) requirements as set forth in DoD Directive 5205.02, Operations Security Program and AFI 10-701, Operations Security. In accordance with DoD 5200.2-R, Personnel Security Program (Jan 87), DoD military, civilian, consultants, and contractor personnel using unclassified automated information systems, including e-mail, shall have, at a minimum, a completed favorable National Agency Check plus Written Inquiries (NACI).

The types of Personnel Security Investigations (PSI) required for the contractor vary in scope of investigative effort depending upon requirements of the Government and/or conditions of the contract. In cases where access to systems such as e-mail is a requirement of the

Government, application/cost for the PSI shall be the responsibility of the Government. In cases where access to systems is as a condition of the resultant contract, application/cost for the appropriate PSI shall be the responsibility of the contractor. In such instances, the contractor shall diligently pursue obtaining the appropriate PSI for its employees prior to assigning them to work any active task order. Acquisition planning must consider Anti-Terrorism (AT) measures when the effort to be contracted could affect the security of operating forces (particularly in- transit forces), information systems and communications systems IAW DoD Instructions

2000.16 Anti-Terrorism Standards.

4.9.5.2 Protection of System Data

Unless otherwise stated in the contract, the contractor shall protect system design-related documents and operational data whether in written form or in electronic form via a network in accordance with all applicable policies and procedures for such data, including DoD Regulation 5400.7-R and DoD Manual 5200.01(v1-v4) to include latest changes, and applicable service/agency/ combatant command policies and procedures. The contractor shall protect system design related documents and operational data at least to the level provided by Secure Sockets Layer (SSL)/Transport Security Layer (TSL)-protected web site connections with certificate and or user ID/password-based access controls. In either case, the certificates used by the Contractor for these protections shall be DoD or IC approved Public Key Infrastructure (PKI) certificates issued by a DoD or IC approved External Certification Authority (ECA) and shall make use of at least 128-bit encryption.

4.9.5.3 System and Network Authorization Access Requests

For Contractor personnel who require access to DoD, DISA, or Air Force computing equipment or networks, the Contractor shall have the employee, prime or subcontracted, sign and submit a System Authorization Access Report (SAAR), DD Form 2875.

4.9.6 Travel

Contractor shall submit requests for (non-local) travel for review and approval by the COR prior to departure. Reimbursement of travel and travel-related expenses incurred in the performance of tasks outlined in this PWS will be in accordance with Federal Acquisition Regulation (FAR) 31, with maximum per diems in accordance with the Joint Travel Regulations (JTR). General and administrative expense(s) will be reimbursed, as appropriate. The JTR is available on the Internet at the following address:

http://perdiem.hqda.pentagon.mil. Contractor shall add no profit or fee for travel.

Contractor shall comply with the following procedures for any non-local travel. Foreign travel may be required for this task order.

4.9.6.1 Contractor shall submit the Contractor Travel Worksheet (Obtain from COR) with estimated travel costs to the COR when travel is requested by the Government.

4.9.6.2 Contracting Officer will review and approve travel all travel and reimbursable expenses in accordance with JTR.

4.9.6.3 Contractor shall bill all approved Contractor travel to the Government at cost (actual), subject to the limits in the JTR.

4.9.7 Other Direct Cost (ODC)

The contractor shall identify ODC and miscellaneous items as needed in the performance of this contract. No profit or fee will be added; however, DCAA approved burden rates are authorized.

4.10 Training

Contractor personnel are required to possess the skills necessary to support their company’s minimum requirements of the labor category under which they are performing. Training necessary to meet minimum requirements will not be paid for by the Government.

4.10.1 Mission-Unique Training

In situations where the Government organization being supported requires some unique level of support because of program/mission-unique needs, then the contractor may directly charge the contract on a cost reimbursable basis. Unique training required for successful support must be specifically authorized by the Contracting Officer. Labor expenses and travel related expenses may be allowed to be billed on a cost reimbursement basis. Tuition/Registration/Book fees (costs) may also be recoverable on a cost reimbursable basis if specifically authorized by the Contracting Officer. The agency requiring the unique support must document the contract file with a signed memorandum that such contemplated labor, travel, and costs to be reimbursed by the Government are mission essential and in direct support of unique or special requirements to support the billing of such costs against the contract.

4.11 Data Rights and Non-Commercial Computer Software

In order to implement the provisions at DFARS 252.227-7013(b) and (e) and DFARS 252.227- 7014(b) and (e) and DFARS 252.227-7017, the Contractor shall disclose to the ordering Contracting Officer and ordering office in any proposal for a task order, or after award of a task order if not previously disclosed in the proposal, any technical data or non-commercial computer software and computer software/source code documentation developed exclusively at government expense in performance of the task order. This disclosure shall be made whether or not an express requirement for the disclosure is included or not included in the PWS or solicitation for the order. The disclosure shall indicate the rights asserted in the technical data and non-commercial computer software by the Contractor and rights that would be acquired by the government if the data or non-commercial software was required to be delivered under the task order and its CDRL requirements and any cost/price associated with delivery. This disclosure requirement also applies to segregable routines of non-commercial software that may be developed exclusively at Government expense to integrate Commercial Software components or applications provided under a commercial software license or developed to enable Commercial Software to meet requirements of the Task Order. This disclosure obligation shall apply to technical data and non-commercial computer software developed exclusively at Government expense by subcontractors under any Task Order. Performance of this disclosure requirement shall be considered a material performance requirement of any task order under which such technical data or non-commercial computer software is developed exclusively at Government expense.

4.13 Enterprise Software Initiative

In situations where the purchase of new COTS software is needed to satisfy the requirements in this PWS, the contractor shall use available existing enterprise licenses. If enterprise licenses are unavailable, then products will be obtained via the DoD Enterprise Software Initiative (ESI) Blanket Purchase Agreements (BPAs). If products are unavailable from ESI, then products will be acquired through the NETCENTS-2 Products contract. The updated listing of COTS software available from DoD ESI sources can be viewed on the web at http://www.esi.mil.

4.19 Incentives

To be completed post RFI. PMO is looking into various incentive structures that can be leveraged to provide high quality products for a fair and reasonable price.

5. SERVICES DELIVERY SUMMARY

To be completed post RFI. PMO is looking into various incentive structures that can be leveraged to provide high quality products for a fair and reasonable price.

Performance Requirements

Performance Threshold

Monitoring Method

Accuracy

Specify precision (resolution) and accuracy (known standard) that is required in the systems output

QAE monthly review of system metrics

QUALITY ASSURANCE

Configuration management database updates and accuracy

Configuration management database updated with new systems or software with 2 duty days

QAE random checks

Configuration management database updates and accuracy

Configuration management database includes all systems and software and a 98% accuracy rate is maintained at all times http://www.esi.mil/

IT systems inventory updates and accuracy

IT system inventories include all systems and software and a 98% accuracy rate is maintained

Accuracy of software architecture drawings

More than 95% of all changes to architecture drawings updated within one week

Change request rate

Change requests are increasing on a month-to-month basis

Change management resolution time

The time it takes to initiate a request, address/resolve the request, and close out the request are kept to a minimum; dependent on mission criticality

6. DATA DELIVERABLES

The Government requires all deliverables that include Scientific and Technical Information (STINFO), as determined by the Government, be properly marked IAW DoD Directive 5230.24 and AFI 61-204 prior to initial coordination or final delivery. Failure to mark deliverables as instructed by the Government will result in non-compliance and non-acceptance of the deliverable. The contractor shall include the proper markings on any deliverable deemed STINFO regardless of media type, stage of completeness, or method of distribution. Therefore, even draft documents containing STINFO and STINFO sent via e-mail require correct markings. Additionally, as required by individual Task Orders, the contractor shall formally deliver as a CDRL all intellectual property, software, licensing, physical records, files, documents, working papers, and other data for which the Government shall treat as deliverable.

Sequence Number

Data Item

Description

Title

Corresponding SEP Artifact

A003 DI-CMAN-80639C Engineering Change Proposal (ECP)

A004 DI-CMAN-80640C Request for Deviation (RFD)

A005 DI-CMAN-80642C Notice of Revision (NOR)

A006 DI-CMAN-80643C Specification Change Notice (SCN)

7. APPLICABLE STANDARDS AND REFERENCES

8. PRODUCTS STANDARDS AND COMPLIANCE REQUIREMENTS

Information Assurance (IA) Technical Considerations

The contractor shall provide Commercial-Off-The-Shelf (COTS) IA and IA-enabled products IAW AFI

33-200, Information Assurance. These products must be National Security Telecommunications and Information Systems Security Policy Number 11 (NSTISSP-11) compliant, requiring them to be validated by accredited labs under the National Information Assurance Partnership (NIAP)

Common Criteria Evaluation and Validation Scheme or National Institute of Standards and

Technology (NIST) Federal Information Processing Standards (FIPS) Cryptographic Module

Validation Program (CMVP). The following are some examples of IA and IA enabled devices:

data/network encryptors, intrusion detection devices such as Firewalls, Intrusion Detection

System, Authentication Servers, Security…