14__PWS_Task_Order_0002.docx
DOCX document 86 KB Posted
- Attached to
- Defense CollaborationServices (DCS)
- Solicitation number
- HC1047-19-R-4005
- Issued by
-
Defense Information Systems Agency
About this file
This document contains draft performance work statements for an indefinite delivery/indefinite quantity contract and associated task orders to provide engineering, software development, and operational support services to the Defense Collaboration Services program. Key details include:
-
The single-award IDIQ would have a ceiling of $49.5 million over five years and require experience with open-source software programs like Big Blue Button as well as other components such as Tomcat, Nginx, FreeSWITCH, Redis, Red5, LibreOffice, and ELK Stack.
-
Task areas under the IDIQ and initial task orders would include engineering support for infrastructure transitions, technology refreshes, customer requirements, and sustainment; development for open-source components; and integration and operational support.
-
Specific requirements include delivering solutions for voice integration, HTML5 migration, cloud optimization, mobility enhancements, and chat federation over the next year as well as maintaining an enterprise file repository system.
-
The effort requires personnel experienced in managing enterprise collaboration services for at least 500,000 customers and expertise in development processes, DoD infrastructure, cloud computing, and containerization.
-
Contractors must demonstrate CMMI Level 3 or ISO 9001 certification and assess and maintain the program's security posture within the Risk Management Framework.
PWS Task Order 0002
View the file
Other files
Show all 23
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
PERFORMANCE WORK STATEMENT (PWS)
As of 06 June 2019 Defense Collaboration Services (DCS) Solicitation Number HC1047-19-R-4005 Task Order 0002
1. Contracting Officer’s Representative (COR) See section H1 of contract “Points of Contact”
2. Contract or Title. Defense Collaboration Services (DCS) Engineering and Sustainment Support. Task Order 0002.
3. Background. Defense Information Systems Agency provides Defense Collaboration Services (DCS) as an unified real time enterprise collaboration capability that delivers secure web conferencing and instant messaging services on Secret Internet Protocol Router Network (SIPRNet), Sensitive but Unclassified Internet Protocol Network (NIPRNet), and internet (via NIPRNet). This critical enterprise service regularly serves 150K monthly web conference users and 20K concurrent daily chat users on NIPRnet. With DCS, DISA promotes and fosters a Joint information collaborative environment with a high quality and cost effective services to improve workflow productivity. DCS capabilities are built on open source solution and provides:
· Collaboration Portal: Social media and collaboration features, links and training info, and real time communications via XMPP chat messages.
· Web Conferencing: Browser-based web conference sessions that provide users with the capability to host presentations, record sessions, share desktops, white-board with all session participants, call into a session from their phone, view closed captioning, chat among session participants, and participant voting in session polls.
· Instant Messaging (Desktop and Mobile Apps): Persistent chat rooms, Multi-User Chat (XEP-0045, XEP-0369), one-to-one chat, presence, chat history search, chat user search, chatbots, and administration functions.
· File Transfer: Secure transfer of files for Department of Defense (DoD) enterprise users.
· Voice Conferencing: Voice conference bridge capability that is accessible to all DoD enterprise users.
4. Objectives: The objective of this contract is to provide DCS engineering and sustainment support to improve and maintain the service. DCS support contract includes managing and maintaining the applications, servers and supporting infrastructure on both the DISA NIPRNet and SIPRNet. The contract personnel should have requisite knowledge of DoD enterprise architectures, networks, frameworks, systems, process, and data requirements. Additionally, the technical contractual personnel should have expert knowledge of Web services, Open source components and trends, DoD integration and networks, DoD engineering and sustainment procedures and processes to deliver a real time enterprise collaborative service to a large customer base.
This includes continuously assessing the DCS security posture leading to and maintaining a current security authorization that meets the criteria of the DoD Risk Management Framework (RMF). This PWS delineates Contractor support in assuring the DCS information system, technology and components are secured according to the applicable security requirements, directives, and regulations and meet all applicable DoD and Non-DoD Information Assurance (IA) security requirements in accordance with (IAW) the DoDD 8140, DoD 8510 (RMF), and DoD 8570.01-M. Because of the complexity of DCS engineering and sustainment functions, Capability Maturity Model Integration (CMMI) Services (CMMI-SVC) Level 3 (or better) and Capability Maturity Model Integration (CMMI) Development (CMMI-DEV) Level 3 (or better) are required.
With rapidly evolving technologies, budget uncertainty, constant customer requirements, and fierce competition, DISA needs to manage these areas closely and continuously seek new, innovative, and effective ways to optimize and improve the DCS service. To better serve DOD and its Mission Partner customers, DCS program office has to continue Development / Security / Operations (DevSecOps) methodologies to manage infrastructure deployments, technology refreshes, and customer requirements.
5. Scope. Task order 0002 consists of following tasks from the base Indefinite Delivery/Indefinite Quantity (ID/IQ): 2 - architecture and engineering for DCS service, 5 - open source component development, and 6.1 - customer enhancements, and infrastructure deployments. These tasks are the foundation for DCS development and integration engineering support that includes the creation, deployment and integration of the service in its current and future environments with current or future software solutions. This task also encompasses the requirement for the vendor to work with the open source community when required and integrate open source software into the service. This task requires the intake and analysis of program requirements and requests; the development, testing, documenting, submission, and integration of requirements and requests if approved.
6.0 Work to Be Performed – The following subsections align to the base ID/IQ section 6. Each subsection provides specific details for the performance of task order 0002. Only the task areas that are required for each specific task orders will be defined in this section. If a task area of the ID/IQ is not part of this task order, it will be noted as “Reserved.”
6.1 Reserved
6.2 DCS Engineering Support
The task is for engineering and architecture support for the DCS program. The support consists of engineering and architecture support for pending infrastructure transitions, tech refreshes, customer requirements, and sustainment functions. The contractor support shall provide technical support to include technical research, planning, engineering, troubleshooting, and architecture development for the DCS service. This includes engineering support for prototyping, open source technology evaluations, government consultation, and advanced troubleshooting of the existing DCS application environment. The engineering solution and capabilities must be delivered to meet the program requirements. Infrastructure, tech refresh, customer requirements, and contract support will be required.
a. The contractor shall provide engineering support for infrastructure deployments and optimizations by being able to:
· Deliver research, planning, engineering, and architecture solutions to include white papers, design, documents, diagrams Operational View (OV-1) and System View (SV1) architectures.
· Deliver research, planning, engineering, and architecture solutions to include white papers, design, documents, and diagrams for shared services to include Application Delivery Controller (e.g. F5 VIPRION Platform), Online Certificate Status Protocol (OCSP), Domain Name System (DNS).
· Deliver research, planning, engineering, and architecture solutions to include white papers, design, documents, and diagrams for DCS application components to include HumHub, BigBlueButton, NGINX, RED5, Remote Dictionary Server (REDIS), My Structured Query Language (MySQL), FreeSWITCH, Tomcat, Swift, and Openfire.
· Deliver research, planning, engineering, and architecture solutions to include white papers, design, documents, and diagrams for containerization to include Kubernetes and Openshift.
· Deliver research, planning, engineering, and architecture solutions to include white papers, design, documents, and diagrams for multi-site cross site interactions.
· Deliver research, planning, engineering, and architecture solutions to include white papers, design, documents, and diagrams for cloud migrations.
b. The contractor shall provide engineering support for tech refreshes by being able to:
· Deliver research, planning, engineering, and architecture solutions to include white papers, design, documents, and diagrams for Hypertext Markup Language 5 (HTML5) Web Conference Client.
· Deliver core updates to the DCS Collaboration Portal (HumHub), Web Conference (BigBlueButton), and XMPP Chat Components (Swift Desktop Chat Client, Openfire XMPP Chat Server, JSXC XMPP Web Client, Tigase) to include software and enhancements.
· Deliver open source component upgrades to include Collaboration Portal, Web Conference, eXtensible Messaging and Presence Protocol (XMPP) Chat, Voice, and NetOps tools component upgrades.
· Web Conference updates - NTE 350 per year.
· XMPP Chat updates – NTE 600 per year
· Collaboration Portal updates – NTE 75 per year
· NetOps Tools (Nagios, Elastic Stack) updates – NTE 150 per year
· Voice Infrastructure updates – NTE 150 per year
· Enterprise File Transfer capability updates – NTE 75 per year
· Open source technology evaluations – NTE 24 evaluations per year
· Software updates – NTE 60 per user.
· Feature Enhancements – NTE 24 per year
c. The contractor shall provide engineering support for customer enhancements by being able to:
· Deliver research, planning, engineering, and architecture solutions to include white papers, design, documents, and diagrams for unified capabilities (voice, video, chat).
· Deliver research, planning, engineering, and architecture solutions to include white papers, design, documents, and diagrams for voice integration for web conference.
· Deliver research, planning, engineering, and architecture solutions to include white papers, design, documents, and diagrams for Five Eyes (FVEY) and Coalition chat capacities in the Classified Environment.
· Deliver research, planning, engineering, and architecture solutions to include white papers, design, documents, and diagrams for Cross-Domain chat.
· Deliver research, planning, engineering, and architecture solutions to include white papers, design, documents, and diagrams for DCS services (Web conference, XMPP Chat, Collaboration Portal, Audio / Video).
· Deliver research, planning, engineering, and architecture solutions to include white papers, design, documents, and diagrams for enterprise chat federation to include chat gateways and protocol converters (SylkServer, Nextplane)
· Deliver research, planning, engineering, and architecture solutions to include white papers, design, documents, and diagrams for Disconnected Intermittent Low Bandwidth.
· Deliver research, planning, engineering, and architecture solutions to include white papers, design, documents, and diagrams for distributed DCS.
· Deliver research, planning, engineering, and architecture solutions to include white papers, design, documents, and diagrams for additional DCS capabilities and enhancements to include file upload and repository enhancements.
d. The contractor shall provide engineering support for sustainment by being able to:
· Complete engineering testing and validation for server, application, Infrastructure, IA /security, network and service impacting issues.
· Document procedures and maintain repository for DCS Engineering documentation and update annually.
· DECC coordination, engineering TEMs, and seminars two times a year.
· Update software forge tasks as required
· Develop and recommend new and improved DevSecOps and Agile methodologies for process improvements.
· Apply Capability Maturity Model Integration (CMMI) Development (CMMI-DEV) Level 3 (or better) and CMMI Services (CMMI-SVC) Level 3 (or better) to engineering efforts in support of development and operation of DCS services where applicable.
Deliverable(s):
| PWS Task# |
| Deliverable Title |
| Minimum Requirements |
| Format |
| Distribution/ Copies |
| Submission Due Date |
| 6.2 |
| Weekly Activity Reports |
| Provide a weekly activity report documenting open work issues, current work efforts, and future work efforts in infrastructure, tech refresh, customer enhancements, and sustainment. |
| Contractor-Determined Format |
| Standard Distribution* |
| Weekly |
| 6.2 |
| DCS Architecture Documentation |
| Develop & Update DCS Architecture documentation for infrastructure, tech refreshes and customer enhancements. |
| MS Word and MS Visio and PDF |
| Standard Distribution* |
| Monthly |
| 6.2 |
| DCS Engineering Document Repository |
| Maintain and Update for DCS Engineering documentation |
| DEPS Document Repository & DCS System Wiki (DEPS) |
| Standard Distribution* |
| Weekly |
| 6.2 |
| DCS System Engineering Testing and Validation |
| Testing and Validation Process & Plan for DCS Systems |
| Contractor-Determined Format |
| Standard Distribution* |
| Draft 15 business days prior to each architecture change and final 30 business days after each architecture change |
| 6.2 |
| System OV-1 and SV 1 |
| Operational View (OV-1) and System View (SV-1) of DCS System Architecture |
| MS Visio and PDF |
| Standard Distribution* |
| Draft 15 business days prior to each architecture change and final 30 days after each architecture change |
| 6.2 |
| SoftwareForge Usage Plan |
| Plan to leverage Software Forge (or equivalent as designated by the Government) to maintain requirements, defects, task, software, playbooks, and executables and fully leverage all capabilities provided by Software Forge |
| Contractor-Determined Format |
| Standard Distribution* |
| Thirty (30) business days after contract start and updated annually. |
| 6.2 |
| SoftwareForge Updates |
SoftwareForge Updates
SoftwareForge Artifacts, Software Code, Executables, Playbooks Per SoftwareForge Format
| Standard Distribution* |
| Daily |
*Standard Distribution: 1 copy of the transmittal letter without the deliverable to the Contracting Officer; 1 copy of the transmittal letter with the deliverable to the Primary COR.
6.3 Reserved
6.4 Reserved
6.5 Task 5 - Enterprise Collaboration Open Source Services Support Development.
The task is to provide development for open source components for DCS capabilities. The contractor shall develop the open source solution as requested by the government. To function in the developmental and operational environments, the software developed must be Integrated in accordance with (IAW) the Agile Model of the Software Developmental Life Cycle (SDLC) and tested within the government SDLC.
a. The contractor shall provide software development and integration support for open source projects that are utilized by the DCS program. Those open source projects may include:
· BigBlueButton
· FreeSwitch,
· Isode Swift Chat Client
· Realtime Openfire XMPP Chat Server
· Apache Tomcat,
· LibreOffice
· MySQL
· Redis
· Tigase Messenger (iOS & Android)
· SylkServer
· HumHub Collaboration Portal
· JSXC XMPP Chat
· Open Source Chatbot Projects
· Open Source Speech to Text Projects (e.g. DeepSpeech, etc.)
· Open Source AI Voice Assistant / Machine Learning (e.g Mycroft, etc.),
· Open Source File Management (e.g. OwnCloud or NextCloud) - add file storage capability for web conference and mobile devices,
· Open Source Chatbot Projects (e.g. Botpress, etc.).
b. The contractor shall be able to:
1. Develop and deliver unified capabilities (video, voice, chat), voice call in, Mobility web conference capabilities.
2. Deliver solutions for HTML5, Core Updates (portal, WC, Chat), and Open source components.
3. Deliver each of the System (Application) Software executable and source code in designated format (e.g. rpms).
4. Conduct, document and deliver test plans and testing results to the Government with each quarterly software (SW) build or release. To include:
· Unit Test
· Integration/System Test
· Volume/Stress Test
· User Test
5. Provide the Government a level-of effort (LOE) assessment on any modifications, fixes, and enhancement to the open source tool sets used by DCS.
6. Deliver open source component upgrades to include Collaboration Portal, Web Conference, XMPP Chat, Voice, and NetOps tools component upgrades.
Examples of the upgrades/updates are:
· Web Conference updates - NTE 350 per year.
· XMPP Chat updates – NTE 600 per year
· Collaboration Portal updates – NTE 75 per year
· NetOps Tools (Nagios, Elastic Stack) updates – NTE 150 per year
· Voice Infrastructure updates – NTE 150 per year
· Enterprise File Transfer capability updates – NTE 75 per year
· Open source technology evaluations – NTE 24 evaluations per year
· Software updates – NTE 60 per user.
· Feature Enhancements – NTE 24 per year
7. Apply Capability Maturity Model Integration (CMMI) Development (CMMI-DEV) Level 3 (or better)
1. The Big Blue Button is an open source software package in which DCS is built upon. BlindSide is the company that created and developed this software. If a company needs to work with BlindSide in order to be able to perform this task, then that company would need to have a (Technical Assistance Agreement) TAA agreement in place with the State Department due to the fact that BlindSide is a foreign company.
8. The Contractor shall perform the following tasks when it comes to The Big Blue Button1 open software:
A. DCS System Check – Develop an improved DCS “System Check” to evaluate a workstations ability to connect to all DCS capabilities (e.g. Web Conference (HTML5, UDP, etc.), XMPP Chat, Collaboration Portal, and Enterprise File Management). The new system check should be HTML5 based and animated to highlight successful connections to DCS capabilities or at what point (e.g. Workstation, LAN, WAN, or Cloud) the connectivity may be failing or if the user will experience issues (e.g. bandwidth, latency, IP/Port tests, etc.). This feature should be incorporated into the DCS Collaboration Portal.
B. DCS End-to-End Monitoring – Engineer, develop, and integrate tools to enable end-to-end monitoring from the DCS users workstation to DCS servers in the cloud. DCS End-to-End capability should integrate with existing NetOps tools.
C. DCS Web Conference Feature Development
1. Configurable HTML5 Layouts for Web Conference Sessions – Allows users to customize session layout, save & reuse the layout.
2. Multimedia Pod – Gives users the ability to include video and audio clips during the session.
3. Streaming Media Pod – Gives users the ability to stream video from a designated source (e.g. YouTube, MilTube, Live News, etc.)
4. World Clock Pod – Gives users the ability to display a world clock (multiple time zones) for sessions that have participants from multiple time zones (e.g. EUCOM, NORTHCOM, PACOM, etc.).
5. Countdown Timer / Stop watch Pod – Gives users the ability to display a countdown timer or stop watch during the session to coordinate activities.
6. Voice Call Only Layout – Layout for users who only want to host a voice conference. Layout should list the participants and give the moderator the ability to record the session audio.
7. Presenter View Layout – Gives the session presenter the ability to preview the next slide before it is presented to the session participants, slide notes, current slide, desktop share, etc.
8. Network Quality Indicators – Gives the session participants a visual indication of their connection quality to DCS servers.
9. User Connection Statistics – Connection statistics for each user should be collected by the DCS Web Conference server and sent to DCS NetOps servers.
10. User typing indicators – Session chat participants should get an indicator when another participant is typing a message in chat.
11. Audible notifications for when users join / leave the room – Participants should get an audible notification when another participant joins or leaves the room. This feature should be configurable by the session admin / moderator so that the admin / moderator can turn this feature on or off.
12. Secure breakout rooms – DCS Web conference breakout rooms should use secure connections (e.g. TLS 1.2 or greater)
13. Recording of breakout rooms – Web Conference breakout rooms should have the ability to be recorded.
14. Breakout Room Content - Content created in breakout rooms transferred to main room
15. Breakout Room Title Modification – Moderators should be able to change title of break out rooms
16. Session User Tracking – Moderators should be able to know who was present in their room throughout the life of the session and how long they were in the session.
17. Guest User Registration – Guest users should have to “register” on a session-by-session basis by providing Name, Phone Number, E-Mail address. Once user has provided a valid e-mail address the system should e-mail the user to verify that the e-mail is valid. The moderator should then get a prompt to let the user in. This feature should be configurable to allow the moderator (e.g. enable / disable) to decide if they want this level of verification for guest users.
18. Voice-to-Text Conversion – Web Conference sessions should support speech audio to text conversion to support closed captioning. Voice to text capability should leverage open source technology for this capability and not rely on any service external to the DCS cloud environment to provide this capability.
19. Web Conference mobile app – Mobile Users should have a mobile app that optimizes the web conference session experience for mobile devices.
20. Enterprise File Management Integration – Web conference sessions should integrate with enterprise file management capability and allow admins / moderators and presenters to access files being stored by enterprise file management system for use during the session.
21. Session Recording Format – Users should be able to download one MP4 video file instead of an archive.
22. Individual User Pin – Provide capability for web conference sessions and voice call session to support assigning individual PINs to participants.
D. Collaboration Portal Feature Development
1. Invite My Colleagues – Portal users should be able to invite portal colleagues to a session or reservation.
2. Open Sessions – Open meeting should appear in a calendar format.
3. NetOps Integration – Portal should integrate with DCS NetOps tools to provide users a status on DCS capabilities.
4. Session User Tracking – Conference Management system should be able to store session information (e.g. users who attended) each time a reservation is run for a defined period of time.
5. Mass Messaging Module – Module should allow the DCS PMO to send e-mails to all users or a defined set of users.
6. Help Module – Help Module should allow users to submit (via e-mail) a pre-formatted trouble ticket with pertinent information required to kick off the troubleshooting process.
7. Session Recoding Sharing – Moderators should be able to share a recording with all participants who were present in that particular session.
8. Mediated Information eXchange Module – Develop and integrate capability for mediated information exchange.
9. Migrate from EDIPI based username to e-mail based user name. For example, EDIP# would become dod.e.user.civ.
10. Conference Session Summary – Session details (e.g. session user tracking data) should be stored for each reservation in the portal and the moderator has the option to have the details mailed to the session moderator / admin at the conclusion of each session.
11. Training Module – Training module should display training videos on how to use DCS capabilities. Videos should be able to added or deleted by the DCS PMO.
12. Enterprise File Management Integration – Portal should integrate with enterprise file management capability and allow users to access files being managed.
13. Recordings – User should be able to download or stream recordings
14. Individual User PIN – Provide moderators with the ability to give each user an individual pin so that they can be identified during web conference or voice conference sessions. Moderator should have the ability to generate new & random PINs for a user, a group of users, or all users.
15. Chatbot Capability – Integrate chatbot capability into portal to provide answers to questions on DCS capabilities for users.
E. Room-Based Video Conference Capability Development – Leverage open source technologies (e.g. FreeSWITCH) to integrate DCS with room based video conference systems.
F. XMPP Chat Feature Development
1. XMPP Desktop Chat Client - Develop XMPP Desktop Chat Client (e.g. Isode Swift) that supports Voice / Video calls, screenshare, file transfer via enterprise file management capability, improved 508 compliance, escalation to Web Conference, and user typing indicators.
2. Enterprise Chat Federation - Develop enterprise chat federation capability using open source project (e.g. SylkServer)
3. Enterprise Chatbot - Develop Chabot capability using open source Chabot project that will answer user questions and support operational troubleshooting of enterprise capabilities.
G. Collaboration Portal mobile app – Develop Collaboration Portal mobile app.
Deliverable(s):
| PWS Task# |
| Deliverable Title |
| Minimum Requirements |
| Format |
| Distribution/ Copies |
| Submission Due Date |
| 6.5 |
| Software Release Documentation |
| Software documentation outlining features and functions of each software deliverable. |
| Designated format (e.g. MS Word ) |
| Standard Distribution* |
| Draft 10 business days before each deliverable. |
Final 10 business days after each deliverable
| 6.5 |
| Test Plans and Results |
| Conduct, document and deliver test plans and testing results to the Government with each software (SW) build or release. To include: |
· Unit Test
· Integration/System Test
· Volume/Stress Test
· User Test
| Contractor-Determined Format |
| Standard Distribution* |
| Draft 10 business days before each deliverable. |
Final 10 business days after each deliverable
| 6.5 |
| Static Code Analysis Reports |
Static Code Analysis Reports
| Contractor-Determined Format |
| Standard Distribution* |
| With each software deliverable |
| 6.5 |
| Software development and integration |
| Software code and ansbile playbooks for bug fixes to software. |
| Contractor determined (source coded) and Ansible Playbooks |
| Software Forge |
| With each deliverable |
| 6.5 |
| Bug Fixes |
| Software code and ansbile playbooks for bug fixes to software. |
| Contractor determined (source coded) and Ansible Playbooks |
| Software Forge |
| With each deliverable |
*Standard Distribution: 1 copy of the transmittal letter without the deliverable to the Contracting Officer; 1 copy of the transmittal letter with the deliverable to the Primary COR.
6.6 Task 6 - DCS Integration and Operational Support
6.6.1 Subtask 6.1. DCS Integration Support
This subtask is to integrate DCS software solution to ensure products delivered by the developer meet or exceed the Cybersecurity and infrastructure requirements for the production network. The development environment is the responsibility of the contractor.
a. The contractor shall deliver and integrate software in accordance with IAW the Agile Model of the Software Developmental Life Cycle (SDLC) to include:
· Infrastructure and optimizations
· Mil 2.0 or AWS transition
· Shared services optimizations - F5, OCSP, EASF, and DNS
· Infrastructure/Client/server optimizations - NGINX, RED5, REDIS, MySQL, Free Switch, TOMCAT, SWIFT, Openfire, containerization to include Kubernetes and Openshift, multi-site cross site interactions
· Tech Refreshes
· Fully HTML5 capable DCS
· Core updates to the portal, WC, and chat components to include software and enhancements
· Open source component upgrades to include Web conference and Chat Component upgrades, Web conference and Chat Component Upgrades – As required (24 times a year), Open Source technology SW (12 per year), Software Updates – approximately 5 per month (60 per year), Feature Enhancements approximately 2 per month (24 per year),
· Customer Enhancements
· Unified capabilities (voice, video, chat)
· Voice integration for web conference
· Five Eyes (FVEY) Classified Environment chat
· Mobility (web conference, XMPP chat Native App)
· Enterprise chat federation and protocol converter (SylkServer, Nextplane)
· Disconnected Intermittent Low Bandwidth
· Regional DCS
· Additional enhancements to include File Repository
b. The contractor shall deliver and integrate open source component upgrades to include Collaboration Portal, Web Conference, XMPP Chat, Voice, and NetOps tools component upgrades.
· Web Conference updates - NTE 350 per year.
· XMPP Chat updates – NTE 600 per year
· Collaboration Portal updates – NTE 75 per year
· Enterprise File Transfer capability updates – NTE 75 per year
· NetOps Tools (Nagios, Elastic Stack) updates – NTE 150 per year
· Voice Infrastructure updates – NTE 150 per year
· Open source technology evaluations – NTE 24 evaluations per year
· Software updates – NTE 60 per user.
· Feature Enhancements – NTE 24 per year
· Information Assurance Updates – NTE 750 per year
c. The contractor shall ensure the deliverables identified meet 100% delivery.
d. The contractor shall ensure the deliverables are fully tested in the DISA staging environment prior to delivery to the Government.
e. The contractor shall ensure any deliverables not accepted by the Government are corrected within 30 calendar days.
f. The contractor shall ensure any Plan of Action and Mitigation (POA&M) are resolved on or before the date of the Government approved POA&M.
g. The contractor shall apply full SDLC processes to the development effort.
h. The contractor shall apply Capability Maturity Model Integration (CMMI) Development (CMMI-DEV) Level 3 (or better) and CMMI Services (CMMI-SVC) Level 3 (or better) to engineering efforts in support of development and operation of DCS services where applicable.
i. The contractor shall ensure modifications to support Information Assurance Vulnerability Management (IAVM) are corrected on or before the designated suspense date.
j. The contractor shall maintain, document, and update annually the requirements management processes to ensure the integrity of approved baseline requirements.
k. The contractor shall collect validate, and document new requirements in Rational Dynamic Object Oriented Requirements System (DOORS) monthly.
l. The contractor shall establish and document formal software development, code control and build processes for major and minor (patches) releases and fully integrate with Forge.mil, MilCloud, DISA DECC, and DECC infrastructure environments.
m. The contractor shall document and update architecture for integration of the DCS Platform for each upgrade.
n. The contractor shall develop and design the software modules for integration of the DCS Platform.
o. The contractor shall provide an Integrated Development and Test environment that can be accessed by all DCS developers and DCS Government Personnel.
p. The contractor shall update Software Forge artifacts and submit software code and deliverables via designated software development management platform (e.g. Software Forge).
q. The contractor shall integrate, test the software modules, and field DCS for use by the DoD user community. The contractor shall provide the Test Plans and results to include:
1. Unit Test
1. Integration/System Test
1. Volume/Stress Test
1. User Test
1. Regression Test
Deliverable(s):
| PWS Task# |
| Deliverable Title |
| Minimum Requirements |
| Format |
| Distribution/ Copies |
| Submission Due Date |
| 6.6.1 |
| Formal Software Development Processes |
| Establish and document formal software development, code control and build processes for major and minor (patches) releases and fully integrate with Forge.mil, Milcloud, DISA DECC, and DECC infrastructure environments. |
| Contractor-Determined Format |
| Standard Distribution* |
| Draft 30 business days after contract award |
Final 60 business days after contract award and updated annually.
| 6.6.1 |
| Baseline Requirements Management processes (updated annually) |
| Maintain, document, and update annually the requirements management processes to ensure the integrity of approved baseline requirements. |
| Contractor-Determined Format |
| Standard Distribution* |
| 6 months from contract award, updated annually |
| 6.6.1 |
| DOORS New Requirements Documentation (updated monthly) |
| Collect, validate, and document new requirements in Rational Dynamic Object Oriented Requirements System (DOORS) monthly. |
| Contractor-Determined Format |
| Standard Distribution* |
| Monthly |
| 6.6.1 |
| Updated DCS Platform Architectural Documentation |
| Document and develop update architecture for integration of the DCS Platform for each upgrade. |
| MS Word or MS Visio as directed. |
| Standard Distribution* |
| Draft 10 business days before each upgrade |
Final 10 business days after each upgrade
| 6.6.1 |
| DCS Integrated Software modules (in rmps format) |
| Develop and design the software modules for integration of the DCS Platform (24 upgrades and 60 updates per year) |
| RPMs or Ansible Playbooks as directed. |
| Standard Distribution* |
| Weekly |
| 6.6.1 |
| Test Plans and Results |
| Integrate, test the software modules, and field DCS for use by the DoD user community. Provide the Test Plans and results to include: |
· Unit Test
· Integration/System Test
· Volume/Stress Test
· User Test Regression Test
| Contractor-Determined Format |
| Standard Distribution* |
| Draft 10 business days before each upgrade |
Final 10 days after each upgrade
| 6.6.1 |
| Software Development / Integration Updates via Software Forge |
| Software Forge updates |
| Software Forge Artifacts, Software Code, Executables, Playbooks |
Per Software Forge Format
| Software Forge |
| Weekly |
| 6.6.1 |
| Request For Change (RFCs) |
| Request For Change (RFCs) to be reviewed by the DCS Technical Review Board (TRB) Meeting |
| As Directed |
| Standard Distribution* |
| Weekly |
| 6.6.1 |
| Static Code Analysis Reports |
Static Code Analysis Reports
| Contractor-Determined Format |
| Standard Distribution* |
| With each software deliverable |
| 6.6.1 |
| Software development and integration |
| Software code and ansbile playbooks for bug fixes to software. |
| Contractor determined (source coded) and Ansible Playbooks |
| Software Forge |
| Daily |
| 6.6.1 |
| Bug Fixes |
| Software code and ansbile playbooks for bug fixes to software. |
| Contractor determined (source coded) and Ansible Playbooks |
| Software Forge |
| Weekly |
*Standard Distribution: 1 copy of the transmittal letter without the deliverable to the Contracting Officer; 1 copy of the transmittal letter with the deliverable to the Primary COR.
6.7 Reserved
6.8 Reserved
6.9 Reserved
6.10 Reserved
6.11 Reserved
6.12 Reserved
6.13 Reserved
6.14 Reserved
6.15 Reserved
6.16 Reserved
7. Performance Standards.
| Performance Standard |
| Acceptable Quality Level (AQL) |
| Method of Surveillance |
| 6.2 Weekly Activity Reports |
| Materials contain required information and are delivered on time at least 95% of the time. Revisions that occur are minor and are resolved |
| Each deliverable will be reviewed. |
| 6.2 DCS Architecture Documentation |
| Materials contain required information and are delivered on time at least 95% of the time. Revisions that occur are minor and are resolved |
| Each deliverable will be reviewed. |
| 6.2 DCS Engineering Document Repository |
| Materials contain required information and are delivered on time at least 95% of the time. Revisions that occur are minor and are resolved |
| Each deliverable will be reviewed. |
| 6.2 DCS System Engineering Testing and Validation |
| Performance occurs with no required re-performance or re-work at least 95% of the time. Problems that occur are minor and are resolved in a satisfactory manner. |
| Each deliverable will be reviewed. |
| 6.2 System OV-1 and SV 1 |
| Materials contain required information and are delivered on time at least 95% of the time. Revisions that occur are minor and are resolved |
| Each deliverable will be reviewed. |
| 6.2 SoftwareForge Usage Plan |
| Materials contain required information and are delivered on time at least 95% of the time. Revisions that occur are minor and are resolved |
| Each deliverable will be reviewed. |
6.2 Software Forge Updates
6.5 Software Release Documentation
| Materials contain required information and are delivered on time at least 95% of the time. Revisions that occur are minor and are resolved |
| Each deliverable will be reviewed. |
| 6.5 Test Plans and Results |
| Performance occurs with no required re-performance or re-work at least 95% of the time. Problems that occur are minor and are resolved in a satisfactory manner. |
| Each deliverable will be reviewed. |
6.5 Static Code Analysis Reports
| Materials contain required information and are delivered on time at least 95% of the time. Revisions that occur are minor and are resolved |
| Each deliverable will be reviewed. |
| 6.5 Software development and integration |
| Performance occurs with no required re-performance or re-work at least 95% of the time. Problems that occur are minor and are resolved in a satisfactory manner. |
| Each deliverable will be reviewed. |
| 6.5 Bug Fixes |
| Performance occurs with no required re-performance or re-work at least 95% of the time. Problems that occur are minor and are resolved in a satisfactory manner. |
| Each deliverable will be reviewed. |
| 6.6.1 Formal Software Development Processes |
| Materials contain required information and are delivered on time at least 95% of the time. Revisions that occur are minor and are resolved |
| Each deliverable will be reviewed. |
| 6.6.1 Baseline Requirements Management processes (updated annually) |
| Materials contain required information and are delivered on time at least 95% of the time. Revisions that occur are minor and are resolved |
| Each deliverable will be reviewed. |
| 6.6.1 DOORS New Requirements Documentation (updated monthly) |
| Materials contain required information and are delivered on time at least 95% of the time. Revisions that occur are minor and are resolved |
| Each deliverable will be reviewed. |
| 6.6.1 Updated DCS Platform Architectural Documentation |
| Materials contain required information and are delivered on time at least 95% of the time. Revisions that occur are minor and are resolved |
| Each deliverable will be reviewed. |
| 6.6.1 DCS Integrated Software modules (in rmps format) |
| Performance occurs with no required re-performance or re-work at least 95% of the time. Problems that occur are minor and are resolved in a satisfactory manner. |
| Each deliverable will be reviewed. |
| 6.6.1 DCS Integrated Software modules (in rmps format) |
| Performance occurs with no required re-performance or re-work at least 95% of the time. Problems that occur are minor and are resolved in a satisfactory manner. |
| Each deliverable will be reviewed. |
| 6.6.1 Software Development / Integration Updates via Software Forge |
| Performance occurs with no required re-performance or re-work at least 95% of the time. Problems that occur are minor and are resolved in a satisfactory manner. |
| Each deliverable will be reviewed. |
| 6.6.1 Request For Change (RFCs) |
| Materials contain required information and are delivered on time at least 95% of the time. Revisions that occur are minor and are resolved |
| Each deliverable will be reviewed. |
6.6.1 Static Code Analysis Reports
| Materials contain required information and are delivered on time at least 95% of the time. Revisions that occur are minor and are resolved |
| Each deliverable will be reviewed. |
| 6.6.1 Software development and integration |
| Performance occurs with no required re-performance or re-work at least 95% of the time. Problems that occur are minor and are resolved in a satisfactory manner. |
| Each deliverable will be reviewed. |
| 6.6.1 Bug Fixes |
| Performance occurs with no required re-performance or re-work at least 95% of the time. Problems that occur are minor and are resolved in a satisfactory manner. |
| Each deliverable will be reviewed. |
8. Incentives. The Government will positively and/or negatively review the contractor's performance based on the success or failure in meeting Quality Assurance Surveillance Plan objectives. The contractor is incentivized to earn favorable Government reviews to support continuation of DISA work and to support contract awards with other Government agencies seeking DISA's input on the contractor's past performance and the Contract Performance Assessment Reporting System (CPARS). Failure to meet the acceptable quality levels may result in an unsatisfactory past performance report by the Government.
9. Place of Performance and Hours of Operation. Contract performance shall be a combination of Contractor-provided facilities performing unclassified work and all classified work being performed at DISA facilities at DISA HQ, 6910 Cooper Ave, Ft. Meade, MD 20755-7088. Travel in and around the primary place of performance may be required throughout the period of performance. Additional travel within CONUS may be required to support the requirements of this PWS.
0. Local Travel. Travel will be considered local travel within 50 miles of the individual’s main place of performance/duty station and will not be reimbursed. Local travel within the National Capital Region (NCR), to other than DISA HQ, is very limited. Local Travel will not be reimbursed. The government shall not reimburse for travel between the contractor facility (or facilities) and the DISA facility at Ft. Meade, MD.
0. Temporary duty (known as TDY) Travel. Any Government-approved long-distance travel or TDY travel will be a cost-reimbursable direct cost to the resultant contract, and will require pre-approval by the COR. All TDY must be approved by the COR prior to its execution.
0. Alternate Place of Performance - Contingency Only. As determined by the Contracting Officer, contractor employees may be required to work at an alternate place of performance (e.g., home, the contractor's facility, or another approved activity within the local travel area) in cases of unforeseen conditions or contingencies (e.g., pandemic conditions, exercises, government closure due to inclement weather, etc.). Non-emergency/non-essential contractors should not report to a closed government facility. Contractor shall prepare all deliverables and other contract documentation utilizing contractor resources. To the extent possible, the contractor shall use best efforts to provide the same level of support as stated in the PWS. In the event the services are impacted, reduced, compromised, etc., the KO or the contractor may request an equitable adjustment pursuant to the Changes clause of the contract.
0. Work Hours. Core business hours, Monday through Friday. Only exception is Tier 1 support which will require 24X7 support.
0. The contractor will be required to participate and travel to designated locations for coordination, on-site conferences.
0. The contractor is responsible to obtain and pay for any regulatory approvals. This includes initial fee and annual fees for technical assistance agreements, personnel certifications, and any other contractor certifications.
0. If authorized in the Task Order, travel will be reimbursed at actual cost in accordance with the limitations set forth in FAR Subpart 31.205-46, Travel Costs. Profit shall not be applied to travel costs. To the extent authorized by the Task Order, Contractors may apply indirect costs to travel in accordance with the Contractor’s usual accounting practices consistent with FAR 31.2. The OCO must identify a not-to-exceed travel ceiling under a separate CLIN on the Task Order.
10. Period of Performance /ordering period. This single award IDIQ is for a five year ordering period. Orders may be issued against the IDIQ up until the last day of the ordering period. As directed by the Contracting Officer, the contractor shall continue performance in emergency or mission essential conditions. Additionally, the contractor may be required to account for the whereabouts of their personnel should this information be requested by the COR.
11. Security Requirements. This section supplements Block 13 of the Government provided DD Form 254. Contract Security Classification Specification. The following security requirements shall apply to this effort.
References:a. DISA Form 786, DISA Statement of Information System Use and Acknowledgement of User Responsibilities – Basic User
b. DISA Policy Letter, Unauthorized Connections to Network Devices, 11 September 2013
c. DISA Instruction 240-110-8, Information Security
d. DISA Instruction 240-110-36, Personnel Security
e. DISA Instruction 240-110-38, Industrial Security
f. DISA Instruction 240-110-43, Insider Threat Program
g. DISA Instruction 630-230-19, Cybersecurity
h. DoD Manual 5200.01, Vol 1-4 Information Security Program, 24 February 2012
i. DoD Manual 5200.02, Procedures for the DoD Personnel Security Program, 3 April 2017
j. DoD 5220.22-M, National Industrial Security Program Operating Manual, February 2006 Incorporating Change 02 May 2016
11.1 Facility Security Clearance. Work performed under this contract/order is up to the Secret level. Therefore the company must have a final Secret Facility Clearance from the Defense Security Service Facility Clearance Branch.
11.2 Security Clearance and Information Technology (IT) Level. All personnel performing on or supporting a DISA contract/order in any way shall be U.S. citizens. The personnel security requirements for this contract/order cover the individuals supporting the Task Areas delineated in the table below. Contractor personnel must possess the interim or final security clearance and interim or final IT-level eligibility delineated in the table below when performance starts.
| PWS Task / Subtask |
| Clearance Level |
| IT Level Access |
| Level of Classified Access |
| Justification for Access to Classified |
| Task 6.1 |
| Final |
Secret Final
IT– II
Some of the standards being worked on in this task are classified Secret. Access to SIPR Required
| Task 6.2 |
| Final |
Secret Final
IT– I
Tasks and deliverables require access to live systems within the environment
| Task 6.3 |
| Final |
Secret Final
IT– I
Incident investigation will require access to live systems within the environment
| Task 6.4 |
| Final |
Secret Final
IT–II
Some of the standards being worked on in this task are classified Secrete. Access to SIPR Required.
| Task 6.5 |
| Final |
Secret Final
IT– I
Integration of services will require access to live systems within the environment
Task 6.6.1
Final Secret Final
IT– I
Patching of systems will require access to the live environment
| Task 6.6.2 |
| Final |
Secret Final
IT– I
Requires the contractor to access DCS systems on NIPRNet and SIPRNet for the purposes of managing and configuring DCS systems, managing and configuring DCS cloud environments, and understanding and assisting lower tiers in application of cybersecurity controls.
| Task 6.7.1 |
| Final |
Secret Final
IT– I
Access to reporting environment is require to complete tasks
| Task 6.7.2 |
| Final |
Secret Final
IT– I
Access to reporting environment is require to complete tasks
| Task 6.8 |
| Final |
Secret Final
IT– II
Some of the standards being worked on in this task are classified Secret. Access to SIPR Required
| Task 6.9 |
| Final |
Secret Final
IT– II
Some of the standards being worked on in this task are classified Secret. Access to SIPR Required
| Task 6.10 |
| Final |
Secret Final
IT– I
Infrastructure issues will require access to the live environment
| Task 6.11 |
| Final |
Secret Final
IT– I
Tech refresh activities will require access to the live environment
| Task 6.12 |
| Final |
Secret Final
IT– II
Some of the standards being worked on in this task are classified Secret. Access to SIPR Required
| Task 6.13 |
| Final |
Secret Final
IT– I
Implementation of services will require access to the live environment
| Task 6.14 |
| Final |
Secret Final
IT– II
Some of the standards being worked on in this task are classified Secret. Access to SIPR Required
| Task 6.15 |
| Final |
Secret Final
IT – I
Tiered support will require access to the live environment.
11.3 Investigation Requirements. All personnel requiring IT-I access under this contract/order shall undergo a favorably adjudicated Tier 5 (T5) investigation (formerly known as a Single Scope Background Investigation (SSBI)) as a minimum requirement. The T5 will be maintained current within 6-years and requests for Tier 5 reinvestigation (T5R formerly known as Single Scope Background Period Reinvestigation (SBPR) or Phased Periodic Reinvestigation (PPR)) will be initiated prior to the 6-year anniversary date of the previous Tier 5.
11.3.1 Investigation Requirements. All personnel requiring Secret or IT-II access under this contract/order shall undergo a favorably adjudicated Tier 3 (T3) Investigation formerly known as a National Agency Check, Local Agency Check and Credit Check or Access National Agency Check and Inquiries as a minimum investigation. The Tier 3 Investigation will be maintained current within 10-years and requests for Secret Periodic Reinvestigations will be initiated by submitting a Tier 3R investigation prior to the 10-year anniversary date of the previous Tier 3 Investigation.
11.3.2 IT-I access. Contractor personnel that do not meet the investigative requirements for Privileged IT1 access may be granted interim access by the DISA Personnel Security Office (MP62) provided there is no disqualifying information within the adjudicative guidelines that cannot be mitigated. The Personnel Security Specialist (PERSEC) assigned to the organization in which the contractor will be working will initiate a T5 e-QIP (Electronic Questionnaire for Investigation Processing) of which fingerprints will be required. If the contractor has an adjudicated NACLC/ANACI/T3 investigation, upon completion of the T5 review and SAC (fingerprint) results from the FBI (Federal Bureau of Investigation), if there is no disqualifying information, the individual may be granted Interim eligibility/IT1 access. Contract personnel found ineligible for Interim IT1 will not be allowed to support a DISA contract requiring IT1 access nor will MP62 go forward with the T5 Investigation. If, while still on a DISA contract that requires IT1, the contractor is due for his/her PR (Periodic Reinvestigation), DISA will initiate, review and submit the T5R investigation.
11.4 Adjudication for IT-I access. Favorable Adjudication of any previous T5, T5R, SSBI, SBPR or PPR by the DoD Central Adjudication Facility or other federal adjudications facilities within a six year period will be automatically accepted for final IT-I access.
11.4.1 Other requirements. Prior to granting interim IT-I authorization, the supporting security manager will forward a written request for interim IT-I authorization to DISA PSO for approval. The request for SSBI e-QIP, FBI name and fingerprint check must be submitted by DISA PSO to the OPM.
11.5 Visit Authorization Letters (VAL). Visit requests shall be processed and verified through the Joint Personnel Adjudication System (JPAS) to SMO DKABAA10. JPAS visits for contracts/orders are identified as “Other” or “TAD/TDY” and will include the Contract/Order Number and ADP/IT-Access level of the contract/order in the Additional Information section. Contractors that do not have access to JPAS may submit visit authorizations by e-mail in a password protected .pdf to the COR/ACOR specified in Section 1.0.
If JPAS is not available, the VAL must contain the following information on company letterhead
• Company name, address, telephone number, facility security clearance
• CAGE CODE
• Contract/Order Number
• Name, SSN, date and place of birth, and citizenship of the employee intending to visit
• Certification of personnel security clearance and any special access authorizations required for the visit (type of investigation & date, adjudication date & agency, and IT access level)
• Name of COR/Alt COR
• Dates or period the VAL is to be valid
11.5 Security…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .