HSIN 3x SOO Excerpt.pdf

Excerpt

HSIN 3.x Statement of Objectives

May 31, 2011

1. Introduction

1.1. Purpose

The purpose of this Statement of Objectives (SOO) is to accomplish the Homeland Security Information Network (HSIN) core platform upgrade to Microsoft SharePoint 2010, integrate the SharePoint 2010 solution with the existing Identity Management solution, and provide O&M support for the new platform. The new version of the HSIN solution will be referred to as HSIN 3.x.

1.2. Vision

HSIN 3.x will be recognized as a best practice program model and technology solution for secure, mission-focused information sharing and collaboration. HSIN will become the single data access point for queries to DHS supplied data.

1.3. Mission

HSIN is a secure, web-based platform for sensitive but unclassified (SBU) information sharing and collaboration among DHS and its Federal, State, Local, Tribal, Territorial, Private Sector, and International partners across the full spectrum of homeland security mission areas.

HSIN will support the following DHS mission needs:

• Timely and accurate information related to detecting, preventing, responding, and recovering to terrorism or other natural or manmade hazards;

• Timely and accurate information regarding vulnerabilities and threats; manage incidents to mitigate risks and reduce post incident loss of life and property;

• Support for the Emergency Management community for information exchange and collaboration in support of response and recovery operations; and

• Efficient and coordinated information sharing to connect disparate information users in dynamic and diverse information exchange environment.

1.4. Background

HSIN is the Department’s platform for sharing Sensitive But Unclassified (SBU) information between Federal, State, Local, Tribal, Territorial, Private Sector, and International partners engaged in preventing, protecting from, responding to, and recovering from all threats, hazards, and incidents within the authority of DHS.

The primary HSIN solution, referred to as HSIN Legacy, is based on Microsoft SharePoint 2003 and hosted in DHS Data Center One. The solution includes instant message capability based on Jabber, and online meeting capability based on Adobe Connect. Other services for identity management are included in the solution. HSIN Legacy currently hosts over 30,000 users across 48 major Communities of Interest (COI)s.

In the spring of 2008, a contract was awarded to upgrade the HSIN platform and assume the Operations & Maintenance (O&M) activities for HSIN. This upgrade to a Sun and Documentum based solution was referred to as HSIN NextGen 2.x. HSIN NextGen 2.x was partially stood up with limited functionality in late 2009 and hosts over 1600 users (15% active users). This solution is also located in DHS Data Center One.

Recent analysis has concluded that further development on the HSIN NextGen 2.x platform is not in the best interest of the Government and the HSIN users. We are looking for a new integrator to perform a system upgrade to a new solution based on Microsoft Share Point 2010 and hosted in DHS Data Center Two. This system will be referred to as HSIN 3.x.

HSIN has been identified as the Department’s target SBU portal as part of a portal consolidation effort. A DHS SBU Portal Interoperability Segment Architecture has identified candidate portals for both consolidation and interoperability onto the HSIN platform. By the end of FY12, at least 10 DHS portals are to be consolidated onto the HSIN platform.

To support the decision to move to the Microsoft Share Point 2010 based solution, the HSIN program initiated a number of activities to assess and define the program needs. Outputs from these activities will help the contractor understand the Program and how we envision the new solution. HSIN 3.x development will involve configuration of the standard SharePoint application, customizations to the SharePoint application, some custom coding, and integration with other services.

HSIN 3.x will be developed and users will be transitioned over a 24 month period in three primary phases: Pilot, Initial Operating Capability (IOC), and Final Operating Capability (FOC)which includes the user transition to the new platform. The release time frames for all phases will start after a one month Transition Phase. The releases are defined as follows:

Pilot - HSIN Release 3.0 (6 months after Transition Phase) - The contractor will, at a minimum, configure Out-of-the Box requirements/features identified in Task

4.3 and add HSIN look and fell elements.

Initial Operational Capability (IOC) – HSIN Release 3.1 (9 months after Transition Phase), the contractor will, at a minimum, implement all the IOC requirements identified in Task Error! Reference source not found. and as many of the other remaining requirements as possible, implement any of the features identified in Task Error! Reference source not found. and integrate an IDM solution.

Final Operational Capability (FOC) - HSIN Release 3.2 (18 months after Transition Phase) the contractor will implement all the HSIN 3.2 requirements identified in Task Error! Reference source not found. with full IDM capability. The FOC will actually be at least three releases that will go out approximately every three months.

COI transition activities will extend five months past the development efforts that conclude at FOC. For additional information on this task please see Section 4.5.

1.5. Implementation Challenges

Implementing HSIN 3.x given its scale, complexity and mission will require a rigorous management approach that addresses both current, as well as anticipated, delivery challenges.

The contractor will take direction from the HSIN Program Office and work with several other project teams.

The HSIN Program Management Office will work collaboratively with current HSIN NextGen 2.0 developers, HSIN 3.0 integrators, the HSIN O&M team, the HSIN Help Desk, other applicable contractors, the HSIN Outreach Team, DHS leadership, and others, to effectively mitigate implementation risks in the areas listed below:

