A07_W91CRB-17-R-0019_Solicitation.pdf

CODE

(Hour)

PAGE(S)

until 08:00 AM local time 26 Jun 2017

X

A X B X C

D

EX

X G F 65 - 73

74 - 81 X H 82 - 85

RATING PAGE OF PAGES

7. ISSUED BY

(Date)

IMPORTANT - Award will be made on this Form, or on Standard Form 26, or by other authorized official written notice.

Previous Edition is Unusable 33-134 STANDARD FORM 33 (REV. 9-97)

Prescribed by GSA FAR (48 CFR) 53.214(c)

1 85

(If other than Item 7)

15A. NAME 16. NAME AND TITLE OF PERSON AUTHORIZED TO

AND

ADDRESS

SIGN OFFER (Type or print)

OF

OFFEROR

AMENDMENT NO. DATE

15B. TELEPHONE NO (Include area code) 17. SIGNATURE15C. CHECK IF REMITTANCE ADDRESS

IS DIFFERENT FROM ABOVE - ENTER

SUCH ADDRESS IN SCHEDULE.

18. OFFER DATE

1. THIS CONTRACT IS A RATED ORDER

UNDER DPAS (15 CFR 700)

2. CONTRACT NO.

W91CRB 8. ADDRESS OFFER TO

See Item 7

9. Sealed offers in original and 1 copies for furnishing the supplies or services in the Schedule will be received at the place specified in Item 8, or if handcarried, in the depository located in

CAUTION - LATE Submissions, Modifications, and Withdrawals: See Section L, Provision No. 52.214-7 or 52.215-1. All offers are subject to all terms and

ACC-APG

conditions contained in this solicitation.

10. FOR INFORMATION

CALL:

A. NAME (NO COLLECT CALLS)

11. TABLE OF CONTENTS

SOLICITATION/ CONTRACT FORM

SUPPLIES OR SERVICES AND PRICES/ COSTS

2 - 10

X I CONTRACT CLAUSES

DESCRIPTION/ SPECS./ WORK STATEMENT X

PACKAGING AND MARKING

11 - 41 J LIST OF ATTACHMENTS

INSPECTION AND ACCEPTANCE

DELIVERIES OR PERFORMANCE

43 - 44

X K

REPRESENTATIONS, CERTIFICATIONS AND

OTHER STATEMENTS OF OFFERORS

CONTRACT ADMINISTRATION DATA 45 - 46 X

SPECIAL CONTRACT REQUIREMENTS

OFFER (Must be fully completed by offeror) 47 X M

L INSTRS., CONDS., AND NOTICES TO OFFERORS

EVALUATION FACTORS FOR AWARD

NOTE: Item 12 does not apply if the solicitation includes the provisions at 52.214-16, Minimum Bid Acceptance Period.

is inserted by the offeror) from the date for receipt of offers specified above, to furnish any or all items upon which prices are offered at the price set opposite each item, delivered at the designated point(s), within the time specified in the schedule.

13. DISCOUNT FOR PROMPT PAYMENT

(See Section I, Clause No. 52.232-8)

14. ACKNOWLEDGMENT OF AMENDMENTS

(The offeror acknowledges receipt of amendments

AMENDMENT NO. DATE

to the SOLICITATION for offerors and related documents numbered and dated):

FACILITY

