NWS_Watchbill_Generator_RFP_-_approved_-_PDF-version_08.13.13.pdf

N00030-13-R-0029

AUTHORIZED FOR LOCAL REPRODUCTION STANDARD FORM 33 (Rev. 9-97) Previous edition is unusable Prescribed by GSA – FAR (48 CFR) 53.214©

SOLICITATION, OFFER AND AWARD 1. THIS CONTRACT IS A RATED ORDER

UNDER DPAS (15 CFR 700) ► RATING

DX-A2

PAGE OF PAGES

1 | 102

2. CONTRACT NUMBER

3. SOLICITATION NUMBER

4. TYPE OF SOLICITATION

SEALED BID (IFB)

NEGOTIATED (RFP)

5. DATE ISSUED

13 August 2013

6. REQUISITION/PURCHASE NO.

PR 114EWBILL

7. ISSUED BY CODE N00030 8. ADDRESS OFFER TO (If other than Item 7)

Strategic Systems Programs ATTN: Sterling Whitehead (SPN105) 1250 10th Street SE, Suite 3600 Washington Navy Yard, DC 20374-5127

Same as Block 7

NOTE: In sealed bid solicitations “offer” and “offeror” mean “bid” and “bidder”

SOLICITATION

9. Sealed offers in original and copies for furnishing the supplies or services in the Schedule will be received at the place specified in Item 8, or if handcarried, in the depository located in 1250 10th Street SE, Suite 3600 | Washington Navy Yard, DC 20374-5127 until _1400_______ local time 13 September 2013

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

10. FOR A. NAME B. TELEPHONE (NO COLLECT CALLS) C. E-MAIL ADDRESS

INFORMATION ►

CALL:

Sterling Whitehead, SPN105

AREA CODE

NUMBER

EXT.

Sterling.Whitehead@ssp.navy.mil

11. TABLE OF CONTENTS

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

PART I - THE SCHEDULE PART II - CONTRACT CLAUSES

X A SOLICITATION/CONTRACT FORM 1 X I CONTRACT CLAUSES 48-68

X B SUPPLIES OR SERVICES AND PRICE/COST 2 PART III - LIST OF DOCUMENTS, EXHIBITS AND OTHER ATTACH.

X C DESCRIPTION/SPECS./WORK STATEMENT 3-18 X J LIST OF ATTACHMENTS 69

X D PACKAGING AND MARKING 19 PART IV – REPRESENTATIONS AND INSTRUCTIONS

X E INSPECTION AND ACCEPTANCE 20 X K REPRESENTATIONS, CERTIFICATIONS 70-77

X F DELIVERIES OR PERFORMANCE 20-23 AND OTHER STATEMENTS OF OFFERORS

X G CONTRACT ADMINISTRATION DATA 24-29 X L INSTRS., CONDS., AND NOTICES TO OFFERORS 78-98

X H SPECIAL CONTRACT REQUIREMENTS 30-47 X M EVALUATION FACTORS FOR AWARD 99-102

OFFER (Must be fully completed by offeror) NOTE: Item 12 does not apply if the solicitation includes the provisions at 52.214-16, Minimum Bid Acceptance Period.

12. In compliance with the above, the undersigned agrees, if this offer is accepted within _____ calendar days (60 calendar days unless a different period is inserted by the offeror) from the date for receipt of offers specified above, to furnish any or all items upon which prices are offered at the price set opposite each item, delivered at the designated point(s), within the time specified in the schedule.

13. DISCOUNT FOR PROMPT PAYMENT

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

10 CALENDAR DAYS

20 CALENDAR DAYS

30 CALENDAR DAYS

CALENDAR DAYS

14. ACKNOWLEDGMENT OF AMENDMENTS AMENDMENT NO. DATE AMENDMENT NO. DATE

(The offeror acknowledges receipt of amendments to the SOLICITATION for offerors and related documents numbered and dated):

15A. NAME CODE FACILITY 16. NAME AND TITLE OF PERSON AUTHORIZED TO SIGN

AND OFFER (Type or print)

ADDRESS

OF

OFFEROR

15B. TELEPHONE NUMBER 15C. CHECK IF REMITTANCE 17. SIGNATURE 18. OFFER DATE

AREA CODE

NUMBER

EXT.

ADDRESS IS DIFFERENT FROM ABOVE -

ENTER SUCH ADDRESS IN SCHEDULE.

AWARD (To be completed by Government)

19. ACCEPTED AS TO ITEMS NUMBERED

20. AMOUNT

21. ACCOUNTING AND APPROPRIATION

SEE ATTACHED FINANCIAL DATA SHEET

22. AUTHORITY FOR USING OTHER THAN FULL AND OPEN

COMPETITION:

23. SUBMIT INVOICES TO ADDRESS SHOWN

IN (4 copies unless otherwise specified)

ITEM

Block 25

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

26. NAME OF CONTRACTING OFFICER (Type or print)

27. UNITED STATES OF AMERICA

(Signature of Contracting Officer)

28. AWARD DATE

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

PART I – THE SCHEDULE

