1

Administration for Community Living 

Data Restructuring II and ACL Data: 

Work Plan and Timeline 

March 2019

 
2

TABLE OF CONTENTS 

Introduction and Background ------------------------------------------------------------------------------------------------- 4

ACL Data Restructuring: Phase II --------------------------------------------------------------------------------------------- 6

Task 1.0: Project Planning, Coordination, and Communication --------------------------------------------------- 6

Task 2.0: Data Documentation--------------------------------------------------------------------------------------------- 6

Task 3.0: Consolidated Database for Aging Datasets----------------------------------------------------------------- 6

Task 4.0: Align Measures for Conceptual Linkages across ACL Datasets ---------------------------------------- 7

Task 5.0: Topical Navigation------------------------------------------------------------------------------------------------ 7

Task 6.0: Compile Requirements List for ACL Data ------------------------------------------------------------------- 8

Task 7.0: Technical Advisory Group--------------------------------------------------------------------------------------- 8

Major Deliverables------------------------------------------------------------------------------------------------------------ 8

Timeline ------------------------------------------------------------------------------------------------------------------------- 8

Estimated Staff Levels of Effort-------------------------------------------------------------------------------------------- 9

ACL Data: Phase III --------------------------------------------------------------------------------------------------------------10

Task 1.0: Project Planning, Coordination, and Communication --------------------------------------------------10

Task 1.1: Transition operation at the beginning of contract ---------------------------------------------------10

Task 1.2: Conduct Kick-Off Meeting----------------------------------------------------------------------------------10

Task 1.3: Develop Project Work Plan --------------------------------------------------------------------------------11

Task 1.4: Develop a Quality Assurance Surveillance Plan (QASP)---------------------------------------------11

Task 1.5: Transition operation at the end of contract -----------------------------------------------------------11

Task 2.0: Compile business requirements -----------------------------------------------------------------------------11

Task 3.0: Define system requirements----------------------------------------------------------------------------------12

Task 4.0: Define technical requirements-------------------------------------------------------------------------------12

Task 5.0: Define security requirements---------------------------------------------------------------------------------12

Task 6.0: Develop wireframes---------------------------------------------------------------------------------------------12

Task 7.0: Develop the system ---------------------------------------------------------------------------------------------13

Task 7.1: Define the development methodology -----------------------------------------------------------------13

Task 7.2: Establish the environments--------------------------------------------------------------------------------13

Task 7.3: Develop the code for the system-------------------------------------------------------------------------14

Task 8.0: Test the system --------------------------------------------------------------------------------------------------14

Task 8.1: Conduct functional testing ---------------------------------------------------------------------------------14

Task 8.2: Conduct quality assurance (QA) testing ----------------------------------------------------------------14

Task 8.3: Conduct accessibility testing-------------------------------------------------------------------------------14
3

Task 8.4: Conduct full pilot testing with user groups ------------------------------------------------------------15

Task 9: Develop Authority to Operate (ATO) Package --------------------------------------------------------------15

Task 10: Deliver the system -----------------------------------------------------------------------------------------------18

Task 10: Maintain and operate the system----------------------------------------------------------------------------19

Major Deliverables-----------------------------------------------------------------------------------------------------------19

Timeline ------------------------------------------------------------------------------------------------------------------------19

Estimated Staff Levels of Effort-------------------------------------------------------------------------------------------19
4

Introduction and Background

In 2017, the Administration for Community Living (ACL) began the ACL Data Restructuring (DR) Project to 

assess the data hosted on the AGing Integrated Database (AGID), and to develop and test a potential 

restructuring of the data. The purpose of this document is to provide a multi-year plan to continue and 

expand ACL DR efforts (Phase II), then develop the next generation platform to replace AGID, ACL Data 

(Phase III), using the new data structure.

Currently, the AGID website hosts a variety of ACL programs’ aging-related data sets as well as key 

demographic data about older adults from the US Census Bureau. The types of information hosted on 

AGID include Older Americans Act (OAA) program services, such as administrative information on longterm care ombudsman services, supportive services programs, nutrition services programs, and

caregiver support services for US adults ages 60 and older and individuals with disabilities. 

The data are available at a glance, through state-based profiles, and user-defined custom tables. Data 

hosted on AGID are updated periodically depending on the release schedules of the hosted ACL data. 

Data sources are only viewable as separate windows, and no current joining or linking functionality 

exists on the platform.

ACL’s original impetus for exploring a restructuring of ACL data was to develop a linking functionality 

between ACL data sets to allow for cross-data set analyses and to create an operational approach that 

will allow for the incorporation of additional data sets, such as ACL disability data sets.

The AGID website is used by researchers, professionals in state agencies, and other individuals involved

in aging-related policy and services. An improved AGID with the flexibility to incorporate additional 

datasets and with additional functionality for users in aging- and disability-related fields would enhance 

the abilities of federal and state agencies, service providers, and policy makers to understand and 

deliver care to older Americans and people with disabilities.

ACL DR Phase II and ACL Data Phase III may consider a range of data relevant to ACL, however, the 

primary focus for both sets of workplans and timelines will be the following five aging-related datasets: 

 ACL State Program Reports (OAA Title III and Title VII Chapters 3 and 4). Available 

approximately February of each year. States provide data about the services provided under 

Title III and Title VII Chapters 3 and 4 of the Older Americans Act through web-based 

submissions of the State Program Report (SPR). The annual reports summarize the services 

provided, selected demographics of the individuals served, and information about program 

staffing. Nutrition Services Incentive Program (NSIP) data are reported by these same grantees 

