SharePoint RFP Tech - SLM 20Hand 20Book.pdf

Version 1.2 January 2008

System Lifecycle Management

The Systems Development Lifecycle of Immigration and Customs Enforcement

FROM: Luke McCormack, Chief Information Officer

DATE: January 28, 2008

SUBJECT: ICE System Lifecycle Management (SLM) Handbook, Version 1.2

Version 1.2 of the ICE System Lifecycle Management Handbook continues the evolution of the ICE System Lifecycle Management (SLM) process. Significantly, this latest version moves to align the ICE SLM process with the proposed DHS SDLC, Version 0.751.

As part of this alignment, you will find information regarding Section 508 of the Rehabilitation Act of 1973 woven throughout the process. Information includes background, compliance, testing, reporting, and gate review documentation. For further information regarding Section 508 compliance, contact the ICE Section 508 Coordinator in the OCIO Policy and Planning Office.

Additional information regarding privacy protection is also included in SLM Version 1.2.

As mandated by Section 208 of the E-government Act of 2002 and Section 222 of the Homeland Security Act, technology implementations across DHS must sustain privacy protections. Overview and compliance, activities, and gate review documentation have been added to this version for further alignment with the proposed DHS SDLC.

Further updates to this document include ICE Information Assurance Division (IAD) process and documentation. This office was formerly known as the Office of Information Systems Security (OISS).

The ICE OCIO Architecture Assurance Branch is responsible for coordinating all SLM activities. Contact ICE Architecture Assurance at ICE-SLMREVIEW@DHS.GOV for any questions or comments concerning the SLM process. For more information on the ICE Architecture Division, visit POWERPORT.ICE.DHS.GOV/TAPWEB.

Luke McCormack, Chief Information Officer

REVISION HISTORY

Version Date Summary of Changes

1.1 July 2006 Added text describing the referencing of other processes within the SLM Handbook (Preface: P-1)

Defined “system” (Preface: P-1) Added section that identifies the high-level parallel processes included in the

SLM Handbook (Preface: P-3) Updated Training Services (Office of Training and Development) activities and information (Global: 2, 4, 6, 29, 31, 32, 39, 41, 42, 50-54, 60, 63, 64, 71, 73, 74, 82, 87, Appendix A)

Added Privacy Impact Assessment activities and information (Global: 4, 26, 38, 40, 50, 51, Appendix A)

Updated Program Control Office role and activities (Global: 6, 26, 31, 32, 41, 42, 54, 64, 74, 82, 86, 87)

Updated the Security activities, information, and documents (Global: 6, 26, 30, 31, 39, 40, 41, 50-54, 63, 70, 72, 73, 80, Appendix A)