SECTION B – SUPPLIES OR SERVICES AND PRICES/COSTS

CLIN SUPPLIES/SERVICES QTY UNIT PRICE/AMOUNT

0001 Security Forces Qualification and

Certification Management software tool (FY14 Base) (FFP-Completion)

(OPN)

0002 Technical Support (FY15 Option)

(FFP-LOE) (O&MN)

0003 Technical Support (FY16 Option)

(FFP-LOE) (O&MN)

0004 Contract Data Requirements List (CDRL) (Not Separately Priced)

NSP

[End of Section]

[End of Page]

SECTION C – DESCRIPTIONS/SPECIFICATIONS/STATEMENT OF WORK

Strategic Systems Programs (SSP) security forces have identified the need to merge and automate processes and tools used to track member qualifications and certifications, generate security watch-standing schedules, perform audits/verifications, and support user general database needs. This need has been designated as the Security Forces Qualification and Certification Management Tool. This statement of work (SOW) defines the efforts required to deliver said software tool.

ITEM 0001 – Security Forces Qualification and Certification Management software tool (FY14 Base) (FFP-Completion) (OPN) 1 Software Tool Application The Contractor shall perform all tasks required and delineated in this SOW to design, develop, and deliver a Security Forces Qualification and Certification Management software tool that shall meet the performance criteria specified by attachment 1 (Requirements Document For Security Forces Qualification and Certification Management Tool, Version: 1.0), the applicable requirements of T9001B (as set forth in exhibit B), and the detailed requirements of paragraphs

1.1 through 1.8 below. The software tool shall identify, track, and assign individual security force member(s) qualifications for duties. Additionally, the software tool shall provide the following:

• An application capable of generating an accurate security watch-bill containing only qualified and Personnel Reliability Program (PRP) certified personnel.

• An application that supports a web based configuration, accessible from remote sites.

• An application capable of being hosted on or accessible from existing SSP hardware without the use of additional hardware or personnel.

• An application that shall provide senior leadership with an ability to conduct reviews of administrative, training and PRP status, monitor qualification timelines and objective qualifying evidence (OQE) of individual(s) qualifications and certifications.

• An application that provides training department personnel with a single source for tracking, and verifying individual security force member training and qualification requirements.

• An application that allows Watchbill Reviewing Officials (ROs) with a means to review and validate individual security force members for their assigned duties.

• An application that shall notify the chain of command via email when an individual’s PRP status changes.

1.1 Development and Qualification

1.1.1 Program Management

The Contractor shall establish and maintain program management practices throughout the period of performance. Program management practices shall provide visibility into the Contractor’s organization and techniques used in managing the program, specifically subcontractor and data management. Documentation shall be readily available to Government representative(s) during planned visits. The Contractor shall include a monthly status of the efforts of this SOW as a separately identifiable part of the Contractor’s Progress, Status and Management Report [CDRL A001]. The Contractor shall plan and manage the technical, schedule, and cost performance of the contract.

1.1.2 Integrated Master Plan (IMP)

The Contractor shall develop an Integrated Master Plan (IMP) that addresses and integrates all disciplines and aspects of the project.

1.1.3 Integrated Master Schedule (IMS)

The Contractor shall develop an Integrated Master Schedule (IMS) [CDRL A003] to reflect the work scope of this SOW. The IMS shall also include the efforts of all activities and present a current, integrated view of the contract or agreement that is consistent with resource plans, Contract Performance Reports, and other approved documentation. Furthermore, the IMS shall reflect those risks identified and documented in the Contractor’s Risk Management Plan. The Contractor shall coordinate milestones with the Government and shall provide notification of variances greater than ten (10) work days.

1.1.4 Cost Performance Reports

The Contractor shall develop an integrated baseline Work Breakdown Structure (WBS) with associated cost and schedule and conduct an Integrated Baseline Review (IBR) prior to issuing the first monthly Cost Performance Report to be included in the Progress Status and Management Report [CDRL A001]. A preliminary program risk assessment shall be part of this review.

1.1.5 Risk Management

The Contractor’s current Risk Management Plan, delivered as part of the base contract, shall apply to this SOW. The Contractor shall ensure risk management is an integral part of the systems engineering process and the overall program management effort. Risks shall be presented to the Program Office via the Systems Engineering IPT structure.

Since the contractor will not have privileged access to the system hosting the application, this risk shall be mitigated to ensure the application is supportable.

1.1.6 Assignment of Responsibility and Authority

The Contractor shall identify the organizational elements responsible for the conduct of the activities delineated in this SOW. Responsibilities shall be assigned and clear lines of authority defined for determining and controlling the resources necessary to satisfy each element of this SOW. The Contractor shall clearly identify the hierarchical organizational structure, identify by name and billet of all functional area leads, to include their roles and responsibilities.

Additionally, the Contractor shall propose how the organizational structure will support the Government Integrated Product Team (IPT) structure required to fulfill the requirements of this SOW. The Contractor shall identify any sub-contractors participating in the IPT structure and clearly identify their roles and responsibilities.

1.1.7 Formal Project Reviews, Conferences and Audits

