CODIS_DMSS_RFP_V.14_06242015.docx

REQUEST FOR PROPOSAL (RFP)

DJF-15-0700-PR-0021749

COMBINED DNA INDEX SYSTEM (CODIS) DEVELOPMENT AND

MAINTENANCE SUPPORT SERVICES (DMSS)

Table of Contents

Part I

SECTION A

A.1 SF 33

SECTION B – SUPPLIES OR SERVICES AND PRICES / COSTS

B.1 CONTRACT TYPE

This will be an Indefinite Delivery, Indefinite Quantity (IDIQ) contract awarded in accordance with FAR Part 16.5. To allow flexibility in meeting the future needs of the Government, this IDIQ contract will allow the Government to issue a Task Order using any contract type identified in FAR 16.2, 16.3, and 16.601.

See appendix 1 –VI for specific Quotes to be provided on the TOs identified in the Appendix

B.2 PRICING INFORMATION

This is an IDIQ requirement which will become a single award to a Prime Contractor for work to be performed over (10) ten years, if all options are exercised. Contract type will be identified in either the tables (per contract line item (CLIN)) in attachment 1 and 2 or in the request for quote (RFQ) issued for a respective follow-on TO.

The Offeror will be required to propose, at the IDIQ contract and the TO level, the pricing and the labor rates for the individual labor categories, required meeting this IDIQ requirement. (See Attachment 1 and 2 for tables).