1. HSIN Scope Management / Requirements Management & Change Control – Aligning the development and deployment of HSIN 3.x with the capability requirements of DHS’ operational mission is critical. Managing to a clearly defined purpose and scope of the system will be a challenge given the breadth of “information sharing” and/or “collaboration” related requirements that have been identified by users.

The HSIN PMO will deploy a formalized HSIN information sharing governance model and a clearly defined requirements management, prioritization and change control process that will be used throughout implementation. The HSIN PMO will train and support compliance among team members with these processes and procedures as needed.

2. Usability, User Adoption & Information Overflow – With an estimated user base for FOC of 120,000, more than 70 major communities of interest, and the high volume of unstructured content making sure that users can find what they need quickly and easily will continue to be a challenge for HSIN. Improving the usability of HSIN will directly impact user adoption and mission performance improvement.

The HSIN PMO will institute a user-centric design and testing approach that is based on measurable and proven usability activities that will be conducted with users throughout implementation. Because usability testing activities are low cost / level of effort, while providing high value early in the design process, these activities will be conducted, in collaboration with the development team, early and often in order to make HSIN 3.x as easy to use as possible and as a result, achieve the highest levels of user adoption.

3. Schedule Management - Given the aggressive implementation schedule for the HSIN NEXT GEN Pilot and IOC (6 months and 9 months respectively), developing and managing to a realistic implementation schedule will be a challenge. Because IOC is due only three months after Pilot, there are several risks that will need to be identified and mitigation strategies that will need to be developed immediately.

The HSIN PMO has developed a Program Operating Model. The HSIN PMO will work collaboratively with the development team to monitor and report on schedule, escalate schedule-related risks and issues as early as possible and ensure compliance with schedule change control processes and procedures.

4. Performance Management and Executive Reporting – Understanding and communicating the value that HSIN NEXT GEN provides to DHS and users is important. Given the visibility, scale and mission of HSIN NEXT GEN, it is critical to demonstrate how HSIN NEXT GEN helps mission operators do their jobs more effectively, easily and/or quickly.

Providing DHS leadership meaningful, accurate and timely performance reporting to help inform decisions is imperative throughout implementation. Reporting how a HSIN NEXT GEN requirement translates into improved mission capabilities (e.g., better situational awareness, decreased time to coordinate incident response in the field, etc.) or internal operational efficiencies (increased ROI, reduced schedule variance, reduced cost variance, improved user satisfaction, etc.) is one of the HSIN NEXT GEN PMO primary responsibilities.

The HSIN PMO will work collaboratively with the development team to ensure the highest levels of performance and highest quality of performance reporting in order to support effective DHS decision-making throughout implementation.

5. Knowledge Management – Deploying integrated SOPs on a scale as large as HSIN NEXT GEN user base presents many challenges. For example, an SOP used for national incidents in which there may be 120,000 concurrent HSIN NEXT GEN users and 240,000 concurrent document accesses will require a high degree of coordination and collaboration. Moreover, additional complexities arise due to content governance and role-based access requirements for the large number and different types of HSIN users.

The HSIN PMO will work collaboratively with the development team to ensure the efficient and effective knowledge management, communications, training and change management processes and procedures are used throughout implementation.

2. Description

2.1. HSIN Software Environments

The next few sections describe, at a high level, the major releases and their progression through the proposed development environments. Each release will have some unique environment based requirements based upon its progression through the environments and its ultimate end state. HSIN’s goal is to work with the contractor to define the most cost effective sets of environments that will meet development, testing, and production needs of each release.

2.1.1. Development Environment

This environment will be used for the development of the HSIN 3.x solution. It is HSINs expectation that the development team will take the necessary steps to setup and configure this environment to support all activities defined by the SOO. This includes, but is not limited to, the installation of third party applications such as Adobe Connect, Jabber and Open SSO that will be necessary for IOC/FOC. This environment should include capabilities for source code control for storing and vetting custom code. This environment must be made available for use by multiple development teams to support HSIN requirements beyond FOC.

2.1.2. Test & Evaluation Environment

HSIN envisions the Test & Evaluation (T&E) environment to be used for multiple purposes. Those purposes include, but are not limited to;

Demonstrating new functionality to the user working groups as well as training of administrators and users in advance of a release.

All independent testing including, but not limited to, IT&E, UAT, 508, Integration, and Load/Capacity.

Potential sandbox area for the Outreach team to work with the end users to configure and demonstrate potential functionality.

There may need to be multiple instances of the test environment to support all these activities. This environment will need to be accessible to the Outreach Team, end users (both internal to DHS and external), and internal HSIN resources.

As HSIN is leveraging the agile methodology the T&E environment will receive regular code drops which may happen more frequently than the published Pilot, IOC, FOC release schedule. These code drops will need to be pushed to an environment, such as T&E, so they can be fully vetted. This is currently scheduled at the end of each Sprint.