The Contractor shall plan, host, attend, coordinate, support and conduct formal reviews, conferences and audits (hereinafter called “reviews”). The reviews shall be conducted at Government and Contractor facilities. All such reviews shall be included in the program schedule and may be held concurrently with the Government’s approval. The Government reserves the right to cancel any review or to require any review to be scheduled at critical points during the period of performance. Action item documentation, assignment of responsibility for completion and due dates shall be determined prior to adjournment of all reviews. A summary of all action items, responsible parties, and estimated completion dates shall be included with the minutes.

1.1.7.1 Kick-Off Meeting

Within 30 days of award of this contract, the Contractor shall hold a kick-off meeting at a mutually agreed upon location. This meeting will be focused on ensuring that the Government and Contractor program managers have a mutual understanding of this SOW’s work scope, organizational structure, schedule and risk, and attain agreement on a plan of action to handle the identified risks. Technical, Schedule, Cost, Resource, and Management Processes risks identified during this meeting shall be reviewed; action risks shall be incorporated into the project risk management planning

1.1.7.2 In-Process Reviews (IPR)

IPRs shall be held at a date and location mutually agreed upon IAW the base contract. The Contractor’s progress, management, technical support services (if any), administrative, assurance of compliance with contract requirements, program status, funding, problem identification and resolutions shall be agenda items. Actual versus expected performance of each area shall be addressed. Two IPRs are anticipated within the period of performance.

1.1.7.3 Technical Reviews (TR)

TRs will be held at a date and location mutually agreed upon IAW the base contract. The Contactor shall participate in TRs providing all required review documentation and reports for Government review. TRs will be multi-disciplinary technical reviews to ensure the Security Forces Qualification and Certification Management Tool effort can proceed with system integration, and that system requirements and performance requirements are defined and consistent with cost, schedule, and performance metrics and other systems constraints. Four TRs are anticipated during the period of performance: System Requirements Review (SRR), Preliminary Design Review (PDR), Critical Design Review (CDR), and Test Readiness Review

(TRR)

1.2 System Design and Development

The Contractor shall plan and apply a comprehensive systems engineering approach that integrates all the disciplines and specialty groups into an effective team to provide a quality product that meets the required performance parameters. The Contractor shall ensure that the system engineering process including related disciplines are established, integrated, and maintained throughout this program.

The Contractor shall provide systems engineering and integration support for all work performed under this SOW. As part of the SE effort, the Contractor shall provide Human Centered Design support to fully ingrate users into system concepts, visualization, and user interface design.

1.2.1 System Specification

The Contractor shall develop a system specification, supported by subsystem specifications

(CDRL A005).

1.2.2 Life Cycle Logistics

The contractor shall develop and implement a Life Cycle Logistic (LCL) program that ensures that supportability considerations are an integral part of the design and development process.

1.3 Configuration Management/Data Management (CM/DM)

The Contractor shall implement a CM program for the control of all configuration items representing or comprising the Security Forces Qualification and Certification Management software tool to ensure each item delivered conforms to all approved baselines. MIL-HDBK- 61A (SE) may be used for guidance. The Contractor’s CM program shall consist of, at a minimum, CM life cycle management and planning, configuration identification, configuration control, configuration status accounting, configuration verification and audit, and data management.

The Contractor shall deliver a Configuration Management Plan [CDRL A006] to cover the activities within this SOW. The Configuration Management Plan shall include descriptions of how the Contractor’s CM activities are aligned and interfaced with the Governments CM activities.

1.3.1 Requests for Deviation (RFDs)

If it is necessary to depart from a particular requirement(s) of an item’s current approved configuration documentation, the Contractor shall prepare and submit a Request for Deviation on DD Form 1694 to the Government for disposition. The Contractor shall contact the Government for RFD numbers and titles.

1.3.2 Notification of Changes to Commercial Software

The Contractor shall submit notification to the Government when Contractor makes changes to commercial software that is being procured or fabricated by the Contractor as Commercial off the Shelf (COTS) and the Government does not control the developer’s design [CDRL A007].

1.3.3 Configuration Status Accounting

The Contractor shall establish and maintain a CSA database, which represents the configuration of the Security Forces Qualification and Certification Management software tool. All baselines and changes shall be documented in the contractor’s CSA database. The Contractor’s CSA database shall permit acceptance of commercial product information. However, if requirements to report data outside of the Contractor’s CSA database or format exist, the information may be delivered as a supplement to prevent disruption to their existing system. The Contractor’s CSA database shall reconcile any differences between the supplier information and Contractor practices to provide the Government with clear accountability of product information

1.3.3.1 Configuration Status Reporting

The Contractor shall submit configuration status accounting report data in a format reviewed and approved by the Government as part of the Contractor’s Progress Status and Management Report

[CDRL A001].

1.3.4 Configuration Verification and Audit

The Contractor shall perform configuration verification and audits to maintain the integrity and traceability of established baselines.

1.3.5 Data Management

The Contractor shall perform data management as necessary for the execution of this SOW.