Added ICE Enterprise Architecture information (Section 1.5) Removed “Business Owner” as a recipient of consolidated document assessments (Section 3.2.3) Specified who adjudicates a Request for Deviation (Section 3.4.2) Updated list of Pre-defined Work Patterns (Section 4.2) Added text to document exhibits directing project teams to use the SLM template change history logs (Exhibits 18, 23, 28, 34, 39, 81) Added records retention and management requirements task (Section 5.1.1

#5 and Section 5.1.5 #1) Added Independent Test and Evaluation as attendee to Requirements

Review, Preliminary Architecture and Design Review, and Final Architecture and Design Review (Exhibits 24, 29, 30)

Added Data Management as “Resource and Guidance” for Activity 6.1.1 “Design system”

Changed Data Management to TA&I Information Interoperability as the review partner in Activity 6.1.5 #3 “Develop physical data model” (changed name to Architecture Services Data Architecture in December 2006 changes)

Added Data Management as “Resource and Guidance” for Activity 7.1.1 “Build System” (Exhibit 36)

Added pilot information (Section 7.1.2 and Section 8.2.5) Added Testing Options and Independent Test Plan activity and information

(Section 7.1.6 #5, Exhibit 35) Added System Workload Analysis Document (Exhibits 34, 39) Added Notice of Intent to Release details (Section 9.1 and Exhibit 42) Added Office of Information Systems Security (OISS) Information System

Security Officer, and Data Management as “Resource and Guidance for Activity 10.1.1 “Plan system disposition” (Exhibit 49)

Added OISS as “Resource and Guidance” for Activity 10.1.4 “Close out project” (Exhibit 49)

1.1 January 2007 Updated names throughout the document per the “Architecture Division Naming Conventions Update” (approved 11-06-06)

Final Edits March 2007 • Clarification to SLM process characteristics (P-2)

• Clarification to Exhibit 1: Key SLM Stakeholder Roles; Architecture Division and Program Control Office (p.2)

• Edited redundant language SLM High-Level Lifecycle Activities, Requirements Definition (p.4)

• Edited to correct table Key and for consistent language on Technical Reviews, Design, Final Architecture and Design Review (p.6)

• Correction DHS Enterprise Architecture and EAB reviews (p.9, 10)

ICE System Lifecycle Management Handbook January 2008

Version Date Summary of Changes

• All Requirements Reviews, added verbal approval language to Review Activities, and Sign moved to Post-Review Activities, Exhibits: 19(p.34), 24(p.43), 29p.54), 30(p.55), 35(p.65), 40(p.75, 48(p.88)

• All SLM Roles, changed Systems Engineering Branch to Engineering Division, and added Operations Division column, Exhibits: 5(p.6), 20(p.35), 25(p.44), 31(p.56), 36(p.66), 41(p.76), 45(p.84), 49(p.89)

• Clarified Section 2.3 Iterative (p.15,16)

• Clarified Document Assessment 3.2.2 (p.20)

• Format correction: missing header/footer (p.2,20,22)

• Clarified Planning Documents Exhibits: 18(p.33), 23(p.42), 28(p.53), 34(p.64), 39(p.74), 43(p.83)

• Clarified Incremental: Planning Consideration 4.7.1(p.36)

• Edited Iterative: Requirements Definition Consideration (p.45)

• Correction to 10.1.2 Publish Notice of Deletion, contact ICE Records Management (p.86,87)

• Corrected SLM Documents, Requirements Traceability Matrix (A-3)

• Added missing information to Other standards, Guidelines, and References (B-2)

• Clarified Data Flow Diagram (C-6)

• Exhibit 1: Application Hosting Services is moved under system Engineering Branch; clarified Users Group collaborates with Business Owner; PCO coordinates with the DHS EAB on the IRB

• Exhibit 6: Requirements Management: removed Facilitates user groups;

removed Application Hosting Services (2nd bullet moved to Architecture Consulting

• Page 10, added: through the ICE Program Control Office (PCO), which manages the ICE investment process

• Page 22, 3.4.2 clarified, Operations and Engineering Divisions

• 3.5 (p.23) clarified with the DHS Technical Reference Model (TRM); process in 2007 and coordination with the Architecture Consultant for appropriate course of action

• Exhibit 28 (p.53) Advanced Acquisition Plan in place of Procurement Plan

• ConOps references rechecked and adapted

• A-3 ConOps under SRD

• Inserted 1.6 Contract Tracking and Oversight (p.11)

• Inserted Section 508 Compliance language under SAT (p.70)

ICE OCIO

management review

June 2007 • Page 2 (Exhibit 1) Definition for the Program Control Office (PCO) updated per client input

• Page 2 (Exhibit 1) Change Resource Management Office to Resource Management Division, updated description, added subgroups for AMB and

OAQ

• Page 2 (Exhibit 1) Key Stakeholder Roles, added Resource Management Division, Acquisition Management Branch (AMB) and Office of Acquisitions (OAQ) with descriptions

• Page 7 Deleted “P” under the Program Control Office for the Requirements Definition and the Test & Deployment rows, per client

• Section 1.6 Contact Tracking and Oversight

• Page 12, Updated Contract Tracking and Oversight paragraph and added Exhibit 10 – ICE Contract Acquisition Process

• Page 12 (Exhibit 10) ICE OCIO Contract Acquisition Process, added new table

January 2008 ICE System Lifecycle Management Handbook

1.2

January 2008

GLOBAL:

• Integrated Performance Testing to Performance Testing in Exhibits: 3(p.5), 6 (p.8), Sections: 8.1 (p.72), C-7 (Glossary), In-2 (Index)

• Procurement Plan for COTS/GOTS changed to Acquisition Plan (no COTS/GOTS reference) 6.1.1, 7.1.1, Appendix A, Advanced Acquisition Plan changed to Acquisition Plan

• Technical Reviews changed to Gate Reviews: Pages: 1, 3, 4, 6, 7, 8, 23, 28, 31, 37, 83

• Deleted “Milestone Review”

• ICE Program Control Office (PCO) deleted and replaced with ICE Planning and Financial Management Division (PFM)

• Clarified role of Operations Division in Exhibits 21, 26, 32, 37, 42, 46, and 50

ADDITIONAL:

• Exhibit 17: Added Desktop Service. Mainframe, and SharePoint to Pre-defined Work Patterns

• Exhibit 17: Deleted External Services work pattern

• New Acquisition Plan moved from Requirements Definition to Planning, Updated Acquisition Plan added to Requirements Definition

SECURITY:

• Office of Information Systems Security (OISS) changed to Information Assurance Division (IAD)

• OISS Engineer changed to IAD Security Risk Analyst

• OISS Representative changed to IAD Representative

• OISS artifacts changed to IAD artifacts

• OISS officials changed to IAD officials

• (OISSO – no change)

• 1.4 SLM, IAD and Required IT Security Activities: added description

• Exhibit 7, p. 10 updated

• Certification and Accreditation (C&A) artifacts reviewed and updated per

IAD:

Exhibit 24: Requirements, Exhibit 29: FADR, Exhibit 35: TRR, Exhibit 40: RRR

• Security Requirements Traceability matrix (RTM) document description added

SECTION 508 COMPLIANCE:

Section 508: language added for background, compliance, testing, reporting, and gate review documentation (aligns with DHS SDLC v 0.751):

• Preface (P-3) Parallel Processes

• 1.8 SLM and Section 508 Compliance, new section

• Exhibit 3:High-Level Lifecycle Activities

• Exhibit 5: SLM and Operations and Maintenance

• Exhibit 16: Planning exit criteria

• Table 4.3.6: Conduct initial project planning

• Exhibit 18: Planning documents

• 5.1.1: Contact the ICE Section 508 Coordinator to identify compliance requirements

• 6.1.1: Validate that Section 508 requirements are fully accounted for in the system design

• Exhibit 31: FADR Review Guide, Pre-Review Activities

• Exhibit 36: TRR Guide: Review Activities

• 8.1 Independent Testing Process and Capabilities: Assistive Technology Interoperability Test

• 8.2 Support Independent Testing Effort, Review Section 508 Assistive Technology Interoperability Test Report

• Exhibit 40: Test and Deployment Artifacts produced by Independent Testing, Section 508 Assistive Technology Interoperability Test Report

• Exhibit 41: RRR Guide, Re-Review Activities

• Exhibit 43: Operations & Maintenance Process, Key Activities

• Exhibit 45: Operations & Maintenance Documents

• 9.2.2 Perform System Maintenance, Section 508 Accessibility Incident Remediation Report

Appendix A: SLM Documents (A – 5):

• Office of Accessible Systems and Technologies (OAST) Documents: Section 508 Compliance

• IAD Artifacts: Security RTM description

PRIVACY:

Privacy: overview and compliance, activities, gate review documentation added to align with DHS SDLC v 0.751

• Exhibit 3: SLM High Level Lifecycle Activities

• 1.7 SLM and Privacy Analysis Activities

• Exhibit 16: Planning Overview, Exit Criteria

• 5.1.6: Ensure that the use of personally identifiable information does not include Social Security Numbers (SSN)

• Exhibit 27: Design Overview, Exit Criteria

• 6.1.8: Explain how SSN data will be removed or reduced

• Exhibit 33: Development overview, Exit Criteria

• Exhibit 38: Test and Deployment Overview, Exit Criteria

• 8.2.1 Certify Independent Test Lab (re: data privacy)

ACRONYMS (added):

• System of Record Notice (SORN)

• Privacy Threshold Analysis (PTA)

• Privacy Impact Assessment (PIA)

• Office of Accessible Systems and Technologies (OAST)

• Electronic Information Technology (EIT)

• Planning and Financial Management Division (PFM) [replaced Program Control Office (PCO)]

Appendix D (added):

• Moved Glossary information in Appendix C to new Appendix D

CONTENTS i

CONTENTS

PREFACE

1.0 SYSTEM LIFECYCLE MANAGEMENT OVERVIEW

1.1 Key SLM Stakeholders

1.2 SLM Process

1.2.1 SLM Activities

1.2.2 SLM Documents

1.2.3 Gate Reviews

1.3 SLM and Architecture Services

1.4 SLM, IAD and Required IT Security Activities

1.5 SLM and ICE Enterprise Architecture Activities

1.6 Contract Tracking and Oversight

1.7 SLM and Privacy Analysis Activities

1.8 SLM and Section 508 Compliance

2.0 SLM METHODOLOGIES

2.1 Waterfall

2.2 Incremental

2.3 Iterative

2.4 Rapid Prototyping

3.0 SLM COMMON ACTIVITIES

3.1 ICE Electronic Library Document Submittal

3.1.1 Obtain ICE Electronic Library account and log

in to ICE Electronic Library

3.1.2 Submit documents to ICE Electronic Library

3.2 Document Assessments

3.2.1 Deliver documents to ICE Electronic Library

3.2.2 Architecture Services SLM Project Management

coordinates and consolidates assessments

3.2.3 Architecture Services PM Analyst delivers

consolidated document assessment

3.3 Gate Review Scheduling and Coordination

3.3.1 IT Project Manager requests gate review

3.3.2 Architecture Services SLM Project Management

prepares for and schedules gate review

3.3.3 Gate review meeting occurs

3.4 Request for Deviation

3.4.1 IT Project Manager submits RFD

3.4.2 Adjudicator processes RFD

3.4.3 Adjudicator provides notification of RFD

disposition

3.5 Information Technology Change Request

3.5.1 ICE employee submits ITCR

i i CONTENTS

3.5.2 ICE IT Standards Support Team processes ITCR

3.5.3 ICE IT Standards Support Team provides

notification of ITCR disposition

4.0 PLANNING

4.1 Tailoring

4.2 Pre-defined Work Patterns

4.3 Planning Activities

4.3.1 Perform preliminary security analysis

4.3.2 Complete Privacy Threshold Analysis

4.3.3 Align business concept with target ICE

Enterprise Architecture

4.3.4 Select SLM methodology

4.3.5 Tailor SLM process to achieve project work

pattern

4.3.6 Conduct initial project planning

4.3.7 Define high-level system concept

4.3.8 Define initial technical architectural vision

4.3.9 Plan project

4.3.10 Identify training strategies

4.3.11 Charter user group and project change control

board

4.3.12 Perform initial security risk assessment

4.4 Planning Documents

4.5 Planning Review

4.6 Planning Stakeholder Roles

4.7 Planning: Methodology Considerations

4.7.1 Incremental: Planning Considerations

4.7.2 Iterative: Planning Considerations

4.7.3 Rapid Prototyping: Planning Considerations

5.0 REQUIREMENTS DEFINITION

5.1 Requirements Definition Activities

5.1.1 Define system requirements

5.1.2 Develop system process model

5.1.3 Develop application logical data model

5.1.4 Estimate system workload

5.1.5 Complete Standard Form 115 (Request for

Disposition Authority)

5.1.6 Analyze system usage of personally identifiable

information

5.1.7 Identify preliminary project architecture and

runtime patterns

5.1.8 Identify training requirements

5.1.9 Plan for contingency operations during system

disruptions

5.2 Requirements Definition Documents

5.3 Requirements Review

CONTENTS i i i

5.4 Requirements Definition Stakeholder Roles

5.5 Requirements Definition: Methodology Considerations

5.5.1 Incremental: Requirements Definition

Considerations

5.5.2 Iterative: Requirements Definition

Considerations

5.5.3 Rapid Prototyping: Requirements Definition

Considerations

6.0 DESIGN

6.1 Design Activities

6.1.1 Design system

6.1.2 Establish service level agreements with

production support teams

6.1.3 Establish interface control agreements

6.1.4 Initiate Interconnection Security Agreement with

external organizations

6.1.5 Develop physical data model

6.1.6 Refine system workload estimates

6.1.7 Plan training

6.1.8 Complete Privacy Impact Assessment and

System of Records Notice

6.1.9 Plan development testing

6.1.10 Initiate procurement of development, test, and

production environments

6.2 Design Documents

6.3 Preliminary Architecture and Design Review

6.4 Final Architecture and Design Review

6.5 Design Stakeholder Roles

6.6 Design: Methodology Considerations

6.6.1 Incremental: Design Considerations

6.6.2 Iterative: Design Considerations

6.6.3 Rapid Prototyping: Design Considerations

7.0 DEVELOPMENT

7.1 Development Activities

7.1.1 Build system

7.1.2 Plan system deployment

7.1.3 Design and develop training solution

7.1.4 Perform functional qualification testing

7.1.5 Perform development security test and

evaluation

7.1.6 Prepare for independent testing

7.2 Development Documents

7.3 Test Readiness Review

7.4 Development Stakeholder Roles

7.5 Development: Methodology Considerations

7.5.1 Incremental: Development Considerations

i v CONTENTS

7.5.2 Iterative: Development Considerations

7.5.3 Rapid Prototyping: Development

Considerations

8.0 TEST AND DEPLOYMENT

8.1 Independent Testing Process and Capabilities

8.2 Test and Deployment Activities

8.2.1 Certify privacy compliance requirements

8.2.2 Certify independent test lab

8.2.3 Support independent testing effort

8.2.4 Prepare Certification and Accreditation artifacts

8.2.5 Prepare for production deployment

8.2.6 Deploy system to production environment

8.3 Test and Deployment Documents

8.4 Release Readiness Review

8.5 Test and Deployment Stakeholder Roles

8.6 Test and Deployment: Methodology Considerations

8.6.1 Incremental: Test and Deployment

Considerations

8.6.2 Iterative: Test and Deployment Considerations

8.6.3 Rapid Prototyping: Test and Deployment

Considerations

9.0 OPERATIONS AND MAINTENANCE

9.1 Notice of Intent to Release

9.2 Operations and Maintenance Activities

9.2.1 Establish a strategy for managing O&M releases

9.2.2 Perform system maintenance

9.2.3 Conduct ongoing user training

9.2.4 Conduct annual security training

9.2.5 Conduct performance and security reviews

9.2.6 Re-certify and re-accredit system

9.3 Types of Maintenance Releases

9.4 Operations and Maintenance Documents

9.5 Operations and Maintenance Stakeholder Roles

10.0 DISPOSITION

10.1 Disposition Activities

10.1.1 Plan system disposition

10.1.2 Publish Notice of Deletion in Federal Register

10.1.3 Retire system & archive system components, data, & documentation

10.1.4 Close out project

10.2 Disposition Documents

10.3 Disposition Review

10.4 Disposition Stakeholder Roles

CONTENTS v

APPENDIX A—SLM DOCUMENTS

APPENDIX B—REFERENCES

APPENDIX C—ACRONYMS

APPENDIX D—GLOSSARY

INDEX

EXHIBITS

Exhibit 1: Key SLM Stakeholder Roles Exhibit 2: Key SLM Initiation Activities Exhibit 3: SLM High-Level Lifecycle Activities Exhibit 4: SLM Operations and Maintenance Exhibit 5: Gate Reviews Exhibit 6: ICE SLM and Architecture Services Exhibit 7: ICE SLM and Required IT Security Activities Exhibit 8: ICE Enterprise Architecture Artifacts Exhibit 9: ICE SLM and Enterprise Architecture Reviews Exhibit 10: ICE OCIO Contract Acquisition Process Exhibit 11: SLM Methodologies Applicability Exhibit 12: Waterfall Development Exhibit 13: Incremental Development Exhibit 14: Iterative Development Exhibit 15: Rapid Prototyping Development Exhibit 16: Planning Overview Exhibit 17: Pre-defined Work Patterns and Project Profiles Exhibit 18: System Planning Process Exhibit 19: Planning Documents Exhibit 20: Planning Review Guide Exhibit 21: Planning Stakeholder Roles Matrix Exhibit 22: Requirements Definition Overview Exhibit 23: System Requirements Definition Process Exhibit 24: Requirements Definition Documents Exhibit 25: Requirements Review Guide Exhibit 26: Requirements Definition Stakeholder Roles Matrix Exhibit 27: Design Overview Exhibit 28: System Design Process Exhibit 29: Design Documents v i CONTENTS

Exhibit 30: Preliminary Architecture and Design Review Guide Exhibit 31: Final Architecture and Design Review Guide Exhibit 32: Design Stakeholder Roles Matrix Exhibit 33: Development Overview Exhibit 34: System Development Process Exhibit 35: Development Documents Exhibit 36: Test Readiness Review Guide Exhibit 37: Development Stakeholder Roles Matrix Exhibit 38: Test and Deployment Overview Exhibit 39: System Test and Deployment Process Exhibit 40: Test and Deployment Documents Exhibit 41: Release Readiness Review Guide Exhibit 42: Test and Deployment Stakeholder Roles Matrix Exhibit 43: Operations and Maintenance Process Exhibit 44: Maintenance Release Types Exhibit 45: Operations and Maintenance Documents Exhibit 46: Operations and Maintenance Stakeholder Roles Matrix Exhibit 47: Disposition Process Exhibit 48: Disposition Documents Exhibit 49: Disposition Review Guide Exhibit 50: Disposition Stakeholder Roles Matrix

PREFACE P-1

PREFACE

The Immigration and Customs Enforcement (ICE) System Lifecycle Management (SLM) Handbook, Version 1.2, details the systems development lifecycle process for ICE. It also provides insight into processes parallel to the SLM process to assist IT project teams in coordinating and collaborating with the various organizations necessary for project success.

Authority The authority of the ICE SLM process and the ICE SLM Handbook that documents the SLM process is established by the Office of Management and Budget (OMB) Circular No. A-130, Management of Federal Information Resources. The ICE SLM process and the ICE SLM Handbook are managed by the ICE Office of the Chief Information Officer

(OCIO).

All ICE personnel and technology project teams must adhere to the ICE SLM process when developing or modifying ICE technology. Any departure from these process requirements and guidelines requires the IT Project Manager to obtain an approval for deviation from the ICE OCIO Architecture Assurance Branch Director.

A total departure from the SLM process requires the IT Project Manager to obtain approval from the ICE Chief Information Officer (CIO).

Applicability The SLM process applies to all ICE technology projects (including operational systems, infrastructure, and field technology initiatives), regardless of sponsor, developer, project size, methodology, or technology used.

Most ICE technology projects following the SLM process are systems. In the SLM process, a system is defined as software written and targeted to serve a specific organizational function or set of related functions. The software may be organized into numerous files, but the set of all such files is collectively referred to as “the system.” A system may contain a database, unique hardware, or interfaces to other systems.

System characteristics include the following:

A system contains a number of source code files that may compile to a single primary executable module that may invoke other non-primary executable modules as needed

A system processes data and may also store data; it also may pass data to another system or systems

P-2 PREFACE

The software is written by developers working as a single team under common management or direction

A system may contain subsystems that implement one or more specific functions related to the overall business function

With few exceptions, a system operates according to a regular operations schedule (i.e., nightly, always, second Tuesday of the month)

In the SLM process, these characteristics denote the following:

A system requires the SLM documentation and activities specified in the tailoring plan of the project

A system is the entity that receives the Authority to Operate (ATO) designation

A system is the entity whose iterations over time must be numbered according to Enterprise Systems Assurance Plan (ESAP) guidelines

SLM documents and reviews do not apply to subsystems, nor would subsystems be designated with separate release numbers; however, revision to a subsystem constitutes a release of the “parent” system and thereby remains part of the SLM process

Objectives The objectives of the SLM process are to provide the right amount of assurance for ICE technology projects based on scope, risk, and context and to support the production and integration of quality technology products.

These objectives are achieved by basing the SLM process on the philosophy that process activities and their necessary artifacts must derive from a valid business reason. With this philosophy as its foundation, the SLM process introduces a significant degree of flexibility for the project within a structured framework.

Document Organization The ICE SLM Handbook contains ten main sections. Sections 1-3 present an overview of the SLM process, describe the available methodologies, and identify SLM common activities. Sections 4-8 present the activities, stakeholders, gate reviews, and documents, which are organized by the traditional path from planning to deployment in an SLM process:

Planning

Requirements Definition

Design

PREFACE P-3

Development

Test and Deployment

The final two sections, Sections 9 and 10, identify the operations and maintenance activities that follow system deployment to the production environment and the disposition activities that take place when the system is retired.

Online Resources To assist project teams and other stakeholders in following the SLM process and obtaining the necessary standards and guidelines, two online resources are available:

ICE Architecture Division Program Web Site – (POWERPORT.ICE.DHS.GOV/TAPWEB) serves as a user-friendly online resource for accessing information on the SLM process and related technical architecture processes, technology standards and guidance, and technical architecture services and resources

ICE Electronic Library – (DOCUMENTS.ICE.DHS.GOV) functions as a repository for all documents (including all editions of the documents) throughout the life of a project

Parallel Processes and Governance This handbook includes a high-level view into the following processes, activities, and additional governance parallel to and interconnected with the SLM process:

Certification and Accreditation (C&A) Process – ICE Information Assurance Division (IAD)

ICE Enterprise Architecture Alignment – DHS Enterprise Architecture Board (EAB)

Training – ICE Office of Training and Development (OTD)

Freedom of Information Act/Privacy Act – DHS Privacy Office

Section 508 of the Rehabilitation Act of 1973 (as amended) – ICE Section 508 Office

Records Retention and Management – DHS Records Management

For more information, contact the organization listed with the process or activity.

P-4 PREFACE

Comments and Questions ICE follows a continuous improvement approach to the SLM process.

E-mail your comments, questions, or suggestions to

ICE-SLMREVIEW@DHS.GOV.

SYST EM LIFECYCLE MANAG EMENT OVER VIEW 1

1.0 SYSTEM LIFECYCLE MANAGEMENT OVERVIEW

ICE has established the System Lifecycle Management (SLM) process to oversee the various technical, security, and quality aspects of its technology projects and to manage the integration of technology into the ICE organization.

Because cost and schedule constraints prevent planning for every possible contingency associated with a technology project during its lifecycle, ICE developed the SLM process to be sufficiently adaptive to respond quickly and effectively to unique mission needs as they arise, yet provide a consistent and stable framework for managing ICE technology projects.

This process supports the following:

Multiple lifecycle methodologies (approaches for managing a project from planning to deployment) to enable project teams to select and apply a methodology that fits the unique needs of a project

Tailoring (review and selection of the necessary activities, artifacts, and gate reviews), which produces a customized work pattern for a project team, giving the team the flexibility and agility to meet immediate business needs

Deploying technology solutions to meet immediate and critical business requirements without circumventing the process

Practicing disciplined project management to ensure that the system is developed on schedule and within budget and that it produces the expected results

Establishing a comprehensive project management plan to track, measure, and control the progress of each project

Aligning each project with the target ICE Enterprise Architecture (the future or “to-be” business, data, and IT environment)

Maintaining project information integrity, availability, and confidentiality

Conforming to ICE architecture standards

Verifying and certifying project activities through formal reviews, approval, and acceptance

Incorporating maintainability to enable adjustment to evolving business needs

1.1 Key SLM Stakeholders

The ICE SLM process requires the teamwork of many IT professionals, each performing a specific function. Exhibit 1 summarizes each role and its purpose in support of a project.

2 SYST EM LIFECYCLE MANAG EMENT OVER VIEW

Exhibit 1: Key SLM Stakeholder Roles

Stakeholders Roles ICE Office of the Chief Information Officer (OCIO)

Provides high-level project management coordination and reporting, strategic planning, capital planning investment and control, and oversight for information security activities

OCIO Architecture Division

Manages the development of information systems through the SLM process and advises the ICE CIO on technical recommendations and their associated impacts on the DHS enterprise architecture. (Architecture is a division within the OCIO)

Oversees the implementation of and adherence to the ICE SLM process; manages the adoption, development, and specification of standards supporting the ICE enterprise architecture; and monitors project adherence to ICE technical architecture standards

Reviews the application of technologies to meet ICE business requirements and performance goals and presents guidance on the appropriate application of technologies to meet ICE strategic goals and objectives Develops and maintains the ICE Enterprise Architecture

OCIO Systems Development Division

Ensures IT software solutions are delivered effectively to meet ICE customer needs by providing IT support to business areas, interacting with contractor management, and executing the budget.

(Systems Development is a division within the OCIO)

OCIO Operations Division

Directs the operation of the enterprise IT infrastructure and provides IT support for ICE. (Operations is a division within the OCIO)

Provides on-site technical administration and support to all ICE components worldwide

Provides troubleshooting support for resolving end-user IT problems

OCIO Network Engineering Branch

Manages the ICE local and wide area networks, and provides a secure, reliable, scalable, and highly available Web environment for the deployment of ICE mission-critical systems. (Network Engineering is a branch within the OCIO Engineering Division)

OCIO Systems Engineering Branch

Provides stewardship of ICE data resources; implements their integration by providing the services necessary to provide smooth daily operations; ensures that resources are optimized; manages growth; and enforces data extraction, transformation, load, and delivery standards and functions.

(Systems Engineering is a branch within the OCIO Engineering Division) Provides a secure, reliable, scalable, and highly available Web environment for the deployment and operation of mission-critical systems

OCIO Program Executive Office

Provides support for ICE IT investment review process, including day to day support for the ICE IT Portfolio Working Group. The Program Executive Office provides oversight and direction for ICE’s IT Portfolio, manages the IT Capital Planning and Investment Control process, develops and maintains IT policy and planning documents, and leads a variety of OCIO program and performance management initiatives.

OCIO Planning and Financial Management Division

Provides ICE with the management and administration of IT human and capital resources, including Budget and Finance, Acquisition and Contract Management, Facilities and Space Management, Human Resources and Professional Development, and Training Services.

Establishes acquisition processes and procedures that facilitate efficient and effective means for obtaining and managing IT contracts for products, systems and services; establishes best practices that serve as the foundation for the acquisition planning, execution and administration of ICE IT contracts for products, systems and services; provides support in the identification, tracking and completion of procurement packages to be delivered to Office of Acquisitions (OAQ); supports the source selection process by providing both technical and administrative support necessary to properly evaluate and document award decisions to be presented to the Source Selection Official;

creates and administers Contract Administration Plans specific to large, complex procurements as well as oversees and administers the COTR and PM certification process.

ICE Office of Acquisition Management (OAQ)

Enhances coordination with ICE mission and operational components, both at headquarters and field offices, by providing proactive, customer-service oriented Integrated Contracting Solutions;

tracks the investment review process; integrates activities among mission support components to improve efficiencies; and coordinates with operational and mission support programs to establish acquisition strategies and management of contracts.

ICE Office of Training and Development (OTD)

Provides strategic planning and oversight for training design, development, deployment, and evaluation and also provides training project management services

Help Desk Section

Field Ops Branch

Application Hosting Services Section

Acquisition Management Branch (AMB)

SYST EM LIFECYCLE MANAG EMENT OVER VIEW 3

OCIO Information Assurance Division

(IAD)

Serves as the principal advisor to the ICE CIO for computer security matters and develops and oversees the ICE IT security program Validates how well an information system meets pre-defined technical control security requirements concerning unauthorized internal or external access or willful damage, establishes an application security baseline, and identifies a level of risk before deployment in the production environment

IT Project Manager Serves as the central point of responsibility for project decisions and activities, coordinates the technical aspects of the project, and manages the project to achieve cost, schedule, and performance goals

Designated Accrediting Authority (DAA)

Assumes responsibility for operating a system at an acceptable level of risk and is accountable for the risk he or she accepts

Business Owner

Serves as the project sponsor, representing the operational needs of the business unit and the system users, and participates throughout the SLM process to ensure that the system meets operational and user requirements

Collaborates with the Business Owner and IT Project Manager in defining the proposed system to establish and prioritize requirements that reflect the operational needs of the user

Information Systems Security Officer (ISSO)

Ensures that appropriate steps are taken to implement information security requirements for information systems throughout the SLM process

Users Group

1.2 SLM Process

The SLM process consists mainly of a set of activities, document and technology artifacts, and gate reviews that are customized to fit to the unique needs of a project. During the SLM process, the project team will complete required SLM activities. The results of the activities are recorded in SLM documents; technology artifacts (such as code) are placed under configuration management (CM) control. The document and technology artifacts are then assessed for adherence to ICE standards and guidelines and evaluated in gate reviews to determine how the project should proceed.

1.2.1 SLM Activities

To promote flexibility, the SLM process possesses two key project initiation activities, which are identified in Exhibit 2. These activities occur at the beginning of Planning and determine the methodology and customized work pattern for a project.

4 SYST EM LIFECYCLE MANAG EMENT OVER VIEW

Exhibit 2: Key SLM Initiation Activities

Activity Description

1. SLM

Methodology Selection (2.0, 4.3.4)

A methodology is a lifecycle approach for managing the planning, requirements definition, design, development, testing, and deployment of a project

The SLM process includes multiple methodologies (waterfall, iterative, incremental, and rapid prototyping) to provide options for project teams in how and when project activities are completed. These options mean that project teams are able to adapt to the management needs of a project while maintaining alignment with the SLM process

2. Tailoring SLM Process to Achieve Project Work Pattern (4.1, 4.3.5)

Tailoring is the review of the scope, risk, and context of a project to select the appropriate activities, documents, and gate reviews to be completed by the project team during the SLM process. This approach enables small projects with limited scope and risk to achieve alignment with the SLM process without having to complete a full range of lifecycle activities and documentation typically required for large-scale, complex information system projects

The product of tailoring is a customized work pattern that identifies the activities, documents, and gate reviews necessary for a project to successfully complete the SLM process

For projects that fit a certain profile, pre-defined work patterns are available for use as a starting point in determining the necessary activities, documents, and gate reviews

IT project managers may use these pre-defined work patterns to assemble a project work pattern in preparation for the tailoring review

Pre-defined Work Pattern

Selection (4.2, 4.3.5)

Through these two key activities, the SLM process is able to adapt to the specific needs of a project; provide the appropriate level of systems assurance necessary; and produce a clear plan of the activities, documents, and gate reviews of a project.

With this plan, the project then proceeds through planning to deployment in alignment with the selected methodology and customized work pattern.

These high-level lifecycle activities, historically referred to as phases, are described in Exhibit 3.

SYST EM LIFECYCLE MANAG EMENT OVER VIEW 5

Exhibit 3: SLM High-Level Lifecycle Activities

Activity Key Objectives

Planning (Section 4.0)

Define the system concept from a user’s perspective Establish a comprehensive plan for developing the system Determine security categorization by following Federal Information Processing

Standards (FIPS) Publication 199 Identify the users, locations, and issues that should be considered for developing training strategies

Determine Section 508 National Security Exception applicability

Requirements Definition

(Section 5.0)

Define and codify formal and detailed requirements to ensure that the developed system will meet user requirements

Establish the functional baseline, which comprises the approved System Requirements Document (SRD) and the Requirements Traceability Matrix (RTM)

Assess the security risks associated with the system and its operating environment Identify security controls and countermeasures for safeguarding the system and information processed by or stored in the system Identify training requirements

Document Section 508 accessibility requirements

Design (Section 6.0)

Transform the requirements defined in the SRD into detailed design specifications Establish the design baseline, which comprises the approved Design Document Stipulate procedures for handling system disruptions, including backup, recovery, and post-recovery procedures Specify how personally identifiable information will be used by the system Establish procedures for operating and maintaining the system securely Plan the strategy for training

Document Section 508 exceptions, and/or how Section 508 requirements are captured in the system design

Development (Section 7.0)

Build the system according to the design specified in the approved Design Document Conduct unit and module integration testing Conduct application tuning on the application components Conduct Functional Qualification Testing (FQT) to ensure that the system processes satisfy the requirements stipulated in the SRD Develop training materials and schedule

6 SYST EM LIFECYCLE MANAG EMENT OVER VIEW

Test and Deployment (Section 8.0)

Conduct Independent Functional Test and Evaluation to verify that the developed system functions properly and satisfies the requirements defined in the SRD

Conduct Independent Performance Testing to verify that the system performs the required functions within established performance parameters in a secure manner using the existing infrastructure

Conduct Independent Interoperability Testing on co-located applications in an integrated environment to ensure that no conflicts or compatibility issues exist between ICE-approved applications

Conduct Security Test and Evaluation (ST&E) to ensure that the system security controls are in place and operating as designed and that the system meets all applicable security standards and poses no undocumented security risks

Establish the production baseline, which consists of the production system, databases, an updated data dictionary, associated infrastructure, and supporting documentation

Ensure that the system is deployed to the designated production sites, including configuration of supporting infrastructure, data conversion, and end-user training

Ensure that the system meets all privacy compliance requirements Ensure that the system meets all Section 508 compliance requirements

When the system is placed into the production environment, the project begins operations and maintenance activities, which make up the majority of the life of a system. If the system needs to be fixed, enhanced, or adapted to a new business situation, the project will re-engage one of the SLM high-level lifecycle activities. Exhibit 4 identifies the key objectives of operations and maintenance.

Exhibit 4: SLM Operations and Maintenance

Activity Key Objectives

Operations and Maintenance (Section 9.0)

Maintain the system by recording problems, enhancements, and adaptive changes to prepare for future releases of the system

Provide training to instruct users on how to achieve business tasks and maintain proper security awareness

Conduct periodic system reviews to evaluate system performance Re-certify and re-accredit system Re-engage the SLM process (Planning, Requirements Definition, Design, or

Development) to implement new releases

In the event that a system is retired, the system will begin disposition activities, which are identified and described in Section 10.0. The project team will remove the system from the production environment; archive the software, data, and documentation of the system; and transfer any software or data for use by other systems.

1.2.2 SLM Documents

SLM documents are completed templates that contain detailed information regarding project team activities. The documents enable Government personnel and associated project teams to understand project accomplishments, mitigate risks, make decisions effectively, and coordinate projects efficiently throughout the SLM process. The

SYST EM LIFECYCLE MANAG EMENT OVER VIEW 7

Architecture Division evaluates these documents for adherence to technology standards, accuracy and completeness of information, and consistency of information between artifacts.

The objectives for each SLM document are described in detail in Appendix A.

Templates for SLM documents are available in the ICE Electronic Library under Governance Documents at DOCUMENTS.ICE.DHS.GOV.

1.2.3 Gate Reviews

For the SLM high-level lifecycle activities and disposition activities, gate reviews (previously known as technical reviews) are conducted to certify that the appropriate project activities have occurred and were adequately documented. Exhibit 5 identifies the gate reviews, their objectives, and the review attendees and their roles.

8 SYST EM LIFECYCLE MANAG EMENT OVER VIEW

Exhibit 5: Gate Reviews

Attendees A = P = S =

Approval Authority Participant Signatory

B us in es s O w ne r

IT

P ro je ct M an ag er

C on tra ct or P ro je ct

Te am

A rc hi te ct ur e D iv is io n

In fo rm at io n

A ss ur an ce

D iv is io n

In fo rm at io n

S ys te m s S ec ur ity O ffi ce r

E ng in ee rin g

D iv is io n

O pe ra tio ns D iv is io n

P la nn in g an d Fi na nc ia l

M an ag em en t D iv is io n

O ffi ce o f T ra in in g an d D ev el op m en t

Planning Review

Pl an ni ng

Verify that the documented approach for developing the P S P A P P P P P system is feasible, comprehensive, and consistent with the architectural vision Obtain stakeholder agreement of the project schedule

R eq ui re m en ts D ef in iti on

Requirements Review

Verify that requirements (a) align with business objectives;

(b) support project scope and attributes;

(c) are sufficiently clear, complete, and consistent; and (d) are traceable to their sources S S P A S P P P P

Verify that data specifications follow prescribed standards Verify that requirements are testable Obtain stakeholder agreement that documented requirements are adequate Preliminary Architecture and Design Review

Verify that preliminary architecture and design is consistent with technical architecture and satisfies the requirements baseline

Obtain stakeholder agreement that preliminary architecture and design is consistent with architectural boundaries established for the technology project and conforms to ICE technical architecture standards

P S P A P P S P P

D es ig n

Final Architecture and Design Review

Verify that final architecture and design adequately address system functional, security, and technical requirements

Verify that final architecture and design is consistent with ICE technical architecture standards

P S P A S P S P P

D ev el op m en t Test Readiness Review

Determine whether the system is sufficiently developed and tested before conducting independent testing

Ensure that preparations are underway for deployment Deliver code for independent testing

S S P A S P P P P

Te st a nd ep lo ym en t Release Readiness Review

Determine readiness of the system for deployment Review open test problem reports for criticality and disposition Present identified risks

A S P S S P S P P

G at e R ev ie w s an d

O bj ec tiv es

Disposition Review is po si tio n

Verify that the documented disposition approach is feasible, comprehensive, and consistent with ICE technical A S P S S P S P S architecture standards

Obtain stakeholder agreement that the system is ready for disposition

SYST EM LIFECYCLE MANAG EMENT OVER VIEW 9

1.3 SLM and Architecture Services

To support and guide projects in the completion of SLM activities, documents, and gate reviews, Architecture Services provides project teams with a consistent set of procedures and activities and ensures efficient use of project and support resources. Exhibit 6 identifies the Architecture Services functional support activities that take place throughout the SLM process.

Exhibit 6: ICE SLM and Architecture Services

Coordinates with project teams to establish the architectural foundation

Directs project design activities to align with the ICE Technical Reference Model (TRM) and industry best practices

Assesses development artifacts for adherence to baselined requirements and design Facilitates collaboration among Architecture Division activities and project teams Assesses compliance with architecture standards and sound IT practices Provides IT consultancy services to business owners, IT project managers, and project teams Provides technical consultation and performs extensive design reviews on Web applications

Develops work patterns; assesses tailoring proposals Provides IT project managers with process assistance Performs System Lifecycle Management (SLM) document assessments and brokers subject matter expert (SME) assessments Plans, coordinates, and conducts gate reviews

Coordinates setup and management of document, code, change request, and test problem report (TPR) configuration management (CM) repositories

Provides CM guidance and assistance Verifies Version Description Document (VDD) against supplied code

Assesses defined requirements Verifies traceability of requirements Assists with SLM document assessments

Develops and maintains enterprise data modeling and data interoperability standards

Assesses completed project teams’ data models against established data modeling standards

Supports enterprise data governance Provides guidance to project teams in designing data interoperability solutions Assesses project teams’ data interoperability artifacts against established data interoperability standards

Develops System Acceptance Test strategy Obtains and sets up testing environment Develops a test plan and conducts System Acceptance Testing (SAT) Documents test results Prepares and conducts System Security Testing Develops scripts to support automated regression testing

Develops Performance Test strategy Obtains and sets up testing environment Develops a test plan and conducts Performance Testing Documents test results Prepares and conducts Interoperability Testing

Architecture Consulting

Test and Deployment

Development

Design

Requirements Definition

Planning

SLM Quality Assurance

(QA) / Project Management

Configuration Management

Requirements Management

Design

Requirements Definition

Data

Architecture

Development

Design

Requirements Definition

Planning

Functional Test and

Evaluation Test and Deployment

Development

Design

Requirements Definition

Performance/ Interoperability

Test and Evaluation

Test and Deployment

Development

Design

Requirements Definition

Test and Deployment

Development

Design

Requirements Definition

Planning

Requirements Definition

Design

Development

Test and Deployment

1 0 SYST EM LIFECYCLE MANAG EMENT OVER VIEW

SLM Project Management, Configuration Management, and the SLM process are tightly integrated to form ICE OCIO Architecture Assurance Branch (hereafter referred to as ICE Architecture Assurance). ICE Architecture Assurance assists and monitors project teams in completing SLM activities and in adhering to SLM process requirements. Functional test and evaluation (T&E) and performance/interoperability T&E are also integrated to provide independent T&E, which validates the functionality, security, interoperability, and performance of a system.

Note: In this handbook, the title “Architecture Services” is used before the names of teams (such as Architecture Services SLM Project Management and Architecture Services Configuration Management) to signify that the team is the contractor support team of the Architecture Division. “ICE” is used before the names of Government branches or components (such as ICE OCIO Architecture Assurance).

1.4 SLM, IAD and Required IT Security Activities

The Information Assurance Division (IAD) is fully engaged in the SLM process in defining security requirements to be incorporated in systems…