It is HSINs expectation that the development team will take the necessary steps to setup and configure this environment to support all activities defined by the SOO, but is not limited to, the installation of third party applications such as Adobe Connect, Jabber and Open SSO that will be necessary for IOC/FOC.

Requirements for the T&E environment include the following:

Access to the environment shall be granted to the targeted pilot participants including external/non-DHS users (estimated at approximately 200).

The environment shall be sized to support a representative implementation of COIs, groups, and other structures and the 200 pilot participants. This sizing may increase as the releases that go through T&E progress.

Access by the users to the environment is not impacted by ongoing development activities.

Access by the Outreach team to demo functionality will not be impacted by ongoing testing activities.

Data generated in the T&E environment for the Pilot release will not be migrated to the production environment.

User accounts generated in the T&E environment for the Pilot release will not be migrated to the production environment.

For the Pilot release the T&E environment will support a limited subset of the authentication architecture.

2.1.3. Production Environment

Production is the full scale architecture serving requests from a user base scalable to a maximum of 200,000 users. This environment must be highly available and should be based on a vetted system design based on user requirements. This environment should be controlled by a configuration management team and should not be used as a test or development environment.

The production environment will potentially be used as a testing ground for the IOC release. Requirements for the Production environment while IOC is going through testing include:

Access to the environment shall be granted to the targeted participants including external/non-DHS users.

The environment shall be sized to support a representative implementation of COIs, groups, and other structures.

Access by the users to the environment is not impacted by ongoing development activities.

Access by the Outreach team to demo functionality will not be impacted by ongoing testing activities.

Data generated in IOC will be migrated to FOC.

Prior to IOC the Program shall obtain a RATC (Restricted Authority to Connect);

which will allow COI transitions to begin using production data and production users.

Prior to FOC the Program shall obtain a full Authority to Operate (ATO).

The environment leveraged by the IOC shall support the COI transitions and on boarding of new users.

The environment leveraged by the IOC/FOC will need to include an instance of the selected third party application software, which includes but is not limited to, an IDM suite, OpenSSO, Jabber, and Adobe Connect.

2.2. Release Progression

Pilot Release

The Pilot release shall be developed in the development environment and then be deployed in to a Test & Evaluation environment that will be accessible to numerous parties. The Pilot release will not be promoted to production but is expected to be accessible to select users throughout the development of the IOC release.

IOC Release

The IOC release shall be developed in the development environment and then promoted to an environment that can be leveraged by the independent testing teams. Because the Pilot release will reside in the T&E environment, the production environment can be used for testing the IOC release so that we minimize the number of environments that the contractor is supporting.

Once this release has been fully tested and accepted, it should be promoted to Production.

Please review the graphic below that displays the potential progression of the releases through the suggested environments.

FOC Release

The FOC release shall be developed in the development environment and then promoted to an environment that can be leveraged by the independent testing teams. By the time that FOC is going through development, the user community will have access to IOC and therefore the Pilot release can be cleared from the T&E environment thus allowing FOC to be tested there.

Once FOC has been fully tested and accepted it should be promoted to the Production environment. The FOC release will have the same environmental based requirements as the IOC release save additional capacity and that user accounts and data that is created in the IOC release will convey from the IOC production environment to this FOC production environment.

Figure 1 – Example Release Progression

3. Deliverable Details

The contractor will comply with HSIN Project Management Office (PMO) methods, tools, standards and data requests. The contractor shall promote the sense of partnership with all other teams on the Program. The contractor will take direction from the HSIN PMO. The contractor will be given a 30 calendar day transition period after the contract award before development sprints begin. The PMO will provide documentation and SMEs during the transition period.

Within the proposal the contractor shall submit a draft version of the Project Management Plan (PMP) that describes the contractor’s overall approach to management of the task order as well as information on the following subjects:

Project Management Approach Requirements Management Release Management Quality Management Schedule Management Risk Management with Risk Register based off of proposal assumptions Agile Development Methodology Testing Approach

This Project Management Plan should be refined during the transition phase and finalized before starting the initial agile development sprints.

Within the proposal the contractor shall also submit an approach for knowledge transfer during the transition phase. This approach should highlight the areas that the contractor believes they need additional information on to be successful with the project and a schedule of meetings that are needed to close the gaps.

Within the proposal the contractor shall also submit their Staffing Plan - containing the number of staff required by skill level, the project phases in which the numbers of personnel and types of skills are needed, the source personnel (including subcontractors, if any), subcontractor management and the timely provision of fully cleared staff

Within the proposal the contractor shall also submit a high-level Work Break Structure (WBS), down to level three where level one presents Pilot, IOC, FOC, and COI transitions. This high-level WBS represents contractors understanding of the work needed to successfully achieve on time and successfully scoped Pilot, IOC, and FOC releases.

3.1. Kickoff Meeting