Specific data management functions shall include, at a minimum: schedule control for deliverables, maintenance of deliverables, approval of deliverable format, and distribution and delivery of data products. The Contractor shall provide a capability for the Government to access Contractor deliverables via a means that ensures access to large files and limit access to Government approved personnel.

1.4 Information Assurance (IA)

The contractor is responsible for delivering software that meets DoD, Navy and SSP IA security requirements and ensuring that software works as expected in the existing SSP computing environment at SWFPAC and SWFLANT. Software development must be done in accordance with Security Technical Information Guides (STIG). The Contractor shall provide a list of applicable STIGs and findings. Software with security vulnerabilities or not in accordance with IA standards shall not be accepted.

Information assurance is provided for information technology in accordance with current policies, procedures, and statutes, to include—

(1) The National Security Act;

(2) The Clinger-Cohen Act;

(3) National Security Telecommunications and Information Systems Security Policy No.

11;

(4) Federal Information Processing Standards;

(5) DoD Directive 8500.1, Information Assurance;

(6) DoD Instruction 8500.2, Information Assurance Implementation;

(7) DoD Directive 8570.01, Information Assurance Training, Certification, and Workforce Management; and

(8) DoD Manual 8570.01-M, Information Assurance Workforce Improvement Program

(9) SSPINST 5211.3E, PRIVACY POLICY ACT

(10) SSPINST 5230.11, ELECTRONIC TRANSMISSION OF CONTROLLED

UNCLASSIFIED INFORMATION

(11) SSPINST 5239.10, STRATEGIC WEAPONS SYSTEMS NETWORK (SWSNET)

CONNECTION POLICY FOR FLEET BALLISTIC MISSILE (FBM) PARTNERS

(12) SSPINST 5239.13A, ELECTRONIC MAIL DIGITAL SIGNATURE AND

ENCRYPTION POLICY

(13) SSPINST 5510.20, COMMON ACCESS CARD POLICY

(14) DoD Instruction 8520.03, Identity Authentication for Information Systems

If there is a requirement for the Contractor to access DoD systems, applicable personnel shall complete the Navy’s annual IA awareness training.

1.5 Testing, Evaluation, Validation and Verification

The Contractor shall support the full range of test and evaluation activities required to verify all Security Forces Qualification and Certification Management software tool capabilities and system requirements. The Contractor shall conduct all necessary testing to include development and integration testing, benchmark testing, scalability testing, acceptance testing, and regression testing. The Government and Contractor shall jointly determine which of the Security Forces Qualification and Certification Management software tool requirements will be regression tested during the system-level test events.

1.5.1 Test & Evaluation Master Plan (TEMP)

The Contractor shall develop and deliver the TEMP [CDRL A009] to outline the plan for all Contractor conducted system testing for the work performed under this SOW. Also, the Contractor shall develop and deliver a Software Test Plan (STP) [CDRL A010] that includes Test Event Schedules, and Software Test Reports [CDRL A012]. A Software Test Readiness Review shall be conducted.

1.6 Training

The Contractor shall establish a train-the-trainer program and create the training curriculum with associated courseware. Training shall be conducted at Government facilities or a mutually agreed upon site. The Contractor shall provide a training plan (CDRL A013) that includes the events and schedule required to transition from Contractor training to Government training.

1.6.1 Instructional Level

The Contractor shall develop courses in sufficient depth to meet the following requirements for both SWFLANT and SWFPAC:

1.6.1.1 Operator Course Requirements

The course shall provide students with the knowledge and understanding of the system's capabilities, functions, limitations, interfaces, operations, and Preventive Maintenance Checks and Services (PMCS). The course shall allow the student to become proficient with the required operation's tasks. The course shall be of sufficient depth to ensure that students are qualified to properly operate the system. At a minimum, the hands-on instruction shall include and, upon completion, enable the student to, (1) configure and operate the system, subsystem, and software controls, (2) demonstrate knowledge of general software functions and operations, and (3) perform system checks and verification procedures. Class size shall not exceed twenty (20) students.

1.6.1.2 Application Technician Course Requirements

The course shall provide students with the knowledge and understanding of the operating system capabilities, limitations, interfacing, operations, and basic network operator/maintenance tasks.

At a minimum, the instruction shall include, (1) adding new users, new systems, (2) update network files, check system capacity, backup and archive functions, install additional workstations, and printer configuration, and (3) provide data security, diagnose and fix software problems, manage and integrate client information. The course shall be developed to allow the student to become proficient with the required system administration tasks. The course shall be of sufficient depth to ensure students are qualified to properly administer system software and hardware to the appropriate level, using the manuals and proven diagnostic procedures. At a minimum, the hands-on instruction shall include and, upon completion, enable the student to, (1) configure and administer the system and subsystem, (2) demonstrate knowledge of general software functions and operations, and (3) perform software checks and verification procedures.

Class size shall not exceed eight (8) students.

1.6.2 Methods of Instruction

Methods of instruction are lectures, demonstrations, practical exercises, and application. No less than fifty percent of course presentation shall be practical exercise and hands-on training. Fault isolation shall be accomplished by students identifying faults to the software configuration item, with particular emphasis on high failure items.