in conjunction with their SPR reports.

 ACL OAA Title VI. Available approximately May of each year. Each year ACL disburses Federal 

grant funds, allocated to each state, under Title VI, including funding for the Nutrition Services 

Incentive Program (NSIP) of the OAA Grants for Native Americans. The Title VI reports, which are 

submitted by grantees to ACL, contain program performance data about staffing information 

and nutrition, supportive, and caregiver support services.

 ACL National Ombudsman Reports (OAA Title VII). Available approximately November of each 

year. States provide data about the services provided under Title VII (Chapter 2) of the Older 

Americans Act through web-based submissions of the State Long Term Care Ombudsman 

Program Reporting Form. The annual reports summarize long term care ombudsman efforts on 
5

behalf of residents in long term care facilities, including information on cases, complaints, 

program statistics, and narrative reports.

 National Survey of Older American Act Participants (NSOAAP). Available approximately March 

of each year. The National Survey of OAA Programs is a collection of annual national surveys of 

recipients of six Title III services. The survey instruments focus on consumer assessment of 

service quality and consumer-reported outcomes. The instruments also measure special needs 

characteristics such as physical and social functioning of the people who receive services.

 United States Census American Community Survey (ACS) Public Use Microdata Sample (PUMS) 

1-Year Files. The ACS PUMS 1-Year files are a sample of the actual responses to the ACS, an 

ongoing survey that provides important information about the social, housing, economic, and 

demographic characteristics of the U.S. population. The ACS PUMS 1-Year files contain an annual 

sample of the ACS records representing about 1 percent of the population (i.e., for the U.S., for

each state, the District of Columbia, Puerto Rico, and special non-overlapping sub-state areas 

called Public Use Microdata Areas or PUMAs).
6

ACL Data Restructuring: Phase II

Phase II is designed to continue and expand efforts completed during the initial ACL Data Restructuring 

Project in preparation for development of a consolidated ACL database (ACL Data) in Phase III. This 

phase consists of eight major tasks described in the sections below along with estimated timeline, 

personnel, and budgets by task.

Task 1.0: Project Planning, Coordination, and Communication

ACL and the contractor will conduct an initial kick-off meeting to discuss the Phase II workplan and 

timeline and to address any needs for a smooth transition from the initial ACL Data Restructuring Project 

to Phase II. ACL and the contractor will meet regularly (e.g., bi-weekly) and as-needed to ensure 

effective planning, coordination, and ongoing project management. The contractor will submit monthly 

reports documenting progress on the workplan and completion of deliverables as well as any challenges 

encountered and proposed solutions. At the conclusion of the project, the contractor will collaborate

with ACL to most effectively transition the work and key deliverables of Phase II into the development of 

ACL Data – Phase III.

Task 2.0: Data Documentation

The contractor will develop data documentation, such as static codebooks (e.g., pdf documents), for 

three ACL aging datasets (i.e., SPR/OAA Title III, OAA Title VI, and NORS/OAA Title VII). The contractor 

will review existing data documentation for the three ACL datasets, and cross-walk variables across 

years of data collection for each dataset. The review will include data from 2010 and later. The specific 

years to be included for each of the three datasets will be determined in agreement with ACL. Data 

documentation for related datasets (e.g., NSOAAP, Census datasets) may be considered when 

determining the style and format of data documentation for the three ACL aging datasets. This 

documentation may include the following information:

 Dataset-Level Documentation

o Program description

o Data collection methodology

o Data validation and quality assurance procedures

o Data manipulations from raw data

o Structure and organization of data files

o Variable naming conventions

o Cross-year differences and feasibility of merging

o Data confidentiality, access and use conditions

o Actual data collection tools/instruments

 Variable-Level Documentation 

o Variable name, type, and label

o Question text

o Cross-year differences

o How constructed (for constructed variables only)

o Variable length

o Values and labels for response options

Task 3.0: Consolidated Database for Aging Datasets

The contractor will expand the SQL database built during ACL Data Restructuring (DR) Phase I to include 

additional aging datasets. The SQL database developed in ACL DR Phase I includes all SPR/OAA and OAA 

Title VI data files for fiscal year 2013, 2014, and 2015. The expanded SQL database will include: (1) all 
7

data files for SPR/OAA and OAA Title VI datasets, for additional years determined in agreement with 

ACL, and (2) all data files for NSOAAP, ACS PUMS 1-Year Files, and NORS/OAA Title VII, for years 

determined in agreement with ACL. The consolidated database will include data from 2010 and later. 

The specific years to be included for each of the five datasets will be determined in agreement with ACL.

A key consideration for this task is understanding and accounting for differences in data collection over 

time for each of the five datasets (e.g., new variables, dropped/suppressed variables, revised variables). 

In cases where data change from year to year within a dataset (e.g., due to revision of the data 

collection form or tool), the consolidated database must appropriately account for those differences and 

combine years of data in a way that users can still perform valid multi-year analysis.

The current SQL database demonstrates linkages between two ACL administrative aging datasets. In 

order to demonstrate other dataset relationships of interest, new datasets will be added to the SQL 

database in the following order:

o NSOAAP – To demonstrate linkages with an ACL survey aging dataset.

o ACS PUMS 1-Year Files – To demonstrate linkages with a Census dataset.

o NORS/OAA Title VII 

Once the consolidated database for ACL aging datasets is built, the contractor will use the database to 

demonstrate linkages between datasets and the ability to assess trends over time within datasets. Data 

results from the demonstration will be reviewed against source data and the proposed linkages will be 

re-assessed for appropriateness. If necessary, proposed linkages will be revised or removed.

