Draft_RFP_SBEAS.pdf

DEPARTMENT OF THE AIR FORCE

BUSINESS AND ENTERPRISE SYSTEMS DIRECTORA

MAXWELL AIR FORCE BASE GUNTER ANNEX A

23March2017

Draft Request for Proposal (Rtr'P) for Small Business Enterprise Application Solutions (SBEAS) Indefinite Delivery Indefinite Quantity (IDIQ) Contract

FA817t-17-R-1000

This requirement is a total small business set-aside, issued in accordance with Federal Acquisition Regulations (FAR) Part l5-source Selection.

This effort will consist of a five (5) year base period and two five (5) year option periods; the second option year is reserved for performance ONLY.

The following documents are provided as Section J attachments to the draft RFP.

1. Staternent of Objectives (SOO)

2. Instructions to Offerors GTO)

3. Evaluation Criteria

4. Cross Reference Matrix (CRM)

5. Technical Verification Form (TVF)

6. Self-Scoring Workbook

7. Past Performance Questionnaire

8. Definition of Terms

9. Contract Data Requirements List (CDRL)

10. Intent to Bid Letter

The anticipated acquisition schedule is as follows:

a. Draft RFP Questions Due

b. RFP Release

c. Contract Award

This draft RFP is not authorizati,on to begin performance, and in no way obligates the Government for any costs incurred by the contractor for this requirement. Prior to commencement of any activities associated with performance of this requirement, the Govemment will issue a written directive or contractual document signed by the Contracting Officer with appropriate consideration established.