1.6.3 Course Material

The Contractor shall generate all course materials necessary to successfully conduct training [CDRL A014]. All course material shall be prepared per MIL-PRF-29612 and in accordance with NAVEDTRA 130 Series. The reading level at which written training material is developed shall be the ninth grade (9) reading level. The contractor shall provide a copy of all Course Material required teaching the course to each student. The Contractor shall provide all supplies, test equipment, common and special tools, and technical literature to each Government student while taking the course. For each course, the Contractor shall prepare and deliver the following training documentation in accordance with MIL-PRF-29612. For further guidance MIL-HDBK- 29612 may be used.

1.6.4 Instructional integrated learning Media

The contractor shall provide visual aids (e.g., DVDs and laminated job aids) for use by the instructor in the conduct of classes. They shall be designed to enhance the learning process and be in accordance with NAVEDTRA 136.

1.6.5 Initial Training

The Contractor shall be responsible for Initial Training and all supporting courseware. The contractor shall update training material (courseware) to address Security Forces Qualification and Certification Management Tool operator tasks. Training and courseware shall address Security Forces Qualification and Certification Management Tool system operation. Initial Training shall be conducted at Government facilities or a mutually agreed upon site. The Government reserves the right to inspect, review and provide corrections to the training materials and courseware prior to first period of instruction.

1.7 Open Systems Approach and Goals

The Government intends to procure a system having an Open System Architecture. As part of this contract, the Contractor shall define, document, and follow an open systems approach for using modular design, standards-based interfaces, and widely-supported consensus-based standards. The contractor shall develop, maintain, and use an open system management plan to support this approach and shall be required to demonstrate compliance with that plan during all design reviews. As part of an open system management plan, the contractor shall be required to identify in a listing contained in its proposal to the Government all Commercial-Off-the- Shelf/Non-development Item (COTS/NDI) components, their functionality and proposed use in the system, and provide copies of license agreements related to the use of these components for Government approval prior to use. The proposed open system management plan shall be incorporated into the contract with any changes, alterations, or modifications requiring Government approval.

In addition, the Contractor shall provide the Government electronic access to its integrated digital (or development) environment (IDE) and the ability to download artifacts throughout the term of the contract. The Government reserves the right to witness all Contractor efforts to accomplish the SOW requirements and maintains the right to comment on processes. The Contractor shall provide 30 days advance notice of any events, tests, or activity that the Government identifies as a specific item of interest.

In satisfying the Government’s requirements, the following system architecture approach characteristics shall be utilized:

1.7.1 Open Architecture

The Contractor shall develop and maintain an architecture that incorporates appropriate considerations for reconfigurability, portability, maintainability, technology insertion, vendor independence, reusability, scalability, interoperability, upgradeability, and long-term supportability.

Ensure that external information exchange requirements are implemented in a standard and open manner as part of this effort. These actions shall include planning that identifies the Contractor’s specific approach to ensuring system and interface data is well-defined, available to all programs, and uses a standards-based tool for definition within the context of DoD and Service upgrade programs. The Contractor shall develop system upgrades, IT system capabilities and business rules that ensure that: 1) data shall be posted to shared spaces for users to access and download except when limited by security, policy, or regulations; 2) data shall provide for interoperability with many-to-many exchanges of data, and verified trust and integrity of users and applications; and 3) data shall be transmitted through well and openly defined interfaces.

1.7.2 Modular, Open Design

The Contractor shall develop an architecture that is layered and modular and uses standards-based COTS/NDI operating systems and middleware that all utilize either non-proprietary or non-vendor-unique key module or component interfaces. The Contractor’s design approach shall be applied to all subsystems. As part of its open system management plan, the Contractor shall be required, at a minimum, to describe how the proposed system architecture meets these goals, including the steps taken to use non-proprietary or non-vendor unique COTS or reusable NDI components wherever practicable.

1.7.2.1 Module Coupling

The Contractor’s design approach shall result in modules that have minimal dependencies on other modules (loose coupling), as evidenced by simple, well-defined interfaces and by the absence of implicit data sharing. The purpose is to ensure that any changes to one module shall not necessitate extensive changes to other modules, and hence facilitate module replacement and system enhancement. The approach used to determine the level of coupling and the design trade-off approach shall be described.

1.7.2.2 Module Cohesion

The Contractor’s design shall result in modules that are characterized by the singular assignment of identifiable, and discrete functionality (high cohesion). The purpose is to ensure that any changes to system behavioral requirements can be accomplished by changing a minimum number of modules within the system. The approach used to determine the level of cohesion and the design trade-off approach shall be described.

1.7.3 System Requirements Accountability

The Contractor shall be required to ensure that all system requirements (including those contained in the Initial Capabilities Document, Capabilities Development Document, Capabilities Production Document, and in this SOW) are accounted for through a demonstrated ability to trace each requirement to one or more modules that consist of components that are self-contained elements with well-defined, open and published interfaces implemented using open standards.

1.7.4 Inter-component Dependencies

