J-1_Description_of_Services_SPARC.pdf

Section J -1 Strategic Partners Acquisition Readiness Contract

Department of Health and Human Services

Centers for Medicare & Medicaid Services Strategic Partners Acquisition Readiness

Contract (SPARC)

Section J -1 Strategic Partners Acquisition Readiness Contract

Statement of Work

Contract #: RFP-CMS-2016-SPARC

July 20, 2015

. i ii

Table of Contents

J.1 Strategic Partners Acquisition Readiness Contract Services

J.1.2 Requirements Services J.1.3 Design Services

J.1.3.1 Design Software Services

J.1.3.2 Database Services J.1.3.3 System Integration Services

J.1.4 Development Services J.1.4.1 Design Software Services J.1.4.2 Database Services

J.1.4.3 System Integration Services

J.1.5 Test Services J.1.5.1 Unit Testing

J.1.5.2 Functional Testing J.1.5.3 Application/Integration Testing

J.1.5.4 Section 508 Testing

J.1.5.5 System Regression Testing J.1.5.6 Performance & Stress Testing

J.1.5.7 End-to-End Integration Testing

J.1.5.8 Acceptance Testing J.1.5.9 Implementation Testing

J.1.5.10 Compatibility Testing

J.1.5.11 Testing Coordination J.1.6 Security Control Assessment (SCA) Services

J.1.7 Independent Verification and Validation (IV&V) Services

J.1.8 Maintenance Services J.1.8.1 Maintenance Requirements and Analysis

J.1.8.2 Maintenance Design and Implementation

J.1.8.3 Maintenance Delivery Services J.1.9 Support Services

J.1.9.1 User Documentation Services iii

J.1.9.2 User Training Services

J.1.9.3 Business Operations J.1.10 Data Request Services

J.2 Enterprise-Level Support Services

J.2.1 Agile Methodology:

J.2.1 Technical Review Board

J.2.2 Change/Configuration Control Board

J.2.3 SPARC IDIQ Contract and Administrative Reporting J.2.3.1 Monthly Technical Progress Report for Active Task Orders

J.2.3.2 Monthly Contract Summary Report

J.2.3.2 Monthly Financial Planning Report J.2.3.3 Monthly Financial Status Report

J.2.3.4 Work Breakdown Structure (WBS) and Microsoft Project Schedules

J.2.3.5 Weekly Status Reports J.2.3.6 Change Management

J.2.3.7 Meeting Minutes

J.2.3.8 Template Usage J.2.3.9 Risk Management

J.3 Information Security Services J.4 SPARC Contract-Specific Requirements

J.4.1

Earned Value Management J.5 Qualitative Performance Metrics

J.6 Legislative and Executive Mandates

J.7 Regulatory and Standards Guidance J.8 Departmental Directives and Regulations

J.9 CMS Standards and Guidance

J.9.1 Enterprise Architecture J.9.1.1 EA Repository

J.1.9.2 Adherence to DHHS and CMS EA Policies, Standards, Processes, and Procedures

J.10 Data Use Agreement

J.11 SECTION 508 - ACCESSIBILITY OF ELECTRONIC AND INFORMATION

TECHNOLOGY

Section J

J.1 Strategic Partners Acquisition Readiness Contract Services

The Department of Health and Human Services (HHS), Centers for Medicare & Medicaid Services (CMS), have established the following Service Categories for information technology professional services under the SPARC Indefinite Delivery/Indefinite Quantity (IDIQ) Contract:

• Initiation, Concept, and Planning Services

• Requirements Services

• Design Services

• Development Services

• Test Services

• SCA Services

• IV&V Services

• Maintenance Services

• SPARC Support Services

• Data Request Services

All HHS Operational Divisions (OPDIVS) are able to solicit and award task orders on the SPARC IDIQ contract. Each service category consists of one or more tasks. A single task is the smallest unit of work that may form the basis for a task order under the SPARC IDIQ Contract. HHS may choose to release a separate Task Order within a multi-task category (e.g., Development Services) or combine tasks within or across service categories to form a Task Order. Contractor tasks and subtasks have specified deliverables that rely on documented standards, guidelines, and measures. The junctures and dependencies between categories, tasks, and subtasks may have review points with associated exit criteria and contractual decision points at which HHS management may agree to continue or terminate the effort, combine it with other efforts, or postpone any action concerning the project, task or subtask.

For large and complex development efforts, HHS may choose to sponsor iterative development cycles. If HHS so decides, service categories may be subdivided into increments that address logical modules of functionality. The products from one service category may be developed and delivered incrementally to other areas and service categories. This approach intentionally reduces the complexity of each effort, thereby reducing the risk associated with large, complex systems development efforts.

Assumptions:

The SPARC IDIQ Contract establishes certain assumptions that are applicable to all task orders and all Contractors.

• HHS may elect to perform all or part of a task or issue a Task Order for Contractor assistance or support as required by the scope and complexity of the program/project.

• Task Order SOWs will be tailored as appropriate to the individual projects.

• The Contractor shall verify the quality of work products through formalized internal reviews and audits.

. 4

• The Contractor shall communicate the plan and schedule these quality measures at project startup. Subsequently, the Contractor shall report monthly to HHS (or as specified by the HHS Contracting Officer) results of reviews and audits, including risks, issues, and plans to mitigate and/or rectify contributing factors.