Task 4.0: Align Measures for Conceptual Linkages across ACL Datasets

ACL dataset reviews performed during ACL DR Phase I found measures that were not aligned for 

common constructs across ACL datasets (e.g., age, race/ethnicity, disability). The contractor will review 

documentation of these measures and recommend a process for coordinating across ACL programs to 

standardize measures, wherever possible, to increase the availability of appropriate linkages for crossdataset analysis. This process will begin with reviewing potential conceptual linkages identified during 

ACL DR Phase I and proposing necessary steps to change “potential” conceptual linkages to “actual” 

conceptual linkages (e.g., revising data collection tools, providing standard definitions for 

terms/concepts being measured). The contractor will also explore opportunities for additional 

conceptual linkages within and between key datasets (e.g., NSOAAP, ACS PUMS), determined in 

agreement with ACL.

Task 5.0: Topical Navigation

The current AGID platform allows ACL data users to navigate by dataset. This requires users to 

understand the contents of the datasets in order to access information about particular areas or 

populations of interest. The contractor will develop a cross-dataset classification of information by key 

areas of interest to ACL data users. For example, this classification could include the topic, “nutrition 

services”, and specify where users would pull data about home-delivered meals and congregate meals 

services across ACL programs, rather than having to navigate separately through the SPR/OAA Title III 

and OAA Title VI datasets for this information. Other topic areas for navigation may include: geographic 

areas (e.g., U.S., Census Region, Census Division, HHS Region, ACL Region, State, Tribe), service types 

(e.g., nutrition services, supportive services, caregiver services), populations (e.g., age, race/ethnicity, 

disability), resources (e.g., funding, expenditures).
8

Task 6.0: Compile Requirements List for ACL Data

Many business and system requirements for a consolidated ACL database (ACL Data) have been 

proposed throughout ACL DR Phase I, and through previous contract work (e.g., AGID market research 

white paper, AGID user interviews). ACL also maintains requirements for the current AGID system and 

may have other documentation that could be relevant to defining requirements for ACL Data. The 

contractor will review and compile all known requirements into a Foundational Requirements 

Document. Any new requirements defined during ACL DR Phase II will be added into this document. The 

contractor will also identify gaps, needs, and considerations for defining remaining requirements for ACL 

Data. This document will provide the initial foundation for the contractor and ACL to conduct the 

requirements tasks for ACL Data: Phase III—which will involve completing and approving the business, 

system, technical, and security features for the system that will replace AGID. This document will also 

assist ACL and its contractor to effectively determine the size and scope of work for the development 

and maintenance of ACL Data.

Task 7.0: Technical Advisory Group

Stakeholder engagement will help ensure that ACL DR Phase II is responsive to the needs and 

preferences of ACL data users. At the direction of ACL, the contractor may convene a Technical Advisory 

Group (TAG) for up to four meetings to capture stakeholder input on ACL DR Phase II activities and 

deliverables (e.g., codebooks, conceptual linkages/aligning measures, topical navigation). The TAG may 

include all or some of the members who participated in the initial ACL Data Restructuring Project.

Major Deliverables

 Kick-off meeting

 Revised workplan (if applicable)

 Monthly reports

 Data reviews and cross-walks for SPR/OAA Title III, OAA Title VI, and NORS/OAA Title VII

 Codebook template

 Completed codebooks for SPR/OAA, OAA Title VI, and NORS/OAA Title VII 

 Total of up to six meetings, two for each dataset (i.e., SPR/OAA, OAA Title VI, and NORS/OAA 

Title VII) with ACL program staff responsible for each dataset

 SQL database with up to nine years of data (i.e., 2010-2019) for SPR/OAA, OAA Title VI, 

NORS/OAA Title VII, NSOAAP, and ACS PUMS 1-Year Files

 Report of database development approach and findings

 Report of proposed conceptual linkages and aligned measures across SPR/OAA, OAA Title VI, 

NORS/OAA Title VII, NSOAAP, and ACS PUMS 1-Year Files

 Report describing topical navigation and mapping specific variables to each topic across 

SPR/OAA Title III, OAA Title VI, NORS/OAA Title VII, NSOAAP, and ACS PUMS 1-Year Files

 Report compiling existing requirements for ACL Data and gaps/needs/considerations for 

remaining requirements.

 Total of up to four TAG meetings (e.g., one focusing on task 3, two focusing on task 4, and one 

focusing on task 5)

Timeline

The overall anticipated timeline to complete all tasks for ACL DR Phase II is 24 months. 
9

Estimated Staff Levels of Effort

Estimated staff levels of effort for ACL DR Phase II, by staff and task, are provided in a separate 

attachment (Attachment 1).
10

ACL Data: Phase III

Phase III involves ACL’s effort in partnership with a contractor to finalize requirements and create ACL

Data (the next generation of the AGing Integrated Database, AGID). Researchers, professionals in state 

agencies, and other individuals in aging and disability fields rely on AGID. AGID hosts a variety of ACL 

programs’ aging-related data sets as well as data from the US Census Bureau. These data are available at 

a glance, through state-based profiles, and user-defined custom tables. ACL obtains the data from 

various sources and imports them into AGID after their release dates. 

ACL has invested considerable work (i.e., AGID user interviews, consultations with data subject matter 

experts, market research, new data structure and testing database) toward the development of ACL 

Data. ACL DR Phase II will produce two primary deliverables that will be essential for the development of 

ACL Data. These include a Foundational Requirements Document and a consolidated database

prototype. The Foundational Requirements Document will provide a comprehensive listing of all known 

requirements collected through these efforts. The consolidated database prototype for aging datasets 