The Contractor’s design approach shall result in a layered system design, maximizing software independence from the hardware, thereby facilitating technology refresh. The design shall be optimized at the lowest component level to minimize inter-component dependencies. The layered design shall also isolate the application software layers from the infrastructure software (such as the operating system) to enhance portability and to facilitate technology refresh. The design shall be able to survive a change to the computing infrastructure with minimal or no changes required to the application logic. The interfaces between the layers shall be built to open standards or the technical data and computer software describing the interface shall be available to the Government with at least Government Purpose Rights. The system architecture shall minimize inter-component dependencies to allow components to be decoupled and reused across various DoD or Service programs and platforms.

1.7.5 Design Information Documentation

The Contractor shall document and model the system or component (e.g., software, middleware) design information using industry standard formats (e.g., Unified Modeling Language). It shall also document and model how it shall use tools that are capable of exporting model information in a standard format (e.g., Extensible Markup Language Metadata Interchange (XMI) and AP233/ISO 10303). The contractor shall identify the proposed standards and formats to be used.

The contractor shall maintain the design information, including any models used, so that the design information and models are current with the as-built system.

1.7.6 Technology Insertion

The Contractor’s architectural approach shall support the rapid and affordable insertion and refreshment of technology through modular design, the use of open standards and open interfaces. The Contractor shall define the functional partitioning and the physical modularity of the system to facilitate future replacement of specific subsystems and components without impacting other parts of the system and to encourage third-party vendor’s participation.

1.7.7 Life Cycle Sustainability

The Contractor shall consider use of COTS/NDI and open standards to enhance the system’s life cycle sustainability by implementing performance-based logistics (PBL) arrangements to sustain the components through their life cycle.

1.7.8 Interface Design and Management

The Contractor shall:

• Clearly define and describe all system interfaces;

• Define and document all subsystem and configuration item (CI) level interfaces to provide full functional, logical, and physical specifications;

• Identify processes for specifying the lowest level (i.e., subsystem or component) at and below which it intends to control and define interfaces by proprietary or vendor-unique standards and the impact of that upon its proposed logistics approach. Interfaces described shall include, at a minimum, mechanical, electrical (power and signal wiring), software, firmware, and hardware interfaces;

• Identify the interface and data exchange standards between the system and other data sources;

• Consider using these interfaces to support an overall information assurance strategy that implements Information Assurance (IA) Processes in accordance with DoD Instruction

8500.2 (dated February 6, 2003);

• If applicable, select external interfaces from existing open or Government standards with an emphasis on enterprise-level interoperability. The Contractor shall describe how its selection of interfaces shall maximize the ability of the system to easily accommodate technology insertion (both hardware and software) and facilitate the insertion of alternative or reusable modular system elements;

• Describe the extent that the change or configuration management process proposed shall use “community of interest” teams in an integrated team approach to effectively identify how individual changes impact the system’s internal or external interfaces and information exchange standards.

1.7.9 Treatment of Proprietary or Vendor-Unique Elements

The Contractor shall explain the use of proprietary, vendor-unique or closed components or interfaces. The contractor shall define its process for identifying and justifying proprietary, vendor-unique or closed interfaces, code modules, hardware, firmware, or software to be used.

When interfaces, hardware, firmware, or modules that are proprietary or vendor-unique are required, the contractor shall demonstrate to the Government that those proprietary elements do not preclude or hinder other component or module developers from interfacing with or otherwise developing, replacing, or upgrading open parts of the system.

1.7.10 Open Business Practices

The Contractor shall demonstrate that the modularity of the system design promotes the identification of multiple sources of supply and/or repair, and supports flexible business strategies that enhance subcontractor competition. The contractor shall conduct a market survey to identify candidate COTS, proprietary, open source software (OSS) and other reusable NDI capable of achieving the performance requirements of solutions that it proposes to custom build.

The survey results shall be provided to support each major review. COTS and other reusable NDI selection criteria shall address the following factors, at a minimum: Electrostatic Sensitive Device (ESD) immunity; Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC); Integrated Logistics Support requirements; safety; reliability consistent with the environment described in the System Specification; maintainability; subsystem performance trade-offs; power, cooling, and physical form factors; open system architecture break out compatibility; cost; manufacturer’s quality assurance provisions; market acceptability;

obsolescence; adequacy of available intellectual property including technical data, computer software and re-procurement data rights on the product; and merits of the software supported by the product. Decisions leading to the selection of specific COTS, NDI, proprietary or OSS products shall be supported by appropriate analysis (e.g., with test results, architectural suitability, “best value” assessments, etc.).

1.7.11 Reuse of Pre-existing or Common Items

The contractor shall reuse pre-existing or common items unless a determination is made to not reuse and the Government accepts the determination. Exceptions to reuse of pre-existing items must be accompanied by justification, such as cost (both of adoption and life cycle support), schedule, functional and non-functional performance, etc. The general objective of these efforts shall be the development of a common system and/or common elements or components which meet the performance requirements of the various DoD or Service platform missions, where commonality offers the greatest technical and cost benefits.

1.7.12 Third-Party Development