• The Contractor shall provide updates to existing documentation as the services performed identifies change that affect the consistency and accuracy of existing documentation.

• The Contractor shall coordinate updates to existing work products and those products created within the task order with HHS and other contractors as directed.

• The Contractor shall establish document baselines and shall control changes through a formal change management process that complies with and seamlessly integrates with CMS or HHS OPDIVConfiguration Management. This process should include appropriate negotiation among parties affected by the change and should trigger pertinent risk assessments (e.g., for schedules or cost).

• The Contractor shall ensure that its products and artifacts are in the same format or a format compatible with CMS or HHS OPDIV processes and tools. The Contractor shall be responsible for ensuring that the artifacts and products can be incorporated automatically and integrated seamlessly into CMS or HHS OPDIV processes and tools.

• HHS prefers the use of COTS/GOTS products where feasible and cost effective.

• The Contractor shall not use any proprietary processes, hardware, software, etc. unless approved by CMS or HHS OPDIV.

• The Contractor shall not perform any work, associated with this contract, outside of the

United States unless approved by HHS.

• All products created under this IDIQ are the sole property of HHS.

Constraints:

HHS will assess each task order to determine its eligibility for Small Business (SB) Set Aside.

Task orders determined appropriate for SB Set Aside could fall under any service category.

The following constraints affect SPARC Prime Contractor eligibility to compete for tasks in a specific category:

• A contractor who develops a system or system application shall not perform independent verification and validation (IV&V) or Security Control Assessments (SCAs) on the work products/systems.

• SPARC IDIQ Contract tasks are subject to Software Engineering Institute (SEI®) Capability Maturity Model Integration® (CMMI®) level requirements. Therefore, contractors who do not possess independently prepared SCAMPI appraisal results assessed at the appropriate CMMI level for a given task will be restricted from performing the work.

• Task orders have review points that require HHS to formally authorize continuation or termination of the effort by the Contractor.

• Services are classified for competition as either “Unrestricted” or “small business set-aside”.

• Contractors currently providing Program Management services on another CMS contract will not perform services under the SPARC IDIQ.

Conflict of Interest Exclusion Any contractor (and its subcontractors) serving in the role of SCA Services or IV&V Services Contractor/Provider to CMS through SPARC is prohibited from soliciting, proposing, or being awarded any project management, quality assurance, software design, development, or other manner of planning, design, development, or implementation phase activity on the project/task order. This exclusion likewise extends to any other project within the Department that may interact with or otherwise provide services to the SPARC task order. Such conflicts of interest could be alleged if the SCA Services or IV&V Services Provider were found to be reviewing work products, deliverables, and/or processes for which they currently are or were responsible to plan, design, develop, implement, or operate. Therefore, these exclusions seek to ensure the credibility of the SCA Services or IV&V Services Provider. All exceptions to this conflict of interest exclusion will require Federal written approval prior to any exception being granted to the SCA Services or IV&V Services Provider.

Requirements

• For CMS requirements, The Contractor shall reference the CMS eXpedited Life

Cycle (XLC) for the latest standards, guidance, and templates provided by CMS.

• For HHS requirements, all IT systems development or enhancement tasks supported by the contractor shall follow the HHS Enterprise Performance Life CyCle (EPL) framework and methodology. Information about EPLC policy and framework is available at http://www.hhs.gov/ocio/policy/2008-0004.001.html and http://www.hhs.gov/ocio/eplc-lifecycle-framework.pdf

• The Contractor shall provide the deliverables (artifacts) as defined in the individual Task Order’s Statement of Work (SOW). The list of deliverables may change due to one or more of the following:

• CMS modifies the lists of artifacts in the XLC.

• Contractor shall provide all services in alignment with the CMS PMP developed in the Planning Phase of the XLC.

• Some artifacts may be deemed unnecessary or redundant with other controls in the context of a specific task order

• Additional artifacts may be deemed necessary in the context of a specific task order.

• The contractor shall follow the added measures listed below to ensure true collaborative environment in the best interest of HHS for IT services:

1. The Contractor shall not use any proprietary processes, hardware, software, etc.

unless approved by HHS.

2. SPARC Contractors shall promptly provide HHS, HHS Requirements, Project Management and HHS IV&V contractors with full access to SPARC project-related work products and deliverables.

3. Contractors shall provide HHS and HHS IV&V contractors with reasonable, easy, and sufficient access and visibility into SPARC project related internal processes and practices.

Table 2, Task Controls presents the controls governing the execution of task efforts under the SPARC IDIQ Contract. HHS specifies the necessary quality and content of the deliverables by reliance on the cited standards, guidance, templates, and specific reviews and qualitative/quantitative measures.

http://www.hhs.gov/ocio/policy/2008-0004.001.html http://www.hhs.gov/ocio/eplc-lifecycle-framework.pdf

Legislative and Executive Mandates References

Public Laws (P.L.)

Table 2. Task Controls

• CMS Directives and Policies:

http://www.cms.hhs.gov/home/regsguidance.asp

• CMS Information Security Contract Clause / Provision:

http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS- Information-Technology/InformationSecurity/Info-Security-Library- Items/CMS-Information-Security-Contract-Clause- Provision.html?DLPage=1&DLSort=0&DLSortDir=as cending