represents the data model for ACL Data. It will contain data linkages absent from AGID; and will allow

for easier incorporation of additional data sets, such as ACL disability data sets.

Task 1.0: Project Planning, Coordination, and Communication

The success of the project will require effective planning, coordination, and ongoing project

management. To ensure that the effort is successfully progressing, the contractor should develop key 

project management materials and maintain regular contact with ACL. ACL should instruct the 

contractor on whether they require regular status meetings, monthly progress reports, making 

necessary adjustments to the Project Work Plan on an as-needed basis in consultation with ACL, etc. 

Task 1.1: Transition operation at the beginning of contract

ACL should indicate if they require the transition of operations and maintenance of AGID from the 

existing contractor at the beginning of the contract. ACL should indicate what the transitions are and 

request that the new contractor provide their proposed approach for the transitions. 

Task 1.2: Conduct Kick-Off Meeting

The contractor should conduct an initial Kick-Off Meeting with ACL. The Kick-off Meeting is the first 

meeting with the project team members to discuss the project and the work that will be completed. This 

meeting introduces the members of the project team and provides the opportunity to discuss the role of 

each team member in the project work. ACL should indicate to the contractor what discussion topics 

should be addressed. Discussion topics may include the following, depending on ACL’s needs:

 Review of project purpose, objectives, and expected products

 An overview of existing program issues

 Development of a plan for getting ACL feedback on deliverables and project’s issues

 Development of the project work plan to guide the overall direction of the project and a Quality 

Assurance Surveillance Plan (QASP) to ensure a high quality of deliverables under the plan

 A discussion of the format and timetable for deliverables

 A review of the project governance strategies and processes

 Any other questions or issues identified by the contractor and/or ACL
11

Task 1.3: Develop Project Work Plan

The contractor should develop a Project Work Plan. The plan may include the following, depending on 

ACL’s needs: 

 The contractor’s approach for maintaining regular contact with ACL

 The contractor’s responsibilities, including responsibilities for roles and corresponding personnel 

assignments, and if applicable, subcontractors

 Plan for documenting key project decisions

 Approach for ensuring adequate ACL feedback on key project deliverables

 Work schedule/timeline for the project, including key project milestones, and due dates, and 

artifacts and deliverables— this may include work breakdown or other specific structures that 

define the work of this project

 Management control system to facilitate project performance measurement, and quality 

assurance and improvement against the work breakdown or other structure

 Performance and service levels, and reporting intervals for specific tasks

Task 1.4: Develop a Quality Assurance Surveillance Plan (QASP)

The contractor should produce a QASP to ensure that every process and deliverable meets a high-quality 

standard and provides the desired results according to the scope of work. ACL will use the QASP to 

monitor the quality of the contractor’s performance. The oversight provided for in the contract and in 

the QASP will help to ensure that service levels reach and maintain the required levels throughout the 

contract term. Further, the QASP provides ACL with a proactive way to avoid unacceptable or deficient 

performance. The QASP should include descriptions of performance standards, surveillance methods, 

and explanations of how the contractor will meet performance standards for all tasks and subtasks 

under this effort. The contractor should submit a draft QASP in response to the request for 

proposal/quote. Following award, the contractor should revise the QASP based on feedback from ACL 

during the kickoff meeting. The contractor should submit a revised QASP at the same time as the initial 

draft of the Project Work Plan for ACL’s review and approval.

Task 1.5: Transition operation at the end of contract

ACL should indicate if they require transition of operations at the end of the contract. ACL should 

indicate what transitions they will require and request that the contractor provide their proposed

approach for the transitions.

Task 2.0: Compile business requirements

The contractor should thoroughly review the Foundational Requirements Document. This document

describes the known back-end (to include the consolidated database prototype) and front-end functions 

ACL Data must be able to perform to fulfill ACL’s business needs. The contractor should propose an 

approach for how they will review, validate, and refine these known requirements, as well as how they 

will identify and compile additional requirements to create a final, comprehensive Business 

Requirements Document for ACL’s review and approval. The contractor’s approach should include how 

they intend to gain information from key ACL management, technical staff, program staff, AGID users, or 

others to obtain a clear picture of what users of ACL Data need.
12

Task 3.0: Define system requirements 

The contractor should propose an approach for translating the business requirements within the

approved Business Requirements Document into system requirements. The approach should indicate 

the format of system requirements (i.e., user stories, functional requirements documents, etc.) they 

plan to produce and describe their method for translating the business requirements into system 

requirements that encompass all desired back-end (to include the consolidated database prototype) and

front-end functions, features, and services of ACL Data. The contractor should also provide the process 

for how they will review the system requirements with ACL, and how they propose ACL will

approve/sign-off on them.

Task 4.0: Define technical requirements

Leveraging the approved system requirements, the contractor should develop all technical requirements 

necessary to support ACL Data. These should include software and hardware requirements for 

development and maintenance, as well as processes for migrating, importing, processing, and 

outputting of data. In preparation for developing technical requirements, the contractor should plan a 

meeting with ACL technical staff to identify any technical parameters ACL requires for ACL Data. During 

this meeting the contractor should also confirm all technical documentation required under this task. 

ACL should indicate all the documents that the contractor is expected to complete under the effort.

Task 5.0: Define security requirements

The contractor should develop and execute a System Security Plan (SSP) and conduct related security 

and privacy assessments in accordance with the Federal Information Security Management Act (FISMA) 

for proper operation of ACL Data. The IT Security Plan must ensure the integrity, confidentiality, when 

appropriate, and availability of all data collected on behalf of the Federal government. All records that 