The Contractor shall address how it shall provide to the Government information needed to support third-party development and delivery of competitive alternatives of designs for software or other components or modules on an ongoing basis. The contractor shall provide a list of those proprietary, vendor-unique elements that it requests be exempt from this review.

1.7.13 Life Cycle Management and Open Systems

The Contractor’s architecture shall provide for insertion of COTS into the system and demonstrate that COTS, reusable NDI, and other components are logistically supported throughout the life cycle. The contractor shall describe and demonstrate the strategy for reducing product or system and associated supportability costs through insertion of COTS and other reusable COTS or NDI products. The contractor shall establish a process to logistically support COTS or NDI products. The contractor shall describe the availability of commercial repair parts and repair services, facilities, and manpower required for life cycle support and demonstrate they are adequate to ensure long term support for COTS or NDI products. The contractor shall provide the proposed methodology for pass through of COTS warranties to the Government.

1.7.14 Use of Standards

In designing the system(s), the contractor shall use the following standards in descending order of importance:

• Standards as specified within the contract

• Commercial standards o Standards developed by international or national industry standards bodies that have been widely adopted by industry. Examples of widely adopted standards are:

SQL for databases (e.g., SQL for databases ANSI ISO/IEC 9075-1, ISO/IEC 9075-2, ISO/IEC 9075-3, ISO/IEC 9075-4, ISO/IEC 9075-5)

HTML for presentation layer (e.g., XML 1.0 www.webstandards.org)

XML for data transfer

Web services for remote system calls o Standards adopted by industry consensus-based standard bodies and widely adopted in the market place.

o De facto standards (those widely adopted and supported in the market place).

Note: Standards that are not specified within this contract or that are modified must be submitted to and approved by the Government Program Manager prior to use.

1.8 Software Engineering Approach

1.8.1 Software Engineering

The Contractor shall define a software development approach appropriate for the computer software effort to be performed under this solicitation. This approach shall be documented in a Software Development Plan (SDP) (CDRL A015). The contractor shall follow this SDP for all computer software to be developed or maintained under this effort.

The SDP shall define the Offeror's proposed life cycle model and the processes used as a part of that model. In this context, the term “life cycle model” is as defined in IEEE/EIA Std. 12207.0.

The SDP shall describe the overall life cycle and shall include primary, supporting, and organizational processes based on the work content of this SOW. In accordance with the framework defined in IEEE/EIA Std. 12207.0, the SDP shall define the processes, the activities to be performed as a part of the processes, the tasks which support the activities, and the techniques and tools to be used to perform the tasks. Because IEEE/EIA Std. 12207 does not prescribe how to accomplish this task, the Offeror shall provide this detailed information so the Government can assess whether the Offeror’s approach is viable.

The SDP shall contain the information defined by IEEE/EIA Std. 12207.1, section 5.2.1 (generic content) and the Plans or Procedures in Table 1 of IEEE/EIA Std. 12207.1. In all cases, the level of detail shall be sufficient to define all software development processes, activities, and tasks to be conducted. Information provided must include, at a minimum, specific standards, methods, tools, actions, strategies, and responsibilities associated with development and qualification.

The Contractor shall provide a Software Requirements Specifications (SRS) (CDRL A016) which will provide a complete description of the behavior of a system to be developed, and shall enlist all necessary requirements that are required for the project development; a Software Design Description (SDD) (CDRL A017) to specify the system architecture; and a Requirements Traceability Verification Matrix (RTVM) (CDRL A018).

The Contractor shall provide a Software Installation Plan (SIP) (CDRL A019) for installing software at both SWFLANT and SWFPAC; and a Software Transition Plan (STrP) (CDRL A020) that shall identify the resources needed for life cycle support of deliverable software and describe the developer's plans for transitioning deliverable items to SWFLANT and SWFPAC

1.8.2 Software Code Walkthroughs

The Contractor shall conduct periodic code walkthroughs during the development Phase. Senior technical personnel from the development team shall review the code and unit test plans that have been developed for a Technical Design Specification (TDS). The purpose of the review is to identify that the code adheres to the program’s development standards, is technically sound, meets the design articulated in the related TDS, and that the unit test plan for the code under review is documented in accordance with QA/Test standards as defined. The Government reserves the right to have one or more representatives, on a not-to-interfere basis, observe any and all code walkthroughs and create a detailed report.

1.8.3 Data Management and the Integrated Digital Environment (IDE)

The Contractor shall establish and maintain a data management program, as well as a secure Integrated Data Environment (IDE) for hosting all technical data and computer software used or produced in the performance of this contract. Program management information such as cost, risk and schedule data can also be hosted in the IDE.

The purpose of the IDE is to create a seamless, collaborative data environment for the Contractor and Government team, which contains all pertinent data about the project throughout its development and delivery. This data management program, including IDE structure, format, processes, and procedures, shall be documented as part of the contract Program Management Plan.