CLIN 0001 Development Labor: This requirement consists of multiple CLINs which will require individual pricing data. (The pricing type for a respective Task Order will be determined by the Government at the time of issuing a TO Request for Quote (RFQ).

CLIN 0002 Maintenance Labor: (The pricing type for a respective TO will be determined at the time of the Government issuing a TO RFQ.

CLIN 0003 COTS Hardware, Firmware, and Software (Pricing will be determined at the time of a RFQ for a task order being issued). If Offeror wishes to propose a service fee (G&A only, no profit) it will be provided as a percentage. This percentage represents the Offeror’s fee above and beyond the Offeror’s actual cost of materials/COTS. This percentage will be considered in the overall price evaluation.

CLIN 0004 Travel Direct Costs (Cost Reimbursable), plus G&A, if proposed. Travel will be reimbursed at actual cost in accordance with the limitations set forth in FAR 31.205-46. Profit shall not be applied to travel costs. Offeror may apply indirect costs to travel in accordance with the Offeror’s usual accounting practices consistent with FAR 31.2. Indirect costs will be incorporated into the pricing. Total pricing will be evaluated for contract award. Travel shall be reimbursed according to the Federal Travel Regulations. All offers will submit a total for travel of $14,000.00 per year. Reminder that the base period is for 24 months and all option periods will be for twelve months.

CLIN 0005 Other Direct Costs, Miscellaneous (Cost Reimbursable), plus G&A, if proposed.

B.3 OFFER

The following table is intended to establish a pricing pool for future TOs to be issued against the single award IDIQ contract. See Appendices 1 through 6 for task orders. Offeror will need to include in their proposal, completed tables (provided as attachment 1 and 2 to this RFP) as part of Volume III. Note, shaded cells in the below table are not to be filled in (leave blank).

Task Order 1

Task Order 2

Task Order 3

Task Order 4

Task Order 5

Task Order 6

Total

B.4. CONTRACT PRICING

The Offeror shall provide detailed pricing (see Attachment 1 (Section J), which will fully define the cost for each CLIN. As it is presumed, no labor will be performed at Government facilities, Offeror shall provide contractor facility rates for requirements identified, or to be identified in future TOs.

B.5. LABOR RATES: CLIN 0001 AND CLIN 0002 PRICING.

The cost for performance shall be reflected separately for each Work Breakdown Structure (WBS) element and be broken down by the labor categories proposed, (see Attachment 1). See Attachment I and 2 for the Instructions for Cost Format submittals. Below TOs are defined as actual, except for TO 4, Maintenance which is a sample TO.

Task Orders pricing (Quotes):

Note: Task Orders are located in Appendixes I through VI and in Section J to this RFP

SECTION C – DESCRIPTION / SPECIFICATIONS / STATEMENT OF WORK

C.1 SCOPE

The scope of this IDIQ RFP covers all types of development and maintenance services to include local, national, and international CODIS-related requirements. The services shall satisfy both current requirements as well as those which may emerge during the life cycle of the IDIQ contract.

C.2 BACKGROUND

CODIS allows forensic laboratories to exchange and compare DNA profiles electronically, thereby linking serial crimes to each other to identify potential suspects by matching DNA from crime scenes to offenders. “CODIS” is both the more generic term used to describe the Government's program of support for criminal justice DNA databases as well as the specific software and telecommunications backbone used to run these databases. CODIS has a three-tier hierarchy of Index Systems; the National DNA Index System (NDIS), State DNA Index System (SDIS), and Local DNA Index System (LDIS). The highest level in the CODIS hierarchy is NDIS which contains the DNA profiles contributed by federal, state and local participating forensic laboratories in the U.S. There are currently over 13 million searchable profiles from 192 NDIS participating laboratories consisting of 137 local DNA index systems and 54 state DNA index sites which include the Government, United States Army, other Federal Agencies and Puerto Rico. In addition, the CODIS software is deployed to over 80 laboratories in over 50 international countries resulting in a sizable customer base of over 290 domestic and international laboratories. The current statistics for NDIS can be found on www.FBI.gov.

The concept behind CODIS is to create a database of the Federal and states’ offender DNA profiles and use it to assist in linking and solving crimes for which there are no identified suspects. CODIS enables Federal, State, and local forensic laboratories to exchange and compare DNA profiles electronically, thereby linking serial crimes to each other and to known offenders. CODIS uses several indices to generate investigative leads in crimes where biological evidence is recovered from the crime scene. The Offender Index contains DNA profiles of individuals convicted, arrested, or detained. The Forensic Index contains DNA profiles developed from crime scene evidence.

In addition, the CODIS software facilitates the identification of human remains through the use of DNA. The National Missing Persons DNA Database (NMPDD) was initially outlined in 1996 and was funded by Congress in 1999. This program facilitates the collection and DNA typing of reference samples from relatives of missing persons which are placed in a database managed by CODIS. This program determines the DNA types of human remains in an attempt to associate those remains to missing persons. The Missing Person Index contains DNA records from missing persons. The Unidentified Human Remains (UHR) Index contains DNA records recovered from unidentified human remains. The Relatives of Missing Person Index contains DNA records voluntarily contributed from relatives of missing persons. The DNA profiles from missing persons and relatives are entered into CODIS for Pedigree Analysis. The goal of Pedigree analysis is to link an unidentified person or UHR to the missing person’s DNA. This is accomplished by generating a DNA profile from some personal item or the DNA from a biological relative. The most common type of DNA profile entered into CODIS is the STR DNA profile; however, a DNA profile cannot always be accomplished using only Short Tandem Repeats (STR) data. In some instances when the UHR are very old or degraded the STR data may not be able to be developed. Analysts are less likely to obtain STR data from older and more compromised UHR. When STR data is limited or unavailable, genetic analysts rely upon mitochondrial DNA (mtDNA) to tie unidentified persons or remains to a biological relative. This functionality was originally developed as Next Generation CODIS (NGCODIS) 6.0.

NGCODIS 7.0 replaced the legacy version of CODIS 5.7.4. The re-architecture of CODIS 7.0 was built upon the CODIS 6.0 framework and graphical user interface (GUI) standards. Due to the demands on the system through additional legislative requirements, expanding user base and the requirement to update legacy code, there was a need to re-architect the system. The CODIS 7.0 architecture is designed to support CODIS searches of the entire database of at least 50 million profiles against itself in 8 hours or less. It continues to support one-time searching, provide data exchange through uploads and messaging and manage data migration from existing systems. CODIS 7.0 completed the development effort initiated with the design of CODIS 6.0. The user friendly GUI, the use of Pedigree trees, and the robust search engine that leverages the Combined Likelihood Ratio solution for ranking and matching specimens to pedigrees has been maintained.

CODIS 7.0 continue to support import and export functions. These include the use of xml files such as Common Message Format (CMF) and Interpol formats that are used as mechanisms for input/output of data into other systems. CODIS 7.0 maintains a sound security posture by ensuring the operating environment is maintained securely through the implementation of FTP-S and the application of operating system/Commercial off the Shelf (COTS) security patches.

Concurrently, improvements in search capabilities and efficiencies will be needed to enable the CODIS database to continue to grow without degradation to search and other performance aspects. For more information about CODIS, please see http://www.Government.gov/about-us/lab/biometric-analysis/codis.

C.3 STATEMENT OF REQUIREMENTS

The purpose of the CODIS Development and Maintenance Support and Services (DMSS) IDIQ contract is to develop, test, deliver, maintain, and support the CODIS Program in accordance with the attached functional, operational, and system requirements.

The requirements listed in this section shall apply to all future TOs and work by CLIN within this IDIQ contract. Any specific additions and/or exceptions will be noted by the Offeror within their IDIQ proposal and each respective TO throughout the execution of the IDIQ contract.

C.3.1 CLIN 0001: Development Requirements C.3.1.1 Development Technical Requirements (CLIN 0001) Specific requirements for the Offeror, as part of their total system performance responsibility include:

1) Perform prototyping and testing with Subject Matter Experts (SME) to develop key user interfaces and work process flows through the software. Facilitate customer input and involvement in all phases of development. For each capability, involve users in the development process via user groups. This may include hands on system/prototype evaluation/feedback, presentation of design concepts, etc. Feedback from user assessments is expected to improve the system. Implementation of user assessment feedback shall be coordinated with the CODIS Program Manager or their designee.

a) Using feedback from CODIS Users and guidance from the CODIS Program Manager (PM), major GUI changes shall be refined from the existing version of CODIS prior to developing substantial portions of the back end.

b) Users will be identified by the Government, (CODIS COR with input from the CODIS PM). Use of Human Factors engineering principles in development is required.