12. In compliance with the above, the undersigned agrees, if this offer is accepted within calendar days (60 calendar days unless a different period

SOLICITATION, OFFER AND AWARD

X

(X) SEC. DESCRIPTION (X) SEC. DESCRIPTION PAGE(S)

PART I - THE SCHEDULE

26. NAME OF CONTRACTING OFFICER (Type or print) 27. UNITED STATES OF AMERICA 28. AWARD DATE

EMAIL:TEL: (Signature of Contracting Officer)

CODE CODE

B. TELEPHONE (Include area code) C. E-MAIL ADDRESS

AWARD (To be completed by Government)

19. ACCEPTED AS TO ITEMS NUMBERED 20. AMOUNT 21. ACCOUNTING AND APPROPRIATION

22. AUTHORITY FOR USING OTHER THAN FULL AND OPEN COMPETITION:

10 U.S.C. 2304(c)( ) 41 U.S.C. 253(c)( ) (4 copies unless otherwise specified)

23. SUBMIT INVOICES TO ADDRESS SHOWN IN ITEM

24. ADMINISTERED BY (If other than Item 7) CODE 25. PAYMENT WILL BE MADE BY CODE

PART IV - REPRESENTATIONS AND INSTRUCTIONS

PART III - LIST OF DOCUMENTS, EXHIBITS AND OTHER ATTACHMENTS

48 - 63

PART II - CONTRACT CLAUSES

ACC - APG - W91CRB

4310 BOOTHBY HILL AVE

ABERDEEN PROVING GROUND MD 21005-3013

FAX:

TEL:

FAX:

TEL:

NOTE: In sealed bid solicitations "offer" and "offeror" mean "bid" and "bidder".

SOLICITATION

6. REQUISITION/PURCHASE NO.5. DATE ISSUED

25 May 2017

4. TYPE OF SOLICITATION

SEALED BID (IFB)

NEGOTIATED (RFP)

[ X ]

3. SOLICITATION NO.

W91CRB-17-R-0019

Section B - Supplies or Services and Prices

ITEM NO SUPPLIES/SERVICES QUANTITY UNIT UNIT PRICE AMOUNT

0001 12 Months ART Support

FFP

Per the Army Procurement Response Team PWS included herein.

FOB: Destination

NET AMT

0002 700 Job ART Support

T&M Extended Hour and FY End Support per PWS paragraphs 2.2.4 and 2.4.3 -

2.4.3.3 Not to Exceed 700 Hours.

TOT ESTIMATED PRICE

CEILING PRICE

0003 1 Job Travel

T&M Travel expenses will be reimbursed per the PWS paragraph 4.4. This CLIN shall not exceed $3,000 excluding any any indirect costs to be added.

Accounting For Contract Services

FFP

/Contractor Manpower Reporting requirement has been added to the statement of work, and contractor is required to provide data on contractor manpower (including subcontractor manpower) for performance of this contract. This CLIN is Not Seperately Priced.

Contract Deliverables

FFP

Per the PWS paragraph 5.0. This CLIN is Not Seperately Priced.

0006 1 Job Transition-In

FFP

1001 12 Months OPTION ART Support

FFP

1002 700 Job OPTION ART Support

T&M Extended Hour and FY End Support per PWS paragraphs 2.2.4 and 2.4.3 -

1003 1 Job OPTION Travel

T&M Travel expenses will be reimbursed per the PWS paragraph 4.4. This CLIN shall

OPTION Accounting For Contract Services

FFP

/Contractor Manpower Reporting requirement has been added to the statement of work, and contractor is required to provide data on contractor manpower (including subcontractor manpower) for performance of this contract. This CLIN is Not

OPTION Contract Deliverables

FFP

2001 12 Months OPTION ART Support

FFP

2002 700 Job OPTION ART Support

T&M Extended Hour and FY End Support per PWS paragraphs 2.2.4 and 2.4.3 -

2003 1 Job OPTION Travel

T&M Travel expenses will be reimbursed per the PWS paragraph 4.4. This CLIN shall

OPTION Accounting For Contract Services

FFP

/Contractor Manpower Reporting requirement has been added to the statement of work, and contractor is required to provide data on contractor manpower (including subcontractor manpower) for performance of this contract. This CLIN is Not

OPTION Contract Deliverables

FFP

3001 12 Months OPTION ART Support

FFP

3002 700 Job OPTION ART Support

T&M Extended Hour and FY End Support per PWS paragraphs 2.2.4 and 2.4.3 -

3003 1 Job OPTION Travel

T&M Travel expenses will be reimbursed per the PWS paragraph 4.4. This CLIN shall

OPTION Accounting For Contract Services

FFP

/Contractor Manpower Reporting requirement has been added to the statement of work, and contractor is required to provide data on contractor manpower (including subcontractor manpower) for performance of this contract. This CLIN is Not

OPTION Contract Deliverables

FFP

4001 12 Months OPTION ART Support

FFP

4002 700 Job OPTION ART Support

T&M Extended Hour and FY End Support per PWS paragraphs 2.2.4 and 2.4.3 -

4003 1 Job OPTION Travel

T&M Travel expenses will be reimbursed per the PWS paragraph 4.4. This CLIN shall

OPTION Accounting For Contract Services

FFP

/Contractor Manpower Reporting requirement has been added to the statement of work, and contractor is required to provide data on contractor manpower (including subcontractor manpower) for performance of this contract. This CLIN is Not

OPTION Contract Deliverables

FFP

Section C - Descriptions and Specifications

PERFORMANCE WORK STATEMENT

Army Procurement Response Team Performance Work Statement

27 Apr 2017

1.0 Scope

The Office of the Deputy Assistant Secretary of the Army for Procurement (ODASA(P)) is responsible to Army leadership for the management, measurement, oversight, and continuous improvement of the Army’s procurement mission. ODASA(P) serves as the executive agent for all contracting services and outcomes across the Army, for both the Continental and outside the Continental United States (CONUS).

A key mission of the ODASA(P) is to provide organizational oversight and end‐user support for the procurement business systems in use across the Army Contracting Enterprise. ODASA(P) ensures that contracting tools and systems are available, reliable and properly maintained to support the procurement of systems, goods and services for soldiers both in garrison and in deployed environments.

Additionally, the ODASA(P) serves as the singular advocate for business systems impacting the Army Contracting Enterprise.

The purpose of this Performance Work Statement (PWS) is to obtain tactical and strategic technical and functional support of the current contract writing system environment throughout the Army’s acquisition community. Tactical and strategic support includes: analytical, technical and functional engineering support services for the deployment, upgrade, and sustainment of the Department of Defense (DoD) Standard Procurement System’s (SPS) contract writing software known as Procurement Desktop‐Defense (PD²). The test and production SPS‐A enclaves are located in Radford, VA at the Army Acquisition, Logistics & Technology Enterprise Systems & Services (ALTESS) with a COOP site located in Huntsville, AL at Redstone Arsenal at the Network Enterprise Center‐Redstone (NEC‐R).

The contractor shall be required to perform the SPS‐Army Enclave Support task listed in the PWS at both locations. The team performing the work under this PWS is referred to as the Army Response Team

(ART).

The ART shall also support the SPS‐Army (SPS‐A) enclave and tickets that are out of scope of the SPS Joint Program Management Office’s (JPMO) Help Desk. The services sought herein shall also include but not limited to the PD² integration software components incorporated in the suite of tools known as the PD² Adapter, SPS Legacy and 3rd Party Integrations, General Funds Enterprise Business System (GFEBS), Electronic Document Access (EDA) and the Configuration Data Repository‐Administration (CDR/CDR‐A).

The Army Contracting Enterprise (ACE) workforce currently consists of approximately 8,000 Contract Specialists, Procuring Contracting Officers (PCOs), Procurement Analysts, and other ancillary personnel who support the acquisition and contracting mission function. The Army contracting environment is comprised of the following organizational elements:

a. U.S. Army Contracting Command (ACC)

‐ Mission and Installation Contracting Command (MICC) ‐ CONUS 412th Contracting Support Brigade (PR, SC, KY, WI, TX, CA)

418th Contracting Support Brigade (CO, TX, CA, KS, WA, NM, AZ, UT) 419th Contracting Support Brigade (VA, NC, KY, NY, MD, LA, GA) Field Directorate Office‐Eustis (GA, VA, GA, PA, KS, MO, AL, OK, NY, CA) ‐ Expeditionary Contracting Command (ECC) ‐ OCONUS 408th Contracting Support Brigade (Kuwait, Qatar) 409th Contracting Support Brigade (Germany, Belgium, Italy, Bosnia) 410th Contracting Support Brigade (Cuba, Colombia, Honduras, Caribbean) 411th Contracting Support Brigade (Korea) 413th Contracting Support Brigade (Hawaii, Pacific) 414th Contracting Support Brigade (Italy, Africa, Mediterranean) ECC‐Afghanistan ‐ ACC Contracting Centers ‐ CONUS ACC‐Aberdeen (MD, CO, PA, VA, NC, AZ, MA) ACC‐New Jersey (NJ) ACC‐Redstone (AL, VA, TX, PA, CO) ACC‐Rock Island (IL, IN, KY, UT, OK, TX, SC, AR, Saudi Arabia) ACC‐Warren (AL, TX, NY, CA, MI, IL, VA) ACC‐Orlando (FL)

b. U.S. Army Medical Command (MEDCOM) – CONUS and OCONUS ‐ Medical Research Acquisition Activity (MD) ‐ Army Health Contracting Activity (TX, MD, GA, HI, WA, Germany)

c. U.S. Army Corps of Engineers (USACE) ‐ CONUS and OCONUS ‐ Atlanta (AL, GA, FL, IL, KY, LA, MA, MD, MI, MN, MO, MS, NC, NY, PA, SC, TN, VA, WV, Germany)

‐ Dallas (AK, AR, CA, HI, MO, NE, NM, OK, OR, TX, WA, Japan, Korea) ‐ Winchester (AL, CA, IL, MS, NH, VA, Afghanistan, Iraq)

d. National Guard Bureau (NGB) – CONUS

Includes the Army National Guard and Air Force National Guard – comprised of contracting offices that support the various States and US territories (all 50 States plus the U.S. Virgin Islands, Guam, Puerto Rico, and the District of Columbia)

The Army Response Team will provide support to the current databases and contracting offices currently totaling 190 active PD2 databases (for 247 contracting offices) as well as roughly 50 legacy databases where there is no contracting activity but must be maintained. The movement of databases from active to legacy shall vary under this period of performance under this contract. These databases are currently on the various servers (physical and virtual) and internal and external (DoD and Federal) interfaces/integrations, as follows:

a. Army Standard Procurement System‐Army (SPS‐A) data center, located in Radford, VA, hosts the following PD2 databases for each of the aforementioned Commands:

(1) U.S. Army Contracting Command: 123

(2) U.S. Army Medical Command: 2

(3) National Guard Bureau: 59

b. The ACC‐Orlando and MEDCOM (USARMAA) host independent PD2 databases/infrastructures hosted in Orlando, FL, and Ft. Detrick, MD—1 database each, respectively. These sites may migrate to the SPS‐A data center under the scope of this contract.

c. The U.S. Army Corps of Engineers hosts 57 PD2 databases, located at two centralized data centers in Vicksburg, MS (28 databases), and Portland, OR (29 databases)

d. The SPS‐A enclave also supports non‐Army contracting offices that the ART shall also support:

(1) U.S. Special Operations Command (USSOCOM) – 7 databases

(2) U.S. Military Training Mission (USMTM) – 1 database

The SPS‐A program provides procurement and requirement functionality to the Army acquisition community and consists of both physical and virtual server environments supporting the following major components/technologies:

Sybase Adaptive Server Enterprise (RDBMS/Data Layer)

SPS webMethods Integration/Broker Server (Integration Layer)

Citrix XenApp (Presentation Layer)

Procurement Desktop – Defense (PD2) (Application Layer)

PD2 Application Server Framework (Application/Integration Layer)

Citrix Edgesight (Reporting Layer)

Citrix Web Interface (Presentation Layer)

Citrix NetScaler (Web/Presentation Layer)

Microsoft SQL Server (Reporting/Data Layer)

Army Business Intelligence BiXtractor (Integration Layer)

PD2 Integrity Tool (Application Layer)

SPS Legacy Integrations (Integration Layer)

The current high level architecture for PD² integration software components incorporated in the SPS suite of tools (known as the PD² Adapter and SPS Legacy Integrations) are depicted below:

The current SPS‐A production and test environments are comprised of the following virtual (V) and physical (P) servers depicted below:

The presentation or User Interface (UI) layer PD2 is delivered through a Citrix managed environment via the XenApp servers which host the PD² application. Citrix software is used to secure and regulate access to the SPS PD2 application environment. Authentication is a mixture of government issued Common Access Card (CAC) and Username/Password authenticated users. Once the users are successfully authenticated and granted access to the Citrix environment the PD2 application requires an application level Username/Password for authentication.

Once authenticated to the enclave through the Citrix client, users are load balanced across one of the Citrix XenApp servers which hosts the PD² application and other third‐ party software components necessary for the users to perform their daily PD² work. This load balancing function is performed by the Citrix Data Collector.

The Business Layer is responsible for handling inbound and outbound transactions where data requires translation to a usable PD² format (XML) for inbound transactions or requires data to be interfaced with outside systems.

Within the Integration Layer reside the Document Transfer Utility, SPS Integrations, and the Application Server Framework which interface with internal PD² databases or external financial systems as depicted below:

SPS‐A Document Transfer Utility (DTU)

The Document Transfer Utility (DTU) allows SPS‐A System Administrators to transfer document chains from one PD² database to another. The DTU transfers all documents in an associated contract chain from Purchase Requests to Delivery Orders and all documents in between (Requirements data, Solicitation data, Award data, Attachments, etc.).

SPS‐A supports the integration with several external Government data systems. This integration is managed via a SPS‐specific integration tool ‐ the PD² Adapter. Additionally, SPS Legacy Integrations are installed wherever applicable to facilitate data transfer to/from external systems that do not accept

XML.

The following diagram shows the current SPS‐A Integration Architecture:

The Application Server Framework creates postscript(.ps) and index (.idx) files in support of the DoD’s Electronic Data Access (EDA) system. A Windows Scheduled Task sends these data elements to the DoD Global Exchange (GEX) which, in turn, populates the EDA system.

The data later is comprised of Sun SPARC Enterprise servers which currently host Sybase instances containing database repositories for PD², and CDR.

The following components of the system are infrastructure components. Direct access is secured through the use of Username/Password. This security is enforced for both system operations and system administration/support.

Server data transfer via SFTP webMethods

PDS

Sybase

MDWS

Unix

System access to GFEBS, the Army core financial system, is secured and managed through the use of Secure Socket Layer (SSL) Certificates. SSL Certificates are small data files that digitally bind a cryptographic key to an organization’s details.

The Contractor shall work closely with ODASA(P) and other servicing organizations including but not limited to: Army Business Center for Acquisition Systems (ABCAS), the Virtual Contract Enterprise (VCE) Acquisition Logistics and Technology Enterprise Systems and Services (ALTESS), and Network Enterprise Center Redstone (NEC‐R) to deliver quality, day‐to‐day engineering support services to the Army’s SPS user community. Equipment located at both facilities is Government owned.

In additional to SPS support, this PWS also include support for the following areas:

User and System Support for:

o Federal Procurement Data System‐Next Generation (FPDS‐NG) o General Funds Enterprise Business System (GFEBS)

Targeted Training for the Army Contracting Enterprise

Service Model Maturation

The services to be performed are non‐personal in nature as defined by FAR 37.103. Through the delivery of these services, ODASA(P)’s objectives are to improve the Army Contracting Enterprise workforce with knowledge and training, improve customer service and field productivity through consolidation and standardization, improve processes, enhance subject matter expertise in functional areas, and create more effective test management and execution to build better products and understanding to the contracting workforce.

The following sections provide the support requirements

2.0 Requirements

2.1 Program Management and Control

The contractor shall monitor and control program scope through the understanding of the ODASA(P) Enterprise Business Systems Division (EBSD) organization mission, vision, and goals. The contractor shall plan, manage, integrate and control the requirements defined in this PWS and successfully complete the work required. The contractor shall resolve any issues and problems brought to their attention by the Army during the performance of this contract. The contractor shall monitor contract performance and ensure the accurate and timely submission of reports. The contractor shall provide management services for the contract, including the following, at a minimum:

2.1.1 Schedule Management

The contractor shall outline the necessary tasks and demonstrates the understanding of each task as it relates to desired program outcomes. The project manager shall identify project milestones, maintain an Integrated Master Schedule (IMS), and report progress against this schedule on a monthly basis. The Integrated Master Schedule (IMS) shall be delivered on the 1st business day of each month. (CDRL 001)

2.1.2 Risk Management

The contractor shall develop a Risk Management Plan, which includes a Risk Assessment Matrix as a method to track and manage program risks. The Risk Management Plan shall include the analysis of likely risks, as well as mitigation strategies and action plans to assist the project should common problems arise. The Risk Assessment Matrix serves as a register where risks are identified, assessed, and prioritized based on the probability of the risk occurring and the potential consequence to the program. Risk assessments shall be conducted on an ongoing basis to ensure the timely application of resources to minimize, monitor, and control the probability and/or impact of unfortunate events or to maximize the realization of opportunities.

The Risk Management Plan shall be reviewed with the Government when changes are made within the Matrix. The Risk Management Plan shall be delivered on a quarterly basis or as required by the COR. (CDRL 002)

2.1.3 Resource Management

The contractor ensure proper resources are allocated to successfully complete the work outlined in this PWS, monitor the completion of each task, and provide a detailed Resource Plan that outlines the allocation of resources in support of each task. The outline includes but is not limited to name, role, and responsibility.

The Resource Management Plan shall be delivered on the 1st business day of each month.

(CDRL 0003)

2.1.4 Management Reporting

The contractor shall deliver a variety of management reports that communicate project status and strive to improve the services being provided. The contractor shall submit Weekly Project Status Reports by close of business every Monday that contain updates on project schedule, identified risks, mitigation strategies, resource constraints, known issues, and open actions. (CDRL 004)

The contractor shall submit a Monthly Performance Status Report that shall contain but not be limited to a summary of the technical environment (e.g., SPS Service release versions across the number of Army Sites), Financial Status including but not limited to CLIN balances, and any personnel resource changes. The report shall be delivered on the 10th of each month or prior business day if day falls on weekend or holiday.

The contractor shall participate in Quarterly Progress Meetings with the Army to review current support requirements, highlight any notable trends or systemic issues, and identify any contract or service level concerns. These meetings will occur at either the Contractor or government facility. Additional meetings may be scheduled as required by either the Army or Contractor. The contractor shall assist in producing the agenda and meeting briefing, which shall be exchanged at least three (3) workdays prior to each meeting.

Weekly Project Status reports shall be delivered no later than the close of business (COB) every Monday.

Monthly Performance Status reports shall be delivered on the 10th of every month or prior business day if day falls on weekend or holiday.

Quarterly Progress meetings shall be held quarterly, during the first week of the following quarter. Content for the meeting shall be delivered three workdays prior to each meeting.

(CDRL 005) and (CDRL 006)

2.2 Standard Procurement System (SPS) Program Support

The Standard Procurement System (SPS) Procurement Desktop – Defense (PD²) software is currently in sustainment, and service releases are planned. The Army plays a critical role in the requirements development and testing of delivered software changes.

(CDRL 021A, B, C, D, E)

2.2.1 SPS Requirements

The contractor shall support ODASA(P) by providing impact analyses for all requirements submitted to the JPMO for consideration. Analysis should focus on the Army’s use of SPS, including impacts to interfacing systems. Additionally, the contractor shall vet and prioritize requirements from an Army perspective, and participate in DLA JPMO Operational Requirements Committee (ORC) meetings and review sessions, providing the Army perspective and/or prioritizations for group consideration.

Summary of meeting minutes and actions to include content summary, risks, and recommended actions shall be delivered within 2 business days of the meetings

2.2.2 SPS Testing

As the SPS software vendor delivers service releases and other software updates to the Government, the Army has a role in the JPMO’s Software Acceptance Testing (SAT) process, helping to ensure that all potential software defects, failed requirements, and other anomalies are discovered, documented, and communicated, and the testing process is managed effectively.

The contractor support SPS testing efforts on behalf of the Army. The contractor shall be required to partner with Army Stakeholders within the community (ACC, MEDCOM, USACE, NGB) to solicit testing support across the enterprise. The support contractor shall develop training, documentation, business processes, based on operational use on behalf of the Army. The contractor shall also complete execution of desired/assigned test scripts provided by the JPMO and conduct their own excursion testing to ensure the software will perform operationally in the Army environment.

The support team shall support in the following SPS Service Releases release testing processes unless otherwise directed by the ODASA(P):

PD² Application

Sybase Adaptive Server Enterprise (ASE)

PD² Adapter

Document Transfer Utility (DTU)

Application Server Framework (ASF)

Out‐of‐cycle Sybase updates (as they are released by SPS vendor only)

SPS Legacy Integration Releases

Army Integrity Tool and associated edits

Java Updates (as released by the SPS vendor for use with SPS)

Integration‐related “punch out” utilities (e.g., PDS Punch‐out)

The support team shall work with the SPS JPMO to do the following for each release as required:

Participate in test script development/review sessions

Determine the number of Army‐specific man hours required to execute the JPMO’s prescribed test scripts

Validate the test scripts to be used during each test

Coordinate tester access to Army SPS test environment

Manage and participate in test execution process to include test script and targeted excursion testing

Report daily progress to ODASA(P) and the SPS JPMO

During active test execution, participate in daily SPS JPMO status and review sessions

Document and log all potential software defects or problems within the SPS JPMO bug tracking system

Provide input to ODASA(P) regarding the acceptance or rejection of service releases and other tested software updates

This task includes the following ongoing subtasks (both in and out of active test cycles):

Review new or revised DoD or Army initiatives including upcoming and proposed system changes for possible impact on SPS, FPDS‐NG, GFEBS, or the Army Business Intelligence capability (VCE‐BI) for possible impact on each other

Maintain Army SPS test documentation for all releases tests

Actively engage the Army SPS user community to:

o Advertise upcoming SPS testing events o Solicit for field‐participation in SPS testing events o Gather requests for software change/improvements

2.2.3 SPS Test Environment Management

Manage the Army SPS test server infrastructure (Windows servers, Solaris instances, and SPS components (PD², Adapter, Sybase, archiving utility, Document Transfer Utility and Citrix) to ensure proper hardware and software configurations are installed and working properly. This environment which serves the Army is currently hosted at ALTESS.

Work with hosting environment representatives (e.g., ALTESS) to mitigate or document information assurance risks, and test software functionalities, as necessary

Update any changes to the environment in the SPS‐A Architectural System Design Document.

2.2.4 Afterhours Monthly Maintenance and Patch Testing

The contractor shall provide afterhours support to perform application testing after monthly maintenance and Information Assurance driven‐patching occurs at the SPS‐A host facility. Testing shall be ad hoc and regression in nature and ensure the system is operational after the maintenance and patch activities have occurred.

2.2.5 Deployment Support – Installation and Training Services in Support of a new SPS Install Provide an approval process (Green Light Process) for each contracting office that is preparing to install a new version of the SPS software at non SPS‐A sites. The approval will at a minimum insure that each database is sound and can safely be converted to the new version of the software. Each office will be required to go through this approval process prior to having access to the new software. The desk officer will be provided the status of each office as it is approved or rejected. If this process reveals that an office should not be upgraded, the ART team shall assist the office to correct the problem. This assistance may require reinstallation of SPS software (specifically Sybase and the PD² Database) components when such reinstallation is necessary to recover a site’s operations as the result of any downtime caused by a hardware or software failure as defined in the SPS Help Desk Agreement as a Severity 1 or 2 issue.

2.3 Standard Procurement System – Army (SPS‐A) Enclave Support

2.3.1 Configuration Management

The contractor shall manage a comprehensive Configuration Management (CM) process in order to create and maintain a baseline record of all the components of the infrastructure for the purpose of maintaining system integrity and traceability. Infrastructure includes the hardware, software, network appliances, storage, and other components that comprise the SPS‐Army system. The contractor shall update the Architectural System Design Document that documents the baseline infrastructure and CM Plan that documents the systematic configuration control process when changes to system components are necessary. Within the CM Plan, the contractor shall establish clearly defined roles and responsibilities of all SPS‐A service providers and shall document these items in a responsibility assignment (RACI) matrix.

The Architectural System Design Document shall be maintained throughout the life of the contract and delivered on a quarterly basis or as required by the COR.

The Configuration Management Plan shall be maintained throughout the life of the contract and delivered on a quarterly basis or as required by the COR.

(CDRL 007) and (CDRL 008)

2.3.2 Operational Support

The contractor shall field an SPS-A System Administration Team that shall provide the necessary functional and technical support to maintain the day-to-day operations of the systems hosted within the SPS-A enclaves at ALTESS and the COOP site at NEC-R. Technical support is required to operate and maintain a stable and secure SPS production environment within the given robust hosting infrastructure. Historically the daily, weekly, and monthly tasks are routinely performed. These activities are documented in the current SPS-A Operations and Maintenance

SOP.

The SPS‐A enclave employs a variety of monitoring tools and techniques. Below is a list of technologies that are currently in use or are licensed and readily available to SPS‐A Technical Administrators:

• Citrix Edgesight

• eHealth

• NetScout

• Net Cop

• Net Ranger

• Wireshark

• Remedy

• Session Capture

• Solarwinds IT Management and Monitoring Software & Email Alert System

• Sybase SQL Reports

• VMware vCenter/vSphere

• Sybase System and Performance Monitoring Tool(s)

On a daily basis, the SPS‐A Technical System Administration Team shall perform the following tasks (manually or via scheduled task/cron job):

Database Backups – Back up the following databases: PD² production databases, PRweb databases, MWS databases, CDR databases, Sybase system databases. Backups are automatically filed to tapes, which are stored both on and offsite, in accordance with the SPS-A Backup and Recovery Plan.

Review Backup Logs – Daily manual review of backup log outputs and automated emails containing high-level backup log data. Remediation plans shall be developed and executed in accordance with Sybase and NetBackup best practices, and documented in weekly status reports.

Monitor Application Server Framework Servers – Monitor for EDA and/or document generation failures within the ASF server logs. If any errors, systemic issues, or repetitive document rejections occur, the technical team shall work with the appropriate functional system administrators or ALTESS technical administrators, where appropriate, to resolve the errors.

Monitor PD2 Adapter Servers – Monitor PD2 Adapters and associated log files for errors or server irregularities (check 2-3 servers per day on a rotating schedule). If any errors, systemic issues, or repetitive document rejections occur (e.g., GFEBS pre-award validation failures), the technical team shall work with the appropriate functional or technical system administrators, where appropriate, to resolve the errors.

Please see the SPS-A Architectural Design Document for a list of integrations monitored by the SPS-A Technical System Administration Team.

On a weekly basis, the SPS-A Technical System Administration Team shall perform the following tasks:

Review Error Logs – Review 2-3 Sybase Server error logs. Remediation plans shall be developed and executed in accordance with Sybase best practices, and documented in weekly status reports.

Run Update Statistics/Reorg Compact Script – Complete the “Update Statistics/Reorg Compact” task, which updates various indexes in the PD² production database, and compacts to reclaim space and remove row forwarding.

On a monthly basis, the SPS-A Technical System Administration Team shall perform the following tasks:

Perform Database Consistency Checks – Perform database consistency checks (DBCC) including checkstorage and checkcatalog on all databases.

Check Amount of Free Space remaining in Database – Check both the data and log segments of the production database to make sure that there is no danger of running out of space. The SPS-A Admin Team shall add more space to the device, when any data segment reaches 88% of capacity. The schedule for this task is elevated to bi-weekly or weekly during the month of September, at the discretion of the SPS-A System Owner.

Validate Connectivity to Sybase Servers – From all VM Admin Desktop instances available, confirm connectivity to Solaris server instances using both the Putty and Cygwin applications.

Truncate MWS Document Tables – Run script that shall truncate the tables that contain XML document data in the MywebMethods (MWS) database. This script is necessary if the MWS database has a larger volume of data to delete and/or archive than the total size of the associated transaction log.

Update Sybase Passwords every 60 days – In accordance with Army Regulation AR 25‐2 and the SPS‐A User Access and Account Management SOP, all passwords must be updated every 60 days. To ensure production continuity, when passwords are updated in Sybase, they must also be updated in the PD² Adapter, PD² ASF Server, PRweb, BI Xtractor, the Integrity Tool, and any other application whose function is dependent upon Sybase login account credentials.

Perform SPS Patches, Enhancements, and Upgrades – Apply updates to the SPS product suite for accepted new Service Releases and maintenance releases. Schedules for these updates shall be coordinated separately, and in coordination with the ODASA(P) and program stakeholders.

SPS Standard Data Updates – Standard Data updates are posted to the SPS Knowledge Base one or two times per year and must be applied to each PD² DB. The current process involves first applying the newest update to the pilot database (413th – Hawaii) for one day of testing. If testing produces no errors, the update is applied to all enclave production databases.

FAR/ DFARS Clause and Clause Logic Updates – FAR & DFARS clause updates are posted to the SPS Knowledge Base every 2 – 6 weeks and must be applied to each PD² DB. The current process involves first applying the newest update to the pilot database (413th – Hawaii) for one day of testing. If testing produces no errors, the update is applied to all enclave production databases.

PD2 Reference Library Updates – Reference Library updates are posted to the SPS Knowledge Base every 2 – 6 weeks and are applied to the common SPS-A portal after each release.

Effective provisioning of support requires resources with skill sets capable of diagnosing, troubleshooting and resolving issues across a wide spectrum of technologies including, but not limited to: PD², PD² Adapter, Sybase ASE, PowerBuilder, webMethods Integration Server, Citrix XenApp, Citrix Provisioning Server, VMware, MS SQL Server, MS Windows Server, and Sun Solaris. The contractor shall provide initial response to end‐user requests for assistance within one hour.

The following organizations and personnel (where applicable) shall be involved in management of the SPS‐A and its operations and maintenance activities:

ODASA(P) – Program Sponsor and Oversight

ACC CIO/G6 – Program Technical Lead and Information System Security Officer (ISSO)

ALTESS – Hosting Environment Oversight

Technical System Administrators – Technical Operations and Maintenance

Local Site Functional System Administrators – Functional Operations and Maintenance

The contractor shall provide post deployment support of the SPS‐A capability to post solicitation data in a standard format to third‐party web services automatically from the various SPS production databases.

This implementation effort shall require resources that are familiar with the PD² data model, the PD² Adapter, Sybase ASE, and webMethods Integration Server.

Additional responsibilities include the documentation and execution of SPS‐A Operations and Maintenance Standard Operating Procedures, to include: log review/analysis, database consistency checks, database backups/restores, integration upkeep, implementation of SPS Service Releases and Sybase Application upgrades, clause and standard data updates, user maintenance, and other routine tasks. In some cases, duties shall include assisting users with PD²‐related functional matters and to support changes to the site‐specific security model. In addition, the administration team is expected to run reports as needed using VCE‐BI, the FPDS‐NG site, the EDA site, or other Army or DoD Business Intelligence systems.

The contractor shall perform all system administration (SA) duties in the PWS without anyone initiating a help desk ticket.

The SPS‐A Operations and Maintenance SOP shall be reviewed, updated as required, and delivered on a quarterly basis throughout the life of the contract.

(CDRL 009)

2.3.3 Technology Lifecycle Management

The contractor shall provide the Government with expert advice for the on‐going optimum configuration of the SPS software components within the hosted environments that make up the SPS‐Army Consolidated Enclaves. Support is required in determining both current and future hardware, software, and network configurations to support the core PD² contract writing software and the integration software components. All hardware and software is Government owned or leased.

The contractor shall perform networking optimization tasks relative to the additional increased level of effort and shall include but are not limited to: conducting bandwidth analyses, conducting predictive analyses and troubleshooting, coordinating with external network support entities (e.g., DISA, 2RCC, Army Cyber Command), coordinating with local Army site‐level network points of contact, researching impacts of Army technology stack upgrades and integrations as they relate to legacy systems such as SPS. The contractor shall develop a weekly workload summary report to include actions taken, participants, next steps, POCs, as well as bandwidth analysis reports for Army locations that have exhibited symptoms of poor performance or have risk for developing potential impacts in the future. In addition, the contractor shall develop technology research reports for optimization of service delivery (e.g., technology refresh) as requested by the Government.

The Weekly Workload Summary Report shall be maintained throughout the life of the contract and delivered on a weekly basis as part of the weekly submission or as required by the COR.

The Technology Research Reports and Bandwidth Analysis Reports shall be maintained throughout the life of the contract and delivered on an ad hoc basis as required by the COR.

The contractor shall develop a Technology Lifecycle Management Plan to account for the technology refresh of the infrastructure within the SPS‐Army enclaves. To assure continued supportability throughout its lifecycle, the contractor shall conduct an analysis to address issues of capability enhancement, technology vendor roadmaps, and end‐of life support issues that may require premature technology refresh requirements. Effective and accurate license management is also essential to include in such a plan.

The Technology Lifecycle Management Plan shall be shall be maintained throughout the life of the contract and delivered on a quarterly basis or as required by the COR.

(CDRL 010)

2.3.4 Continuity of Operations

The contractor shall maintain a Continuity of Operations Plan (COOP) to provide a repeatable methodology for the successful backup and recovery for all components within the SPS‐A enclave. The contractor shall continue to analyze the existing COOP and Disaster Recovery (DR) strategy employed by the SPS‐A Administration Team, and shall develop and refine a more complete and testable procedure that shall align with defined Army COOP guidance and vendor best practices. The contractor shall conduct a test of the COOP with end‐user support.

The Continuity of Operations Plan shall be shall be maintained throughout the life of the contract and delivered on a quarterly basis or as required by the COR.

The Continuity of Operations Test shall be tested delivered on a quarterly basis or as required by the COR.

(CDRL 011) and (CDRL 012)

2.3.5 Information Assurance

The contractor shall support the Government in complying with the Army’s Information Assurance (IA) processes and procedures in support of the SPS‐A Enclaves. Specifically, the contractor shall provide direct input into the Plan of Action & Milestones (POA&M) template as part of the DoD Information Assurance Risk Management Framework (RMF) process to achieve and maintain system accreditation.

The contractor shall perform the following:

Input and support to the Information System Security Officer (ISSO) to include but not be limited to: maintaining the Plan of Action & Milestones in eMASS (or other Army approved tracking system) throughout the life of the contract and reviewed on a quarterly basis or as required by the COR paying particular focus on expiring and high risk items.

Actively participate in regular and periodic program security reviews to include documentation reviews and updates as well as consultation and performing key compliance activities and initiatives.

Identify and remediate risks associated with the SPS‐A environment

Update and maintain all ART deliverables as artifacts within the RMF repository as they align to RMF security controls and associated configuration control item (CCI) requirements.

(CDRL 016)

2.3.6 Performance Management

The contractor shall develop a Performance Management Plan to outline the identification, collection, monitoring, and measurement of performance metrics necessary to assess the health of the SPS‐A environments. The plan should focus on Reliability, Availability, Maintainability, and Scalability of the systems within the SPS‐A enclave, and the optimization of application delivery to the end‐user.

In order to address Delivery Optimization strategy, the contractor shall look at network optimization (to include the use of WAN optimizers) and software optimization (configuration changes to the baseline).

In addition, the Performance Management Plan should collect data from both the data center and the end‐point.

The Performance Management Plan shall be shall be maintained throughout the life of the contract and delivered on a quarterly basis or as required by the COR. (CDRL 013)

2.4 Technical and Functional User Support for SPS

2.4.1 Field Support

The contractor shall provide information technology/engineering services to support the hardware/software infrastructure of all the U.S. Army’s SPS operational user community worldwide. The Army’s acquisition and SPS goals shall be achieved by approximately 8,100 acquisition professionals through the user of the software suite comprised of PD², the PD² Adapter, the SPS Legacy Integrations, and/or other government (or contractor) owned interfacing processes. The goal is to enable the various Army Commands (ACOMs); Army Service Component Commands (ASCCs); Direct Reporting Units (DRUs); and other Agencies to sustain operational success with PD² current and future versions.

The contractor shall manage a centralized Service Desk operation to include an incident, change, and problem management solution for support issues and provide initial response to end‐user requests for assistance within one hour of receipt during the contracted service hours.

2.4.2 Escalation Procedures

User issues are reported either through the SPS JPMO Help Desk or the Army Enterprise Service Desk (AESD). Either of these service/help desks could issue a service/help desk ticket to the ART team. When an issue develops that cannot be resolved through the SPS Help Desk (as they are deemed out of scope on the JPMO SPS Contract by the JPMO vendor) or SPS‐Army Enclave Service Desk and is escalated to the ART as a Tier 2 issue, ART shall take immediate action to resolve the issue or provide alternatives to eliminate or mitigate the issue during standard working hours of 0800‐1700 EST. The contractor shall provide initial response to end‐user requests for assistance within one hour.

2.4.3 Afterhours Support

There are three areas of afterhours support that the contractor shall support.

2.4.3.1 End of Fiscal Year Support

The contractor shall establish an End of Fiscal Year User Support Center (EOFYUSC) to support end‐of‐ year contractual operations and ad hoc critical after hours support on an on‐call basis.

The EOYUSC or After Hours Support staff shall coordinate with the JPMO and the Army Help Desk to track, monitor and resolve existing issues and service requests. If the EOYUSC or after hours support staff is concerned that a service request or issue is not receiving appropriate attention, then the staff shall consult with the ART Management Team to determine the appropriate plan of action and provide feedback to the user and Desk Officer.

The contractor staff disseminates pertinent information via the Army’s SPS e‐mail listserver or other Army communication forum that may be in place. Service requests and issues and resulting resolutions that arise repetitively are documented and shared with Army users via the listserver or other communication forum that may be in place, as well as being reported to ODASA(P) and their service partners for posting to the appropriate Army SPS web site(s).

The period of performance of the EOFY support shall be no more than seven (7) calendar days prior to the start of new Fiscal Year. A minimum of one (1) functional and one (1) technical FTE shall be available on‐call from 1700‐2400 Eastern Daylight Savings time (EST) during the weekdays and 0800‐2400 on weekends. During the hours of operation, the staff shall perform the following tasks: Army tickets categorized as Severity 1 or 2 that are EOFY related, either through the SPS Help Desk or through the Army criteria, are immediately assigned to an EOFYUSC staff member and worked as priority. Other tickets in the queue and operational efforts (e.g., updating documentation) that can be accomplished when no other “hot” issues exist shall be worked to make the best use of the time. The contractor shall establish a dedicated phone number for the users to call during this time.

A daily status report shall be developed that tracks the total number of tickets received (i.e., total volume of new requests), the distribution of requests across the extended hour period, category, and all Severity 1 and 2 tickets with a description of the issue and resolution plan. The report should also indicate which requests received are critical to completing end of fiscal year (EOFY) related processing as well as any other “Hot Issues” that need to be brought to management attention. Daily status reports shall be emailed to ODASA(P) Desk Officer, Program Manager, and Contracting Officer’s Representative (COR) and reported in the subsequent weekly, monthly, and quarterly reports. A summary report collating the weekly reports shall be delivered at the end of the period.

Daily status report shall be delivered each day

Summary report shall be delivered 14 days after the completion of the end of the fiscal year support period.

(CDRL 014)

2.4.3.2 After Hours Tier 2 Support

If one or more after hours issues occur, an After Action report shall be developed that details the total number of Severity 1/Priority 1/Critical tickets received, a description of the issue and resolution. This report shall be emailed to the ODASA(P) Desk Officer, Program Manager, and Contracting Officer’s Representative (COR) on a weekly basis and prior to invoicing the Government. The contractor shall accumulate these metrics and shall report the accumulative totals in the subsequent weekly, monthly, and quarterly reports.

After Action report shall be delivered on a weekly basis as required within one week of the incident occurring and prior to invoicing for the support.

(CDRL 015)

2.4.3.3 After Hours Maintenance Support

The contractor may be required to work one weekend a month to perform software updates as required (e.g., Java update). ODASA(P) and the contractor shall ensure that the applicable weekend selected does not coincide with other work that may be done by other entities, e.g., ALTESS network maintenance weekend. The contractor shall work to ensure that the environment is restored to working order by the beginning of the work week through testing, server restarts, etc., as appropriate.

An After Hours Maintenance Support report shall be developed that summarizes the effort and result.

This report shall be emailed to the ODASA(P) Desk Officer, Program Manager, and Contracting Officer’s Representative (COR) on a monthly basis and prior to invoicing the Government. The contractor shall include this report in the monthly and quarterly reports.

Maintenance Support report…