finalNovember10RFI.pdf

REQUEST FOR INFORMATION (RFI)

FOR USPTO’S CONTINUOUS DELIVERY AUTOMATION

RFI PROC1500139

THIS IS A REQUEST FOR INFORMATION (RFI) BEING RELEASED

PURSUANT TO FEDERAL ACQUISITION REGULATION (FAR) PART 10:

MARKET RESEARCH. THIS IS A REQUEST FOR INFORMATION (RFI) ONLY.

The purpose of this RFI is to determine if there are firms capable of providing the

USPTO with all the services as described in this RFI. This RFI is issued by the United

States Patent and Trademark Office (USPTO) solely for information and planning purposes; it does not constitute a Request for Quote (RFQ) or a promise to issue an RFQ.

This RFI does not commit the Government to contract for any supply or services. The

USPTO is not seeking proposals at this time. It is the intent of the USPTO to use this market research to assist in planning. The Government will not pay any costs incurred in response to this RFI. All costs associated with responding to this RFI will be solely at the interested party’s expense. It is the responsibility of the interested parties to monitor the

Federal Business Opportunities (www.fbo.gov) site for additional information pertaining to this RFI. The Government does not intend to award a contract on the basis of this RFI or to otherwise pay for the information solicited.

This RFI includes information that was published in RFI-PROC-1400226 as well as additional requirements. Offerors are encouraged to provide responses to this RFI; only

RFI responses specific to this RFI will be used for market research related to the services included in this RFI.

1.0 RFI OBJECTIVE:

The objective of this RFI is to conduct information technology market research for support services to improve, maintain and sustain the Continuous Integration

Configuration Management (CICM) platform and the associated continuous delivery processes; and to enable the OCIO to transform its practices into a DevOps model. This

RFI is in support of the Office of the Chief Information Office’s (OCIO) mission to transform the system development culture at USPTO into a DevOps model, align the configuration management practices of ECMD to the DevOps model and streamline processes and properly configured tool(s) to provide sophisticated configuration management services. The USPTO seeks market information and to identify firms with the capability to provide solutions to the RFI objective as stated above. The following:

a) The USPTO has a continuing requirement for Continuous Integration

Configuration Management (CICM and Continuous Delivery contractor(s) to provide technical expertise, engineering services, assistance and training for the ongoing effort to mature the central configuration management system called the

CICM.

b) The USPTO has a requirement to provide maturity in the existing CICM platform

c) The USPTO has a requirement for technical services that include planning, design, development and implementation of continuous integration, configuration management and continuous delivery capabilities

2.0 REQUIREMENTS

The OCIO has identified various Information Technology requirements that have been highlighted below. Any potential services would be performed with an integrated team that includes USPTO staff, other USPTO Contractors and outside vendors. The USPTO has provided an overview of identified needs for technical support services in the following areas:

2.1 Continuous Integration Configuration Management Platform Maturity

a) Support for source code management that implements a standard for source control that includes the maintenance of a master repository containing the master branch and a development branch for each one of the developers contributing to the project, along with release, fix and feature branches, as necessary through the use of the existing Subversion in the CICM platform.

b) Technical services for the development of the Continuous Integration Common

Practices repository; provide the capability for the repository to be integrated to the existing CICM platform for an integrated portal that will house all the standard practices for application development.

c) Technical services in maturing the existing lightweight Application Lifecycle

Management (ALM) tool to achieve a full featured Agile Application lifecycle management (ALM) tooling that provides a fully auditable and traceable path from a user requirement to an application in production.

2.2 Continuous Delivery

a) Technical support for developing standard deployment management and release automation that uses the existing Maven/Ant technologies; develop and establish

CICM development policy that describes a more homogeneous implementation employed in the development environment.

b) Support for Build Management that will use the current build automation implemented in the CICM platform using the Jenkins and Nexus technologies;

develop scripts to provide homogeneous build methods for both legacy and Next

Gen applications.

c) Support for onboarding project to the CICM platform; fully migrate all legacy projects to the CICM platform; develop an onboarding process that will not only migrate the AIS source code into the CICM platform but also mature the deployment process of the project so that it can utilize and take advantage of the benefits of a more automated deployment pipeline.

d) Support for Build Management on the transitioning legacy CM environment

(ClearCase); perform manual builds; manage ClearCase environment; manage the remaining transition from ClearCase to CICM.

2.3. Platform Service Support

a) Support to Platform Services in developing an inventory management system to house all the information necessary to provision development workstations, testing servers and development and platform tools for easy self-service access and well-defined control of all development assets

b) Technical services in establishing standards of using only the tools and assets from within the documented inventory, reducing unknown system components or potentially insecure tools and configurations

2.4 Quality Testing

a) Technical services in automating static analysis on a nightly basis that validates code checked-in if it meets specific requirements per the guidelines provided by the Application Engineering and Development (AED); examine the code for layout issues, comments, javadocs, etc., the metrics of the validated are posted in the Sonar dashboard

b) Support in automating unit testing using the JUnit as a framework for Java code.

c) Technical services in code coverage testing that is automatically performed on a nightly basis and includes the calculation of the amount of code accessed by the unit tests and yield result for code coverage; post results in the Sonar dashboard and notify stakeholders of the result.

2.5 Configuration and Change Management

a) Provide Change Management support to capture modifications to the IT services configuration items; recommend changes to streamline the current change management process