2) Use the current version of the Government Life Cycle Management (LCM) policy and its templates to ensure all required content is included in technical documentation. (Most recent version is defined as the last version distributed within the last 90 days).

3) To ensure the Government workload associated with the development and test of the CODIS software produced is limited, the Offeror’s deliverables will be measured against the Quality Assurance Requirements Section of this RFP.

4) Use and expand the existing CODIS 7.0 architecture. The Offeror will employ current industry accepted interfaces to interoperate and exchange data with current and future authorized information systems.

5) Support the Government and, when defined by the CODIS COR, the Operations Contractor, in preparation for system deployment, installation, data migration, and training activities. The Concept of Operations is provided for reference in Attachment #7 of this IDIQ RFP.

6) Provide the latest (available within the last six (6) months), possible technology upon delivery of a system.

a) Ensure hardware technology advances can be seamlessly incorporated throughout the delivery schedule.

b) Within six (6) months of the release of a new commercial operating system, database, or other third party tool used by or in support of CODIS, Offeror shall evaluate its impact, identify when CODIS will support its use, and advise the CODIS PM as to when the new component can be incorporated into the CODIS software.

c) Incrementally develop multiple CODIS baselines (8.0, 9.0, etc.); assume the development foundation is CODIS 7.0, SP7.

d) Existing CODIS requirements, as represented by CODIS 7.0 SP6, shall be retained. The current development information for CODIS 7.0 SP6 is in Attachments #7-15 of this RFP.

e) The requirements for CODIS 8.0 and 9.0 are described in TO 3 provided as Appendix III of this RFP.

7) Propose an all-inclusive development plan and schedule to satisfy every development objective identified in the IDIQ and respective TOs.

8) The Offeror shall deliver FBI Life Cycle M gate artifacts in support of Government LCM technical assessments and Gate reviews, when defined by the Government CO or COR.

9) Provide for a ten (10) business day review for all deliverables, by the Government PMO, unless otherwise addressed by the CO or the COR.

10) Schedules shall comply with all requirements in Attachment #4 of this RFP.

11) Publish technical support documentation to support domestic and international laboratories in the purchase of hardware or software for installation on their equipment, to include the definition of any network and domain requirements and any limitations to operating CODIS remotely, as part of a centralized data center, or other known operational requirements and/or limitations.

12) The objective shall be to maintain a single fielded software baseline. The current baseline includes standard CODIS, CODIS Prϋm, StandAlone PopStats (SAPS), and CODIS Rapid Workstation (CRW,) as well as DataSet Generator (DSG) and Bulk Export utilities.

a) To support the deployment of new software versions, upgrades/new baselines the Offeror shall:

(i) Maintain backward compatibility with the fielded baseline(s) of the software.

(ii) Be self-installable by the receiving organization (law enforcement laboratories, or other entities when defined), requiring only basic knowledge of computers.

(iii) Offeror shall provide an installation wizard to enable users to upgrade to or install CODIS without onsite support. This shall include but not be limited to database conversions; options transfer, networking information, site configuration data, transfer of user/site defaults, transfer of existing user accounts and associated privileges, etc.