• DHHS Directives and Regulations:

www.cms.gov

• DHHS Policies and Regulations:

http://www.hhs.gov/policies/index.shtml

– HHS Information Systems Security Program Policy (guidance on meeting requirements for protecting DHHS information resources, available on the HHS Intranet (infosec/policies_guides.html)

– DHHS OCIO Policy for Information Technology (IT) Earned Value Management (EVM), HHS-OCIO-2005-0004.001

– Department of Health & Human Services (DHHS) EVMS Policy

– Department of Health & Human Services (DHHS) Cost and

Schedule Policy

• Homeland Security Presidential Directives:

• NIST standard references: http://csrc.nist.gov/publications

(computer security division, including FIPS)

• Open Government Directive OMB-M-10-06

• Affordable Care Act

• HITECH

• The Health Insurance Portability and Accountability Act (HIPAA) of

1996 (P.L. 104-191)

• Medicare Prescription Drug, Improvement and Modernization Act

(MMA) of 2004 (P.L. 108-173)

• Medicare Regulatory and Contracting Reform Act (MRCRA) of

2001, H.R. 2768

• E-Government Act of 2002 (P.L. 107-347)

– Federal Information Security Management Act (FISMA) of 2002, Title III, Section 301: Information Security, E- Government Act of 2002 (P.L. 107-347)

• Government Paperwork Elimination Act (GPEA) of 1998 (P. L. 105- 277, Title XVII)

• Computer Fraud and Abuse Act of 1986 (as amended 1994, 1996, and 2001), 18 U.S.C. 1030

• Paperwork Reduction Act (PRA) of 1995 (P.L. 104-13)

• Electronic Signatures in Global and National Commerce Act

(ESIGN) of 2000 (P.L. 106-229)

• Clinger-Cohen Act (CCA), the Information Technology

Management Reform Act (ITMRA) of 1996 (P.L. 104-106, Division E)

– Federal Oversight Guidance, Appendix C, Clinger-Cohen Act

Oversight Guidance, Appendix II – Implementation of the Government Paperwork Elimination Act (GPEA), September 1, 2003, guidance for agencies implementing electronic signature http://www.cms.hhs.gov/home/regsguidance.asp http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Info-Security-Library-Items/CMS-Information-Security-Contract-Clause-Provision.html?DLPage=1&DLSort=0&DLSortDir=ascending http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Info-Security-Library-Items/CMS-Information-Security-Contract-Clause-Provision.html?DLPage=1&DLSort=0&DLSortDir=ascending http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Info-Security-Library-Items/CMS-Information-Security-Contract-Clause-Provision.html?DLPage=1&DLSort=0&DLSortDir=ascending http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Info-Security-Library-Items/CMS-Information-Security-Contract-Clause-Provision.html?DLPage=1&DLSort=0&DLSortDir=ascending http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Info-Security-Library-Items/CMS-Information-Security-Contract-Clause-Provision.html?DLPage=1&DLSort=0&DLSortDir=ascending http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Info-Security-Library-Items/CMS-Information-Security-Contract-Clause-Provision.html?DLPage=1&DLSort=0&DLSortDir=ascending http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Info-Security-Library-Items/CMS-Information-Security-Contract-Clause-Provision.html?DLPage=1&DLSort=0&DLSortDir=ascending http://www.cms.gov/ http://www.hhs.gov/policies/index.shtml http://www.hhs.gov/policies/hhsar/subpart334.html http://www.hhs.gov/ocio/policy/hhs-ocio_policy_for_pbm-2010-0007.html http://www.hhs.gov/ocio/policy/hhs-ocio_policy_for_pbm-2010-0007.html http://csrc.nist.gov/publications technologies

• Government Information Security Reform Act (GISRA) of 2000

(P.L. 106-398) http://www.whitehouse.gov/omb/memoranda/m01- 08.pdf

• Privacy Act of 1974, as amended, 5 U.S.C. 552a (P.L. 93-579)

• ACA 1411(g) and 45 CFR 155.260;

• Section 508 of the Rehabilitation Act of 1973 (29 U.S.C.§ 794 (d)), as amended by the Workforce Investment Act of 1998 (P.L. 105- 220), August 7, 1998 (requiring access to electronic and information technology procured by federal agencies)

• Federal Acquisition Streamlining Act of 1994, Title V

(FASA V) (P.L. 103-355)

Executive Mandates

Regulatory Guidance

• Executive Order 13231, Critical Information Protection in the Information Age, October 16, 2001

• Homeland Security Presidential Directive/HSPD-7, Critical Infrastructure, Identification, Prioritization, and Protection, December 17, 2003

• HSPD-12, Policy for a Common Identification Standard for Federal Employees and Contractors, August 27, 2004

• Office of Management and Budget (OMB) Memorandum, Implementation of Homeland Security Presidential Directive (HSPD) 12 – Policy for a Common Identification Standard for Federal Employees and Contractors, OMB M-05-24, August 5,

• OMB Circular Number A–130, Management of Federal Information Resources, Appendix III, “Security of Federal Automated Information Systems, ”February 8, 1996

• OMB Memorandum, E-Authentication Guidance for Federal Agencies, OMB M-04-04, December 16, 2003

• OMB Memorandum, Implementation Guidance for the E- Government Act of 2002 OMB M-03-18, August 1, 2003

• OMB Memorandum, Guidance on Implementing GISRA, OMB M- 01-08, January 16, 2001

• OMB Memorandum, Guidance on Implementing the ESIGN Act, OMB M-00-15, September 25, 2000

• OMB Circular A-11, Preparation, Submission, and Execution of the Budget, August 2012

• OMB Circular A–130 (Revised), Management of Federal Information Resources, February 8, 1996

• Federal Information System Configuration Audit Manual

• OMB Circular A-94, Guidelines and Discount Rates for Benefit-

Cost Analysis of Federal Programs

• The Common Approach to Federal Enterprise Architecture

• Internal Revenue Code §6103P – Confidential and Disclosure of

Returns and Return Information

• The Consolidated Health Informatics (CHI) initiative standards, http://www.whitehouse.gov/omb/memoranda/m01-08.pdf http://www.whitehouse.gov/omb/memoranda/m01-08.pdf http://www.whitehouse.gov/sites/default/files/omb/assets/egov_docs/common_approach_to_federal_ea.pdf

Standards are published in the “Consolidated Health Informatics (CHI) Initiative; Health Care and Vocabulary Standards for Use in Federal Health Information Technology Systems (70 FR 76287) available at:

https://www.federalregister.gov/articles/2005/12/23/05- 24289/consolidated-health-informatics-chi-initiative-health-care-and-vocabulary-standards-for-use-in

• Capital Asset Plan and Business Case Summary Exhibit 300

• ANSI Standards: http://www.ansi.org/

• Institute of Electrical and Electronics Engineers (IEEE)/Electronic

Industries Association (EIA) 12207.

• IEEE Std 730-1998, IEEE Standard for Software Quality Assurance

Plans

• IEEE Std 828-1998, IEEE Standard for Configuration Management

Plans

• IEEE Std 829-1998, IEEE Standard for Software Test

Documentation

• IEEE Std 830-1998, IEEE Recommended Practice for Software

Requirements Specifications

• IEEE Std 1012-2004, IEEE Standard for Software Verification and

Validation

• IEEE 1016-1998, IEEE Standard for Software Design Descriptions

• IEEE Std 1028-1988, IEEE Standard for Software Reviews

• IEEE Std 1042-1987, IEEE Standard for Software Configuration

Management

• IEEE Std 1045-1992,IEEE Standard for Software Productivity

Metrics

• IEEE 1058-1998, IEEE Standard for Software Project Management

Plans

• IEEE Std 1062-1998, IEEE Standard for Recommended Practice for Software Acquisition

• IEEE Std 1063-2001, IEEE Standard for Software User

Documentation

• IEEE Std 1074-1997, IEEE Standard for Developing Software Life

Cycle Processes

• IEEE Std 1219-1998, IEEE Standard for Software Maintenance

• IEEE Std 1220-1998, IEEE Standard for Application and

Management of the Systems Engineering Process

• IEEE 1362-1998, IEEE Guide for Information Technology – System

Definition – Concept of Operations (ConOps) Document

• IEEE Std 1540-1998, IEEE Standard for Risk Management

• IEEE/EIA 12207.0-1996, IEEE Standard for Information

Technology - Software Life Cycle Processes

• IEEE/EIA 12207.1-1997, Guide for ISO/IEC 12207, Standard for

Information Technology - Software Life Cycle Processes - Life Cycle Data

• IEEE/EIA 12207.2-1997, Guide for ISO/IEC 12207, Standard for Information Technology - Software Life Cycle Processes - Implementation Considerations

• American National Standards Institute (ANSI) /Electronic Industries Alliance (EIA) Standard 748-98, Earned Value Management Standards, May 1998 https://www.federalregister.gov/articles/2005/12/23/05-24289/consolidated-health-informatics-chi-initiative-health-care-and-vocabulary-standards-for-use-in https://www.federalregister.gov/articles/2005/12/23/05-24289/consolidated-health-informatics-chi-initiative-health-care-and-vocabulary-standards-for-use-in https://www.federalregister.gov/articles/2005/12/23/05-24289/consolidated-health-informatics-chi-initiative-health-care-and-vocabulary-standards-for-use-in http://www.ansi.org/

Department of Defense Standards

Table 2. Task Controls

• MIL-HDBK-881, Department of Defense Handbook, Work

Breakdown Structure

• DI-MGMT-81466, Cost Performance Reporting

• MIL-HDBK-61, Configuration Management Guidance

National Institute for Standards and Technology and Federal Information Process Standards

• NIST Special Publication 800-76, Biometric Data Specification for Personal Identity Verification (Draft), January 24, 2005

• NIST, Federal Information Processing Standards (FIPS) Publication 201, Personal Identity Verification (PIV) of Federal Employees and Contractors, February 25, 2005

• NIST, Federal Information Processing Standards (FIPS) Publication 199, Standards for Security Categorization of Federal Information and Information Systems, February 2004

• NIST Special Publication 800-18, Guide for Developing Security Plans for Information Technology Systems, December 1998

• NIST Special Publication 800-25, Federal Agency Use of Public Key Technology for Digital Signatures and Authentication, October

• NIST Special Publication 800-26, Security Self-Assessment Guide for Information Technology Systems, November 2001

• NIST Special Publication 800-29, A Comparison of the Security Requirements for Cryptographic Modules in FIPS 140-1 and FIPS 140-2, June 2001

• NIST Special Publication 800-30, Risk Management Guide for Information Technology Systems, July 2002

• NIST Special Publication 800-32, Introduction to Public Key Technology and the Federal PKI Infrastructure, February 2001

• NIST Special Publication 800-34, Contingency Planning Guide for Information Technology Systems, June 2002

• NIST Special Publication 800-37, Guide for Security Certification and Accreditation of Federal Information Systems, May 2004

• NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems, February 2005

• NIST Special Publication 800-61, Computer Security Incident Handling Guide, January 2004.

• NIST Special Publication (SP) 800-55, Security Metrics Guide for Information Technology Systems

• NIST SP 800-53, Recommended Security Controls for Federal Information Systems

• NIST SP 800-51, Use of the Common Vulnerabilities and Exposures (CVE) Vulnerability Naming Scheme

• NIST SP 800-37, Guide for the Security Certification and Accreditation of Federal Information Systems

• NIST SP 800-34, Contingency Planning Guide for Information Technology Systems

• NIST SP 800-26, Security Self-Assessment Guide for Information Technology Systems

• NIST SP 800-18, Guide for Developing Security Plans for Information Technology Systems

• Health Insurance Portability and Accountability Act (HIPAA) of

• FIPS 200, Minimum Security Requirements for Federal Information and Information Systems

• FIPS 199, Standards for Security Categorization of Federal Information and Information Systems

• FIPS 191, Guideline for the Analysis of Local Area Network Security

CMS Guidelines, Standards, and Templates

• CMS Requirements Writer’s Guide

• CMS Enterprise Architecture – http://www.cms.hhs.gov/EnterpriseArchitecture/

– The CMS Business Reference Model

– The CMS Subject Areas and Data Categories

Note: Contractors without VPN access to CMSNet can acquire these Enterprise Architecture documents through the Government Task Lead (GTL)/Contracting Officer’s Technical Representative (COTR).

• CMS Data Administration

• CMS Technical Reference Architecture (TRA)

• CMS XLC Framework

• CMS Information Security (IS) Acceptable Risk Safeguards (ARS)

• CMS IS ARS CMS Minimum Security Requirements (CMSR)

• CMS Risk Management Handbook (RMH)

• VPAT for Section 508 Accessibility & Compliancy

• Centers for Medicare & Medicaid Services, Operational Concepts for the Enterprise System Development Services Model, Version 0.2, September 11, 2006

• Centers for Medicare & Medicaid Services, Medicare Claims Processing Manual (available for online viewing download and reference at http://www.cms.hhs.gov/manuals ; manual 100-04 under transmittals is the target manual)

• CMS information technology-related policies and standards are available at http://www.cms.hhs.gov/home/rsds.asp via the Information Technology section

• Database Administration (DBA) https://www.cms.gov/Research- Statistics-Data-and-Systems/CMS-Information- Technology/DataAdmin/index.html http://www.cms.hhs.gov/DataAdmin/

• CMS test case specification and traceability requirements in CMS Internet Only manuals (IOM) 100-1, Chapter 7, Section 40.3.10 http://www.cms.gov/Regulations-and- Guidance/Guidance/Manuals/Internet-Only-Manuals-IOMs.html

J.1.1 Initiation, Concept, and Planning Services

Initiation, Concept, and Planning Services address the initiation and program planning tasks required for all system development efforts, including new software/systems development, http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/RequirementsWritersGuide.docx http://www.cms.hhs.gov/EnterpriseArchitecture/ https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/DataAdmin/index.html https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/Technical-Reference-Architecture-Standards/index.html https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/index.html http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Information-Security-Library.html http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Information-Security-Library.html http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Information-Security-Library.html http://www.cms.hhs.gov/manuals http://www.cms.hhs.gov/home/rsds.asp https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/DataAdmin/index.html https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/DataAdmin/index.html https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/DataAdmin/index.html https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/DataAdmin/index.html https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/DataAdmin/index.html https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/DataAdmin/index.html http://www.cms.hhs.gov/DataAdmin/ http://www.cms.gov/Regulations-and-Guidance/Guidance/Manuals/Internet-Only-Manuals-IOMs.html http://www.cms.gov/Regulations-and-Guidance/Guidance/Manuals/Internet-Only-Manuals-IOMs.html http://www.cms.gov/Regulations-and-Guidance/Guidance/Manuals/Internet-Only-Manuals-IOMs.html software/systems re-engineering, and engineering efforts that call for enhancements or change beyond normal maintenance activities. Activities begin with HHS identification and initiation of the IT investment process. Potential initiatives are reviewed and vetted by CMS engineering and investment boards. Decisions are made regarding the impact, cost, priorities, and approach of a particular project.

Planning services involves the development and maintenance of a workable scheme for the project to meet the business needs. In this task, the Contractor creates a Project Management Plan (PMP) and overall planning structure for the SPARC initiative (the system/application development project). Planning at this stage covers the entire scope of the SPARC initiative.

The planning includes acquisition processes and artifacts that support the acquisition strategy for the individual task orders that will comprise the overall effort.

The following constraints apply to Initiation, Concept, and Planning Services:

• CMS’ Initiation, Concept and Planning process considers performance, feasibility, reliability, and maintainability factors supporting an investment decision. The process establishes sound business reasons for proceeding with an IT investment. The process provides necessary information concerning the scope, alternatives considered, estimated costs and return on investment (ROI), risks, and technical and acquisition strategies necessary for the CMS Information Technology Investment Review Board (ITIRB) to make an informed funding decision for the IT investment. All new or proposed IT investments must prepare documentation sufficient to support the CMS ITIRB investment funding decision.

• HHS will perform Initiation, Concept, and Planning Tasks. At its election, HHS may engage a contractor to develop or help support development of required Initiation work products.

Initiation, Concept, and Planning Services dependencies are as follows:

• Legislation.

• Department Initiative.

• Agency Program.

• Management Strategy.

• Enhancement Concept.

• Approval of the selected alternative by the Technical Review Board (TRB) and the IT

Investment Review Board (ITIRB).

J.1.2 Requirements Services

Requirements Services encompass the creation or modification of a Requirements Document.

These tasks build on earlier efforts from Initiation, Concept and Planning in which a business process model, high level business requirements and project planning documents are developed.

CMS may choose to perform this task internally, issue a Task Order, or combine this task into a larger multi-task effort.

Requirements Services constitute services that support the development of functional1 and nonfunctional2 requirements as well as any necessary logical data models. Requirements captured in this area provide a suitable level of detail for establishing a common understanding between HHS and its contractors driving the development of the system. Various methods, including user interviews, Business Owner interviews, and Joint Application Requirements (JAR) sessions, ensure the capture and validation of core functional and nonfunctional requirements. The requirements defined in this stage form the foundation for the System Design Document and Physical Data Model that will be developed in Design Services.

Requirements Services dependencies are as follows:

• Work products from Planning Services and Requirements Services.

The Requirements Services’ requirements are as follows for those tasks where this may apply:

• The Contractor shall plan for (including the creation of agendas) and facilitate Early Involvement Calls (EIC) and JAR sessions.

• The Contractor shall work with the stakeholders to create Change Requests (CRs) that capture the requirements uncovered during the JAR sessions.

• The Contractor shall, at the direction of the GTL, be required to assist Business Owners in completing CRs to capture necessary changes to the requirements.

• The Contractor shall make all necessary changes to requirements in DOORS (standard requirements management tool) or in any other management tool as specified by HHS.

• The Contractor shall establish all applicable links between requirements they create, such as links between lower level requirements and related higher level requirements.

• The Contractor shall update the existing Requirements Document with well-formed requirements statements that state functional and nonfunctional capability, are bounded, and can be validated through testing.

• The Contractor shall ensure a common understanding of the purpose and objectives of requirements through validation of functional and nonfunctional requirements with the Business Owners and users.

• The Contractor shall document and communicate requirements in a structured manner to ensure that capabilities, conditions, and constraints are clearly delineated and exhibit the following characteristics:

• Requirements that are derived from other requirements are clearly identified.

• Requirements of different levels of detail are organized into their appropriate level.

1 Per the CMS Requirements Writer’s Guide, , a functional requirement is a statement of action that describes the behavior and information that the solution will manage. They describe capabilities the system will be able to perform in terms of behaviors or operations – a specific system action or response.

2 Per the CMS Requirements Writer’s Guide, , a nonfunctional requirement is a statement that describes conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the system must have.

• Completeness of the set of requirements can be verified.

• Inconsistencies among requirements can be identified.

• The Contractor shall create “documentation only” Change Requests (CRs) to keep the requirements up to date.

• The Contractor shall manage the process of identifying and resolving all requirements issues uncovered during the requirements gathering process.

• The Contractor shall provide Requirements support during testing services. The Contractor shall work with the stakeholders to help ensure complete and accurate comprehension of each functional requirement and ensure test cases are properly tested and match the functional requirements along with nonfunctional requirements. The Contractor shall support testing activities.

• The Contractor shall provide Requirements support during all lifecycle phases as they pertain to the clarification and maintenance of the requirements document.

• The contractor shall provide design requirements to support HHS lifecycle phases.

J.1.3 Design Services

Design Services supports those activities related to the design of the system and software components, database design, and system integration. It consists of three (3) tasks, each targeting a major design consideration, software, database, and systems integration, and incorporates comprehensive reviews to ensure the quality of the Design Services products before beginning development. The outputs include the design specifications to develop and integrate the system into the HHS environment.

Design Services consist of:

• Software Services

• Database Services

• System Integration Services

The Design Services’ constraints are as follows:

• The product design must adhere to and be consistent with CMS/HHS’ systems architecture, security infrastructure, and architectural standards.

• The product as designed must integrate and interoperate seamlessly with CMS/HHS software, hardware, and network and security infrastructure.

• The product as designed must integrate and interoperate seamlessly with system and network management and monitoring applications.

Design Service requirement: Contractor shall ensure the quality of the design and design artifacts and therefore, shall correct defects when identified during testing phases.

J.1.3.2 Database Services

The Database Services activities focus on the development of physical data models, database design, design of extraction, transformation and load design, data preparation design, and data interface design. Data models developed shall be very detailed and fully attributed (all data elements are defined); adhere to business rules or shall be defined by business rules and adhere to HHS/CMS data administration standards, and align with CMS EA data models.

The Database Services dependencies are as follows:

• Work products from Initiation, Concept and Planning Services and Requirements Services and Design Services.

The Database Services requirement is as follows:

• The Contractor shall comply with all HHS data and database standards and conventions.

J.1.3.3 System Integration Services

The System Integration Services activities ensure that software and database designs integrate and interoperate accurately and effectively with one another and in the context of the overall HHS IT environment. This task includes design and control activities that support integration in the existing environment and, if applicable, the targeted environment. This task must account for existing components, including custom software, Commercial Off-the-Shelf (COTS) and Government Off-the-Shelf (GOTS) products, network, security infrastructure, data architecture, web architecture, mainframe environment, and mid-tier architecture in addition to the standards governing the HHS IT environment. The services in this task are intended to provide proactive system integration design control to ensure any software, system, or infrastructure designs or design modifications are of high quality as demonstrated from meeting the business and operating requirements while also proving to be flexible, cost effective, and forward looking.

The System Integration Services dependencies are as follows:

Services and Design Services.

J.1.4 Development Services

Development Services include software development, web development and database development services. These activities are performed in accordance with the System Design Document to meet the requirements in the Requirements Document. At a minimum, Development Services create source code; create databases; create, prepare, and/or convert data (as needed and appropriate); conduct unit and string testing of development products, and provide support as it pertains to problems found during any of the testing services tasks as required under section J.1.5 Testing Services of this IDIQ.

Development Services consist of following:

• Design Software Services

• Database Services

• System Integration Services

The following requirements apply to Development Services:

• The Contractor is responsible for ensuring that software products meet design objectives and are of good quality, including rectifying software, database, and system defects that are identified during all testing area.

• All developed software will be security tested as applicable per the Acceptable Risk Safeguards (ARS) and Risk Management Handbook (RMH).

• The Contractor shall modify system and software products to rectify performance deficiencies identified during testing new development or major enhancements outside the boundaries of system maintenance.

• The Contractor shall perform security self-assessments, fix code, and correct procedures based upon defects found within the boundaries of system maintenance.

• The Contractor shall correct code and applicable documents based on defects found during various testing phases.

Software Services

Software Services cover the creation of source code for the system or application, including internal and external interfaces; integration of software in the HHS environment; Development Testing within the development environment; and creation and update of operating documentation. Operating documentation describes the processes and procedures required for installing, operating, and supporting the system throughout the software product’s life cycle.

The Software Services dependencies are as follows:

Services.

D e s i g n Software Services

Design Software Services cover the creation of source code for the system or application, including internal and external interfaces; integration of software in the HHS environment;

development testing and creation and update of system and operating documentation.

Operating documentation describes the processes and procedures required for installing, operating, and supporting the system throughout the software product’s life cycle.

The Design Software Services dependencies are as follows:

Services and Design Services.

The Design Software Services requirements are as follows:

• The Contractor shall create the source code that is in accordance to the CMS TRA and industry best practices, as well as suitable comments, as found in the System Description Document (SDD). The code shall be grouped into processing units consistent with the programming language, COTS component or module, and the SDD. All units shall be transformed into executable code (or implemented in COTS, if applicable) and debugged.

Syntactically incorrect code, as identified by the transform output, shall be reworked until the source code can be processed free of syntactical errors.

• The Contractor shall make available to HHS any source code required for integration, test, or other life-cycle activities so that HHS may provide the source code to other processes as needed.

• The Contractor shall format and/or configure source code submitted so that it is compatible and in compliance with HHS Configuration Management processes, procedures, and tools to permit automatic uploading of these products into the HHS Configuration Management system.

• The Contractor shall correct code and applicable documents based on defects found during testing phases.

• The Contractor shall track and communicate the status of defects found during testing.

J.1.4.2 Database Services

Database Services cover the physical implementation activities necessary to deploy a database on a specific platform in the targeted environment. The activities include, but are not limited to, creation of the database; initial performance parameters and object allocation; access control mechanisms (e.g., scripts implementing roles, privileges, and permissions); database interfaces, input and output data feeds, and data preparation (e.g., data cleansing and data conversion); data extraction, transformation and load (ETL); and operational scripts and code supporting archival and backup.

The Database Services dependencies are as follows:

Services and Design Services and Development Services.

J.1.4.3 System Integration Services

The System Integration Services activities ensure that software and databases integrate and interoperate effectively and efficiently with one another and in the HHS IT environment. These services are intended to provide proactive system integration development control to ensure any new or modified software, system, or infrastructure components are of high quality, interoperable, and do not negatively impact HHS systems.

The System Integration Services dependencies are as follows:

• Work products from Initiation, Concept and Planning Services, Requirements Services, Design Services, and Development Services.

The System Integration Services requirements are as follows:

• The Contractor shall verify and document that the Development Services components (software, database, infrastructure) will integrate and interoperate effectively and efficiently within the targeted HHS IT environment. Interoperability pertains, but is not limited, to the following:

• Operational

• Computer to computer

• Data links and protocols

• Telecommunications

• Device to system, system to device

• Computer to system, system to computer

J.1.5 Test Services

Test Services consists of formal testing services to cover validation of software and system components developed or modified in other tasks. Test Services identify bugs, integration and performance issues, and validate that the software meets user and system requirements. Test Services perform testing on newly developed systems, existing systems that have been enhanced, and software that has had bug fixes and routine and emergency maintenance modifications.

These are the types of test services that a contractor shall provide under this IDIQ:

• Unit Testing

• Functional Testing

• Application/Integration Testing

• Section 508 Testing

• System Regression Testing

• Performance & Load Testing

• End-to-End Integration Testing

• User Acceptance Testing

• Implementation Testing

• Compatibility Testing

• Testing Coordination

Test Services requirements are as follows:

1. The Contractor shall interface with entities identified by the GTL and doing business with HHS. These include but are not limited to HHS business components, applications maintainers, business partners, development contractors or Enterprise Service Delivery vendors.

2. The Contractor shall be available to participate in all applicable Change Control Boards as may be affected by the system developed for this SOW whether they are currently existing or formed in the future.

3. The Contractor and HHS shall mutually agree upon the measures and metrics used in the testing program. The contractor shall submit a Metric Plan to HHS for approval. Both software quality metrics and test progress metrics shall be used.

4. The Contractor shall submit a Test Plan.

a. The Contractor shall test all changes and requirements with both positive and negative test cases to ensure that the requirements are correctly implemented.

5. The Contractor shall provide HHS insights and recommendations with regard to testing progress and software quality based on the metrics reported.

6. The Contractor shall document and execute test cases for each requirement in all software releases.

7. The Contractor shall provide a Test Incident Report to document any significant event that has a detrimental impact on testing, the testing effort, or schedule.

8. The Contractor shall deliver a Test Summary Report in accordance with HHS XLC artifacts.

9. The Contactor shall create and deliver a Release Readiness Report. The Contractor shall maintain and update standard operating procedures that document the steps in completing their aspect of testing services being provided.

10. The Contractor shall provide comments to HHS on draft CRs and Requirements as needed to convey issues regarding the testability of the requirement.

11. The Contractor shall develop and maintain the test data to satisfy all test case requirements.

12. The Contractor shall conduct regression testing to ensure that coding changes to software components do not change core functionality of the system in a manner not specified by the requirements. The contractor shall utilize test automation where possible and file comparisons when executing regression tests.

13. The Contractor shall fully test interfaces and data exchanges.

14. The Contractor shall coordinate data exchanges between the validation environment and other test sites such as the Virtual Data Centers (VDCs) or Medicare claims processing centers The Contractor shall complete performance testing to ensure that all performance requirements are met. Performance requirements include but are not limited to minimum sustained user load, response time, and user ramp-up requirements.

15. The Contractor shall complete stress testing by subjecting the software to abnormally high testing loads in order to test its behavior and responsiveness under high load conditions.

16. The Contractor shall complete end-to-end testing, prior to production implementation, on all system components and services that interface with the components and services. The contractor shall work with the business partners as required to implement valid test data and to manage synchronized test data as needed across the interfaces.

17. The Contractor shall design and build a smoke test that can be quickly executed when an intake test is required to determine if the system or a specific service is ready for more stringent and detailed testing or when otherwise requested by the Government. A smoke test shall be designed as a subset of all defined and planned test cases that cover the main functionality of a system to ensure that the most crucial function of the application works properly.

J.1.5.1 Unit Testing

Unit Testing is testing of individual components of code, independent of other components, to identify failures early in the development process.

The Unit Testing dependency is as follows:

• Work products from Planning Services, Requirement Services, Design Services, Development Services and Maintenance Services.

The Unit Testing requirements are as follows:

• The Contractor shall create a test matrix linking test cases to requirements to design. The Contractor shall create, review, and validate the Test Plan for accuracy, completeness and robustness, and make any updates as necessary

• The Contractor shall execute the testing in accordance with the existing Test Plan.

• The Contractor shall provide reports identifying failures encountered during execution.

• The Contractor shall provide a robust, repeatable process.

• The Contractor shall provide a Test Summary Report detailing the system test results.

J.1.5.2 Functional Testing

Functional Testing is performed to validate a specific action or code function.

The Functional Testing dependency is as follows:

The Functional Testing requirements are as follows

• The Contractor shall create a test matrix linking test cases to requirements to design. The

Contractor shall create, review, and validate the Test Plan and Test Case Specification for accuracy, completeness and robustness, and make any updates as necessary

• The Contractor shall execute the systems tests in accordance with the existing Test Plan and Test Case Specification.

• The Contractor shall provide reports identifying failures encountered during execution and re-execute if needed.

J.1.5.3 Application/Integration Testing

Application/Integration Testing is testing of multiple components of an application to ensure interoperability.

The Application/Integration Testing dependency is as follows:

The Application/Integration Testing requirements are as follows:

• The Contractor shall create, review, and validate the Test Plan and Test Case Specification for accuracy, completeness and robustness, and make any updates as necessary

• The Contractor shall execute the integration tests in accordance with the existing Test Plan.

• The Contractor shall provide reports identifying failures encountered during execution and re-execute if needed.

• The Contractor shall provide a Test Summary Report detailing the integration test results.

J.1.5.4 Section 508 Testing

Section 508…