The Contractor shall provide the Government team access to and the ability to download and use all data posted to the IDE, whether or not listed in a CDRL. For all data posted to the IDE (whether or not listed in a CDRL), the Government team’s rights to use shall be defined by the DFARS clauses and prescriptive sections. All items posted to the IDE, including drafts of deliverables that are not final versions, shall be considered delivered for purposes of the DFARS data rights clauses (and subject to the same rights asserted for final deliveries). However, these non-final versions shall not constitute acceptance for purposes of Inspection and Acceptance requirements or the DFARS data rights clauses. The DAL shall contain the list of all data developed or used in the performance of work under this contract. Deliveries of data, in addition to the IDE, shall be as indicated in the CDRL attachment; delivery and subsequent distribution of technical data and computer software may be in storage media other than paper, including direct electronic exchange of data between two computers. The DAL shall be updated via a delivered data item each month, provided as an attachment to the Monthly Status and Progress Report, which shows the data added each month (incremental reporting). The procedures must provide for the identification of any portions of the data provided with restrictive legends. The acceptance criteria must be consistent with the authorized delivery format.

Data (technical data and computer software) shall be protected in accordance with the appropriate Program Protection Plans and Information Assurance guidelines. The Government reserves the right to witness all contractor efforts to accomplish the Statement of Work (SOW) requirements and maintains the right to comment on processes.

The Contractor who operates and maintains the IDE shall indemnify the Government from any liability to data owners or licensors resulting from, or as a consequence of, a release or disclosure of technical data and computer software made by this IDE contractor or its officers, employees, agents, or representatives.

All computer software and technical data developed or used in the performance of work under this Contract in whole or in part with Government funds and posted to the IDE shall be delivered with at least Government Purpose Rights, as defined in DFARS clauses 252.227.7013, -7014, and -7017 and appropriately marked as such unless a waiver has been submitted and approved by the Government. In this context, technical data and computer software developed or used in the performance of work under this contract do not include embedded open source software or COTS software products which must be identified to the government and the respective licenses provided. A scan report verifying the appropriate markings, including distribution statement, copyright statements, open source software, security classification and data rights shall be delivered with the data. In addition, structural and descriptive metadata shall be provided with all final computer software and technical data.

The Contractor shall comply with the requirements of the DD 254 for implementation of the IDE and to ensure proper safeguarding of classified materials, events and processes. This shall include documentation developed by the Contractor or received in support of working groups and IPTs.

1.8.4 Product Reuse Demonstration

The Contractor shall consider use of third-party products that may be innovative or new to the Government and provide compelling system performance improvements or best value. In particular, the Government’s goal is to encourage contractors to reuse software and components, especially in cases where the Government has Government Purpose Rights (GPR) or greater rights. As part of system acceptance, the contractor shall demonstrate the steps necessary to give third parties, as directed by the Government, the ability to integrate their components into the contractor’s solution. This effort shall be comprehensive and require the contractor to perform the following activities:

1.8.4.1 Inventory

A detailed inventory of all code files in the product baseline shall be conducted. This inventory shall extend to all third-party software not delivered within the terms of the contract but used in the system to form the working product. Third-party product descriptions and version information shall be required for all operating systems, applications, middleware, and device drivers.

1.8.4.2 Inspection

File headers and any other company markings found in the source code shall be inspected to ensure clear indication that the Government has GPR to use the software delivered in the contract.

1.8.4.3 Build Procedure Development

A build procedure shall be developed in sufficient detail to allow a third party to recreate the operational system on a compatible processing platform. This build procedure shall address the results of the code inventory and inspection to account for software that is not deliverable due to proprietary rights limitations such that the user can still complete the installation process.

1.8.4.4 Conduct Demonstration

The Contractor shall conduct a formal demonstration of the build process using the product baseline software and approved procedures to show the software can be successfully ported to other third-party compatible open architecture processing systems.

ITEM 0002 – Technical Support (FY15 Option) (FFP-LOE) (O&MN) During the period from the exercise of option through twelve (12) months after exercise of option, the Contractor shall make available and employ its facilities, personnel at the level of effort set forth in Section F, services of others, and materials, and shall use its best efforts to provide operational support, maintenance, software fixes, and functional improvements to the Security Forces Qualification and Certification Management software application tool, as described under Item 0001.

• The Contractor shall issue software patches to address changes in the needs of the organization, to correct issues relating to bugs in the software or to resolve potential security issues.

• The contractor shall maintain, update and/or create application configuration management data in accordance with Navy requirements. This configuration management data shall consist of application source code, technical and user documentation, change control records, code review results, unit tests, code coverage records and other required data.

• The contractor shall maintain, update and/or create system life cycle management data in accordance with Navy requirements.

• The Contractor shall submit a plan for migrating away from unsupported software/hardware at least 6 months prior to the product EOL date.

• The Contractor shall apply security patches in accordance with Navy requirements.

• The Contractor shall ensure that application updates do not degrade the security of the application such that the application is no longer compliant with DoD, Navy and SSP IA policies.

• The Contractor shall assist the government in analyzing the impact of changes in IA policy, to include: required software modifications, documentation revisions, staff re-training, product or tool recommendations, level of effort requirements and related schedule impacts.

• The Contractor shall monitor IA compliance by performing STIG checks and inspections as required and provide documented results to the government.

• The Contractor shall complete an annual IA review and provide documented…