(iv) Provide CODIS Installation Guide to properly manage the software installation. This shall include, but not be limited to new installation and migration instructions, detailed installation instructions with supporting images and graphics, sample/typical deployment configurations, quick start-up for both, new installation and new migration instructions, etc. Working with the Operations Offeror, incorporate feedback and lessons learned in future installation guides.

13) Extend/develop the CODIS architecture to be flexible, scalable and maintainable.

14) The Offeror shall maintain documentation of CODIS databases using tool(s) appropriate for the chosen database. The CODIS Data Model shall be delivered in an easily readable format.

15) When required by the Government, the Offeror shall conduct engineering trade studies to validate engineering tradeoffs at all levels, selection of third party software, major design/development options, etc. The Offeror shall deliver results and recommendations in trade study papers or Decision Analysis Reports (DARs), as defined (specifics and time of delivery) by the CO or CODIS COR.

16) The underlying database, system architecture, and design practices shall:

a) Support efficiency, speed and growth.

b) Fully exploit state of the art computer technology.

c) Enable efficient processing of at least 50 million DNA profiles (all system functionality) with extensibility to 100 million DNA profiles with minor software changes and/or hardware solutions.

17) The design objective of the CODIS architecture shall promote high availability and reduce disaster recovery time. CODIS 8.0 and follow on baselines shall meet or exceed the following performance metrics:

a) 50 million DNA profiles, DNA searched against 50 million DNA profiles in eight (8) hours or less using moderate stringency.

b) One profile searched against 50 million DNA profiles in five (5) minutes or less.

c) 300,000 pedigree trees, containing at least four (4) relatives – no more than two (2) generations from the unknown node, searched against 300,000 unknown human remains in eight (8) hours or less.

d) One (1) pedigree tree, containing at least four (4) relatives – no more than two (2) generations from the unknown node, searched against one (1) million unknown human remains in ten (10) minutes or less.

e) For each baseline, design and implement a hardware suite to function as the NDIS. At a minimum, develop at least one (1) test suite for development system test requirements.

f) Test and Evaluation Requirements.

g) For each baseline, the Offeror will generate the below:

i) Test and Evaluation Master Plan (TEMP) satisfying the LCM TEMP template, which defines formal test events, methodologies, and processes used to support all test activities during the development lifecycle.

ii) Defined test procedures, including all planned test environment specifications.

h) Demonstrate test lifecycle to support all test activities during the CODIS Development & Maintenance (D&M) lifecycle. At a minimum this should include unit, system, integration, and regression test events. During the appropriate test events, installation (both migration and new installation), performance, load, and concurrency testing shall be incorporated.

18) Each test phase during development lifecycle shall include an associated test plan with the following information:

a) Provide traceability of user stories (requirements) to test case(s) and vice versa. These user stories are elaborated from the themes and epics that are targeted for inclusion in the release.

b) Test environment configuration.

c) Installation/data conversion test approach/procedures.

d) Entry/Exit criteria.

e) Software Build List inclusive of Government approved enhancements and defects assigned for validation of the particular test event. Every sprint will include a build report indicating the user stories being delivered for the sprint and a list of known issues (bugs). At the start of the Government Acceptance Test (GAT) sprint, a build report will be provided indicating all relevant user stories being delivered for the current release and a list of all known issues (bugs).

f) Test reports shall be generated for each sprint executed during CODIS development and maintenance (D&M) development lifecycle. Test reports at a minimum should include the following information:

g) Pass/Fail (P/F) status for all test cases, as well as all historical test runs.

h) P/F status for each applicable user story (requirement) based on the associated test case(s).

i) List and status of all defects found, linkage to test case that discovered the defect, and fix/verification audit trail.

j) List of software builds tested during test event.

k) Test issues, constraints, limitations, deviations.

l) Before delivery of a ‘final’ build is submitted for the GAT sprint, the following information should be provided to the Government:

i) Formal System Test Report (including system test cases, environment specifications, test results, and Bugs found/fixed/open).

ii) Finalized list of completed user stories with the traceability to corresponding test case(s).

iii) Draft version of the version Release Notes.

iv) Draft version of the Online Help files.

v) Draft version of the installation kit.

m) Offeror shall document, submit, and maintain documentation for later Government review, the Configuration Change Board (CCB) process including defect classification definitions (as defined by the Government), defect tracking system used, and defect reporting mechanism during and outside of test activities.

n) Documentation includes but not limited to:

i) Meeting invitation (As early as possible).