are the property of the Federal government must be maintained in accordance with HHS policies and 

procedures, and National Archives and Records Administration (NARA) disposition schedules.

ACL will determine the appropriate security level for the disparate data sets as well as the entirety of 

ACL Data. ACL expects that the system to be at a FISMA low-impact level since the data are publicly 

available and do not include any personally identifiable information.

Under this task, the contractor should document and verify the existence of specific security threats, 

their severity, minimum mitigation, or authentication measures needed, and the need for specific 

requirements such as firewalls, access control and user permissions, encryption methods, and data

source-specific security requirements, if any. The contractor must also include detailed protocol for how 

they would approach and resolve incidents involving breaches of security. Task 9.0 provides an overview 

of the requirements, activities, and documentation that may be applicable for Task 5.0.

Task 6.0: Develop wireframes

Using wireframing tools (e.g., Balsamiq, Lucidchart, Microsoft Visio, etc.), the contractor, should create 

wireframes, or visual representations of ACL Data. These may include diagrams, schemas, or mock-ups 

that depict the proposed methods for accomplishing the system requirements for all back-end (e.g., 

schema) and front-end (e.g., user interfaces) elements. Wireframes that depict data relationships, flow, 

and interactions are essential for this effort. The contractor should review all wireframes with ACL and 

modify them as necessary until ACL approves them. The contractor should be prepared to minimally 

revise system requirements if modifications to wireframes warrant the changes.
13

Task 7.0: Develop the system

Task 7.1: Define the development methodology

The contractor should propose a methodology for developing ACL Data. It is recommended that ACL be 

open to Waterfall, Agile, or hybrid approaches. The Waterfall methodology is linear, employing a 

sequential design and implementation process that defines the activities and processes completely 

before work begins. The system would be developed, then presented to ACL. Progress and status 

presentations would be given to keep ACL informed of potential slippage to the project timeline and 

risks to project completion. The Agile methodology proposes an incremental and iterative approach to 

system design. The design process is broken into individual models that designers work on. There is no 

pre-determined course of action or plan. Designers are free to respond to changes in requirements as 

they arise and make changes as the project progresses. ACL may serve as a Product Owner or identify a 

customer representative who will be a member of the core Agile team. Hybrid methodologies involve a 

combination of aspects of Agile and Waterfall.

The contractor should indicate the primary methodology they intend to use and provide an explanation 

of the benefits the methodology will provide ACL. It is assumed that an Agile methodology will demand 

a deeper level of ACL’s participation and resources compared to the Waterfall approach. Since the 

choice of development methodology can significantly affect ACL’s role and involvement, ACL should 

request an estimated level of effort (in hours) the contractor anticipates ACL staff should plan to 

participate in discussions, reviews, demonstrations, etc. on a weekly basis during the development 

phase.

ACL can decide if one approach makes more sense to deploy than the other prior to making a final 

selection among the RFP finalists if it is clear that the requirements and skillsets of the applicant pool 

make it more feasible for one approach or the other. For example, if it is expected that ACL will prefer a 

more iterative approach to user experience and user interface development, but is clear on stability of 

the back-end requirements, then ACL may choose to adopt a hybrid approach according to specific 

phases of development.

Regardless of the approach selected, the contractor’s role will be to formalize the working agreements 

and structure of the project management team and process. These decisions shall be presented by the 

contractors to ACL, who will then review and approve the approach.

Task 7.2: Establish the environments

In addition, the contractor will define the environments in which to develop ACL Data. At a minimum,

the following should be established:

 testing environment (i.e., where data is first imported, processed, and tested)

 staging environment (i.e., where the accuracy/integrity of the data is verified)

 production (i.e., where the data goes live for public use).

Having the three environments gives the contractor greater flexibility to reverse any errors/problems 

that may occur. These environments should be based on Microsoft technologies such as Windows 

Server and SQL Server. The consolidated database prototype is developed in SQL Server.
14

The contractor should fully document the tasks and milestones which must be completed at each stage 

before updates can be pushed to the next environment. In addition, the contractor should provide ACL 

with access to the three or more environments to facilitate design decisions, feature implementation, 

and user testing.

Task 7.3: Develop the code for the system

Once the environments are identified and established, the contractor should develop the code for ACL 

Data. The contractor should provide scripts for SQL tables informed by the system requirements and 

wireframes to code the back-end and front-end (e.g., coding the user interface for different types of 

users – administrator, public-user, super-user [e.g., public-user with approved access to certain 

restricted files, etc.]). For producing the front-end website, the contractor should employ WSYIWYG / 

HTML coding for the UI/UX development, including prototypes.

To conduct rigorous and logical version control of the code base, the contractor should outline a system 

and process for version control in a memo to ACL. The contractor may choose among popular version 

control systems, such as SQL Source Control in conjunction with Git, TFS, or Subversion.

ACL may want to request that the contractor share access to the code base platform with ACL staff. This 

would allow ACL to review the coding with a minimum of file transfers and email attachments. ACL may 

also want to request that the contractor provide a changelog at a mutually agreed upon interval. The 

changelog would allow ACL to better track iterations and progress made in achieving functional and 

business requirements.

Task 8.0: Test the system

To ensure that the new system fulfills the business requirements and is fully functional to all user types 

without potential failure points, the contractor should perform functional testing, quality assurance 

testing, and accessibility testing.

Task 8.1: Conduct functional testing

The contractor should perform functional testing to check that back-end and front-end system 

requirements have been met for proper input, processing, and output of data (e.g., queries can produce 

information from multiple data sets). Typically, the developer performs basic functional testing. The 

contractor should consider key steps of the testing phases performed in the initial ACL Data 