Questions regarding this draft RFP AI{D the intent to bid letter shall be submitted via email to both the Contracting Officer, Shaneka Brown at shaneka.brown@us.af.mil and the Contract Specialist, Britney Jenkins, at britnev.ienki for oues p.m. (CSD 14 April2017.

14 April?}l7 IluJy 2017 December 2017 y(qr,,,^- Shaneka K. Brown Contracting Officer

DRAFT

Attachment 1

FA8771-17-R-1000

STATEMENT OF OBJECTIVES (SOO)

FOR

SMALL BUSINESS ENTERPRISE APPLICATION SOLUTIONS (SBEAS)

1. Purpose

The purpose of this Indefinite Delivery/Indefinite Quantity (ID/IQ) Contract is to provide a vehicle for customers to access a wide range of Information Technology (IT) Network Centric services and solutions that support the IT lifecycle. While the SBEAS contract is specifically established within the Business Enterprise System (BES) Directorate, this contract vehicle may be used by all other agencies that support an Air Force requirement.

2. Scope

The scope of this ID/IQ includes the comprehensive suite of IT services and IT solutions to support

IT systems and software development in a variety of environments and infrastructures. Additional IT services include, but are not limited to, documentation, operations, deployment, cybersecurity, configuration management, training, commercial off-the-shelf (COTS) product management and utilization, technology refresh, data and information services, information display services and business analysis for IT programs.

3. Technical Objectives

The objectives identified within this SOO are described in general terms. Each task order will address specific requirements, project scheduling, and other related performance criteria, as applicable. In accordance with AF and DoD standards, Contractors shall provide IT solutions that operate in Network Centric enterprise environments and exploit approved infrastructures.

3.1 Life-Cycle Software Services

Life-cycle Software Services include but are not limited to:

3.1.1 Project management

3.1.2 Systems engineering, including technical and technical management processes

3.1.3 System architecture and design documentation

3.1.4 Technical solution design, creation, and implementation from a defined business process, user stories, or business use cases

3.1.5 Software development using various methodologies to include Agile, Prototype, Rapid, Dynamic, Lean, Spiral, and Waterfall. Agile is the preferred methodology

3.1.6 Information/web services development and information/web services testing to include Service-Oriented Architectures

3.1.7 Mobile or other Internet of Things (IoT) devices applications development

3.1.8 Information Display Solutions and Services, including but not limited to, mashups, dashboards, portals, and rich internet applications (RIA)

3.1.9 Database development or conversion

3.1.10 Information assurance/Cybersecurity to include Risk Management Framework (RMF) or DoD Information Assurance Certification and Accreditation Process (DIACAP)

3.1.11 Build, testing, implementation and integration

3.1.12 Data or system migration

3.1.13 Administration of applications, systems, databases and interfaces to include system performance monitoring, tuning, provisioning and configuration management

3.1.14 Modifications to the Form, Fit, Function, or Interface (F3I) of an in-service, configuration-managed or produced Configuration Item (CI)

3.1.15 Technology refresh, software or hardware upgrades

3.1.16 Software modernization or re-engineering

3.1.17 Decommission planning and execution

3.2 Supporting IT Services

Supporting IT services objectives include, but are not limited to:

3.2.1 Data and Information Services

3.2.2 IT Business analysis and Functional Business Area Expertise (FBAE) for business process areas to include, but not limited to, contracting, finance, medical, logistics, personnel, communications, transportation, civil engineering, munitions, infrastructure and operations

3.2.3 Service desk, field and technical support to include access management, event management, incident management, problem management, and request fulfillment

3.2.4 Customer and user training

3.2.5 Creating and updating system documentation

3.3 Supporting Systems Within Various Computing Environments

Provide development and supporting IT services and solutions within environments including:

3.3.1 AF-owned

3.3.2 DISA-operated

3.3.3 Commercial, Non-commercial and Hybrid Cloud environments

3.3.4 Mobile devices

3.3.5 Other DoD-approved common operating environments

3.4 General Objectives

Other general requirements include:

3.4.1 Meet Cybersecurity and privacy requirements as defined by all AF and DoD policies, as amended as applicable.

3.4.2 Apply disciplined/best practices for systems engineering process optimizations.

Each contract holder is required at the time of contract award to have Capability

Maturity Model Integration (CMMI) Development Level 2 or higher.

Certification shall be maintained throughout the life of the contract.

3.4.3 Generate necessary design and implementation artifacts that will support lifecycle management of each solution developed or service provided.

3.4.4 Develop and provide all data in accordance with the data right clauses and as identified in each task order.

3.4.5 Use only Government-off-the-Shelf (GOTS) tools, approved Commercial-off-the-

Shelf (COTS) tools or approved Free and Open Source Software (FOSS) for systems design and development, or incorporation into system solutions, in accordance with AF and DoD Standards.

3.4.6 Support the Government in demonstrating audit readiness by responding to agency audits, inspections, and product assessments (i.e., monitoring/inspection/auditing of

IT regulated activities to ensure compliance).

3.4.7 Supply work breakdown structure (WBS), integrated master schedule (IMS), and transition plans as defined at the task order level.

3.5 Program Management Objectives

Identify a Program Manager (PM) who shall be the primary representative responsible for all work awarded under this contract, participating in Program Management Reviews (PMR) and ensuring all standards and requirements referenced herein are adhered to. The SBEAS Program conducts a maximum of one (1) mandatory PMR per fiscal year held in a Government facility at a location that might require overnight travel. A PMR may alternatively be conducted via a virtual webinar when resources for facilities or travel are not available to the Government.

3.5.1 Ordering Authority

The SBEAS Program will utilize a control number process for all requests for proposal (RFP) or request for quote (RFQ) on this contract. RFPs and RFQs are only valid if they include a control number. No decentralized orders shall be placed by DoD and other Federal Agencies without an assigned SBEAS control number.

3.5.2 Task Order Management and Status Reporting

Establish and maintain a documented set of disciplined, mature, and continuously improving processes for administering all task order efforts. All information for overall task order reporting will be submitted via a contract data requirements list (CDRL). This monthly CDRL will include but not be limited to; new task orders, modifications to existing task orders, RFQ submissions, order status updates, service descriptions, payment amounts/dates by CLIN, and DFAS invoices. (CDRL A001)

3.5.3 Earned Value Management (EVM)

EVM may be required at the task order level. If required, each individual task order will provide specific requirements for EVM.

4. Other Considerations

4.1 Security

The ID/IQ will support the following levels of security: Unclassified; Unclassified, But Sensitive;

Secret (S); Secret Sensitive Compartmented Information (S/SCI); Top Secret (TS); and Top Secret

Sensitive Compartmented Information (TS/SCI).

Task orders may require personnel security clearances up to and including Top Secret and may require all employees to be United States citizens. The security clearance requirements will depend on the security level requirements at the task order level. The task orders may also require access to sensitive compartmented information (SCI) for which SCI eligibility will be required.

Individuals performing work under task orders shall comply with applicable program security requirements as stated in the task order. Contractor personnel shall be required to have the appropriate level of investigation and/or security clearance for each agency and information system as applicable at the task order level prior to performing services under the task order. All costs associated with obtaining/possessing such security clearances are the responsibility of the

Contractor.

All Contractors located on military installations shall also comply with Operations Security

(OPSEC) requirements as set forth in DoD Directive 5205.02, Operations Security Program and

AFI 10-701, Operations Security. In accordance with DoD 5200.2-R, Personnel Security

Program (Jan 87), DoD military, civilian, consultants and contractor personnel using unclassified automated information systems, including e-mail, shall have, at a minimum, a completed favorable National Agency Check plus Written Inquiries (NACI).

4.2 North American Industry Classification System (NAICS)

The NAICS code for this acquisition is 541511: Custom Computer Programming Services. This

U.S. industry comprises establishments primarily engaged in writing, modifying, testing, and supporting software to meet the needs of a particular customer. This NAICS Code is revenue based at $27.5M. All Contractors shall be certified as a small business under this NAICS code prior to contract award.

4.3 Limitation of Subcontracting

In performance of services awarded, at least 50% of the cost of task order performance incurred for personnel shall be expended by the SBEAS Prime Contractor. FAR 52.219-14, Limitations on

Subcontracting, will be monitored and strictly enforced.

The Contractor shall specifically identify the total Prime and Subcontracted labor dollars combined and the total labor dollars Subcontracted separately in each invoice submitted under SBEAS task orders. (CDRL A002)

4.4 Small Business Recertification

Each contract holder under this ID/IQ shall recertify under the 541511 NAICS Code used for this contract award. Recertifications shall be completed 120 days before the end of the base period and every year thereafter. Any Contractor who cannot recertify as a small business, will be removed from the contract. However, if a Contractor has been awarded task orders and the task order period of performance has not ended, the Government will exercise the Contractor’s remaining option periods for the purpose of task order performance completion only. The Contractor shall not, however, be awarded any new contract actions under the contract and the contract will be terminated for convenience once task order performance is completed.

4.5 OnRamp

The Government intends to establish an awardee pool under the SBEAS effort by competitively awarding multiple-award ID/IQ contracts. The Government reserves the right to reopen competition at any time during the term of the contract to add additional Contractors to the original pool of awardees.

When reopening competition, the Government will advertise via Federal Business Opportunities

(FedBizOpps) and conduct a full and open competition to bring the awardee pool up to the initial awardee pool. Any awardee already in the awardee pool will not recompete for an awardee pool position. The On-Ramp competitions will use the same evaluation methodology and documentation (updated to reflect changes in regulatory provisions and commercial practices and certifications) as the original competition.

Once a new awardee is selected, that awardee will be included in the awardee pool and will compete for future task orders. The ordering period for new Contractors being added to the initial awardee pool will coincide with initial awardees ordering period, inclusive of options, but shall not extend the overall term of the contract beyond the original ordering period nor shall it reestablish the contract base period, inclusive of options.

4.6 Potential Places of Performance

It is anticipated that there may be task orders under this contract for work within and outside of the

United States. The specific place of performance will be identified at the task order level. For the purposes of this ID/IQ, Contiguous United States (CONUS) means the 48 contiguous States and the District of Columbia, and OCONUS means outside of the contiguous United States to include the Non-Foreign OCONUS Area (the states of Alaska and Hawaii, the Commonwealths of Puerto

Rico and the Northern Mariana Islands, Guam, and U.S. territories and possessions).

4.7 Other Direct Costs (ODCs)

ODCs will be addressed at the task order level. ODCs will be paid on a reimbursable basis. No profit, fee, G&A, or overhead will be paid.

4.8 Travel

Travel requirements will be addressed at the task order level. Costs associated with Contractor travel shall be in accordance with FAR Part 31.205-46, Travel Costs. Travel will be reimbursed on a cost reimbursable basis; no profit, fee, G&A or overhead will be paid.

4.9 Organizational Conflicts of Interest (OCI)

FAR 9.5 Organizational and Consultant Conflicts of Interest, prescribes responsibilities, general rules, and procedures for identifying, evaluating, and resolving organizational conflicts of interest;

provides examples to assist contracting officers in applying these rules and procedures to individual contracting situations; and implements section 8141 of the 1989 Department of Defense

Appropriation Act, Pub. L. 100-463, 102 Stat. 2270-47 (1988).

The general rules in FAR 9.505-1 through 9.505-4 prescribe limitations on contracting as the means of avoiding, neutralizing, or mitigating organizational conflicts of interest that might otherwise exist in the stated situations. Conflicts may arise in situations not expressly covered in

FAR section 9.505 or in FAR section 9.508. Each individual contracting situation should be examined on the basis of its particular facts and the nature of the proposed contract. The exercise of common sense, good judgment, and sound discretion is required in both the decision on whether a significant potential conflict exists and, if it does, the development of an appropriate means for resolving it.

In the event that a task order requires activity that would create an actual or potential conflict of interest, the procedures in FAR 9.506 Procedures, are applicable to resolving such conflict.

5. Period of Performance (PoP)/Ordering Period

5.1 Period of Performance

The PoP for the SBEAS contract is defined as the time period the overarching IDIQ is available for performance to continue for all the task orders issued under the contract. The SBEAS contract PoP is a total of 15 years from date of contract award. The PoP is broken out as follows: a five (5) year base period and two 5-year option periods, if exercised. Option period two is a non-ordering option and is for the continued performance of task orders only.

5.2 Ordering Period

The ordering period for this contract is 10 years. The ordering period for the SBEAS contract is defined as the time period that a task order award can be issued under this contract. Each ordering agency shall specify the PoP for each task order awarded under this contract. Task orders must be solicited and awarded prior to the SBEAS ordering period expiring and may extend up to 5 years after the SBEAS ordering period expires.

6. Data Deliverables

The Contractor shall provide reports identified below.

1. CDRL A001: Task Order Status Report (TOSR): No reference

2. CDRL A002: Limitation of Subcontracting: No reference

DRAFT

http://farsite.hill.af.mil/reghtml/regs/far2afmcfars/fardfars/far/09.htm#P665_119008 http://farsite.hill.af.mil/reghtml/regs/far2afmcfars/fardfars/far/09.htm#P686_123711 http://farsite.hill.af.mil/reghtml/regs/far2afmcfars/fardfars/far/09.htm#P659_117582 http://farsite.hill.af.mil/reghtml/regs/far2afmcfars/fardfars/far/09.htm#P717_129579

7. Reference Documents

Individual task orders may impose additional standards to those required at the contract level.

A list of certifications, specifications, standards, policies and procedures that may be placed on individual task orders may be found under the AF Standards of Excellence header at:

http://www.netcents.af.mil/Contracts/NETCENTS-2/AppSrvs/Documents/

The most current version of the document at the time of task order issuance will take precedence.

http://www.netcents.af.mil/Contracts/NETCENTS-2/AppSrvs/Documents/

Attachment 2

Section L Instructions to Offerors

1.0 General Instructions

(a) Only one (1) proposal may be submitted by each offeror in response to this requirement. The proposal submitted in response to this requirement shall be in compliance with the Request for Proposal (RFP).

The offeror's proposal shall include all data and information requested by this Instructions to Offerors

(ITO) and shall be submitted in accordance with these instructions. Non-conformance with the instructions provided in this ITO may result in an offeror’s proposal being rejected from the competition.

(b) The proposal shall be clear, specific, and shall include sufficient detail for effective evaluation and for substantiating the validity of stated claims. Legibility, clarity, and coherence are very important.

Your responses will be evaluated against the Technical and Past Performance criteria defined in Section

M for Award. All the requirements specified in the solicitation are mandatory. The proposal should not simply rephrase or restate the Government's requirements but rather shall provide convincing rationale to address how the offeror’s proposal meets these requirements. The offeror shall assume that the

Government has no prior knowledge of the offeror’s facilities and experience and will base its evaluation on the information presented in the offeror's proposal. By your proposal submission, you are representing that your firm will perform all the requirements specified in the solicitation. It is not necessary or desirable for you to tell us so in your proposal.

(c) Elaborate brochures or documentation, binding, detailed art work, or other embellishments shall not be submitted with the offeror’s proposal.

(d) The completion and submission of all proposal volumes constitutes the offeror's acceptance of the terms and conditions in this RFP and in any attachments hereto. Proposals will be considered late IAW

FAR 15.208 if they are not received by the date specified in this ITO.

(e) In accordance with FAR Subpart 4.8 (Government Contract Files), the Government will retain the original copy of all unsuccessful proposals. Unless the offeror requests otherwise, the Government will destroy extra copies of such unsuccessful proposals.

Offerors are advised that teaming is not being evaluated at the ID/IQ level. Offerors may submit technical experience and past performance as a prime, subcontractor and/or joint venture. Once contract award has been made, all awardees are allowed to form teams as necessary at the task order level.

Proposal Submission

Submission of Hard Copy Proposal Volumes

One hard copy of the proposal shall be clearly marked, addressed, and mailed or hand-carried to the

Procuring Contracting Officer (PCO) at the below address no later than TBD (CST):

SHANEKA K. BROWN, PCO, SBEAS

AFLCMC HIK

501 EAST MOORE DR.

BLDG 884, SUITE 1400M

MAXWELL AFB - GUNTER ANNEX, AL 36114

Submission of Electronic Proposal Volumes

One copy of the proposal shall be submitted electronically by uploading a copy into the Army’s Safe

Access File Exchange (SAFE) at https://safe.amrdec.army.mil/safe/Welcome.aspx no later TBD

(CST).The content and page size of electronic copies must be identical to the hard copies. Use separate files to permit rapid location of all portions, including sub-factors, exhibits, annexes, and attachments, if any. The electronic copies of the proposal shall be submitted in a format readable by Microsoft (MS)

Office 2010 or later.

In the event that there are any discrepancies between the hard copies and the electronic copies of the proposal, the hard copies will be used for evaluation.

Proposal Validity

The offeror shall make a clear statement in each proposal volume that the proposal is valid for a period of not less than 180 days from receipt.

1.1 General Information

Point of Contact

Ms. Shaneka K. Brown, PCO - SBEAS, is the point of contact for this acquisition. Written requests for clarification may be sent via e-mail to the PCO at shaneka.brown@us.af.mil with a copy to the Contract

Specialists, Britney Jenkins at britney.jenkins@us.af.mil and Thomas Corum at thomas.corum@us.af.mil.

Joint Venture Agreements

Joint Ventures (JV) including Mentor Protégé JVs are allowed to submit a proposal in response to this solicitation; however, the joint venture agreement must be established prior to proposal due date.

Debriefings

Pre-award Debriefing of Offerors: IAW FAR 15.505, Offerors excluded from the competitive range or otherwise excluded from the competition before award may request a debriefing before award. The offeror may request a pre-award debriefing by submitting a written request for debriefing to the PCO within three (3) days after receipt of the notice of exclusion from the competition. At the offeror’s request, this debriefing may be delayed until after award. If the debriefing is delayed until after award, it shall include all information normally provided in a post-award debriefing. If the offeror does not submit a timely request, the offeror need not be given either a pre-award or a post-award debriefing.

Offerors are entitled to no more than one debriefing for each proposal. The PCO shall make every effort to debrief the unsuccessful offeror as soon as practicable, but may refuse the request for a debriefing if, for compelling reasons, it is not in the best interest of the Government to conduct a debriefing at the requested time.

Post-award Debriefing of Offerors: An offeror, upon its written request received by the agency within three (3) days after the date on which that offeror has received notification of contract award in accordance with 15.503(b), shall be debriefed and furnished the basis for the selection decision and contract award. To the maximum extent practicable, the debriefing should occur within five (5) days after receipt of the written request. Offerors that requested a post-award debriefing in lieu of a pre-award debriefing, or whose debriefing was delayed for compelling reasons beyond contract award, also

DRAFT

https://safe.amrdec.army.mil/safe/Welcome.aspx mailto:shaneka.brown@us.af.mil mailto:britney.jenkins@us.af.mil should be debriefed within this time period. An offeror that was notified of exclusion from the competition, but failed to submit a timely request, is not entitled to a debriefing.

Discrepancies

If an offeror believes that the requirements in these instructions contain an error, omission, or are otherwise unsound, the offeror shall immediately notify the PCO in writing with supporting rationale, as well as the remedies the offeror is asking the PCO to consider as related to the omission or error.

Electronic Reference Documents

Official RFP documentation, including RFP amendments, and other related information will be available via Federal Business Opportunities (FedBizOpps) at https://www.fbo.gov/.

Communications

Exchanges of source selection information between Government and offerors will be controlled by the

PCO, therefore all questions or concerns shall be submitted to the PCO. Email will be used to transmit source selection information to offerors only. Offerors’ emails will include “Source Selection

Information – See FAR 2.101 & 3.104” in the Subject line.

1.2 Organization/Number of Copies/Page Limits

The offeror shall prepare the proposal as set forth in the Proposal Organization Table (Table 1.2 below).

The titles and contents of the volumes shall be as defined in this table, all of which shall be within the required page limits and with the number of copies as specified in Table 1.2. The contents of each proposal volume are described in the ITO paragraph as noted in the table below:

Table 1.2 - Proposal Organization

VOLUME ITO Paragraph

Number

VOLUME TITLE COPIES PAGE LIMIT

I 2.0 CMMI Development

Certification

1 Original Hard Copy and 1 Digital Copy

No Page

Limit

II 3.0 Technical Experience 1 Original Hard Copy and 1 Digital Copy

20 Pages

Total

III 4.0 Past Performance 1 Original Hard Copy and 1 Digital Copy

25 Pages

Total

IV 5.0 Contract Documentation 1 Original Hard Copy and 1 Digital Copy

No Page

Limit

1.2.1 Page Limitations

Page limitations shall be treated as maximums. If exceeded, the excess pages will not be read or considered in the evaluation of the proposal. Each page shall be counted except the following; any

Cover Sheets, Table of Contents, Cross-Reference Matrix (CRM), security control artifacts, Tabs, Glossaries of terms/abbreviations/acronyms and matrices.

1.2.2 Page Size and Format

Page size shall be 8.5 x 11 inches, not including foldouts. Pages shall be single-spaced. Except for the reproduced sections of the solicitation document, the font size shall be no less than Times New Roman ten (10) point. Use at least 1- inch margins on the top and bottom and ¾-inch side margins. Pages shall

DRAFT

https://www.fbo.gov/ file://///periwinkle_vnx/SAF_AQC_ORG/AQCP/5640%20-%20AFFARS/Templates%20Project%20--%20Sep%202013/5315/AppData/Local/Microsoft/Windows/Temporary%20Internet%20Files/AFAC%20Working%20Folders%20--%20PM/far/Far02.doc%23T2101 file://///periwinkle_vnx/SAF_AQC_ORG/AQCP/5640%20-%20AFFARS/Templates%20Project%20--%20Sep%202013/5315/AppData/Local/Microsoft/Windows/Temporary%20Internet%20Files/AFAC%20Working%20Folders%20--%20PM/far/FAR03.DOC%23b3104 be numbered sequentially by volume. For tables, charts, graphs and figures, the font shall be no smaller than eight (8) points.

1.2.3 Cross-Reference Matrix (CRM)

Offeror shall complete the CRM at Section J, Attachment 4 of this ITO. The CRM for the technical volume shall show traceability between the contract references and the TVFs. The CRM for the past performance volume shall show traceability between the Past Performance Narratives (PPNs) and the sub-factors. The CRM shall identify the contract references being used for both the technical and past performance volumes. The contracts referenced for the technical volume shall be used and identified in the past performance volume. The offeror shall include a CRM in the Technical (Volume II) and Past

Performance (Volume III) volumes that shall mirror each other.

1.2.4 Indexing

Each volume shall contain a more detailed table of contents to delineate the subparagraphs within that volume. Tab indexing shall be used to identify sections.

1.2.5 Glossary of Abbreviations and Acronyms

Each volume shall contain a glossary of all abbreviations and acronyms used, and with an explanation for each.

1.2.6 Binding and Labeling

Proposals shall be bound in a three-ring, loose leaf binder permitting the volume to lie flat when open.

Staples shall not be used. Volumes I and II shall be submitted together in one (1) binder and the remaining volumes shall be submitted in separate binders. A cover sheet shall be included in each volume identifying the volume number, title, solicitation identification, and the offeror's name. The same identifying data should be placed on the spine of each binder. All unclassified document binders shall have a color other than red or other applicable security designation colors. Be sure to apply all appropriate markings including those prescribed in accordance with FAR 52.215-1(e), Restriction on disclosure and use of data, and FAR 3.104-4, Disclosure, Protection, and Marking of Contractor Bid or

Proposal Information and Source Selection Information.

2.0 Volume I – CMMI Development Certification

The offeror shall provide valid proof of Capability Maturity Model Integration (CMMI) Development

Level 2 certification (at a minimum).

The offeror shall submit a copy of the certificate w/ embossed symbol or seal of the accreditation agency; the appraiser or accessor information; and the date which validates the certification is current.

This certification must be held at the offeror’s organizational level, not for an individual person.

If the offeror’s CMMI certification expires prior to contract award, the offeror shall submit a copy of its recertification which meets the same requirements listed above; otherwise the offeror will be ineligible for contract award.

file://///periwinkle_vnx/SAF_AQC_ORG/AQCP/5640%20-%20AFFARS/Templates%20Project%20--%20Sep%202013/5315/AppData/Local/Microsoft/Windows/Temporary%20Internet%20Files/AFAC%20Working%20Folders%20--%20PM/far/FAR52.215.doc%23b522151 file://///periwinkle_vnx/SAF_AQC_ORG/AQCP/5640%20-%20AFFARS/Templates%20Project%20--%20Sep%202013/5315/AppData/Local/Microsoft/Windows/Temporary%20Internet%20Files/AFAC%20Working%20Folders%20--%20PM/far/FAR03.DOC%23b31044

3.0 Volume II - Technical Experience

3.1 General

Each offeror shall submit a technical experience volume with its proposal. Offerors are allowed to reference a maximum of six (6) contracts to address the criteria for technical experience.

3.1.1 Volume Organization

The Technical Verification Form(s) (TVFs) within the Technical Proposal Volume shall be submitted in sequential order. The volume shall contain the information in tabbed sections IAW the following general outline:

(1) Table of Contents

(2) Cross-Reference Matrix (CRM)

(3) Self-Scoring Worksheet

(4) TVFs

3.1.2 Self-Scoring Worksheet

Offerors shall complete and submit a single Self-Scoring Worksheet in Section J, Attachment 6 of this solicitation. The worksheet shall be submitted in Microsoft Excel 2010 or later. The Government will not accept any worksheets that have been password protected or “locked.” A locked worksheet shall be considered to be non-compliant with the instructions of the solicitation and therefore, the worksheet will not be evaluated.

Complete the Worksheet using the following instructions:

1. Enter the offeror’s name in Row 4 of the Self-Scoring Worksheet.

2. In Column C, the offeror shall check the box if points are being claimed for that technical area and if a TVF has been submitted to support the claimed points. The worksheet will auto populate the offeror’s score and running total at the bottom of the worksheet.

3. Offerors shall enter the number of the TVF corresponding with the chosen technical area.

Example: If the offeror’s TVF # 3 references Technical Element (cybersecurity) of the self-scoring worksheet, the number 3 should be entered into column F (Technical Verification

Form Reference Number).

4. Offerors shall only enter responses in Columns C and F, Columns A, B, and D shall not be altered, Column E will auto-populate points, and Column G is for Government use only.

Offerors shall ensure TVF numbers are identified in Column F of the self-scoring worksheet and also in the CRM. If points claimed on the self-scoring worksheet cannot be verified due to missing TVF references on the CRM and the self-scoring worksheet, then the technical elements where points are claimed for that specific TVF will not be evaluated.

3.1.3 Technical Verification Form (TVF)

Offerors shall provide TVFs to support the points claimed on the self-scoring worksheet. Offerors may submit a maximum of six (6) TVFs; each TVF is limited to one (1) contract. Each TVF may address multiple technical elements. Offerors shall complete the TVF, in Section J, Attachment 5 of this solicitation, in accordance with the following instructions:

1. Number each of the TVF forms using the drop down field at the top of the form.

Section I. Project Identification

2. Enter Company Name

3. Enter the Title of the Project

4. Enter the Contract/Project Number (or equivalent)

Section II. Technical Element Identification

5. Select all applicable technical elements for the work performed under the contract listed above in

Section I, Project Identification.

Section III. Technical Element Criteria Description

Offerors shall describe its experience as it relates to the technical elements on the self-scoring worksheet and as described below. Pages two (2) and three (3) of the TVF shall be used to describe the offeror’s experience for each specific technical element(s) being addressed and where the offeror is claiming points on the self-scoring worksheet. The offeror is limited to 7,000 characters per page, 14,000 characters per TVF.

Offerors shall spell out each acronym with its first use.

For technical elements which do not call out a specific term (e.g., operating system, tool, software, etc.), the offeror may claim credit for similar experience. In those instances, the offeror shall describe the similarities between the terms.

Example: An offeror could claim full points for Technical Element 5c Tools / Development

Methodology (Testing) with a statement similar to the following: “We have used Rommana

Integrated Lifecycle Manager in our testing processes which is comparable to Hewlett Packard

Application Lifecycle Management (HP ALM). Rommana and HP ALM are similar test management tools because they both use a common database to manage test information for software projects.”

3.1. Technical Element Criteria

Offerors shall utilize the Definition of Terms provided in Section J, Attachment 8 of this solicitation to help form a better understanding of the Government’s use of specific technical terms. All capitalized terms used in this subsection can be found in Section J, Attachment 8.

1. Life-cycle Software Services

Sub-Element 1a: Life-cycle Software Services (Developing/ Implementation)

Offeror shall describe its experience in design, build, test, and implementation of an Information System

(IS) as defined in all of the following:

The process of implementing software solutions to one or more sets of problems

The process by which source code is converted into a stand-alone form that can be run on a computer or to the form itself. One of the most important steps of a software build is the compilation process, where source code files are converted into executable code

Obtaining, verifying, or providing data for any of the following: the performance, operational capability, and suitability of systems, subsystems, components, or equipment items; or vulnerability and lethality of systems, subsystems, components, or equipment items

Planning; coordinating; scheduling; deploying/installing (or providing all needed technical assistance to deploy/install) and transitioning a technical solution (e.g. information system) into the operational environment.

(SOO Sections 3.1.11, 3.4.3, and 3.4.5)

Sub-Element 1b: Life-cycle Software Services (Re-Engineering)

Offeror shall describe its experience re-engineering an IS during its life-cycle to include what was altered from the system’s existing state and the resulting reconstituted form (SOO Sections 3.1.4 and

3.1.16).

Sub-Element 1c: Life-cycle Software Services (Migration)

Offeror shall describe its experience migrating an IS during its life-cycle to include identifying both the previous and new operating environments. Offerors must also annotate the type of hardware/software used in both the previous and new operating environment (SOO Section 3.1.12).

Sub-Element 1d: Life-cycle Software Services (Modernization)

Offeror shall describe its experience modernizing a legacy IS during its life-cycle to include the type of modernization: conversion, code rewriting, or porting the IS to modern computer programming language, software libraries, protocols, or hardware platform (SOO Sections 3.1.9, 3.1.14, and 3.1.16).

Sub-Element 1e: Life-cycle Software Services (Commercial-off-the-Shelf software [COTS SW]

/Enterprise Resource Planning [ERPs] Systems)

Offeror shall describe its experience in one of the following:

Implementing one (1) COTS SW/ERP Package to satisfy complex business processes in the finance, personnel, and/or supply chain/manufacturing domain for one or more customer organizations where the offeror's COTS SW/ERP implementation was ultimately fielded for operational use by the customer

OR

Providing lifecycle software service support for one (1) COTS SW/ERP implementation for which the offeror was not the original implementer at initial deployment where one (1) of the following is demonstrated:

o the offeror played a key role in working with the customer to develop, define and/or blueprint operational business rules that were implemented by the COTS SW/ERP package o the offeror performed gap analysis and developed resulting custom reports, interfaces, data conversions, and functional extensions to the COTS SW/ERP product.

(SOO Section 3.4.5)

2. Cybersecurity

Offeror shall describe its experience integrating DoD and/or National Institute of Standards and

Technology (NIST) Information Assurance/Cybersecurity concepts, practices, and procedures for an IS within the network environment (SOO Section 3.1.10).

3. Information Technology [IT] Business Analysis

Sub-Element 3a: IT Business Analysis (Requirements Analysis)

Offeror shall describe its experience providing Requirements Analysis as a Life-cycle Software Service.

Offeror shall also describe its experience working with stakeholders to define a design solution (SOO

Section 3.2.2 and 3.1.2).

Sub-Element 3b: IT Business Analysis (Testing, Validation and Verification)

Offeror shall describe its experience in the life-cycle software services of Testing, Validation and

Verification in all areas defined below:

Obtaining, verifying, or providing data for any of the following: the performance, operational capability, and suitability of systems, subsystems, components, or equipment items; or vulnerability and lethality of systems, subsystems, components, or equipment items

Evaluating a system or software component in the development process to determine whether the item satisfies specified requirements; and

Confirming a system element meets design-to or build-to specifications.

(SOO Section 3.1.2 and 3.2.2)

Sub-Element 3c: IT Business Analysis (Service Desk/Help Desk)

Offeror shall describe its experience providing Service Desk/Help Desk services for an IS in the following IT Service Desk domains:

Access Management - process of granting authorized users the right to use a service while preventing access to non-authorized users.

Event Management - process of identifying and prioritizing all events that occur throughout the

IT infrastructure and establish the appropriate response to those events.

Incident Management - process of restoring normal service operation as quickly as possible, minimizing the adverse impact on mission partner operations, thus ensuring that the best possible levels of service quality, security, and availability are maintained.

Problem Management - process of preventing problems and incidents from happening, eliminate recurring incidents and minimizing the impact of incidents that cannot be prevented.

Request Management - process of fulfilling requests from users and routing each request to the appropriate process owner for handling within accepted service levels.

(SOO Section 3.2.3)

Sub-Element 3d: IT Business Analysis (Functional Business Area Expert [FBAE])

Offeror shall describe its experience providing FBAE as a Life-cycle Software Service. Offerors shall also demonstrate FBAE experience assessing either the “as is” or the “to be” operational/functional business process, identifying inadequacies or deficiencies affecting the ability of the technical solution to meet stakeholder requirements (SOO Section 3.2.2).

4. Programming Languages

Sub-Element 4a

Offeror shall describe its experience using two (2) of the following programming languages: Java, COBOL, PowerBuilder, .NET, ColdFusion or C#.

Sub-Element 4b

Offeror shall describe its experience providing programming services as a Life-cycle Software Service using two (2) of the following programing languages: JavaScript, Perl, SQL, PYTHON or PHP.

Sub-Element 4c

Offeror shall describe its experience providing programming services as a Life-cycle Software Service using one (1) of the following programing languages: SWIFT, Ruby On Rails, JavaScript MV*

Frameworks, or Spark.

(SOO Section 3.1.5)

5. Tools / Development Methodology

Sub-Element 5a (Security)

Offeror shall describe its experience using a COTS or free and open source (FOSS) tool in the functional areas of security to analyze source code for vulnerabilities during the life-cycle of a project. Offerors shall identify the tool with which they have experience to include, but not limited to: Fortify, Sonatype, or AppScan.

Sub-Element 5b (Quality)

Offeror shall describe its experience using COTS or FOSS tool, in the functional areas of quality to analyze source code, executables, and related artifacts (e.g., code documentation) against code quality metrics during the life-cycle of a project.

Sub-Element 5c (Testing)

Offeror shall describe its experience using a COTS or FOSS tool in the functional area of testing to analyze source code for vulnerabilities during the life-cycle. Offeror shall describe its experience using a common database to manage the test information for the system under test (to include capturing defects) or the offeror’s experience creating, maintaining, and executing test scripts using an automated tool.

Sub-Element 5d (Methodologies)

Offeror shall describe its experience using an agile software development methodology during the life-cycle of a project.

(SOO Sections 3.1.5, 3.1.6, 3.1.11 and 3.4.5)

6. Platforms / Environments

Sub-Element 6a: Platforms/Environments (Mainframe, Mid-tier/Client-server, or Web Services)

Offeror shall describe its experience implementing an IS into one (1) of the following: mainframe, mid-tier/client-server or web services.

Sub-Element 6b: Platforms/Environments (Customer’s Facility)

Offeror shall describe its experience providing support services in the customer’s facility (e.g., not the offeror’s home office) of a non-DoD or DoD mainframe, mid-tier/client-server or web services.

Sub-Element 6c: Platforms/Environments (Commercial, Non-commercial, or Hybrid Cloud)

Offeror shall describe its experience developing or modifying an existing IS to operate within or migrate to a commercial, non-commercial or hybrid cloud.

Sub-Element 6d: Platforms/Environments (Defense Information Systems Agency [DISA] Enterprise

Computing Center [DECC] or Air Force [AF] Computing facility)

Offeror shall describe its experience developing or modifying an existing IS to operate within a DISA

DECC or AF computing facility.

(SOO Section 3.3)

7. Database Components

Sub-Element 7a: Database Components (Relational Database Management System [RDBMS])

Offeror shall describe its experience developing, designing or maintaining a RDBMS database to include, but not limited to: Oracle, SQL Server, DB2, SyBase, Postgresql, MarialDB, JasperSoft, or

MYSQL.

Sub-Element 7b: Database Components (Not Only Structured Query Language [NoSQL])

Offeror shall describe its experience developing, designing, or maintaining a (NoSQL) database to include, but not limited to: Postgresql, Cassandra, MongoDB, Hadoop, Spark, or CouchDB.

Sub-Element 7c: Database Components (RDBMS or NoSQL)

Offeror shall describe its experience providing data store support in a RDBMS or NoSQL database.

(SOO Section 3.1.9)

8. Mobile/Internet of Things (IOT)

Sub-Element 8a: Mobile/IOT (Mobile Application Development)

Offeror shall describe its experience developing and implementing a mobile application that runs on one

(1) of the following: Apple iPhone Operating System (IOS), Windows, or Android.

Sub-Element 8b: Mobile/IOT (Mobile IT Programming Services)

Offeror shall describe its experience redesigning a legacy system to work with or on a mobile device using one (1) of the following: Apple IPhone Operating System (IOS), Windows, or Android.

Sub-Element 8c: Mobile/IOT (Automatic Identification Technology [AIT])

Offeror shall describe its experience developing and implementing an IOT software-based solution for

AIT that operates on a handheld terminal, using sensors for Radio Frequency Identification (RFID)

(Active or Passive).

(SOO Section 3.1.7)

9. Server Operating Systems

Offeror shall describe its experience providing life-cycle services to support the efficient operations for an IS for one (1) of the following: Windows Server, Red Hat enterprise Linux, SUSE, or UBUNTU

(SOO Sections 3.1.13 and 3.1.15).

10. COTS Product Support

Offeror shall describe its experience creating and maintaining IS’s in development, test, or production environments by implementing COTS software patches and upgrades (SOO Section 3.1.15 and 3.4.5).

4.0 Volume III - Past Performance

4.1 General

Each offeror shall submit a past performance volume with its proposal. Offerors are allowed to reference a maximum of six (6) recent contracts to address the criteria of the past performance sub-factors.

4. 2 Volume Organization

The Past Performance Narratives (PPNs) shall be submitted in sequential order. The volume shall contain the information in tabbed sections IAW the following general outline:

(1) Table of Contents

(2) Cross-Reference Matrix (CRM)

(3) Past Performance Narratives (PPNs)

(4) Security Control Artifact(s)

4.2.1 Offeror shall address the following three (3) Sub-factors in its PPNs. Each PPN shall be numbered separately; “PPN 1” to a maximum of “PPN 6.”

4.3 Past Performance Narratives

PPNs are required for each contract that was provided to support the Technical volume. If the Offeror referenced less than six (6) contracts in the Technical volume, additional contracts may be used to address the past performance sub-factors; however only a maximum of six (6) are allowed to be referenced. Each

PPN shall include contract number (IDIQ contracts are not allowed to be used as a reference), order number (if applicable), period of performance, and the point of contact information for the questionnaire assessor requested in 3.3.1 below. Offerors shall reference the applicable SOO sections, Definition of

Terms (Section J, Attachment 8), and the DoD or NIST standard required to verify the security control(s) in order to ensure the information being referenced in the proposal is relevant as it relates to the evaluation criteria.

4.3.1 Past Performance Sub-Factor Criteria

Sub-factor 1: Life-Cycle Software Services

Offeror shall describe past performance as it relates to the requirements identified in the SOO

Sections 3.1.3 through 3.1.17.

Sub-factor 2: Cybersecurity

Offeror shall describe past performance as it relates to the following requirements identified in the SOO:

Information assurance/Cybersecurity to include Risk Management Framework (RMF) or

DoD Information Assurance Certification and Accreditation Process (DIACAP) (SOO

Section 3.1.10)

Offerors with DoD past performance shall describe:

Its past performance integrating NIST Special Publication 800-53 Rev 4 Security and

Privacy Controls for Federal Information Systems and Organizations and the guidelines in NIST Special Publication 800-37 Revision 1, Guide for Applying the Risk Management

Framework to Federal Information Systems into a system’s life-cycle or

Its past performance integrating DIACAP, reference DoD 8510.01 and DoD 8500.02, into a system’s lifecycle.

Offerors without DoD past performance shall describe:

Its past performance integrating NIST Special Publication 800-53 Rev 4 Security and

Privacy Controls for Federal Information Systems and Organizations and the guidelines in NIST Special Publication 800-37 Revision 1, Guide for Applying the Risk Management

Framework to Federal Information Systems into a system’s life-cycle.

All offerors shall:

Provide at least one (1) example identifying the control by name with supporting security control artifacts used to verify the IS met the RMF or DIACAP control.

Describe its testing and remediation actions and the result of those actions for the compliant and non-compliant security controls.

Sub-factor 3: Information Technology Business Analysis

Offeror shall describe past performance as it relates to the requirements identified in the SOO:

IT Business analysis and functional business area expertise (FBAE) for business process areas to include, but not limited to, contracting, finance, medical, logistics, personnel, communications, transportation, civil engineering, munitions, infrastructure and operations. (SOO Section 3.2.2)

Service desk, field and technical support to include access management, event management, incident management, problem management, and request fulfillment.

4.3.2 Questionnaires

The offeror shall send Questionnaires to the customer identified in Questionnaire Section I.B requesting the customer provide a completed Questionnaire to the Points of Contacts (POCs) listed in…