The Task Order Kick-Off Meeting will take place within five (5) days after the contract award. The purpose of this meeting is for the Government and the Contractor to introduce team members, present their roles and responsibilities, provide an overview of the requirement based on the SOO and discuss any administrative matters. Also, the Contractor shall present its DRAFT project management plan contained in the Contractor’s quote. The contractor will take meeting minutes at this meeting and deliver them to the government No Later Than five (5) business days after the meeting.

The contractor has been tasked with creating a proposed schedule and approach for the transition phase, and this approach will be reviewed during the Kickoff Meeting. In preparation for the project initiation the government will also be preparing a proposed set of transition activities which shall be aligned with the contractor’s approach at the Kickoff Meeting.

3.2. SOO Transition

The transition will take place over the first calendar month of the contract and will be a time period for the contractor to ramp up, plan, and finalize the development Work Breakdown Structure (WBS) and schedule. It is expected that most meeting and knowledge sharing sessions will take place at DHS NOMA.

It is the expectation of the government that the contractor’s transition approach will include sufficient detail to finalize a schedule within the first few days of the project, including necessary functional and technical working/discovery sessions.

The information below has been provided as a standard schedule for the meetings that can take place during the transition period. These details are suggestions and should not constrain the contractor in any way.

Monday Tuesday Wednesday Thursday Friday