Restructuring Project and Phase II.

Task 8.2: Conduct quality assurance (QA) testing

The contractor should test many scenarios to try to ‘break’ the system and identify requirements of the 

system that are not being fulfilled. The contractor should provide their approach to QA testing since 

there are many acceptable forms; and approaches tend to vary based on unique organizational 

processes. It would be advantageous if the contractor had their own dedicated group of staff who 

perform QA testing given the size/scope of the system to be developed. QA testing may include test 

cases (or testing against user stories), multiple levels of QA (e.g., junior staff that perform preliminary 

testing followed by senior staff that review/approve the testing), etc.

Task 8.3: Conduct accessibility testing

The contractor must conduct testing to ensure the system is accessible to users with disabilities. The 

contractor should detail their approach for ensuring 508 compliance. Accessibility testing should be 
15

conducted throughout the development process. A comprehensive and thorough process to ensuring 

the accessibility of the system, such as the Interagency Trusted Tester Program (ITTP) is preferred (More 

information available from: https://www.dhs.gov/interagency-trusted-tester-program).

The contractor will provide progress reports of testing results in regular status updates to ACL. Any 

issues that are identified in the testing phases will be documented in a tracking document with 

resolution plans included. After discussing potential issues with ACL, ACL may approve the resolutions 

plans and the contractor may implement them.

Task 8.4: Conduct full pilot testing with user groups

The contractor should verify the entire system under a real-time operating condition in a user simulated 

environment before deploying it to production. The contractor should provide ACL with a pilot test plan 

detailing their proposed criteria for the group of end users who will participate in the test, how they will 

recruit the group, the test cases the group will perform, and the mechanisms to collect feedback from 

the group. After ACL has approved the plan, the contractor should perform the pilot test. The contractor 

should document and prioritize, with ACL, any bugs or enhancements gleaned from the pilot testing. The 

contractor should be prepared to remediate any high priority bugs or implement critical enhancements 

prior to launch, dependent on ACL’s instruction. 

Task 9: Develop Authority to Operate (ATO) Package

All of the contractor deliverables (described below) under this task must comply with applicable federal 

laws that include, but are not limited to, the Federal Information Security Modernization Act (FISMA) of 

2014, (Title III of the E-Government Act of 2002, Public Law 107-347), Office of Management and Budget 

(OMB) Circular A-130, Management of Federal Information Resources, Appendix III, Security of Federal 

Automated Information Resources, Federal Acquisition Regulation (FAR) 39.101 , HHS Acquisition 

Regulation (HHSAR) Subpart 311.70—Section 508 Accessibility Standards , and other applicable federal 

laws, regulations, National Institute of Standards and Technology (NIST) guidance and Departmental 

policies.

In accordance with the timeframes specified by ACL’s Chief Information Security Officer (CISO), ACL 

should direct the contractor to prepare and submit the security requirements for review, comment, and 

acceptance to achieve an authority to operate (ATO) for the system. Adherence to FISMA standards is 

required for federal agencies, departments, and contractors who are engaged in the processing or 

storage of federal data systems. The contractor must complete the FIPS 199 Standards for Security 

Categorization of Federal Information and Information. Based on the FIPS 199, ACL should require that 

the contractor perform the applicable Security Assessment and Authorization (SA&A) activities 

necessary to obtain the ATO. These may include the following:

 System Security Plan (SSP) – The SSP must provide an overview of the system environment and 

security requirements to protect the system as well as describe the security controls in place or 

planned for meeting those requirements. It must provide a structured process for planning 

adequate, cost-effective security protection for a system. The contractor must review and 

update the SSP at least annually thereafter, if a substantive change is made to the system, or if 

emerging circumstances require a change the system to ensure adequate management and 

technical controls.

 Security Assessment Report (SAR) – The contractor and ACL must arrange for an independent 

assessor to conduct a security assessment consistent with NIST SP 800-53A, NIST SP 800-30, 
16

latest revisions, and any additions or augmentations requested by ACL. The assessor must

document the assessment results in a SAR. The contractor must update the SAR at least annually 

thereafter.

 Plan of Actions and Milestones (POA&M) – The contractor must mitigate all security risks found 

during continuous monitoring and security reviews of the system. The contractor must mitigate 

all high-risk vulnerabilities within 60 days and all moderate risk vulnerabilities within 180 days 

from the date vulnerabilities are identified. The contractor must track all identified risks 

between required security control baselines, continuous monitoring controls, and the 

contractor’s implementation, as documented in the SAR, for mitigation in POA&M 

documentation. 

 Contingency Plan – The contractor must develop a contingency plan in accordance with NIST SP 

800-34, latest revision, and other applicable HHS guidance. Upon acceptance by the system 

owner, the contractor must test the contingency plan and prepare a contingency plan test 

report that includes the test results. The contractor must update and test the contingency plan 

at least annually thereafter.

 Security Review – The contractor must perform an independent annual security control 

assessment and provide to ACL for verification by the ACL CISO that the system ATO remains 

valid. Evidence of a valid system security authorization includes written results of (A) annual 

testing of the system contingency plan and (B) the performance of a security control

assessment. Upon the ATO award, the contractor-operated system must meet or exceed the

continuous monitoring requirements identified below.

 Government Access for IT Inspection – The contractor (and/or its subcontractors) must afford 

the government, including but not limited to the U.S. Department of Justice and the HHS Office 

of the Inspector General (OIG), access to its and the subcontractors’ facilities, installations, 

operations, documentation, information systems, and personnel used in performance of this 

contract to the extent required to carry out a program of IT inspection (to include vulnerability 

testing), investigation, and audit to safeguard against threats and hazards to the integrity, 

confidentiality, and availability, of federal data or to the protection of information systems 

operated on behalf of HHS. The contractor, and any subcontractor at any tier handling or 

accessing protected information, must consent to and allow the government, or an independent 

third party working at the government’s direction, without notice at any time during a weekday 

from 9:00 a.m. to 5:00 p.m. contractor/subcontractor local time, to access contractor and 

subcontractor installations, facilities, infrastructure, data centers, equipment (including but not 

limited to all servers, computing devices, and portable media), operations, documentation 

(whether in electronic, paper, or other forms), databases, and personnel which are used in 

performance of the contract. The purpose of the access is to facilitate performance inspections 

and reviews, security and compliance audits, and law enforcement investigations. For security 

audits, the audit shall likely check, at a minimum, buffer overflows, open ports, unnecessary 

services, lack of user input filtering, cross site scripting vulnerabilities, SQL injection 

vulnerabilities, and any other known vulnerabilities. The contractor’s (and any subcontractor’s) 

cooperation with inspections, audits, investigations, and reviews must be provided at no 

additional cost to the government.

 Information Security Continuous Monitoring – All of the contractor- and subcontractorowned/operated systems that input, store, process, output, and/or transmit sensitive 

information must meet or exceed the information security continuous monitoring requirements 

identified in FISMA, based on the sensitivity level of the system. The contractor (and/or any 

subcontractor) must also store monthly information security continuous monitoring data at its 

location for a period not less than one year from the date the data is created. The monthly 
17

continuous monitoring data must be encrypted in accordance with FIPS 140-2 Security 

Requirements for Cryptographic Modules and shall not be stored on systems that are shared 

with other commercial or government entities. The government may elect to perform 

information security continuous monitoring and IT security scanning of the contractor (and/or 

any subcontractor) systems from government tools and infrastructure. Based on the sensitivity 

level of the system, and the need for monitoring defined in the SSP, ACL may request the 

contractor work with HHS Incident Response Teams to include the system’s continuous 

monitoring data in HHS-maintained IT security continuous monitoring dashboards.

 Asset Management – The contractor (and/or any subcontractor) must use any available Security 

Content Automation Protocol (SCAP)-compliant automated tools for active/passive scans to 

provide an inventory of all IT assets for both hardware and software, (computers, servers,

routers, databases, operating systems, etc.) that are processing government-owned 

information/data. It is anticipated that this inventory information will be required to be 

produced at least monthly. The contractor (and/or any subcontractor) must be capable of 

providing detailed IT asset inventory information, to include IP address, machine name, 

operating system level, security patch level, and SCAP-compliant format information. The 

contractor (and/or any subcontractor) must work towards ultimately maintaining a capability to 

provide an inventory of 100% of its IT assets using SCAP-compliant automated tools. The 

contractor must consult with the ACL CISO to determine how best to satisfy this requirement.

 Configuration Management – The contractor (and/or any subcontractor) must use available 

SCAP-compliant automated tools, per the NIST IR 7511, for authenticated scans to provide 

visibility into the security configuration compliance status of all IT assets, (computers, servers, 

routers, databases, operating systems, application, etc.) that are processing government-owned 

information/data. Compliance will be measured using IT asset and system security configuration 

guidance provided by the government, for all IT assets. The SCAP-compliant automated tools 

will compare the installed configuration to the government specific security configuration 

guidance; contractor may reflect the most restrictive security configuration mode consistent 

with operational requirements. It is anticipated that this IT asset security configuration 

information will be required to be produced at least monthly. The contractor must work 

towards ultimately maintaining a capability to provide security configuration compliance 

information for 100% of IT assets using SCAP-compliant automated tools. The contractor must

consult with the ACL CISO to determine how best to satisfy this requirement.

 Vulnerability Management – The contractor (and/or any subcontractor) must use SCAPcompliant automated tools for authenticated scans to detect any security vulnerabilities in all IT 

assets, (computers, servers, routers, Web applications, databases, operating systems, etc.) that 

are processing government-owned information/data. It is anticipated that this IT asset security 

vulnerability information will be required to be produced at least monthly. Contractors (and/or 

any subcontractors) must actively manage system vulnerabilities using automated tools and 

technologies where practicable. Automated tools must be complaint with NIST-specified SCAP 

standards for vulnerability identification and management. Additionally, contractors without inplace automated SCAP-compliant vulnerability management tools and technologies, are 

required to provide the number of systems (expressed in a percentage) that vulnerability 

information can be obtained for along with plans for procuring and implementing automated 

tools that comply with HHS requirements. The contractor (and/or any subcontractor) must work 

towards ultimately maintaining a capability to provide security vulnerability scanning 

information for 100% of IT assets using SCAP-compliant automated tools. The contractor must 

consult with the ACL CISO to determine how best to satisfy this requirement.
18

 Data Protection – Current Federal government security guidance requires that sensitive 

government information that is stored on laptops and other portable computing devices must 

be encrypted using Federal Information Processing Standard (FIPS)-140-2 validated encryption. 

The contractor must provide the percentage of portable IT assets that are equipped with FIPS 

140-2 validated encryption, to encrypt all sensitive government information, via a report on a 

quarterly basis. ACL requires that all data used to satisfy the requirements of this contract be 

encrypted, both at rest and while in transit.

 Remote Access – Current Federal government security guidance requires that two-factor 

authentication be implemented when remotely accessing sensitive government-owned 

information/data on IT systems (both government owned and contractor owned systems). The 

contractor must work with the ACL CISO to determine, adhere to, and report on any additional 

remote access requirements for the system based on results of the FIPS 199.

 Continuous Vulnerability Remediation – The contractor (and/or any subcontractor) must install 

critical security patches or take other security remediation action as directed to Federal agencies 

by the Department of Homeland Security (DHS) to resolve weaknesses in systems processing 

government-owned information/data. The contractor must report status and when the directed 

action has been completed. It is anticipated that this type of urgent security remediation action 

may be necessary at least 1-2 times per month.

 Secure Coding – The contractor (and/or any subcontractor) must follow secure coding best 

practice requirements, as directed by United States Computer Emergency Readiness Team (USCERT) specified standards and the Open Web Application Security Project (OWASP), that will 

limit system software vulnerability exploits. The contractor must consult with the ACL CISO to 

determine when and how the appropriate code reviews are undertaken.

 Standard for Security Configurations – The Contractor (and/or any subcontractor) must apply 

approved security configurations to IT that is used to process information on behalf of HHS.

 Desktop and/or Laptop Computers or Other Computing Devices Required for Use by the 

Contractor – The Contractor (and/or any subcontractor) must ensure that IT equipment that is 

used to process information on behalf of HHS are deployed and operated in accordance with 

approved security configurations determined by ACL and the contractor.

 Information Technology Application Design or Support – The Contractor (and/or any 

subcontractor) must ensure IT applications designed for end users run in the standard user 

context without requiring elevated administrative privileges per the HHS Acquisition Regulation 

(HHSAR) Subpart 352.239-70–Standard for Security Configurations.

Task 10: Deliver the system

After all testing is completed to ACL’s satisfaction, the contractor will push the site “live” to production 

so that end users can use the system. The contractor will describe their approach for pushing the system 

to production.

There are many acceptable pathways for getting the system live for public use, which may include 

performing user acceptance testing (UAT), post-launch acceptance testing (PAT), etc. UAT is like QA

testing but is performed by ACL as a final step of review and approval before the system moves to 

production. PAT is like UAT but performed in the production environment.

After the site goes live, the contractor will continue to monitor and fulfill troubleshooting and 

maintenance tasks for originally agreed-upon functional requirements that experience outages, errors, 

warnings, or deviant functionality from the expected requirements. This period of maintenance will last 
19

for a fixed period of time prior to the end of the contract in order to avoid interruptions in service or 

unacceptable customer service to users.

Task 10: Maintain and operate the system

Following deployment of ACL Data to production, the contractor should maintain the system. Prior to 

the launch, the contractor should provide details of how they will accomplish this task in an Operations

& Maintenance (O&M) Plan. The O&M Plan describes the day-to-day activities that are conducted and 

managed and indicates who is responsible for each task. ACL should provide the O&M Plan template to 

the contractor to complete. ACL should also consider if they wish the contractor to provide helpdesk 

assistance for system users.

Major Deliverables

 Kick-Off Meeting

 Project Work Plan

 Quality Assurance Surveillance Plan

 Business Requirements Document

 System Requirements

 System Security Plan

 Wireframes

 List of milestones and checkpoints for advancing system codebase from one environment to the 

next

 Results of functional, quality assurance, accessibility, and pilot testing

 ATO Package

 Final Live Website

 Operations and Maintenance Plan

Timeline

Without having a full set of foundational requirements to scope out entirely the work required for Phase 

III, it’s difficult to determine an accurate timeline. ACL can determine a more accurate estimate once 

these requirements are complete. However, based on the known requirements and previous efforts of 

similar size and scope, the timeline (excluding activities performed under “Task 10: Maintain and 

operate the system”) is currently estimated to be within 9 to 12 months, given the estimated staff levels 

of effort indicated below.

Estimated Staff Levels of Effort

More accurate staff levels for Phase III should be determined based on the final Foundational 

Requirements Document and the consolidated database prototype developed in ACL Data Restructuring 

Phase II. However, the following staff would be essential for the project and estimated hours are 

provided based on a 9 to 12-month development cycle for the base year.

Staff Type Role Description Estimated Hours

Product or System 

Owner

Responsible for defining all business requirements for the 

system and how it will be used. His or her input describes 

the problem or the opportunity that the system will 

ultimately solve. ACL staff will serve in this role.

N/A
20

Staff Type Role Description Estimated Hours

Technical Project 

Manager

Develops and maintains a project plan for developing, 

operating, and maintaining the system. The plan outlines 

the project tasks, milestone dates, status, and allocation of 

resources. He or she also has a background and essential 

experience in managing Information and Communication 

Technology projects.

380-640

Business Analyst Captures, consolidates, and communicates information 

from Subject Matter Experts to the rest of the development 

team. This person works with the Product or System Owner 

and other subject matter experts to translate their needs 

into business, system, and/or technical requirements.

580-1,100

Database Architect Develops and maintains a formal description of the system 

data and data structures - this can include data definitions, 

data models, data flow diagrams, etc.

260-520

Database 

Developer

Develops databases used within a system. 640-1,140

Database 

Administrator

Maintains databases used within a system. 390-520

Quality Assurance 

Lead

Responsible for developing methods to test that the system 

that is built meets its system requirements and functions 

properly.

300-560

Accessibility 

Testing Lead

Responsible for testing a system to ensure it meets the 

Federally mandated accessibility requirements of Section 

508 of the Rehabilitation Act.

170-300

Contractor 

Systems Security 

Officer

Responsible for overseeing the implementation of all 

security requirements and system-related security controls. 

This person also manages the contractor’s involvement in 

obtaining and maintaining the system’s ATO.

150-250