ii) Read ahead material e.g. agenda items, problem reports, etc. (Minimum of 24 hours in advance of meeting)

iii) Meeting minutes are to be delivered to the Government within ten (10) business days from the CCB.

o) The Offeror shall be able to provide technical support as needed by the Government, during the Government test events particularly. When directed, User Acceptance Testing (UAT) support shall include the ability to remote into GAT and UAT test networks to support installations and defect investigations. Support informal and formal visits of the CODIS PM to Offeror’s facility and/or test lab during test phases.

p) Demonstrate when requested by the CODIS PM that test environment, test plans, software and any other formal test artifacts are under configuration control.

q) Maintain all applicable test cases (system, performance, installation/migration, etc.) to reflect all for emergent software, environmental, and other relevant changes; modified test cases shall be formally delivered to the CODIS COR/PM for review and approval.

r) Provide CODIS D&M online help material in addition to CODIS software with formal delivery to CODIS COR/PM at the start of the GAT sprint.

s) Provide formal CODIS training to participants involved in the Government and User Acceptance Tests for both the Development and Maintenance phases if identified in a task order.

t) Test environment shall mimic the CODIS D&M operational environment including database composition (number of specimens, number of pedigrees, number of matches, number of ranks, etc.), Hardware/Software configurations, and CODIS network. A separate performance test database shall also be maintained by the Offeror for backup and restore during performance testing phases.

u) All data sets used for testing shall be statistically valid DNA profiles.

v) System Testing shall simulate network traffic and bandwidth availability in accordance with the operational network.

w) Offeror shall maintain existing SpecFlow/NUnit automated tests and associated reporting capabilities during the software build process.

x) All automated test software shall be certified by the Offeror for use with all CODIS third party software.

19) Automated Testing Requirements

a) Offeror shall demonstrate recent corporate and staff (within the past year) experience with automated testing (to include writing and running automated test plans).

b) Offeror shall maintain existing CODIS integrated (SpecFlow/NUnit) automated tests and related test reporting (Pickles) capability through software changes to resolve defects.

c) Offeror shall expand from existing automated testing capability, which will be provided by the Government, for developed software changes.

d) Offeror shall deliver all automated test plans developed for CODIS for every release or upon request by the CODIS CO or COR.

20) Configuration Management (CM) Requirements

a) LCM related deliverables shall be in accordance with LCM requirements as outlined in the CODIS D&M Tailoring Guide for IT Governance Gate. A copy of the tailoring guide will be provided to the Offeror after contract award. The latest version of the LCM shall be established at the beginning of a baseline. The current LCM version is 7.0. If there is a new version of the LCM, the Offeror shall adopt and commence using it within 120 calendar days from the release date of the newer version.

b) The Offeror shall address ad hoc configuration management requests and/or data calls from the Government.

c) The Offeror shall conduct Monthly (every thirty (30) calendar days) CM Verification Reviews and internal CM Audits to include the following:

i) Ensure that the product design provides the agreed-to functionality and performance capabilities.

ii) Validate the integrity and quality of all work product deliverables prior to delivery for CODIS PM.

iii) Verify the consistency between the software product and its supporting documentation.

iv) Provide confidence in establishing a product baseline.

v) Determine that adequate CM processes are in place to provide continuing control of established configurations at all phases of the project life-cycle.

vi) Determine number of defects/problem reports broken out per application area (e.g., Specimen Manager, AutoSearcher, Installation, etc.) and by severity.

vii) Quantify number of Configuration Items (CIs) and work products (baselined) that have been checked into the repository in addition to verifying that supporting due diligence artifacts (code review forms, peer review forms, etc.) are checked into the repository at the same time.

viii) All artifacts shall be posted on a web portal to enable ease for the CODIS PM to access and review.

d) Maintain CM repository(s) for source code and project deliverables that is accessible by the CODIS PM via a secure web interface.

e) Develop and maintain CM Plan using the latest version of the LCM template DT-037. LCM 7.0 is the most current version of the LCM for responding to this RFP.

f) Generate CM Metrics on a monthly (every 30 calendar days); basis based on the latest version of the Government LCM requirements for CM and Measurement and Analysis. The Government will review the metrics and advise of specific changes and or format.

g) Support the CODIS PM CM Audits, to be conducted as needed.

h) Develop and maintain all CCB and Change Control records and meeting minutes. Additionally, the Offeror shall follow and adopt the Government’s existing CCB processes and procedures.

