SOW for SDL-Xysoft.docx

STATEMENT OF WORK

Section 1. Objective

Bureau of Labor Statistics (BLS) has a need to acquire professional services that will maintain, enhance, configure, and offer training to support SDL-XyEnterprise’s Professional Publisher (XPP) System in use by BLS. This software takes data and text as input (XML format) and produces PDF output to be published to the agency website. This system as implemented will reside in BLS offices in the Postal Square Building, and be operated and administered by BLS personnel.

Section 2. Background

BLS is the principal fact-finding agency for the Federal Government in the broad field of labor economics and statistics. BLS is an independent national statistical agency that collects, processes, analyzes, and disseminates essential statistical data to the American public, the U.S. Congress, other Federal agencies, State and local governments, business, and labor.

BLS has transitioned more and more of its data and content to the web (http://www.bls.gov) and reduced what’s available on print. Print friendly formats such as PDF are now available on the website instead of being mailed to customers.

One of the primary methods for representation of BLS data, either in print or electronic form, is through the use of statistical tables. Representation of tables in a print environment is more complex than it is in a web environment due to the more restrictive size of a standard printed page verses the virtually unlimited size of a web page. Currently BLS requires substantial manual manipulation of the layout for printed output to ensure that tables, and to a lesser degree, text and graphics are displayed in a sensible and readable fashion.

The goal is for BLS to have a system that extracts the data and content from a central database which is transformed into formatted pages for display on the Bureau’s website in a printer-friendly, particularly PDF.

Section 3. Scope of Work

SDL-XySoft Professional Services shall provide support for additional functionality and enhancement to the currently deployed system at BLS. The objectives of the contract are defined as follows:

· Additional analysis, design, customization and documentation

· Collaborative development to solve technical challenges

· Training of BLS staff where necessary to maintain developed system

3.1 Tasks

3.1.1. Analyze formatted examples, as identified in Section 7 of the Statement of Work, and develop a system that will convert the text and statistical table requirements to the same layout and format as the examples provided, and in a PDF format that is suitable for posting to the web and for print.

3.1.2. Develop reusable templates that will allow the conversion of text (in XML) that require similar formatting to PDF format for the web and print

3.2 Deliverables

3.2.1 A software system that supports web publishing as follows:

· Content publishing ( in PDF)

· Layout management (templates, variants)/ Styles

· Scripts for controlling styles

3.2.2 Source code for all executable software developed in response for this project.

3.2.3 Reusable templates for the conversion of XML to PDF.

3.2.4 Documentation of the system that is built including all licensing information for any COTS software used in this solution.

3.3 Requirements

3.3.1 The text and other content in XML is defined by BLS. The solution shall use this input.

3.3.2 The solution shall provide a default presentation layout for any XML page/table, which can be manually adjusted by a BLS designer or user of the software system..

3.3.3 Once a page/table presentation layout (template) has been defined, the conversion of XML content to PDF format shall be fully automated and will require no manual intervention at run time.

3.3.4 Multiple layouts of XML tables/pages shall be supported including features that support creation of ad-hoc (one-time) formats as suitable to a particular need.

3.3.5 The PDF shall be in black and white and contain statistical tables of varying length, text, graphics, header and footer information, footnotes, and may contain multiple fonts.

3.3.6 The layout of the statistical tables shall support multiple levels of nested column headings, spanned across columns, and multiple levels of nested row headings, indicated through indentation.

3.3.7 Statistical tables will vary in length and some will extend over multiple pages. Long tables shall be broken across page boundaries at appropriate places, with the position of page breaks to be automatically determined by the software (allowing for a manual override where necessary.)

3.3.8 Column header information and footnotes shall be repeated on new pages when tables span multiple pages.

3.3.9 Tables shall have a varying number of columns. The default size of each column must be automatically determined by its contents, with the possibility of design-time overrides of the defaults.

3.3.10 Columns containing Numeric data shall be wide enough to display the data and associated footnotes on one line (subject to the constraints of page width.)

3.3.11 Columns and headers containing text shall be hyphenated as needed to fit within the boundaries of the cell.

3.3.12 Table layouts shall support decimal-point alignment when specified for a particular column

3.3.13 The solution shall run on a Windows or Unix-Solaris platform in order to be compatible with the existing production environment.

3.3.14 The solution should be capable of running in a virtualized environment.

3.3.15 The solution shall be capable of running in an IPv6 environment, or documented plans shall exist for a timetable for implementation of any necessary enhancements required for proper functionality in an IPv6 environment.

3.3.16 A single instance of the system shall be capable to handle up to 20 users accessing simultaneously. The system shall be able to scale up to support more user access if necessary.

3.3.17 The solution would be compatible with 1024-bit SSL certificates.

3.4 Constraints

3.4.1. The vendors must provide a statement of how the applicable Federal 508 requirements are addressed.

3.4.2. The source XML datasets specify content and structure. As such they do not, and should not, contain presentation information. Style sheets containing presentation information do not currently exist.

3.5 Acceptance and Quality Control

3.5.1 All software (and hardware if applicable) will be evaluated in a simulated BLS . computing environment to determine that the solution meets the functional and system requirements set forth in this document as well as BLS security, networking, and usage guidelines applicable to software and hardware permitted to run in the BLS computing environment

3.5.2 Acceptance shall be further defined as beneficial use by BLS. Acceptance will be deemed “in full” upon receipt by the Vendor of a Notice of Acceptance issued by BLS upon beneficial use and full implementation of the Terms and Conditions and Technical Specifications of the Contract. Upon receipt of the Notice of Acceptance, The Vendor shall notify BLS in writing of a release of all liens for all materials and services associated with this project.

3.5.3

Section 4. Contractor Qualifications

4.1 The contractor shall provide a Project Manager who will act as a single point of contact for all activities regarding this project.

4.2 The selected contractor shall be fully capable and experienced in the use and implementation of SDL-XySoft’s Professional Publisher. To ensure the system has continued support, BLS will contract only with vendors demonstrating a successful history of implementing XPP. During the evaluation process, BLS may, with full cooperation of the vendors, visit the vendors’ places of business, observe operations, and inspect records.

4.3 BLS may, with full cooperation of the vendors, visit reference clients. Specified visits and discussion shall be arranged through the vendors.

Section 5. Data

BLS will own all products outputted from this project except where licensed COTS software is used. In the case of COTS BLS shall receive all rights and benefits of usage for the duration of the licensing period for any licensed COTS software that is included in the solution.

Section 6. Security and Clearance

6.1 The contractor is subject to BLS standard security guidelines and privacy agreements.

6.2 The contract r shall comply with agency personal identity verification procedures that implement HSPD-12, OMB guidance M-05-24, and FIPS Pub 201.

6.3 The contractor shall insert this clause in all subcontracts when the subcontractor is required to have physical access to a Federal controlled facility or a access to a Federal information system.

Section 7. Government-Furnished Property

7.1 COTS software and licenses

7.2 XPP software and maintenance licenses

7.3 XML datasets and desired sample tables.

Section 8. Period of Performance Base Period = Date of Award (DOA) to 12 Months from DOA Option Period 1 = 12 Months after DOA to 24 Months after DOA Option Period 2 = 24 Months after DOA to 36 Months after DOA

Section 9. On Site Place of Performance United States Bureau of Labor Statistics, 2 Massachusetts Ave. N.E.

Washington, DC 20210

Section 10. Billing and Payment A progress payments clause is not included in this solicitation, and will not be added to the resulting contract at the time of award. All work shall be performed and completed prior to assurance of the Notice of Acceptance

Section 11. Payment Procedures

11.1. Monthly invoices shall be submitted electronically, via email, to the email addresses listed below:

11.2. To constitute a proper invoice, the following data and certification must be included in the invoice:

3. For prompt payment purposes, the prompt payment time begins when BLS receives the invoice from the Contractor. Payment will be made upon approval by the Finance Manager. Payment shall be made within thirty (30) calendar days after receipt of invoice.

4. If there are any invoice discrepancies, the Finance Manager will complete the preliminary review of the invoice(s) and notify the Contractor within three (3) working days after receipt.

Section12. Other Clauses and Provisions

12.1 Contingencies

The Contractor shall ensure continuity of operations throughout the duration of this contract. The Contractor shall be responsible for maintaining continuity of support for all work under this contract. Contractor employment and staffing difficulties will not be acceptable justification for failure to meet the requirements of the Performance Work Statements of the contracts.

As applicable and upon request by the Contracting Officer, the Contractor shall submit a contingency plan to the CO for approval by BLS. The plan shall outline the Contractor’s response to operational problems and unusual events that may occur during the life of the contract and disrupt operations. For example, a structural fire, accident, terrorist attack, personnel strike, extended power failure, etc., may require the Contractor to proceed under altered work conditions at locations other than those originally established. The Contractor shall continue to provide the services required by the contract, as directed by the CO or COTR, for the duration of such an emergency situation.

12.2 Training

The Contractor is responsible for ensuring that its staff is fully trained and qualified to perform assigned duties and responsibilities under this contract. If the Contractor provides technical staff with applicable certifications, the Contractor shall assure that its staff maintains such certifications throughout the life of the contract. The Contractor shall provide staffing with expertise that is current and shall ensure that its staff maintains a satisfactory level of knowledge and skills necessary to perform assigned tasks. Contractor staff shall not perform tasks they are not qualified to carry out.

12.3 Removal of Contractor Personnel

The CO may require removal from work on a contract of those Contractor employees who he/she deems incompetent, careless, insubordinate, unsuitable or otherwise objectionable, or whose continued employment on the contract he/she deems contrary to the public interest or inconsistent with the best interests of the BLS.

In the event that the performance of assigned Contractor personnel or any substitute(s) is determined by the BLS to be unsatisfactory at any time during the life of the contract, the BLS reserves the right to request and receive satisfactory personnel replacement within five (5) calendar days of receipt by the Contractor of written notification. To the extent permitted by law, the BLS’s written notification shall include the reason for requesting replacement personnel.

12.4 BLS IT Security Provisons

12.4.1

GENERAL

The contractor shall agree to maximize the security of the software development throughout the term of this contract according to general industry standards including but not be limited to the following terms and conditions.

The contract shall clarify the security-related rights and obligations of all the parties to a software development relationship including any third-party contractors, subcontractors or other entities hired by the contractor.

The contractor shall agree in writing that the terms of this contract shall apply to contractor's employees, as well as to third party contractors and subcontractors that will be employed by contractor for the contract.

The contract shall take all actions necessary to protect information regarding security issues and associated documentation, to help limit the likelihood that vulnerabilities in operational Government software are exposed.

Consistent with the provisions of this contract, the contractor shall use the highest applicable industry standards for sound secure software development practices to resolve critical security issues as quickly as possible. The "highest applicable industry standards" shall be defined as the degree of care, skill, efficiency, and diligence that a prudent person possessing technical expertise in the subject area and acting in a like capacity would exercise in similar circumstances.

Personnel The contractor shall identify in writing the person who will be responsible for overall security of the application development, management, and update process throughout the contract period. The person identified shall be a single senior technical security specialist, to be known as the project Security Lead. The Security Lead shall certify in writing the security of each deliverable.

Security Training The contractor shall be responsible for verifying that all members of the developer team have been successfully trained in secure programming techniques.

The contractor shall document the process including training courses that their application developers have taken prior to developing applications under this contract.

The contractor shall certify to the Government that only application developers who have received appropriate level of formal training on secure application development and passed a competency test on application security shall be involved in the contract.

Background Checks of Developers The contractor shall perform appropriate background investigation of all development team members and shall certify that all individuals who will be involved in this contract and the software development process have cleared the background investigation.

Vulnerabilities, Risks and Threats The contractor shall agree in writing that they will strive to identify vulnerabilities, risks and threats as early as possible at any time during the software lifecycle. The software lifecycle shall mean from development, management, and updates through retirement of such application.

The contractor shall identify the key risks to the important assets and functions provided by the application. The contractor shall conduct an analysis against an industry-recognized list of common programming errors – such as the SANS Top 25 Most Dangerous Programming Errors – and document in writing that they have been mitigated. The contractor shall conduct risk assessment(s) to determine and prioritize risks, enumerate vulnerabilities and understand the impact that particular attacks might have on an application to ensure it meets applicable contractual obligations, regulatory mandates and security best practices and standards.

The contractor shall share with the Government in writing all security-relevant information regarding the vulnerabilities, risks and threats to the application immediately and completely upon identification. Such security documentation shall describe security design, risk analysis, or issues.

Application Development The contractor shall provide the Government written documentation detailing their application development, patch management, and update processes. The documentation shall clearly identify the measures that will be taken at each level of the process to develop, maintain and manage the software securely.

The contractor shall provide secure configuration guidelines in writing to the Government that fully describe all security relevant configuration options and their implications for the overall security of the software. The guideline shall include a full description of dependencies on the supporting platform, including operating system, web server, and application server, and how they should be configured for security. The default configuration of the software shall be secure.

The contractor shall follow NIST security guidance SP800-53 Rev 3. Recommended Security Controls for Federal Information Systems and Organizations and SP800-64 Rev. 2 Security Considerations in the System Development Life Cycle in the application software lifecycle.

The contractor shall specify in writing to the Government what additional industry security standards and level of care that they follow.

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

12.4.2

DEVELOPMENT ENVIRONMENT

(a) Secure Coding The contractor shall disclose what tools are used in the software development environment to encourage secure coding.

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

(c) Distribution The contractor shall use a build process that reliably builds a complete distribution from source. This process shall include a method for verifying the integrity of the software delivered to the Government.

(d) Disclosure The contractor shall document in writing to the Government all third party software used in the software, including all libraries, frameworks, components, and other products, whether commercial, free, open-source, or closed-source.

(e) Evaluation The contractor shall make reasonable efforts to ensure that third party software meets all the terms of this agreement and is as secure as custom developed code developed under this agreement.

12.4.3

TESTING

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

(b) Source Code The contractor shall agree in writing to the Government that during the application development lifecycle process the source code shall be evaluated to ensure the requirements of this contract including the security standards, policies and best practices are followed. The contractor shall have a well-documented procedure and framework for conducting code reviews.

(c) Vulnerability and a Penetration Test The contractor shall agree in writing that prior to production the application shall undergo vulnerability and a penetration test.

Post production, the contractor shall perform contractually agreed upon security scans (with the most current signature files) to verify that the system has not been compromised during the testing phase.

The contractor shall provide to the Government written documentation of the results of the scans and tests along with a mitigation plan.

The contractor shall agree in writing that these vulnerabilities shall be mitigated within a pre-negotiated period.

Patches and Updates The contractor shall provide notification of patches and updates affecting security within a pre-negotiated period as identified in the patch management process throughout the software lifecycle.

The contractor shall apply, test, and validate the appropriate patches and updates and/or workarounds on a test version of the application before distribution.

The contractor shall verify and provide written documentation that all updates have been tested and, prior to production, installed.

The contractor shall verify application functionality, based upon pre-negotiated procedures, at the conclusion of patch updates, and provide documentation of the results.

Tracking Security Issues The contractor shall track all security issues uncovered during the entire software lifecycle, whether a requirements, design, implementation, testing, deployment, or operational issue. The risk associated with each security issue shall be evaluated, documented, and reported to Government as soon as possible after discovery.

12.4.4

DELIVERY OF THE SECURE APPLICATION

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

The contractor shall resolve all security issues that are identified before delivery. Security issues discovered after delivery shall be handled in the same manner as other bugs and issues as specified in this agreement.

Self-Certification The Security Lead shall certify to the Government in writing that the software meets the security requirements, all security activities have been performed, and all identified security issues have been documented and resolved. Any exceptions to the certification status shall be fully documented with the delivery.

No Malicious Code Developer warrants that the software shall not contain any code that does not support a software requirement and weakens the security of the application, including computer viruses, worms, time bombs, back doors, Trojan horses, Easter eggs, and all other forms of malicious code.

12.4.5

SECURITY ACCEPTANCE AND MAINTENANCE

Acceptance The software shall not be considered accepted until the contractor certification package is complete and all security issues have been resolved.

Investigating Security Issues After acceptance, if security issues are discovered or reasonably suspected, the contractor shall assist the Government in performing an investigation to determine the nature of the issue.

12.5 FAR Subpart 17.1 – Multi-Year Contracting

17.104 General.

(a) Multi-year contracting is a special contracting method to acquire known requirements in quantities and total cost not over planned requirements for up to 5 years unless otherwise authorized by statute, even though the total funds ultimately to be obligated may not be available at the time of contract award. This method may be used in sealed bidding or contracting by negotiation.

(b) Multi-year contracting is a flexible contracting method applicable to a wide range of acquisitions. The extent to which cancellation terms are used in multi-year contracts will depend on the unique circumstances of each contract. Accordingly, for multi-year contracts, the agency head may authorize modification of the requirements of this subpart and the clause at 52.217-2, Cancellation Under Multi-year Contracts.

(c) Agency funding of multi-year contracts shall conform to the policies in OMB Circulars A-11 (Preparation and Submission of Budget Estimates) and A-34 (Instructions on Budget Execution) and other applicable guidance regarding the funding of multi-year contracts. As provided by that guidance, the funds obligated for multi-year contracts must be sufficient to cover any potential cancellation and/or termination costs; and multi-year contracts for the acquisition of fixed assets should be fully funded or funded in stages that are economically or programmatically viable.

(d) The termination for convenience procedure may apply to any Government contract, including multiyear contracts. As contrasted with cancellation, termination can be effected at any time during the life of the contract (cancellation is effected between fiscal years) and can be for the total quantity or partial quantity (where as cancellation must be for all subsequent fiscal years’

FAR 52.217-4 Evaluation of options exercised at Time of Contract Award (Jun 1988)

Except when it is determined in accordance with FAR 17.206(b) not to be in the Government’s best interests, the Government will evaluate the total price for the basic requirement together with any option(s) exercised at the time of award.

FAR 52.217-8 Option to Extend Services (Nov 1999)

The Government may require continued performance of any services within the limits and at the rates specified in the contract. These rates may be adjusted only as a result of revisions to prevailing labor rates provided by the Secretary of Labor. The option provision may be exercised more than once, but the total extension of performance hereunder shall not exceed 6 months. The CO may exercise the option by written notice to the Contractor within 30 days prior to the expiration of the contract term.

FAR 52.217-9 Option to Extend the Term of the Contract (Mar 2000)

(a) The Government may extend the term of this contract by written notice to the Contractor within 7 days prior to the expiration of the contract term; provided that the Government gives the Contractor a preliminary written notice of its intent to extend at least 30 days before the contract expires. The preliminary notice does not commit the Government to an extension.

(b) If the Government exercises this option, the extended contract shall be considered to include this option clause.

(c) The total duration of this contract, including the exercise of any options under this clause, shall not exceed 60 months years.