b) Provide configuration management support to improve the ECMD Records database to monitor the change status of configuration items; provide a robust data source for the Physical Configuration Audit (PCA); perform the PCA, establish a centralized Configuration Management Database that will house all the applications’ configuration items to facilitate identification, status monitoring and audit

2.6. Program/Project Management Support

2.7. DevOps Transformation Consulting

a) Support for DevOps Cultural Transformation initiative; provide mentoring on

DevOps cultural transformation that will be driven by the principles of collaboration, trust between teams and continuous improvement of processes

b) Support for the alignment of Agile Software Development to DevOps Model;

identify the gaps between the Development and Operations processes; develop a technical approach to implement DevOps practices

c) Technical services in architecture and tools choices; inventory the existing tools used by infrastructure, platform deployment, configuration management, and software deployment teams and develop a roadmap to bridge disparate tools towards full automation

d) Technical services in Process Optimization; support in directing the agency to intelligently reduce the time spent on tasks that can be automated; assist the teams in process improvement between Dev and Ops, and eliminate reliance on ad-hoc tools.

e) Support in validation and value measurement in organizing and implementing of a

DevOps model within OCIO; define metrics that will guide the choice of tools and automation of processes, identify an eligible project for DevOps proof of concept and define upstream targets.

2.8 Quality Assessment and Metrics

Provide enterprise quality management (not testing) activities in support of business area, infrastructure and automated information systems. The QA activities are a disciplined set of techniques for planning, reviewing, and measuring processes, and products to ensure that they are acceptable to the business area and the CIO. Quality

Management will be oriented toward prevention and not testing. The goal of the quality management program is to design quality into all aspects of system development projects.

3.0 ACQUISITION STRATEGY (OPTIONAL):

If an acquisition is conducted as a result of this RFI, proposed strategy input is welcome from companies who respond to this RFI. The USPTO will consider the technical capabilities and solutions offered as a result of this RFI. The respondent is encouraged to identify and provide any unique solutions that will result in effective/efficient operations. Acquisition strategy should address contract type such as BPA or IDIQ. The USPTO also desires input into a fixed price strategy based on deliverables for the requirements described in this RFI.

4.0 RFI RESPONSES

4.1 RFI Response Content

This RFI seeks to obtain information from a broad community on the availability of similar implementation and administration of similar platforms in other Federal agencies. Offerors shall provide a written response not to exceed 12 pages including a cover page (optional) that address the following:

a) Point of Contact Name, Company Name, Address, Email, Phone, DUNS number, CAGE code;

b) A capability statement with reference to the Section 1 Objective, each of the requirements included in Section 2 and optional acquisition strategy solutions as included in Section 3. The information needs to provide a detailed description of the approach in implementing a platform that will support a full life cycle software development operations from requirements management to post deployment assessment with the above feature set included as well as speak to the experience with similar platform administration;

c) An indication of whether teaming is intended, and if so, identification of each vendor involved in the team, and the role of each contractor;

d) The applicable GSA Schedule number(s) for each vendor involved in the response;

e) At least three past performance references for work performed for same or similar services, and/or any product solutions performed as a prime contractor (for each reference include contact name, contact organization, telephone number, email, award value, award period of performance, a brief description of the tasks completed, and include an annotation of Section 2 USPTO requirements 2.1-2.8 to show similarity of services);

f) For each vendor responding to this RFI, provide the business size for NAICS

541519 (Other Computer Related Services, $27.5 million);

g) An indication of interest in responding to a solicitation, should one be issued.

4.2 Instructions for RFI Responses:

Responses must be submitted electronically to the e-mail address below:

U.S. Patent and Trademark Office

Office of Procurement

ATTN: Dennis Jolliffe

EMAIL: Dennis.Jolliffe@uspto.gov

Respondents must submit their responses via email in pdf. format no later than

November 17, 2014 at 10 AM Eastern time. Please submit responses via e-mail to Dennis.Jolliffe@uspto.gov, Contract Specialist. The response should be no more than 12 pages in length and no larger than 5 megabytes and should use font size 12 or larger.

Proprietary information submitted in response to this RFI will be protected from unauthorized disclosure as required by the Federal Acquisition Regulation (FAR).

The respondent shall identify where data is restricted by proprietary or other rights and mark it accordingly. All proprietary markings should be clearly delineated.

4.3 RFI Response Due Date

November 17, 2014 at 10 AM Eastern Standard Time (EST)

4.4 Clarification of RFI Responses

To fully comprehend the information contained within a response to this RFI, there may be a need to seek further clarification from those respondent(s). This clarification may be requested in the form of brief verbal communication by telephone; written communication; electronic communication; or a request for a presentation of the response to a specific USPTO group or groups. The USPTO reserves the right to seek additional information from vendors.

4.5 USPTO’s Current Platform

The USPTO’s requirements as stated in this RFI are based on a platform built by

Steel Thread Software, Inc. The USPTO required an architectural solution for a

Subversion environment to move USPTO away from the multitude of environments in use to a common development platform to simplify

Configuration Management and other operational disciplines at USPTO. In 2013, Steel Thread Software, Inc. was able to meet the USPTO’s requirement by providing a unique social coding platform that integrates social networking and collaboration capabilities with application lifecycle management. This particular social coding platform was essential to meet the USPTO's requirement.

The USPTO current platform is built upon open source products (Subversion, Jenkins, nexus, sonar, maven, ant).