i) All meeting minutes shall be available within ten (10) work days of the meeting.

j) Develop quarterly report to:

· Verify that the established CM procedures are adequate to control software changes and document updates on a continuing basis.

· Verify that changes are accurately identified, controlled and tracked to the software as well as associated documentation and software code.

21) Quality Assurance (QA) Requirements for the Offeror to adhere to are below.

a) Track and measure test efficiency (e.g., number of defects detected per sprint, number of escaped/latent defects, test phase detected/phase introduced, defect density ratio) and report monthly as applicable.

b) Track and measure process compliance and report monthly (30 calendar days).

c) Deliver a monthly (30 calendar days) report by the 5th working day of the following month, listing all documentation that has been reviewed along with those documents to be reviewed for the upcoming reporting month. Provide status of items delivered (early, on time or late).

d) Deliver the number of on-schedule deliverables and technical submissions on a monthly (30 calendar days) basis.

e) Provide the number of deliverables and technical submissions releases behind baselined schedule on a monthly (30 calendar days) basis as identified by the below categories.

i) <10 days

ii) >10-20 days

iii) >21-29 days

iv) >30 days

f) Complete review forms for every code or document review and check them into the CM repository within seven (7) business days after each review. When work products are delivered to the CODIS COR, these forms should be delivered as well.

g) Adhere to the latest version of the Government LCM requirements for QA, Verification, and Validation.

h) Generate monthly (30 calendar days) internal and external QA Metrics and demonstrate use of the data collected.

i) Generate QA Lessons Learned on a quarterly basis (based on a calendar year) and recommend process improvements.

j) Support CODIS PM bi-annual (conducted at the end of a six (6) month period), Compliance Audits.

k) Conduct monthly (30 calendar days) internal QA Audits to ensure compliance with defined processes. Post all related documentation on the web portal.

l) Develop and maintain QA Plan using latest version of the LCM template DT-038.

22) For all software deliveries, upgrade and develop all appropriate online help training, instructor led curriculum (to include manuals, workbooks, and presentations), PC machine images for use in instructor-led training classes, user guides, computer based training (CBT), and supporting documentation for CODIS. At a minimum, the following parameters are provided:

a) Except where noted, all training artifacts shall be delivered with the software build for any major release (N.X release or service pack) for Government Acceptance Testing.

b) Upgrade and develop Sharable Content Object Reference Model (SCORM) compliant Computer Based Training (CBT) in Adobe Captivate. The current CBT curriculum consists of roughly 40 distinct training modules, equivalent to approximately 80 hours of training.

c) An objective is to minimize customizations required by the Meridian Global Learning Management System (LMS) used by CODIS to host all CBTs. Coordination with the Operations organization is required for LMS testing and troubleshooting.

d) Additional SCORM compliant CBT packages (annual update or less) shall include:

i) NDIS Eligibility Training (annual update)

ii) System Administrator Training (update when appropriate)

iii) CODIS IT Training (update when appropriate)

iv) Quality Assurance Standards (update when directed)

e) Completion of each CBT module shall only be achieved through successful evaluation. A mechanism to automatically capture and centrally maintain records of training is required. The addition of new training modules shall require little or no software development in the capability that tracks training status for each student.

f) Offeror shall coordinate with the Operations Offeror for LMS testing and troubleshooting of CBTs. Offeror shall coordinate with the Operations Offeror to capture recommended improvements for all training artifacts (at each major release).

g) Note: Ensure the CODIS COR is copied and informed when coordination is being conducted.

h) Develop Instructor-Led Training materials, tutorials or other user help to be available while using the CODIS software.

i) Develop, test, and deliver laptop/PC images with all necessary components and data to support Instructor-Led Training classes; these shall be delivered to the Government within 5 business days of the GAT approval of a major software release

j) Context sensitive help (Online Help) shall be available for all input fields in the CODIS software.

23) Development phases:

a) Develop latest industry standard technical documentation and all development artifacts required by the most current version Government LCM.

b) Maintain complete traceability (forwards and backwards) between user stories and test cases and deliver list to the CODIS COR in accordance with the LCM template. For the Agile SDLC, a Capabilities and Constraints (CaC) shall be created that includes Epics (functional requirements) and business user stories. Demonstrate traceability between user stories and test cases. Test cases should be automated to the greatest extent possible.

c) All technical documentation for a given release, including design documents, specifications, training artifacts, etc., shall be submitted to CODIS COR/ PM with or prior to the first GAT software build.