M ee ti ng s (A

M

Daily Stand‐ Up (30 mins)

Weekly Status (60 mins)

Daily Stand‐Up (30 mins)

Daily Stand‐ Up (30 mins)

Daily Stand‐Up (30 mins)

Daily Stand‐Up (30 mins)

M ee ti ng s (P

M ) Daily

Transition Working Sessions (120 mins)

Daily Transition Working Sessions (90 mins)

Daily Transition Working Sessions (90 mins)

Daily Transition Working Sessions (120 mins)

Daily Transition Working Sessions (120 mins)

Table 1 - Example schedule for weekly transition activities

Daily Stand-Up (am) – Facilitated by Contractor

• Identify agenda items for afternoon working session to include materials, attendees and meeting lead to coordinate

• Identify issues or risks that need to be included on logs

• Identify any items for DHS escalation

Daily Working Sessions (pm)

• One or multiple breakout sessions depending on agenda items identified in Daily Stand-Up Meeting

• Review select transition documentation in detail

• Answer questions / transfer knowledge

• Resolves issues / mitigate risks

• Develop / review transition schedule

Weekly Status

• Review project transition status (schedule, risks, issues, planned activities, accomplishments, etc.)

• Review escalated risks / issues for DHS to make decisions / provide guidance

3.3. Transition Exit Meeting

The contractor shall present the final versions of all the deliverables requested for the award and the baseline WBS, down to level five, for development.

The Transition Exit Meeting will take place at the DHS NOMA location one month after contract award and will signal the beginning of the Pilot development phase. The contractor will deliver and facilitate the transition exit meeting. The contractor will take meeting minutes at this meeting and deliver them to the government no later than five (5) business days after the meeting.

3.4. Development Schedule

The contractor shall develop and maintain a task-based development schedule. The schedule shall contain the milestones, accomplishments, criteria, and activities from contract award to the completion of the development contract. The contractor shall ensure schedule integration with its subcontractors and verify and ensure the validity of the subcontractors’ schedule data, including demonstrating effective methods for incorporating schedule data from subcontractors into the contractor’s schedule.

Subcontractor labor hours will be included in the schedule, along with an accurate updated percent complete. Material costs and percent complete will also be included in the schedule as material purchases correspond with a schedule the same way that labor does.

The contractor will work with the HSIN PMO to integrate this schedule into the overall Program Integrated Master Schedule (IMS). This will ensure a more complete picture of the program via the IMS.

3.5. Bi-weekly Schedule Risk/Issue Reports

The Contractor shall provide bi-weekly schedule risk/issue status reports to the HSIN PM. These informal reports will also include a listing of tasking outside of the scheduled tasks.

3.6. Bi-weekly Technical Meetings

The Contractor shall facilitate bi-weekly meetings at the DHS NOMA location with the HSIN team to review all aspects of the project.

The contractor will take meeting minutes at this meeting and deliver them to the government no later than five (5) business days after the meeting.

3.7. Monthly Status Reports

The Contractor shall provide monthly Status reports to the TO COTR, HSIN PM, and TO Government Contracting Officer (CO). The Status reports shall contain a standard heading with the following information at a minimum:

Contract number

Task order number

Task Order Period of Performance

Contractor Name, Project Manager’s name and telephone number

Task Order Award amount

Period of Performance being reported

Date of submission

Each status report will contain the following support items:

A brief summary description of technical progress;

For each task, provide: a summary of work completed, work in progress and work planned; and for labor hour tasks include hours/dollars expended for the reporting period and cumulatively and hours/dollars remaining;

Updated Project Management Plan;

Identify significant problems and their impacts, causes, proposed corrective actions; and the effect that such corrective actions will have on the accomplishments of the task order objectives;

The Schedule status or the degree of completion of tasks/activities by time intervals;

Upcoming events; and

Travel

4. Tasks

It is expected that the HSIN system will be developed following an agile methodology, with regular demonstrations of working software and iterative and incremental development of the requirements, design, and final solution. The contractor is expected to work closely with the government to discuss and define the appropriate implementation for any requirements being worked on. Documentation will be delivered incrementally with updates reflecting work that has been accomplished at the end of any sprint. The contractor and government will work together to finalize the processes for collaboration upon contract award. The PMO will provide the SELC tailoring plan for this agile development effort.

The major phases (Pilot, IOC, and FOC) will be broken down into releases and then further down into sprints. The sprints will consist of user stories and then tasks that have a maximum individual duration of five working days.

At the end of each Sprint, a Sprint Demo and Review will take place. This Demo and Review will demonstrate the user stories on working software to the end user community, the HSIN PM, and other stakeholders. Additionally, the review portion will include updates of the documentation of the architecture, design, and logistics of the HSIN system. This review will be an opportunity for governance boards to comment and make recommendations on the current implementation of HSIN. Any major updates to these areas will include a short presentation of those updates along with the documentation provided before the meeting.

Both the contractor and the government will have scrum masters to manage the daily schedule and user story backlog. Putting it all together:

The contractor will use a combination of user stories, screenshots from the HSIN PMO sandbox to configure the solution, and other requirements documentation. The user story template is provided as Appendix B to this document.

Development Testing

In addition to the software development process described above it is HSINs expectation that the contractor will conform to standard agile build and testing practices. It is expected that automated testing will be used for unit, integration, and system level testing. In addition to the automated test suite, ongoing manual tests and demonstrations in collaboration with the HSIN staff are expected. At the end of each sprint, test results are required to be part of the review and accepted by HSIN.

Independent Testing

In addition to the development testing efforts each HSIN release will go through independent testing which has been identified in the tailoring plan as User Acceptance Testing (UAT) and Operational Testing (OT). HSIN PMO will coordinate and manage the independent testing but the contractor will be required to provide support and any required test data.

Agile Meetings

In accordance with standard Agile best practices it is expected that there will be a series of meetings that take place on a daily, weekly, and monthly schedule. It is the expectation of the government that these meetings will involve both the contractor and other HSIN resources.

The table below should be used as an example of what the government considers to be standard agile development meetings. Details of the contractor’s agile approach and standard meetings should be incorporated into the proposal (via the Agile Development Methodology deliverable) and should include both sprint and release meetings.

Monday Tuesday Wednesday Thursday Friday

Week 0 Release Planning Story Refinement/ Planning Prep for

Sprint

Sprint 1

M1 Week 1 Sprint Planning Daily standup Daily Standup Daily Standup Daily Standup

M1 Week 2 Daily Standup Daily Standup Daily Standup Daily Standup Daily Standup

M1 Week 3 Daily Standup Daily Standup Daily Standup Daily Standup Daily Standup

M1 Week 4 Daily Standup Daily Standup

Daily Standup

Daily Standup

Sprint Demo and Review

Story Refinement/ Planning Prep for

Sprint

Sprint Retrospective

Sprint 2

M2 Week 1 Sprint Planning Daily standup Daily Standup Daily Standup Daily Standup

M2 Week 2 Daily Standup Daily Standup Daily Standup Daily Standup Daily Standup

M2 Week 3 Daily Standup Daily Standup Daily Standup Daily Standup Daily Standup

M2 Week 4 Daily Standup Daily Standup

Daily Standup

Daily Standup

Sprint Demo and Review

Story Refinement/ Planning Prep for

Sprint

Sprint Retrospective

Sprint 3

M1 Week 1 Sprint Planning Daily standup Daily Standup Daily Standup Daily Standup

M1 Week 2 Daily Standup Daily Standup Daily Standup Daily Standup Daily Standup

M1 Week 3 Daily Standup Daily Standup Daily Standup Daily Standup Daily Standup

M1 Week 4 Daily Standup Daily Standup

Daily Standup

Daily Standup

Sprint Demo and Review

Story Refinement/ Planning Prep for

Sprint

Sprint Retrospective

Post Sprints

TRR

PRR ORR

Table 2 - Example Agile Meeting Schedule

4.1. Planning and Engineering (Exclusive of Share point)

The contractor will perform project planning, engineering and implementation for all HSIN 3.x environments per agreed requirements leveraging P&E work that was completed for HSIN NextGen 2.x. The planning and engineering shall include all parties from the HSIN Program Office that have provided the current usage and planned growth of the system. The contractor shall review all planning and engineering documentation with the HSIN Program Office. The P&E effort will result in an updated Design Proposal Summary (DPS) delivery.

4.2. Train the Trainer

Prior to each release, the contractor is expected to provide the Outreach team with functional training based upon the newly introduced capabilities. This training can take place through software demos, documentation, or other methods that are agreed upon between the contractor and the HSIN Outreach Team. The Outreach team will take part in the User Acceptance Testing (UAT) and agile sprint demos.

4.3. HSIN Platform “Pilot” Implementation, Release 3.0

The initial Pilot will be referred to as HSIN Release 3.0. The target deployment date for this release will be six months following the Task Order Kick-Off Meeting. This release will primarily contain Microsoft SharePoint 2010 out of the box features configured to meet requirements identified in the table below. In order to provide the HSIN look and feel some level of custom configuration will be required for the pilot. The contractor will be incentivized to also develop any capabilities from IOC and FOC during the pilot phase.

The contractor will be given a one month Transition Period to gain a more in-depth understanding of the business requirements, the Program implementation methodologies.

Subject Matter Experts will be available to provide addition requirements and methodology details. The Pilot phase of the contract will commence after the Task Order Kick-Off Meeting.

The Pilot will be configured for use by a selected group of approximately 200 internal and external pilot stakeholders. Given the quick turnaround for this pilot phase, utilization of an IDM solution is not envisioned. The contractor must provide an alternate user access and authorization method.

It is anticipated that the pilot solution will be developed using the Testing and Engineering (T&E) environment, but the government is open to other possible solutions for hosting the pilot.

The HSIN Knowledge Management (KM) strategy will provide a high-level outline of HSIN community structure, content attributes, user attributes, and primary site template layouts.

The contractor will use this information to help refine level of effort estimates. These elements of the KM strategy will be incorporated into user stories prioritized for agile development.

With all HSIN 3.x releases, the Program plans for its minimum deployment expectations but seeks to pull capabilities forward to deliver more than expected where ever possible.

5. Optional Tasks

In addition to the required tasks above HSIN has identified a number of optional tasks that may be requested of the contractor.

5.1. (Optional) Portal Consolidation Assessments

When asked, the contractor shall assess the requirements for migration of specified DHS portal(s) based on the DHS SBU Interoperability Portal Segment Architecture, the DHS Portal Consolidation Transition Plan, and the specified DHS Portal(s) requirements and develop the appropriate migration plan which includes cost and schedule. At least 10 DHS portal are identified to be consolidated onto HSIN in FY11 and FY12.

5.2. (Optional) Surge Support

HSIN must be able to quickly respond to events and disasters. Effective support of these activities requires the ability to quickly increase capabilities and capacities (the number of users and sites supported) while not interrupting the availability and performance of the environment. This collaboration infrastructure design must include the ability to be extended without the reconfiguration of the base platform.

Based on the HSIN mission requirements, surge support by the service provider(s) may be required on limited notice.

6. Quality Assurance Surveillance Plan

The Government desires to provide incentives for completing requirements ahead of schedule and/or under cost ceilings.

7. Applicable References

Policy & Governance Documents

DHS MD 4200.1: Information Technology Capital Planning and Investment Control Portfolio Management https://acc.dau.mil/GetAttachment.aspx?id=251967&pname=file&aid=399 11&lang=en-US

Department of Homeland Security Acquisition Directive 102-01, including the Systems Engineering Life Cycle (SELC) in Appendix B, Final, Version 2.0, dated January 20, 2010 https://acc.dau.mil/CommunityBrowser.aspx?id=245749

IT Capital Planning and Investment Control (CPIC) and Portfolio Management, Attachment 1, Management Directive 4200.1 http://www.dhs.gov/xlibrary/assets/foia/mgmt_directive_42001_it_capital_planning_a nd_investment_control_cpic_and_portfolio_management_attachment_1.pdf

MD 0007.1

http://www.dhs.gov/xlibrary/assets/foia/mgmt_directive_0007_1_informati on_technology_integration_and_management.pdf

Department of Homeland Security Management Directive System MD Number: 4900 Individual Use and Operation of DHS Information Systems Computer http://www.dhs.gov/xlibrary/assets/foia/mgmt_directive_4900_individual_use_and_op eration_of_dhs_information_systems_computers.pdf

Enterprise Data Management http://www.dhs.gov/xlibrary/assets/foia/mgmt_directive_103_01_enterprise_data_man agement_policy.pdf

Information Technology Integration and Management http://www.dhs.gov/xlibrary/assets/foia/mgmt_directive_0007_1_information_technol ogy_integration_and_management.pdf

DHS Technical Reference Model (TRM) National Information Exchange Model (NIEM) http://www.niem.gov/files/NIEM_Introduction.pdf Clinger Cohen Act of 1996 http://www.tricare.mil/jmis/download/PublicLaw104_106ClingerCohenActof1996.pdf Government Performance and Results Act of 1993 http://www.orau.gov/pbm/links/PL103_62.pdf Paperwork Reduction Act of 1995 http://www.reginfo.gov/public/reginfo/pra.pdf Computer Security Act of 1987 http://security.isu.edu/pdf/csa_87.pdf Government Information Security Reform Act of 2000 http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=106_cong_public_laws&docid=f:publ398.106.pdf

Federal Information Security Management Act of 2002 http://csrc.nist.gov/drivers/documents/FISMA-final.pdf

Privacy Act of 1974 http://www.usdoj.gov/opcl/privstat.htm

OMB Circular A-130 Appendix III http://www.whitehouse.gov/omb/circulars_a130_a130appendix_iii/

OMB Circular A-123 http://www.whitehouse.gov/omb/circulars/a123/a123_rev.pdf

OMB Circular A-11 http://www.whitehouse.gov/omb/assets/a11_current_year/a_11_2008.pdf

Section 508 of the Rehabilitation Act of 1973 (amended) http://www.usdoj.gov/crt/508/508law.pdf

Executive Order 13011, Federal Information Technology, July 1996 http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=1996_register&docid=fr19jy96-133.pdf

President’s Management Agenda http://www.whitehouse.gov/omb/budget/fy2002/mgmt.Pdf

HSIN Privacy Impact Assessment http://www.dhs.gov/xlibrary/assets/privacy/privacy_pia_hsind.pdf

8. Deliverables and Delivery Schedule

All deliverables shall be prepared using Microsoft Office Suite module tools and delivered electronically to the Task Order (TO) Government Contracting Officer Technical Representative (COTR) with a transmittal notice of delivery to the TO Contracting Officer and TO Contract Specialist (CS) by the close of business 4:00 PM local time (Washington, D.C) unless otherwise stated in the Deliverable Table. Note: The Contractor shall send a copy of the monthly status report to the TO Government Contracting Officer and TO Contract Specialist. Deliverables shall be free of any known computer virus or defects. If the Government finds a virus or defect is found, the deliverable will not be accepted. The replacement file shall be provided within two (2) business days after notification of the presence of a virus.

Each deliverable shall be accompanied by a cover letter from the Contractor on Company letterhead. Multiple deliverables may be delivered with a single cover letter describing the contents of the complete package. The letter shall clearly indicate the following:

(a) Contract Number;

(b) Task Order Number;

(c) Name and address of the Contractor;

(d) Name and address of the TO COTR;

(e) Description of the deliverable, including the associated contract line item number;

In the event the Contractor anticipates difficulty in complying with any deliverable, the Contractor shall provide written notification immediately to the TO Government Contracting Officer, TO CS and TO COTR. Each notification shall give pertinent details, including the date by which the Contractor expects to make delivery; provided that this data shall be informational only in character and that receipt thereof shall not be construed as a waiver by the Government of any task order delivery schedule, or any rights or remedies provided by law under the EAGLE contract HSHQDC-06-D-00032.

8.1. Review of Deliverables

The Government will provide written acceptance, comments and/or change requests, if any, within five (5) business days from receipt by the Government of the deliverable.

Upon receipt of the Government comments, the Contractor shall have two (2) business days to incorporate the Government’s comments and/or change requests and to resubmit the deliverable in its final form.

8.2. Deliverable Table

The table below represents an overview of the current understanding of the documentation based deliverables and a general due date for each of those deliverables, the deliverables identified here and their due dates may change in order to comply with DHS and HSIN guidance.

THE DUE DATES OF ALL DELIVERABLES LISTED IN THE TABLE SHALL

COMMENCE AFTER FAVORABLE ENTRY ON DUTY (EOD) IS GRANTED.

Task

Deliverable Title Due Dates

Program Level Deliverables

3.0 Program Management Plan With Proposal Package

3.0 Draft - Development High-level Work Breakdown Structure (WBS)

With Proposal Package

3.0 Draft - Staffing Plan With Proposal Package

3.0 Draft - Risk Register With Proposal Package

3.2 Proposed Schedule & Approach for Transition Phase

With Proposal Package

3.1 Kickoff Meeting Presentation At the Kickoff Meeting

3.3 Transition Exit Meeting Presentation Five (5) business days prior to the Transition Exit

Meeting

3.3 Final Development Work Breakdown Structure (WBS)

Five (5) business days prior to the Transition Exit Meeting

3.3 Final Staffing Plan Five (5) business days prior to the Transition Exit

Meeting

3.3 Risk Register Five (5) business days prior to the Transition Exit

Meeting

3.5 Development Schedule Five (5) business days prior to the Transition Exit

Meeting

4.3.1 Fine Grained Permissioning Tool Assessment, Test Results and Recommendation

1 months after Transition Exit

4.1 Design Summary Proposal 2 months after Transition Exit

4.2 User manuals, Training Materials, PowerPoint Presentations and Work Instructions

At least Five (5) business days before an update is released to production

4.2 Train the Trainer Sessions With each release

5.1 Portal Consolidation Plans When Requested

Performance Reporting & Meetings

3.6 Bi-weekly Schedule Risk/Issue Reports Starting after contract award

3.7 Monthly Status Report The 5th business day of each month

4.0 Monthly Sprint Planning Meeting As Required

4.0 Monthly Sprint Demo Meeting As Required

4.0 Monthly Sprint Retrospective Meeting As Required

Software Deliverable

4.3 HSIN Pilot 3.0 6 months after Task Order kickoff

4.4 HSIN IOC 3.1 9 months after Task Order kickoff

4.6 HSIN FOC 3.2 12 months after Task Order kickoff

4.6 HSIN FOC 3.3 15 months after Task Order kickoff

4.6 HSIN FOC 3.4 18 months after Task Order kickoff

COI Transition

4.5.1 Technical COI Transition Strategy and Tool Selection

1 months after Transition Exit

4.5.2 Technical COI Transition Scripts Five (5) business days prior to IOC

4.5.2 COI Transition Test Results Five (5) business days prior to IOC

4.5.3 HSIN 3.0 COI site frame work for all major COIs

Five (5) business days prior to IOC

4.5.3 Technical COI Transition execution

Ongoing activity starting at IOC averaging 10 COI migrations per month, ending 24 months after Task Order kickoff

SELC Documents (as specified by the Tailoring Plan)

4.0 Integrated Logistics Support Plan Draft due at each Sprint, Final due at Release

4.0 System Design Document Draft due at each Sprint, Final due at Release

4.0 Interface Control Document (s) Draft due at each Sprint, Final due at Release

4.0 Requirements Traceability Matrix Draft due at each Sprint, Final due at Release

4.0 Logical Architecture and Design Document Draft due at each Sprint, Final due at Release

4.0 User/Data Technical Migration Plan Draft due at each Sprint, Final due at Release

4.0 Data Management Plan

Draft due at each Sprint, Final due at Release.

Responsibility of this document will be shared between the contractor and HSIN Team.

4.2 Training Material Five (5) business days prior to the TRR

4.2 Manuals Five (5) business days prior to the TRR

4.0 Deployment Plan Five (5) business days prior to the TRR

4.0 IRR/TRR Briefing Deck Five (5) business days prior to the TRR

4.0 Sprint Test Results Five (5) After each Sprint

4.0 Risk and Issue Log (Technical) Five (5) business days prior to each Sprint

4.0 Version Description Document Five (5) business days prior to TRR and PRR/ORR

SELC Stage Reviews (as specified by the Tailoring Plan)

4.0 Project Planning Review (PPR) As Required

4.0 Test Readiness Review (TRR) As Required

4.0 Production Readiness Review (PRR) As Required

4.0 Operational Readiness Review (ORR) As Required

In the table above numerous SELC documents are listed as “Draft due at each Sprint, Final due at Release”. The term draft in this context means that the document should be fully detailed out to a point that accurately and completely reflects that current state of the working system.

There are a number of documents/ items that the contractor is not directly responsible for but is expected to help support in order to facilitate the success of the entire program. These deliverables include, but are not limited to, Security documentation, Section 508 documentation, Technical Insertion Packages, User Acceptance Testing documentation as well as inputs to other program/project documents.

8.3. Additional Resources

In addition to the key personnel listed here HSIN has the expectation that the prime will be able to provide Subject Matter Experts with experience in all the technologies leveraged by the HSIN Solution.

9. Government Furnished Property (GFP)/Government Furnished Information (GFI)/Government Furnished Resources (GFR)

9.1. Government Furnished Property (GFP)

The Contractor may occasionally work at Government facilities, in which case the Government will provide access to computer workstations, if available.

The Government will provide components of the HSIN NextGen 2.0 Identity Management (IDM) solution as required by the final HSIN 3.0 solution.

10. Place of Performance

Performance of this task will primarily occur at the DHS Data Center facilities. Additional support will be provided from the EDS location in Herndon, VA and Raleigh, NC. The contractor shall meet at the customer site as needed and as identified above. Local Travel to DHS facilities for data migration coordination activities may also be required. The systems and services defined in this service agreement may not be performed in any other facility without the prior approval of the DHS Contracting Officer’s Technical Representative (COTR).All meetings, technical discussions and periodic reviews shall occur at DHS facilities (including numerous locations in the Washington, DC metropolitan area), or at The Contractor facilities described above. Other locations may be approved by the COTR.

11. Period of Performance

The Period of Performance for this task order is two years from date of award.

12. Travel

Travel performed for personal convenience or daily travel to and from work at the Contractor’s facility or local Government facility (i.e. designated work site) shall not be reimbursed. Travel will be reimbursed in accordance with the Federal Travel Regulations.

Travel will not be reimbursed within a 50 mile radius of the worksite. The Contractor must get Task Order COTR and HSIN PMO approval prior to travel. All travel must comply with the Federal Travel Regulations.

The Contractor shall coordinate specific travel arrangements with the Task Order COTR and HSIN PMO to obtain advance, written approval for the travel about to be conducted. The Contractor’s request for travel shall be in writing and contain the dates, locations and estimated costs of the travel. If any travel arrangements cause additional costs to the task order that exceed those previously negotiated, written approval by Task Order modification issued by the Task Order Contracting Officer is required prior to undertaking such travel.

The project management plan must include proposed travel.

The Contractor shall to the maximum practical extent, minimize overall travel costs by taking advantage of discounted airfare rates available through advance purchase and or existing Department transportation. Charges associated with itinerary changes and cancellations of nonrefundable airline tickets are reimbursable as long as the changes are approved by the Task Order COTR.