24) Information Security Requirements. CODIS complies with the following security requirements. CODIS is rated at a moderate security level, as defined in the most recent published Federal Information Processing Standards Publication 199.

a) Overall

i) The Offeror shall meet and/or exceed the security of the CODIS software development and Offeror’s system/network environments according to industry standards, federal and Government guidelines including but not be limited to:

· DOJ IT Security Standards (most recent version)

· NIST SP 800-37, Revision 1, Guide for Applying the Risk Management Framework to Federal Information Systems. (most recent version)

· NIST SP 800-53, Revision 4 Recommended Security Controls for Federal Information Systems and Organizations, Special Publication 800-53. (most recent version)

· Federal Information Security Management Act of 2002, Title III, Pub. L. No. 107-347. (most recent version)

· Federal Information Processing Standard (FIPS) Publication 140

· FIPS Publication 199 (most recent version)

· FIPS Publication 200 (most recent version)

i) The Offeror shall take all actions necessary to protect information regarding security issues and associated documentation, to help limit the likelihood that vulnerabilities in CODIS software or system and their system/network environments are exposed.

ii) The Offeror shall support all aspects of the Government’s Certification and Accreditation (C&A) process and implement required security features in the software development of CODIS, the Offeror’s system/network environments to include systems that access the CJIS WAN/SEN, and the processing and transmission of “Unclassified//For Official Use Only/Law Enforcement Sensitive” data.

iii) The Offeror shall perform application and hardware Security Technical Implementation Guidelines (STIGs), patches, and updates, as needed and as required under Federal and Government guidelines.

iv) The Offeror shall use at all times the highest applicable industry and Government standards for sound secure software development and system/network protection practices to resolve critical security issues as quickly as possible. The "highest applicable industry and Government standards" shall be defined as the degree of care, skill, efficiency, and diligence that a prudent person possessing technical expertise in the subject area and acting in a like capacity would exercise in similar circumstances.

v) The Offeror staff will be required to take Government required annual InfoSec training (within the defined time identified by the CODIS COR) and provide documentation (certificates) to demonstrate completion.

b) Vulnerabilities, Risks, and Threats

i) The Offeror shall strive to identify vulnerabilities, risks, and threats as early as possible at any time during the software lifecycle. The software lifecycle shall mean following the Government’s LCM most recent process.

ii) The Offeror shall identify all risks to the important assets and functions in support of CODIS. The Offeror shall conduct an analysis of all software errors, common programming errors, system/network vulnerabilities, risks, and threats, and document in writing that they have been mitigated and how they were mitigated. The Offeror shall conduct risk assessment(s) to determine and prioritize risks, enumerate vulnerabilities and understand the impact that particular attacks might have on the CODIS software/system and the Offeror’s development environment(s) to ensure it meets applicable contractual obligations, federal and Government regulatory mandates and security best practices and standards. The Offeror shall utilize most recent best practices and tools to perform this requirement. The Offeror needs to define the best practices, standards and tools they recommend or use.

iii) The Offeror shall provide the CODIS COR/PM in writing all security-relevant information regarding the vulnerabilities risks and threats to the CODIS software/system application during development; development testing; and the Offeror’s system/network environment(s) immediately and completely upon identification. Such security documentation shall describe security design, risk analysis, or issues.

iv) The Offeror shall provide written documentation detailing their application development, patch management and update process. The documentation shall clearly identify the measures that will be taken at each level of the process to develop, maintain and manage the CODIS software securely and Offeror’s system/network environments.

v) The Offeror shall provide secure configuration guidelines that describe completely all security relevant configuration options and their implications for the overall security of the CODIS software/system and Offeror’s system/network environments. The guideline shall include a full description of dependencies on the supporting platform, including operating system, application server, hardware components, etc., and how they should be configured for security. The default configuration of the CODIS software and Offeror’s system/network environment(s) shall be secure.

vi) The Offeror shall comply with industry, federal and Government standards and level of care. The Offeror shall provide written documentation to the Government that clearly explains the design for achieving each of the security requirements. The Offeror shall provide and follow a set of secure coding guidelines and best practices. These guidelines will indicate how code should be formatted, structured, and commented. All relevant code shall be thoroughly commented. Specific guidance on avoiding common security vulnerabilities shall be included. Also, all code shall be reviewed by at least one other Developer against the security requirements and coding guideline before it is considered ready for test.

c) Development Environment(s)

i) Secure Coding and Environment: the Offeror shall disclose what tools are used in the software development environment to encourage secure coding and vulnerability tools used to secure the Offeror’s system/network environments.

ii) Configuration Management: the Offeror shall use a source code control system that authenticates and logs the team member associated with all changes to the software baseline and all related configuration and build files.

iii) Distribution: the Offeror shall use a build process that reliably builds a complete distribution from source. This process shall include a method for verifying the integrity of the CODIS software delivered to the Government.

iv) Disclosure: the Offeror shall document in writing all third-party software used in the development of CODIS, including all libraries, frameworks, components, and other products, whether commercial, free, open-source, or closed-source.

v) Evaluation: the Offeror shall make reasonable efforts to ensure that third party software meets all applicable federal and Government guidelines, processes, and procedures.

vi) Data Protection: The Offeror shall develop and maintain a Contingency Plan. The Offeror shall provide failover/system back-up processes (with provision for off-site back-up) and disaster recovery procedures for all systems within their environments within the defined contingency planning objectives. Provide evidence of restoration in the event of an emergency situation.

d) Development Testing Prior to Government Acceptance Testing, the Offeror shall perform the following:

i) General: the Offeror shall provide and follow a security test plan that defines an approach for testing or otherwise establishing that each of the security requirements has been met. The level of rigor of this test process shall be detailed in the plan. The Offeror shall implement the security test plan and provide the test results to the Government.

ii) Source Code: throughout the CODIS development lifecycle process, the Offeror shall ensure that the source code is evaluated to ensure the requirements of this contract including the security standards, policies and best practices are followed. The Offeror shall have a well-documented procedure and framework for conducting code reviews. The Government reserves the right to review the procedure and framework for conducting code reviews

iii) Vulnerability and a Penetration Test: the Offeror shall perform vulnerability and penetration testing prior to each GAT release.

e) The Offeror shall propose and provide security scanning tools in addition to using Government Furnished Equipment (GFE) AppDetective and Tenable Nessus tools to perform required security scans (with the most current signature files) to verify that the system has not been compromised during all Test sprints and prior to GAT release. The Offeror shall provide written documentation of the results of the scans and tests along with a mitigation plan.

f) The Offeror shall track all security issues uncovered during the CODIS development LCM process. The risk associated with each security issue shall be evaluated, documented, and reported to the Government as soon as possible after discovery.

g) Patches and Updates

h) In compliance with DOJ/Government guidelines, processes, mandates, and procedures, the Offeror shall install, test, and evaluate third-party, platform specific, Microsoft, etc. updates for CODIS functionality and operability as required. The Government shall require the Offeror to install, test, and evaluate software updates for immediate compliance and functionality.

i) The Offeror shall provide notification of patches and updates affecting security within the CODIS application as identified throughout the most current Government LCM process.

ii) The Offeror shall apply, test, and validate the appropriate patches and updates and/or workarounds on a test version of the CODIS application before distribution to GAT.

iii) The Offeror shall verify and provide written documentation that all updates have been tested and, prior to GAT release.

i) The Offeror shall verify application functionality, based upon CODIS software baselines, at the conclusion of updates (third-party, platform specific, etc.), and provide documentation of the results.

j) Security Acceptance

k) The Offeror shall provide a "certification package" consisting of the security documentation created throughout the development process. The package shall establish that the security requirements, design, implementation, and test results were properly completed and all security issues were resolved appropriately.

i) The Offeror shall resolve all security issues that are identified before delivery to the Government. Security issues discovered after delivery shall be handled in the same manner as other bugs and issues as specified in this Contract.

ii) The Offeror shall designate a single security contact that shall certify in writing that the CODIS software meets the security requirements, all security activities have been performed, and all identified security issues have been documented and resolved. Any exceptions to the certification status shall be fully documented with the delivery.

iii) The CODIS software shall not be considered accepted until the Offeror certification package is complete and critical security issues have been resolved.

25) Offeror Data Center Requirements

a) Offeror shall provide a data center facility with properly equipped infrastructure, utilities and management tools required supporting new and if provided, Government furnished equipment hardware. The data center facility shall be at a minimum Tier 2 level (as defined by the Uptime Institute).

b) Offeror shall provide and support data center related environmental and infrastructure elements (e.g., equipment racks, HVAC, UPS, power, cable plant, fire detection and suppression systems, temperature and humidity controls, and controlled physical access).

c) Offeror shall…