Documente Academic
Documente Profesional
Documente Cultură
Table of Contents
1. Introduction .............................................................................................................. 1
1.1 Purpose
1.2 Applicability
1.3 DHS SELC Process Overview
1.4 Relationship to the DHS Acquisition Review Process and the Capital Planning and Investment
Control Process
1.4.1 Alignment with the DHS Acquisition Review Process
1.4.2 Alignment with the DHS Capital Planning and Investment Control Process
1.5 Governance, Roles and Responsibilities
1.6 Document Organization
4. Stage 2: Planning................................................................................................... 28
4.1 Planning Entry Criteria
4.2 Planning Activities
4.2.1 Develop SE Risk Management Plan
4.2.2 Develop SE Quality Assurance Plan
4.2.3 Develop Training Plan
4.2.4 Develop Configuration Management Plan
4.2.5 Complete Privacy Threshold Analysis (As Applicable)
ATTACHMENTS
List of Tables
Table 1-1. DHS SELC Approval Authorities
Table 1-2. DHS SELC Stakeholder Roles and Responsibilities
Table 1-3. Document Organization and Descriptions
Table 2-1. Development Methodology Selection Guide
Table 2-2. Summary of Recommended Project Elements
Table 3-1. Solution Engineering Stage Documents
Table 3-2. Participants for Solution Engineering Review
Table 3-3. Solution Engineering Stage Exit Criteria
Table 4-1. DHS IT Project Management Plan Elements
Table 4-2. Planning Stage Entry Criteria
Table 4-3. Planning Stage Documents
Table 4-4. Planning Stage Exit Criteria
Table 5-1. Requirements Definition Documents
Table 5-2. Requirements Definition Stage Exit Criteria
Table 6-1. SRD Elements
Table 6-2. Logical Design Elements
Table 6-3 Detailed Design Elements
Table 6-4. Deployment Plan Elements
Table 6-5. Design Stage Documents
Table 6-6. Participants for Critical Design Review
Table 6-7. Design Stage Exit Criteria
Table 7-1. Development Stage Documents
Table 7-2. Development Stage Exit Criteria
Table 8-1. Integration and Test Documents
Table 8-2. Integration and Test Exit Criteria
List of Figures
Figure 1-1. DHS SELC Process
Figure 1-2. DHS SELC Alignment with ARP and CPIC
Figure 2-1. SELC Summary Snapshot
Figure 5-1 Developmental Testing and Operational Testing and Key Documents
This DHS SELC Guide documents the Systems Engineering (SE) methodology and its
application throughout the DHS enterprise. To support the stated purpose, the SELC
Guide describes the SELC and its relationship to other DHS enterprise-wide processes
and defines the following:
• DHS SELC roles and responsibilities
• DHS SELC elements (stages, including activities and products, entry/exit criteria,
and reviews)
• System development methodologies, guidance on their usage, and methods for
customization
The purpose of this DHS SELC Guide is to standardize the system life cycle process
across DHS Components and to ensure that DHS capabilities are efficiently and
effectively delivered. The DHS SELC Guide is designed to ensure that appropriate
activities are planned and implemented in each stage of the life cycle to increase the
project’s success.
The following key concepts form the basis for the DHS SELC Guide:
• The DHS SELC represents the systems engineering guidance for the acquisition
management process.
• The DHS SELC is the framework used to guide all DHS projects with specific
guidance provided for each type of acquisition mechanism (capital investment IT and
non-IT, enterprise services, etc).
• The SELC provides flexibility by supporting tailoring based on the unique
characteristics of a project (e.g., size, scope, complexity, risk, and security
The DHS SELC Guide discusses nine process stages. The following figure, DHS SELC
Process – Capital Assets, summarizes the SELC process. Each element of the process
is discussed in the following pages.
ADE ADE
ADE
1 2 3
SPR SER PPR SDR PDR CDR TRR PRR ORR PIR
Stage 7:
Stage A: Stage 2: Stage 5:
Stage 1: Stage 3: Stage 4: Stage 6: Operations Stage 8:
Solution Requirements Integration &
Planning Design Development Implementation Disposition
Engineering Definition & Test Maintenance
Engineer the Plan the project and Analyze user needs Transform Convert the Integrate and test System moved to The system is The system is
program solution to acquire and document requirements into system design with other systems; Production operated to carry disposed
ensure all resources needed functional detailed into system conduct UAT; environment; out
alternatives are to achieve solution requirements system design develop C&A Production data has intended function
considered been loaded
SPR: Study Plan Review Key Note: A Project Tailoring Plan must be developed that defines what
SER: Solution Engineering Review TRR: Test Readiness Review stages, activities, and artifacts will be completed for the project. The
PPR: Project Planning Review PRR: Production Readiness Review Project Tailoring Plan should reflect the unique characteristics of the
SDR: System Definition Review ORR: Operational Readiness Review
project and provide the best opportunity to deliver the system effectively.
PDR: Preliminary Design Review PIR: Post Implementation Review
CDR: Critical Design Review
The new Acquisition Management Process applies to Enterprise Services (as well as
Capital Assets). The figure on the next page depicts a modified life cycle tailored for
Enterprise Services.
1.2 Applicability
The DHS SELC Guide is applicable to all DHS projects throughout Components or
other DHS organizations (unless specifically exempted) whose purpose is to deliver a
DHS capability.
IT Specific
The DHS SELC applies to all DHS IT projects. As defined in MD 0007.1, IT is:
“Any equipment or interconnected system or subsystem of
equipment/software, or any national security system, that is used in the
automatic acquisition, storage, manipulation, management, movement,
control, display (including geospatial technologies), switching,
interchange, transmission (wired or wireless telecommunications), or
reception of data, voice, video, or information by an executive
agency…equipment is used by DHS if the equipment is used by DHS
directly or is used by DHS organizational partners (including other
Federal agencies, State and local governments and private
contractors) under a contract with DHS which (a) requires the use of
such equipment, or (b) requires the use, to a significant extent, of such
equipment in the performance of a service or the furnishing of a
product. It includes computers, ancillary equipment (including imaging
peripherals, input, output, and storage devices necessary for security
and surveillance), peripheral equipment designed to be controlled by
the central processing unit of a computer, software, firmware and
similar procedures, services (including support services), and related
resources. It does not include any equipment acquired by a contractor
1
MD 0007.1, section IV.J.
For purposes of illustration, the DHS SELC stages and stage reviews are represented
sequentially in Figure 1-1, which is traditionally how they have been performed.
ADE ADE
ADE
1 2
3
SPR SER PPR SDR PDR CDR TRR PRR ORR PIR
Stage 7:
Stage A: Stage 2: Stage 5:
Stage 1: Stage 3: Stage 4: Stage 6: Operations Stage 8:
Solution Requirements Integration &
Planning Design Development Implementation Disposition
Engineering Definition & Test Maintenance
Engineer the Plan the project and Analyze user needs Transform Convert the Integrate and test System moved to The system is The system is
program solution to acquire and document requirements into system design with other systems; Production operated to carry disposed
ensure all resources needed functional detailed into system conduct UAT; environment; out
alternatives are to achieve solution requirements system design develop C&A Production data has intended function
considered been loaded
SPR: Study Plan Review Key Note: A Project Tailoring Plan must be developed that defines what
SER: Solution Engineering Review TRR: Test Readiness Review stages, activities, and artifacts will be completed for the project. The
PPR: Project Planning Review PRR: Production Readiness Review Project Tailoring Plan should reflect the unique characteristics of the
SDR: System Definition Review ORR: Operational Readiness Review
project and provide the best opportunity to deliver the system effectively.
PDR: Preliminary Design Review PIR: Post Implementation Review
CDR: Critical Design Review
1.4 Relationship to the DHS Acquisition Review Process and the Capital
Planning and Investment Control Process
As one of the foundational elements of the DHS acquisition process, the objective of the
DHS SELC Guide is to provide a framework to guide effective and efficient enterprise-
wide capability delivery. Understanding the relationship of the DHS SELC to other DHS
enterprise governance processes is essential to this objective. The primary applicable
DHS governance processes are the DHS Acquisition Review Process (ARP), as
mandated by Directive 102-01, and the CPIC Process, as mandated by MD 4200. The
CPIC process will use the products and information produced in the ARP to fulfill its’
reporting requirements. These processes are focused on selecting and managing both
IT and non-IT acquisitions (also referred to as programs and projects). Each acquisition
may comprise multiple programs and projects. The SELC applies to the level of activity
at which capabilities are produced and delivered, which may be at a singular acquisition
level or through the related efforts of multiple types of acquisition. The applicability is
determined through the SELC tailoring process based on the individual needs and
conditions of each acquisition.
For purposes of illustration, the alignment of the Systems Engineering processes from a
sequential point of view (see section for other delivery patterns) is depicted in Figure 1-
2. This view provides insight into the alignment of the different phases of each
governance process, as well as the alignment of some of the SELC stage reviews with
those of the ARP. It is important to note that the responsibility for ensuring compliance
with both the ARP and the SELC lies with a single project team, which may be part of a
program team. The SELC is tightly integrated with the ARP. Therefore, there are
dependencies between deliverables in each process (e.g., the Functional Requirements
Document in the SELC is dependent upon the information found in the ARP’s Mission
Needs Statement [MNS], Concept of Operations [CONOPS] and Operational
Requirements Document [ORD]).
CPIC Control
Evaluate
0 1 2A 3
2B
Analyze/
ARP Need Obtain Produce/Deploy/Support
Select
It is the intent of DHS to interlink the key decision support systems. CPIC is a part of
acquisition considered in the broadest sense: that of providing the organization with
the capabilities it needs to accomplish the mission. However, as noted above, there
are some differences between CPIC processes and documentation, and acquisition
processes and documentation. The plan to use acquisition information as the source
information for the CPIC process is the first important step towards interlinking these
DHS decision systems.
The CPIC process includes four phases: Pre-Select, Select, Control and Evaluate.
• Pre-Select Phase. All proposed IT initiatives must go through the Pre-Select
Phase, during which time the sponsor presents the new initiative to review
authorities for consideration. During this phase of the CPIC process, the
Department identifies all new, ongoing, and operational investments for the
Department's IT portfolio. Within this phase, proposed IT initiatives are screened,
scored, and ranked relative to other initiatives. The principal objectives of the
Pre-Select phase are to determine whether the initiative is viable and whether the
appropriate level of analysis and documentation has been completed.
The Pre-Select decision is made at the Component level. Key outcomes resulting
from the assessment process include: (1) defining the level of review required to
approve the initiative for funding, and (2) defining the appropriate set of
analysis/documentation needed to characterize the initiative fully as it moves
forward in the process.
• Select Phase. The Select Phase ensures that Resource Allocation Plan
(RAP)/Capital Investment Plan (CIP) submissions include the resource
requirements for investments. Additionally, it ensures that new and existing
investments are assessed against a uniform set of evaluation criteria and
thresholds. The Exhibit 300 business case is the primary artifact used in the CPIC
Select Phase to support the annual review and (re-)selection of both new and
continuing investments. It is a formal justification for a project or program that
outlines the associated benefits, cost, risks, and alignment with organizational
Project Type
SELC Stage
Review Capital Investment Capital Investment Enterprise Service
IT Non-IT
AoA Study Plan APMD/CIO APMD/CIO APMD/CIO
Review
(SPR)
SER CIO Component SE group1 Component SE group1
PPR Component CIO Component SE group1 Component SE group1
SDR Component CIO Component SE group1 Component SE group1
Role Definition
Program / Project Manager A Program Manager is the responsible person who, with significant discretionary
authority, is uniquely empowered to plan the scope of work, life cycle cost,
schedule, and performance acceptability levels (for an assigned program[s]), and
who is responsible and accountable for accomplishing program objectives or
production requirements through the acquisition of in-house, contract or
reimbursable support resources, as appropriate, and as agreed to in an approved
APB. The Program Manager is responsible for management of the project
manager(s) and ensuring the project within the program is successfully completed.
The Program / Project Manager is responsible for establishing the project team,
completing the documentation set, presenting the business case and status of the
project through all phases of the review and approval process, scheduling and
coordinating the SELC stage reviews, and managing the performance of the project
throughout the life cycle. The Program / Project Manager must be certified at the
appropriate level, per Management Directive 0782.
IT Specific
Component CIO IT Approving Authority: The Component CIO is the most senior Federal executive in
the Component exercising leadership and authority over mission-unique IT policies,
programs, services, solutions, and resources. The Component CIO acts to
implement the policies of the DHS CIO. This includes compliance of IT acquisitions
with the DHS SELC. The Component CIO is responsible for:
1. Ensuring that all SELC entry criteria are satisfied.
2. Conducting SELC stage reviews.
Designated Accrediting The DAA is responsible for operating a system at an acceptable level of risk based
Authority (DAA) on the System Security Plan (SSP)and final risk assessment, and is accountable for
the risk he or she accepts.
Section Description
Section 1: Introduction Describes the purpose of the SELC and provides background regarding its development,
objectives, and benefits. Additionally, this section covers the SELC-related authorities,
provides a high-level overview of the process and its relationship to the DHS investment
review and CPIC processes. It also documents the applicability of the SELC to IT projects
and describes roles and responsibilities.
Section 2: SELC Describes the elements that constitute the SELC, the transition at DHS to a Service
Overview Oriented Architecture (SOA) and how this transition impacts system development. It also
covers development methodologies and how projects are tailored. Finally, it identifies the
required elements that all Project Managers must ensure are incorporated in IT projects.
Section 3: Solution Describes the elements (activities, documents) associated with the solution engineering
Engineering Stage needed to properly define the program capability solution.
Section 4: Planning Describes the entry criteria, activities, documents, stage review, and exit criteria for the
Stage Planning Stage.
Section 5: Describes the activities, documents, stage review, and exit criteria for the Requirements
Requirements Definition Stage.
Definition Stage
Section 6: Design Describes the activities, documents, stage review, and exit criteria for the Design Stage.
Stage
Section 7: Describes the activities, documents, stage review, and exit criteria for the Development
Development Stage Stage.
Section 8: Integration Describes the activities, documents, stage review, and exit criteria for the Integration and
and Test Stage Test Stage.
Section 9: Describes the activities, documents, stage review, and exit criteria for the Implementation
Implementation Stage Stage.
Section 10: Operations Describes the activities, documents, stage review, and exit criteria for the Operations and
and Maintenance Maintenance Stage.
Stage
Section 11: Describes the activities to ensure users are notified of the disposition of the system,
Disposition secure and archive the system and associated data in accordance with DHS and Federal
policies regarding retention of electronic records, and to dispose of the system assets.
Attachment B-1: SELC Describes the Spiral, Iterative/Incremental, and Waterfall methodologies and illustrates
Development how they are implemented in the SELC.
Methodologies
Attachment B-2: Work Provides work patterns (also referred to as pre-tailored plans) suitable for usage or for
Patterns further tailoring. Work patterns are provided for each of the three development
methodologies, as well as for projects with special focus (service delivery, Commercial
Off-the-Shelf [COTS], and infrastructure) efforts.
Attachment B-3: Other Provides detailed DHS information on the required elements that must be incorporated in
SELC Considerations all projects.
Attachment B-4: Lists all of the SELC exit criteria by SELC stage.
Summary of Exit
Criteria
2. SELC Overview
This section defines the DHS SELC framework and the elements it comprises. As such,
it provides the basis for the detailed information on each stage of the SELC in
subsequent sections of this document. For IT acquisitions, this section also provides
information regarding the transition that DHS is making to a Service Oriented
Architecture (SOA). Lastly, it discusses different development methodologies and
technical approaches and how they may be used to tailor a project to best achieve
project success.
2
Per guidance in the DHS CPIC Guide.
SPR SER PPR SDR PDR CDR TRR PRR ORR PIR
Stage A: Stage 7:
Stage 2: Stage 5: Stage 8:
Stage 1: Stage 3: Stage 4: Stage 6: Operations
Solution Requirements Integration
Planning Design Development Implementation & Disposition
Engineering Definition & Test Maintenance
Engineer the Plan the project and Analyze user needs Transform Convert the Integrate and test System moved to The system is The system is
program solution to acquire and document requirements into system design with other systems; Production operated to carry disposed
ensure all resources needed functional detailed into system conduct UAT; environment; out
alternatives are to achieve solution requirements system design develop C&A Production data has intended function
considered been loaded
• CONOPs • PMP • FRD • SRD • Training Materials • System Test Report • Pilot Results Report • Performance • Disposition
• ORD • DHS Periodic • SLAs • Logical Design • Test Case • Acceptance Test • ORR Approval Letter Reports Approval Request
• AP Reporting • Site Prep Plan Document Specification Report IT Specific • Operational • Archived System
• AoA • Risk Management • RTM • System Design • System • DHS Periodic • Authority To Analyses IT Specific
• CBA Plan • TEMP Document Acceptance Test Reporting Operate (ATO) Letter • Lessons Learned • Archived Data
• LCCE • Quality Assurance • SDR Approval Letter • Deployment Plan Procedures • PRR Approval Letter • PIR Results
• APB Plan IT Specific • PDR Approval Letter • Operators IT Specific IT Specific
• Project Tailoring • Training Plan • SRTM • CDR Approval Letter Manuals • Section 508 • FISMA metrics
Plan(s ) • PPR Approval Letter • POA&M IT Specific • Maintenance Assistive Technology reports
• MS2B ADM IT Specific • SSP • ISA Manuals Interoperability Test • Security Incident
IT Specific • CM Plan • Contingency Plan • Data Architecture • User Manuals Report reports
• Service Reuse Plan • PTA • DR Plan Document • Initial System • EA Insertion • C&A Updates
• HLS EA Program • Section 508 EIT • SRA • Technology Implementation Packages • Privacy
Alignment DR Accessibility Plan • ST&E Plan Insertion Decision • TRR Approval • SAR Documentation
• Map to Business • DM Plan • Map to the Data Request Letter • Security
Architecture Architecture • PIA IT Specific Accreditation
Figure 2-1: Summary Snapshot (summarizes the SELC stages, reviews, and products)
2.2 DHS Development Methodologies
Projects vary in the challenges they present. They can range from a simple installation
and configuration to intense software development; from tried and tested technology to
bleeding edge integration; and from software development to systems development.
Given the variety of project types and project characteristics, a single development
methodology is not sufficient to meet the needs of all projects. This section discusses
various methodologies and provides a guide for selecting the one most appropriate for
optimizing project success.
In accordance with Directive 102-01, for Level 1 and Level 2 programs (where not
delegated), the Project Tailoring Plan is approved at the HQ level at ADE 2B, and any
subsequent changes to it must be coordinated with the approval authority. For Level 3
and below projects, approval is at the Component level. The approval of the Project
Tailoring Plan is granted as Project Managers are responsible for developing a Project
Tailoring Plan that is best suited to address the characteristics of the project. In order to
assist Project Managers, this DHS SELC Guide provides six work patterns in
Attachment B-2. A work pattern is a tailored version of the DHS SELC and is based on
either a standard development methodology (e.g., spiral) or other special use (e.g.,
COTS implementation).
Project Managers may select one of the work patterns as is or tailor the selected work
pattern further to meet the needs of the project. The Project Tailoring Plan should
indicate how the chosen methodology will fit with the ARP review cycle. For example,
spiral or incremental acquisitions may require separate 2B (or a 2A review when
requirements, AoA’s, ORD segments, costs and other planning for a new spiral were
not approved at a prior 2A). Most important is that the Project Tailoring Plan define the
optimal development methodology that provides the project the best opportunity for
successful delivery and meets all of the required standards for reviews. Evidence of plan
approval should be maintained with the project documentation.
Many documents are prepared in the life cycle of a project; some are created and
finalized in a single DHS SELC stage while others are updated in successive stages
after creation. Project baselines, the Project Management Plan, and the System
Security Plan (SSP) are examples of documents that are refined over multiple stages.
This applies particularly to security, privacy, and Section 508 Accessibility
documentation (29 U.S.C. Section 508, as amended by P.L. 105-220, August 1998. For
more information on project documents and their status per stage, refer to the DHS
SELC Artifact Summary, found in Attachment B-5 of this document.
3
Guide to the Software Engineering Body of Knowledge, IEEE Computer Society, 2004 Version.
3.2 Documents
The project team records the results of their efforts in a set of documents, which are
presented in Table 3-1, Solution Engineering Stage Documents. All documents should
be placed under CM control.
Implementation
Requirements
Development
Operations &
Integration &
Maintenance
Engineering
Disposition
Definition
Planning
Solution
Design
Test
Mission Need Statement ARP (DIR 102-01) C F
Capability Development Plan (CDP) ARP (DIR 102-01) C/F
Acquisition Plan ARP (DIR 102-01) C U U U F
CONOPS ARP (DIR 102-01) C/F
Analysis of Alternatives / Alternatives Analysis ARP (DIR 102-01) C/F
Lifecycle Cost Estimate (LCCE) ARP (DIR 102-01) C U U U U
Operational Requirements Document (ORD) ARP (DIR 102-01) C/F
Integrated Logistics Support Plan (ILSP) ARP (DIR 102-01) C U U F
Acquisition Program Baseline ARP (DIR 102-01) C U F
Project Tailoring Plan DHS SELC C/F
Service Reuse Plan DHS SELC C U U U U U U F F
HLS EA Program Alignment Decision Request DHS EA Process C U U U F F
Program Alignment Documentation Matrix DHS EA Process C U U U F
Map to Business Architecture DHS EA Process C U U U F
Map to OCIO Portfolios DHS EA Process C U U U F
Section 508 National Security Exception
Determination DHS OAST C/F
Critical Infrastructure Protection Report DHS CISO C F
FIPS 199 Security Categorization DHS CISO C U
Preliminary Security Risk Assessment DHS CISO F
Project Authorization Review Approval Letter DHS SELC C/F
4.3 Documents
The project team records the results of their efforts in Stage 1 Planning in a set of
documents, which are presented in Table 4-3, Planning Stage Artifact Summary.
Documents must be traceable to the project Work Breakdown Schedule (WBS). All
documents should be placed under CM control. For a full listing of the documents,
including others that get updated during the Planning stage, see Attachment B-5 of this
document.
Implementation
Requirements
Development
Operations &
Integration &
Maintenance
Engineering
Disposition
Definition
Planning
Solution
Design
Test
Figure 5-1: Developmental Testing and Operational Testing and Key Documents
4
DHS Information Security Categorization Guide.
5
DHS Information Security Categorization Guide.
5.1.10 Map Documents to the HLS EA Technical Reference Model (IT Only)
The Technical Reference Model (TRM), a component of the HLS EA, provides guidance
to ensure that proposed IT solutions are consistent and to promote interoperability
across the DHS enterprise. The implementation of the TRM is accomplished through
the use of the Standards Profile (SP). The DHS Standards Profile reflects the industry
standards and actual documents that have been adopted for use throughout DHS. DHS
IT project teams are responsible for mapping proposed solutions to the DHS TRM (and
Target TRM) and Standards Profile in order to ensure compliance with existing
standards and with the future architecture. Where no standard is in place, projects
should identify the standard to be used. Projects may propose refinements to the TRM
via the DHS Technology Insertion Process. For more information on DHS Technology
Standards and Documents, refer to the EAB Process Guide.
5.2 Documents
The project team records the evidence of its work in the set of documents listed in Table
5-1. The tailored plan approved for use in the project determines the documents
applicable for the project. The project WBS must include the corresponding line items
for completion of each artifact. All documents should be placed under CM control. For a
full listing of the documents, including other items that get updated during the
Requirements Definition stage, see Attachment B-5 of this document.
6
EAB Governance Process Guide Version 3.0, March 31, 2006, Department of Homeland Security Enterprise
Architecture Board, Appendix G, p. 121.
Implementation
Requirements
Development
Operations &
Integration &
Maintenance
Engineering
Disposition
Definition
Planning
Solution
Design
Test
Functional Requirements Document (FRD) DHS SELC C U U U U F
Requirements Traceability Matrix (RTM) DHS SELC C U U U U F
Test and Evaluation Master Plan (TEMP) DHS SELC C U F
Security Requirements Traceability Matrix (SRTM) DHS CISO C U F
Plan of Action & Milestone (POA&M) DHS CISO C U U F
System Security Plan (SSP) DHS CISO C U U U F
Contingency Plan DHS CISO U F
Disaster Recovery Plan DHS SELC C U F
Security Risk Assessment (SRA) DHS CISO C U F
Security Test & Evaluation (ST&E) Plan DHS CISO C F
Map to the Data Architecture DHS EA Process C U U F
Map to the Business Architecture DHS EA Process C U U F
Map to Technology Standards & Products DHS EA Process C U U F
System Definition Review Approval Letter DHS SELC C/F
6. Stage 3: Design
The objective of the Design stage is to transform the baselined requirements into
comprehensive, logical, and detailed designs to efficiently and effectively guide
development. The decisions made in this stage address, in detail, how the system will
meet the variety of defined requirements. Activities performed in this stage also ensure
that the following objectives are met:
• The detailed design specifications align with the HLS EA (including SOA), Section
508 Accessibility standards, privacy requirements, and security requirements
• Mechanisms to handle system disruptions are considered and planned
• All required technology insertions into the DHS EA TRM are completed and
approved
Design activities may be conducted in an iterative fashion, producing first a logical or
preliminary design of the solution that emphasizes the functional features of the system,
then a more detailed design that expands the logical design by providing all the
technical detail required to implement the logical design and that allows system
development to begin. Projects are encouraged to use an automated design tool. If
appropriate, prototyping should be used to help refine requirements, provide
stakeholders with an initial view of the system, and gain their approval to proceed with
development. More information on prototyping can be found in Attachment B2, section
B2.6.2.
The Design stage includes a Preliminary Design Review (PDR) and a Critical Design
Review (CDR). The PDR is conducted during the Design stage while the CDR is
conducted at the end of the Design stage. For information on Developing the
Deployment Plan activities, see Appendix J: Supportability and Sustainment Guide of
the Instruction/Guidebook 102-01-001.
7
Enterprise Life Cycle Guide v2.0, Internal Revenue Service, May 1, 2006, p.47.
8
Ibid, p. 45-47.
9
Enterprise Life Cycle Guide v2.0, Internal Revenue Service, May 1, 2006, p.48.
6.2 Documents
The project team records the results of their efforts in Stage 3, Design in the set of
artifacts presented in Table 6-5. Artifacts must be traceable to the project WBS. Table 6-5
only shows the artifacts that are first created in the Design stage. All artifacts should be
placed under CM control. For a full listing of the artifacts, including others that get
updated during the Design stage, see Attachment B-5 of this document..
Implementation
Requirements
Development
Operations &
Integration &
Maintenance
Engineering
Disposition
Definition
Planning
Solution
Design
Test
Service Level Agreements DHS SELC C U F F
System Requirements Document DHS SELC C U U U F F
Interconnection Security Agreement (ISA) DHS CISO C/F
Logical Design Document DHS SELC C/F
Data Architecture Document DHS SELC C/F
System Design Document DHS SELC C U U F
Technology Insertion Decision Request DHS EA Process C/F
Site Prep Plan DHS SELC C/F
Critical Design Review Approval Letter DHS SELC C/F
7.2 Documents
The project team records the results of its efforts in Stage 4, Development in a set of
documents, presented in Table 7-1. Documents must be traceable to the project WBS.
All documents should be placed under CM control. For a full listing of the documents,
including other items that get updated during the Development stage, see Attachment
B-5 of this document.
Implementation
Requirements
Development
Operations &
Integration &
Maintenance
Engineering
Disposition
Definition
Planning
Solution
Design
Test
Training Materials DHS SELC C/F
Test Case Specification DHS SELC C/F
System Acceptance Test Procedures DHS SELC C/F
Test Readiness Review Approval Letter DHS SELC C/F
10
Summary of Section 508 Standards, General (Sub-Part A), www.section508.gov.
11
For detailed directions or guidance on the DHS POA&M process, consult the DHS 4300A Sensitive Systems
Handbook, Attachment H -- POA&M Process Guide.
8.2 Documents
The project team records the results of their efforts in Stage 5, Integration and Test in a
set of documents identified in Table 8-1. Documents must be traceable to the project
WBS. All documents should be placed under CM control. For a full listing of the
documents, including other items that get updated during the Integration and Test
stage, see Attachment B-5.
Implementation
Requirements
Development
Operations &
Integration &
Maintenance
Engineering
Disposition
Definition
Planning
Solution
Design
Test
Operators Manuals DHS SELC C F
Maintenance Manuals DHS SELC C F
User Manuals DHS SELC C F
System Test Report DHS SELC C/F
Acceptance Test Report DHS SELC C/F
Section 508 Assistive Technology Interoperability
Test Report DHS OAST C/F
Service Insertion Package (SIP) DHS EA Process C U F F
Security Assessment Report (SAR) DHS CISO C/F
Security Accreditation package DHS CISO C/F
Privacy Impact Assessment (PIA) Privacy Office C/F
DHS Periodic Reporting CPIC C U U U
Production Readiness Review Approval Letter DHS SELC C/F
9. Stage 6: Implementation
The objective of Stage 6, Implementation, is to prepare the system, operational
environment, organization, and users for the intended use of the new solution.
For information on Transition to Support and Training activities, see Appendix J:
Supportability and Sustainment, of the Instruction/Guidebook 102-01-001.
9.1.3 Perform Data Conversion and Load Production Data (IT Only)
Data may be extracted from legacy systems, converted or transformed, and uploaded
into the target system at multiple points within the development life cycle. Security and
privacy policies must be adhered to. It is also advisable that as each batch upload or
system interface procedure is completed, both data integrity and business function
testing procedures be applied. These procedures may include running parallel
operations testing, reconciliations, or combinations of both. Depending upon the size
and complexity of legacy data, converting legacy data and loading them to a production
9.1.5 Publish System of Records Notice and Acquire Privacy Office Affirmation
(IT Only)
A SORN is a publicly published document that describes a certain type of data
collection and how that data is used. A “system of records” is a group of any records
under the control of any agency from which information is retrieved by the name of the
individual or by some identifying number, symbol, or other identifier assigned to the
individual. The Privacy Act requires each agency to publish notice of its systems of
records in the Federal Register. Prior to implementation, the project must receive an
affirmative statement from the DHS Privacy Office that all privacy compliance
requirements are met.
For more information on DHS privacy compliance requirements, contact the Privacy
Office, U.S. Department of Homeland Security, Washington, DC 20528, available via
email PIA@dhs.gov. Examples of PIAs and SORNs, as well as additional educational
materials related to compliance, are available on the DHS Privacy Office website:
www.dhs.gov/privacy.
9.2 Documents
The project team records the results of its efforts in Stage 6, Implementation in a set of
documents that is presented in the Implementation Stage Document summary, shown
in Table 9-1. Documents must be traceable to the project WBS. All documents should
be placed under CM control. For a full listing of the documents, including other items
that get updated during the Implementation stage, see Attachment B-5.
Implementation
Requirements
Development
Operations &
Integration &
Maintenance
Engineering
Disposition
Definition
Planning
Solution
Design
Test
Pilot Results Report ARP (DIR 102-01) C/F
Follow on Test Results ARP (DIR 102-01) C/F
Version Description Document DHS SELC C/F
Critical Infrastructure Protection Report CIP C/F
System of Record Notice (SORN) DHS Privacy C/F
Authority To Operate (ATO) Letter DHS CISO C/F
Operational Readiness Review Approval Letter DHS SELC C/F
Activity Description
Security Operations and • Perform backups
Administration • Hold annual security awareness classes for all users
• Maintain current user administration and access privileges
• Hold specialized security training for security personnel
• Update security software
Configuration Management • Use DHS CM and control procedures to document proposed or actual changes
and Control to the system (including hardware, software, firmware, and surrounding
environment)
• Analyze changes to determine their security impact
Ongoing Security Control • Identify potential security-related problems in the system not identified through
Verification the security impact analysis conducted during the CM task
• Select an appropriate set of security controls and evaluate the effectiveness of
the controls through security reviews, self-assessments, security testing and
evaluation, vulnerability assessments, or security audits (selection to made by
Information Security System Engineer and project sponsor)
SSP Maintenance and • Update the SSP as changes occur (annually, at a minimum) to reflect the most
Security Incident Reports recent changes to the system and any identified or potential security impacts
• Report proposed or actual changes and identified or potential security impacts to
the authorizing official or designated representative
• Use information from status reports to determine the need for security re-
accreditation
C&A Maintenance • Validate that existing documentation meets requirements for a signed ATO letter
(operational systems must have a signed ATO letter that is good for 3 years or is
issued when a major change occurs to the system or the system environment)
• Validate that C&A documentation (defined in the Department of Homeland
Security Certification and Accreditation Guidance for SBU Systems User’s
Manual) is current and is uploaded to the CISO-approved FISMA reporting tool
NIST SP 800-53 Controls • Perform annual tests of NIST SP 800-53 controls using NIST SP 800-53A tests
Test
POA&M Updates • Develop corrective action plans for newly identified weaknesses
• Provide monthly status updates for previously identified weaknesses
Contingency Plan • Update the Contingency Plan as changes occur (annually, at a minimum)
• Perform annual tests of the Contingency Plan
Monthly Updates for • Perform monthly updates of IT system data included in the CISO-approved
Security Reports FISMA reporting tool to facilitate 1) Information Security Scorecard development,
2) quarterly FISMA report development, 3) annual FISMA report development
10.1.8 Develop Section 508 Accessibility Incident Remediation Report (IT Only)
The Accessibility Incident Remediation Report (29 U.S.C. Section 508) documents all
end-user problems with Section 508 Accessibility and describes the changes made to
remediate the problem(s). The report is included in project documentation with the
Section 508 Accessibility Plan; a copy is to be provided to DHS OAST. For more
information on the Section 508 Accessibility Incident Remediation Report, refer to DHS
OAST.
Implementation
Requirements
Development
Operations &
Integration &
Maintenance
Engineering
Disposition
Definition
Planning
Solution
Design
Test
Performance Reports ARP (DIR 102-01) U
Post Implementation Review (PIR) Results CPIC U
DHS Periodic Reporting CPIC U U
Operational Analyses CPIC U
Lessons Learned CPIC U
FISMA metrics reports DHS CISO U
Security Incident reports DHS CISO U
C&A Updates (every 3 years or when major change
is made) DHS CISO U
Privacy Documentation (updated for systems
decommissioned) Privacy Office U
ARP Phases
PRODUCE/
ANALYZE/ DEPLOY/
NEED SELECT OBTAIN SUPPORT
Governing SELC Stages
PRODUCT Authority
Implementation
Requirements
Development
Operations &
Integration &
Maintenance
Engineering
Disposition
Definition
Planning
Solution
Design
Test
Disposition Approval Request DHS SELC C/F
Archived Data DHS SELC C/F
Archived System DHS SELC C/F
Attachment B-1
Systems Engineering Life Cycle
Development Methodologies
This attachment provides additional information on the DHS SELC system development methodologies
discussed in Section 2. The methodologies described are Spiral, Iterative/ Incremental, and Waterfall. Each
of the following sections discusses the advantages and disadvantages of each methodology and the
applications for which each is most suitable.
nts
me
u ire Pla
q
Re nn
nal ing
n ctio n ts
F u me Pla
q uire nn
ing
a l Re ent
s
Pla
ion irem
ct equ nn
Fun ctional R
ess R
eq. PPR ing
Fun Busin Pl
an
ents Pl ni
irem an ng
Requ
q.
ni
Re
ng
s
es
l
na
in
io
Spiral
us
ct
B
n
Fu
SDR
Development
Model
Sy Req
Sy Req
Sy Req
Sy
st . D
S y Re q
st .
e
em
st as
st .
em
em
sC ns
st .
em
tio
Pr s i g
es ra s
em
on
e li n
Con
Pr si
in pe ati
m
s
De
cep
el gn
u O
.
P
Coroof
t B of er
im
t p
ns
De
De nc o f ep O
ep nc of tio
si
mo t
Co pt ra
gn
Pro ns Test ce
De
ing C
De of
gn
Un velo User R
eview pt
i tTp
CDR est n ce
D Co
Un evelo TRR Integra
ti
it T p & Teston
est
Integ
ra t
TRR & Tes ion Acceptance
t Disposition
Testing Implementation O&M
PRR ORR PIR
The strengths of the Spiral methodology are that 1) not all requirements need to be well understood at the
beginning of the project and 2) there is a heightened focus on risk reduction. Risk is accounted for early in
the project life cycle, before large-scale development activity has begun, through the use of prototypes.
The methodology provides frequent checkpoints for risk mitigation and management oversight. If the risk
of a given cycle proves insurmountable, an alternative solution can be explored.
The assessment of the Spiral development methodology presented in Table B1-1 is adapted from the
Department of the Air Force, Guidelines for Successful Acquisition and Management (GSAM) Condensed
Version (February 2003).
DHS SLC
FQT
Integration
(Dev
FQT
Integration
Test)
(Dev
FQT Test)
Integration
(Dev Test) Develop
Develop
Development
Develop
& Test& Test
& Test
DesignDesignDesign
Requirements
Requirements
Requirements
Planning
Planning
Planning
Requirements
Planning
the diagram in Figure B1-3. The key distinction is that each sub-project (increment) is deployed into
production as it is completed.
DHS SLC
Integration Operations &
Planning/ Design Development Implementation Disposition
& Test Support
Requirements
The fundamental similarity between the Iterative and Incremental methodologies is that both require a
good understanding of the requirements at the beginning of the project. The Iterative and Incremental
methodologies are best suited to those projects with a well-defined and stable scope that need the
flexibility to divide the project into multiple parallel efforts.
Table B1-2 presents the advantages and disadvantages of Iterative/Incremental methodologies and is
adapted from the Department of the Air Force, GSAM Condensed Version (February, 2003).
PPR
PLANNING
REQUIREMENTS SDR
DEFINITION
PDR
DESIGN CDR
DEVELOPMENT TRR
INTEGRATION PRR
& TEST
IMPLEMENTATION ORR
OPERATIONS
& SUPPORT PIR
DISPOSITION
The Waterfall methodology is documentation-intensive because early stages document the capability that
must be achieved and subsequent stages provide greater granularity to requirements already defined,
then define how the required capability will be achieved. The output from one stage serves as the input to
the next stage, with the project flowing from one step to the next in a cascading fashion. Stages are
typically sequential, with only localized feedback during the transition between stages. Comprehensive
reviews validate the work of one stage and require the resolution of any problems before development is
allowed to proceed to the next stage.
An important consideration for selection of the Waterfall methodology is that fixes or modifications are
often put off until the maintenance stage (after implementation). This can be costly, as the cost of error
correction is magnified in later stages. The advantages and disadvantages presented in Table B1-3 are
adapted from the Department of the Air Force, GSAM Condensed Version (February, 2003).
Element Section
Project Management B.2
Organizational Change Management (OCM) B.3
Enterprise Architecture Alignment B.4
Requirements Definition B.5
Prototyping B.6
Information Security B.7
Privacy Compliance B.8
Critical Infrastructure Protection B.9
Human Factors Engineering B.10
Section 508 EIT Accessibility B.11
Risk Management B.12
Independent Validation and Verification (IV&V) B.13
Electronic Records Management B.14
National Information Exchange Model (NIEM) B.15
B2.2.1 Definitions
The following paragraphs define project management-related terms found in this DHS SELC Guide for
use in DHS acquisitions.
Project Management: Project Management is the application of knowledge, skills, tools, and techniques
to a broad range of activities in order to meet the requirements of a particular project. The Project
Management Institute (PMI) groups Project Management activities into five process groups: Project
Initiation, Project Planning, Project Execution, Project Monitor and Control, and Project Close 12 (e.g.,
known collectively as the project life cycle). PMI also identifies nine supporting knowledge areas: Project
Integration Management, Project Scope Management, Project Time Management, Project Cost
Management, Project Quality Management, Project Human Resources Management, Project
Communications Management, Project Risk Management, and Project Procurement Management.
Program: A program is a group of related projects or a project that is large in scope and dedicated to a
specific purpose. In this DHS SELC Guide, for the sake of convenience, the term “project management”
will be used to mean either “program” or “project” management.
Project: PMI defines a project as a temporary endeavor undertaken to create a unique product, service,
or result.
12
PMI website, Professional Practices section, “About the Profession,” www.pmi.org.
Program Manager: DHS Management Directive (MD) 0784 defines the role of the Program Manager and
the associated tasks as follows: 13 A Program Manager is the responsible person who, with significant
discretionary authority, is uniquely empowered to make final the scope of work, capital investment, and
performance acceptability decisions (for an assigned program[s]), and who is responsible for
accomplishing program objectives or production requirements through the acquisition of in-house,
contract or reimbursable support resources, as appropriate. The Program Manager is responsible for
management and oversight of the Integrated Project Team. In general, the Program Manager is the
manager of an acquisition program, but may be a manager of a procurement that does not rise to the
level of an acquisition program (i.e., janitorial services, HR services, bulk commodity purchases).
Project Management Methodology: A defined process (methodology) with the specific purpose of
managing a project or program through all phases of the project life cycle. The methodology is a
framework that acts as a mechanism for coordination in combining the responsibilities of managing both
an organization (Integrated Project Team – IPT) and a process (project life cycle) for the life of a project.
Integrated Project Team: A group of subject matter experts (SME) who represent the interests of their
sponsoring functional organizations in performing project activities as members of a project team under
the direction of a Project Manager for the duration of a project.
Project Life Cycle: A standardized collection of distinct phases grouped together to create the process
that a Project Manager uses to manage a project. PMI defines the set of common phases and activities in
the project life cycle (Table B2-2) as follows:
B2.2.2 Benefits
Project management conveys several benefits. It:
• Provides a standard method to ensure that projects are defined, monitored, and implemented in a
structured, consistent manner that promotes predictability and quality of outcome so that projects are
completed on time and within scope and budget.
13
Office of the Chief Procurement Officer, Department of Homeland Security, Acquisition Oversight Program
Guidebook, July 2005, p77, https://dhsonline.dhs.gov/portal/jhtml/tracking/viewdoc2.jhtml?doid=42070.
14
IEEE Std 1490-2003, IEEE Guide Adoption of PMI Standard – A Guide to the Project Management Body of
Knowledge.
• Supports major functional processes within the life cycle, providing a uniform method to comply with
and integrate multiple life cycle requirements and tasks (e.g., strategic planning, enterprise
architecture [EA], investment planning, SELC) to ensure that projects meet stated goals.
• Uses a defined project management approach/methodology to coordinate the management of
organizational needs and expertise with the management of the project management process in order
to achieve results.
B2.2.3 Considerations
DHS Acquisition Managers, including Program Managers and Project Managers are responsible for
managing projects as “investment stewards,” ensuring compliance with MD 0784. 15 Though this DHS
SELC Guide does not define or specify a particular project management methodology to be used, it does
make the following recommendations with regard to the management of DHS IT projects:
• Program and/or Project Managers must meet the PM certification requirements as defined in MD
0784.
• Project goals and objectives should directly relate to the DHS mission.
• Key stakeholders (internal and external) should be identified early and involved throughout the life of
the project to ensure that business needs are accurately defined and met.
• Project Management Plans should identify and deliver measurable benefits to stakeholders, such as
reduced cost, improved quality, and more efficient response time.
• Project Managers are responsible for identifying and communicating risks and issues that may hinder
the successful delivery of a project.
• Project Management Plans must be flexible and should use a methodology that efficiently supports
DHS’ dynamic development environment, which is characterized by requirements and priorities that
can change due to external events.
• Project Management Plans must include program and project reviews defined in this DHS SELC
Guide in order to ensure effective reporting and management of project progression.
• Project Managers should define levels of effort and project detail relative to the level of risk to the
program, project, and/or task.
• Project Managers must develop and maintain comprehensive elements to support the project
management processes of project initiation, project planning, project execution, project monitor and
control, and project close, including a work breakdown structure, project schedule, ADEs, resource
plans, and identification of critical path, in order to ensure effective and efficient project management
and delivery to meet project objectives.
• Project Management Plans must include all appropriate standard elements found in best practice
project management methodologies to manage the project (e.g., project communication plan, project
training plan).
• Project Managers must ensure that all privacy compliance requirements (including analysis and
documentation) are met prior to implementation.
15
Department of Homeland Security, Management Directive (MD) 0784, Acquisition Oversight Program, issued
December 19,/2005, p2, https://dhsonline.dhs.gov/portal/jhtml/tracking/viewdoc2.jhtml?doid=4097002.
B2.3.1 Definition
Organizational Change Management (OCM) helps organizations plan for, adapt to, and integrate change
that occurs as a result of changes in enterprise mission, IT systems, 16 or process. The implementation,
modification, or disposal of any enterprise IT system or component may result in significant change to
related business processes, organizational structure or culture, and workforce. OCM is the set of
management practices used to proactively assess and address the impact of significant organizational
change at appropriate points in the life cycle. OCM activities (e.g., reviews, assessments, tasks,
communications, and production of documents and products) should be conducted when necessary to
promote project success.
Changes to enterprise mission or IT systems can result from several types of initiatives, such as:
B2.3.2 Benefits
The benefits of employing OCM include the following:
• Ownership and commitment to the enterprise change among both the leadership team and other
stakeholders
• Facilitation of new roles and responsibilities (e.g., strategy drives structure)
• Enhanced workforce readiness to support and successfully implement the mission
• Earlier identification and resolution of critical issues (e.g., unintended consequences)
B2.3.3 Considerations
• Organizational and business process improvements identified using OCM techniques should be
integrated with the Homeland Security (HLS) EA Business Architecture.
• Information Technology (IT) does not drive OCM (e.g., processes can be improved to meet mission
needs more effectively than simply by automating).
• While DHS does not mandate specific approaches to manage enterprise change, OCM is recognized
as a best practice throughout government and industry.
• OCM should be employed for all major 17 DHS development projects, especially those involving
significant change to technology, process, or organization structure.
• Project Managers should incorporate OCM concepts and activities in the project plan (e.g., Business
Impact Assessments, Outreach and Communication tasks).
16
Dr. Craig J. Petrun, The MITRE Corporation, Organizational Change Management - Practice Area Overview, Slide
1 of 27, August 3, 2006.
17
Refer to Directive 102-01 for the current investment thresholds for major projects.
B2.4.1 Definition
The domain of EA includes baseline architecture, target architecture, and a sequencing plan. 18 EAs are
essential for evolving information systems, developing new systems, and inserting emerging technologies
which optimize mission value. The existence of an EA is federally mandated by the Clinger-Cohen Act,
which makes Chief Information Officers responsible for developing, maintaining, and facilitating the
implementation of a sound and integrated IT architecture in their organizations. 19 The DHS EA is aligned
to the Federal Enterprise Architecture (FEA). The FEA is used to document, describe, and develop the
baseline architecture, the target architecture, and the sequencing plan. Component EAs are required to
align with the HLS EA. Individual projects are evaluated through the EA Governance process for
architectural alignment. The HLS EA target architecture is evolving to a Service Oriented Architecture
(SOA).
B2.4.2 Benefits
Among its benefits, an EA: 20
• Establishes the enterprise-wide roadmap to achieve the enterprise mission within the IT environment
• Acts as a “blueprint” for systematically and completely defining the current (baseline) and desired
(target) IT environment, thereby facilitating change and promoting standardization, alignment, and
integration
• Improves communication and decision making through use of a standard vocabulary, the capture of
enterprise facts, and support for enterprise analyses and decision making
• Provides a mechanism for sharing services
• Expedites the integration of legacy, migration, and new systems
• Ensures legal and regulatory compliance
• Facilitates transition to new EA concepts
B2.4.3 Considerations
• Official DHS guidance states that the role of the target architecture in the HLS EA is to establish a
cohesive and consistent view of the future in terms of the data, software, and technology required to
implement it. 21
• The HLS EA contains:
– DHS architectural principles
– A baseline inventory of “as-is” business practices and technology resources
– A four-layer target architecture (consisting of business, data, applications, and technology layers)
– A transition strategy and plan intended to move the HLS enterprise toward the evolving target
architecture
18
A Practical Guide to Federal Enterprise Architecture, version 1.0, p.1., Chief Information Officers Council, February
2001.
19
Division E – Information Technology Management Reform Act (now the Clinger/Cohen Act), s.1124, as found at
http://www.cio.gov/Documents/it_management_reform_act_Feb_1996.html.
20
Ibid, p8.
21
From HLS Target Architecture, Version 2.0, October 29, 2004.
• DHS IT systems must align with the HLS EA. EA alignment refers to how well IT investments support
the enterprise architecture and the transition to the target architecture. To guide IT project alignment
to the HLS EA, appropriate EA-related exit criteria are defined in each DHS SELC stage.
• Project Managers and system architects are responsible for designing DHS systems that take the
following into account:
– Adherence of all IT system development efforts to the principles, standards, and processes
defined by the DHS Service Component Based Architecture
– Leverage of existing services (reuse of registered services)
– Identification of opportunities to create additional services (new services or enhancements of
existing services) for reuse throughout DHS
– Leverage of existing data assets to increase information sharing opportunities
• The EA Alignment Process is conducted:
– As part of the project approval process to ensure EA alignment of proposed projects
– Periodically, as part of the ARP, to:
– Validate alignment throughout the life of the investment (e.g., as IT investments are
defined, designed, developed, tested, implemented, maintained, and disposed of)
– Ensure that variances are identified, assessed, and either approved or rectified
• The HLS Technical Reference Model (TRM) provides technical standards for all DHS IT systems.
The TRM applies to both the development of new systems and the enhancement of existing
systems. Additionally, it applies to both pilots and prototypes. Pilots must be compliant with the
TRM; prototypes may use emerging technologies if approved by the DHS EAB.
• The EAB Governance Process Guide describes the EA Decision Request (DR) processes.
Specific types of EA DRs include the following:
– Program Alignment DR (confirm alignment of a program to the HLS EA)
– Technology Insertion DR (approve insertion of technology products/standards into the HLS
TRM)
– Service Insertion DR
– Data Insertion DR
– Performance Insertion DR
For more information on EA planning, technical insertion, and assessment processes or the DHS TRM,
contact either the EA staff in the DHS Office of the CIO’s Office of Applied Technology or the Technology
and Architecture staff of the DHS Component organization of interest.
B2.5.1 Definition
The activities in the requirements definition phase (commonly referred to as requirements engineering by
the Software Engineering Institute [SEI]) of the systems engineering life cycle include the gathering,
analysis, specification, verification, validation, and management over time of the stakeholder-desired
capabilities and characteristics of a product and/or product component to be produced in support of
mission needs.
B2.5.2 Benefits
The benefits of effective and efficient requirements engineering include the following:
• Greater likelihood of successful delivery that meets project cost, scope, and schedule (“requirements
development is one of three factors critical to successful acquisitions”) 22
• Improved risk management due to increased project stability
• More effective project-related communication
• Enhanced enterprise decision making via defined requirements baselines
B2.5.3 Considerations
Many of the concepts and descriptions below are adapted from the Requirements Engineering Section of
an SEI article called “A Framework for Software Product Line Practice.” 23
• Effective and efficient configuration management must be used to establish baselines from which to
manage change; requirements engineering affects all aspects of systems development and
maintenance as changes in requirements in one project may affect other related systems and/or
components (e.g., changes in requirements for a development project may affect the requirements for
maintenance of existing systems and/or components, as well as the requirements of parallel
development efforts).
• Requirements engineering is a communications exercise among the many internal and external
stakeholders it involves: citizens, executives, systems engineers, operations personnel, field
personnel, taxpayers, other “end-users” (including persons with disabilities), contractors, oversight
agencies, other projects under development, among others. Therefore, effective communication
plans, activities, and products must be established and managed with appropriate levels of detail
available for all stakeholders.
• Requirements must be defined with the appropriate level of both behavioral (e.g., the specificity to
support functional need, and the generality at appropriate points to deal with change over the lifetime
of the component) and quality characteristics (performance, reliability, security). 24
• This DHS SELC Guide recognizes a series of related activities and products that must be addressed
in requirements engineering efforts for DHS IT projects. These include the following:
– Identification of desired business capabilities from activities conducted as part of the Strategic
Planning, Enterprise Engineering, Operations, and from other appropriate components of the
enterprise life cycle
– The creation of a Concept of Operations (CONOPS), a Business Impact Assessment (BIA), and
subsequent requirements documents as defined in Section 5 Requirements Definition and
including the following:
Operational Requirements Document (ORD)
Functional Requirements Document (FRD)
Requirements Traceability Matrix (RTM)
Systems Requirements Document (SRD)
– The appropriate set of activities, products, tools, and techniques (e.g., testing, prototyping,
modeling, analyses, documentation and communication of trade-off decisions and results) as
recommended by recognized best practice organizations (e.g., SEI, PMI, IEEE) with evidence of
successful execution to support the effective and efficient development of systems and/or
components required for successful project completion in support of the DHS mission
22
Effective Acquisition Practices = Successful Government Program Management Offices (GPMO), Lisa M. De
Mello, MBA, PMP, Joseph A. Pegnato, DPA;William Sullivan, MS; Scott Webb, MS, PMP; September 2005
23
Software Engineering Institute, “A Framework for Software Product Line Practice, Version 4.2,” c.2007.
24
Ibid.
B2.6 Prototyping
B2.6.1 Definition
Prototyping is defined as the development and implementation of a model (e.g., physical, electronic,
digital, analytical) of a product built to do the following:
B2.6.2 Benefits
In many traditional system development methodologies, prototypes were not used, were not available
during development, and/or were maintained only long enough to establish technical feasibility. It is now
recognized that prototyping can provide a variety of benefits throughout the systems development life
cycle, rather than at a single time for a single purpose:
• Prototyping is an effective technique used in product design and evaluation to accomplish the
following:
– Discover physical principles of a product
– Assess and/or confirm product feasibility, requirements, performance, and/or features
– Mitigate project and program risks
– Evaluate technical integration feasibility or alternative solutions
– Elicit user feedback and refine requirements
25
EIA 632: Processes for Engineering a System, January 1999.
26
EAB Governance Process Guide, ver. 3.0, September, 2006.
27
Ibid.
B2.6.3 Considerations
• Prototyping provides increased value in the use of evolutionary/Spiral development methodologies,
such as Rapid Application Development (RAD), Agile Development, and Xtreme Programming.
• All major 29 DHS IT development projects should use prototyping to facilitate requirements analysis
and technical feasibility.
• All major 30 DHS IT development projects should continue to leverage the prototype as part of the
initial build or baseline capability, where feasible.
• Privacy compliance requirements do not distinguish between pilot and prototype and instead look
purely at the data and data usage; consequently, privacy requirements must be met for both.
B2.7.1 Definition
The term “information security” means protecting information and information systems from unauthorized
access, use, disclosure, disruption, modification, or destruction in order to provide:
• Integrity, which means guarding against improper information modification or destruction and includes
ensuring information non-repudiation and authenticity
• Confidentiality, which means preserving restrictions on unauthorized access and disclosure, including
ways to protect personal privacy and proprietary information
• Availability, which means ensuring timely and reliable access to and use of information 31
B2.7.2 Benefits
It is DHS policy that all information systems that generate, store, process, transfer, or communicate
sensitive information shall be protected at a level commensurate with the threat. The level of protection
will be determined by the criticality and sensitivity of the information and of the mission supported by the
information system, and in compliance with national policy and standards. Information security policies,
processes, and procedures provide a variety of benefits throughout the systems development life cycle. 32
• Establish policies and procedures for the overall DHS Information Security Program and information
security in order to ensure incorporation of standards into information security technology efforts.
• Ensure that information assurance requirements are addressed by the mission areas and that
security is adequately incorporated into information system functions throughout the systems
engineering life cycle.
• Ensure that all DHS operational components can exploit the maximum advantage from information in
order to accomplish their missions while keeping residual risk to a minimum.
• Provide security policies and architecture that provide a common, interoperable, cost-effective means
of protecting DHS information resources.
28
IEEE, Guide to the Software Engineering Body of Knowledge.
29
Refer to Directive 102-01 for the current investment thresholds for major projects.
30
Ibid.
31
Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347, December 17, 2007.
32
DHS Information Security Program Strategic Plan, April 4, 2004, version 1.
• Ensure that DHS information, systems, major applications, and general support systems are
sufficiently secure to accomplish the DHS priority missions.
• Ensure compliance with Federal Information Security Management Act of 2002 (FISMA), National
Institute of Standards and Technology, Office of Management and Budget (OMB), National Security
Agency, and Central Intelligence Agency guidance as well as all applicable laws, directives, policies,
and directed actions on a continuing basis.
B2.7.3 Considerations
Government agencies are required to protect information assets against loss, theft, damage, and
unauthorized destruction, modification, and access. To fulfill this responsibility, various risk management
activities must be performed throughout the systems development life cycle. These activities include the
following:
• Identification of an Information Systems Security Officer (ISSO) to serve as the principal point of
contact for all IT security aspects of the system.
• Use of the CISO-approved tool for conducting certification and accreditation. The Office of
Information Security maintains both a classified and unclassified version of the CISO-approved C&A
tool. DHS 4300A applies to all unclassified systems and is used throughout this document as
reference. For classified systems, all references should be made to DHS 4300B. Access to the
classified or unclassified version of the CISO-approved C&A tool should be made through the
Component’s Information System Security Manager (ISSM).
• Use of the CISO-approved tool for conducting annual self assessments and for FISMA reporting.
• Development of a Security Risk Assessment, System Security Plan (SSP), and Plan of Action and
Milestones (POA&M).
• Completion of an independent Security Test and Evaluation (ST&E) with the effort documented in the
Security Assessment Report (SAR).
• A validated Privacy Threshold Analysis reviewed and approved by the DHS Privacy Office.
• IT system C&A completed every three years except in cases where a DHS IT system or an
operational environment has experienced a “major” change. If an IT system or operational
environment is significantly changed prior to the system reaching its three year milestone, the
affected system(s) must be re-certified and re-accredited prior to being allowed to again operate in
the DHS environment.
All DHS IT projects must be in compliance with DHS Systems Security requirements; compliance is
verified throughout the systems development life cycle via exit criteria used in SELC stage reviews.
Additional information regarding the DHS IT security program is presented in DHS 4300A Sensitive
Systems Policy and Handbook, 4300B National Security Systems Policy and Handbook, and Security
Architecture Guides Volumes 1-3.
B2.8.1 Definition
Privacy Compliance is a structured review process to ensure that all privacy compliance requirements are
met prior to final project implementation. Section 208 of the E-Government Act of 2002 requires all
Federal government agencies to conduct Privacy Impact Assessments (PIA) for all new or substantially
changed technology that collects, maintains, or disseminates personally identifiable information. The DHS
Chief Privacy Officer (CPO) is required by Section 222 of the Homeland Security Act to ensure that the
technology used by the Department sustains and does not erode privacy protections. The PIA is one
mechanism through which the CPO fulfills this statutory mandate. The CPO is also required by Section
222 to conduct PIAs for proposed rulemakings of the Department. The CPO approves PIAs conducted by
the Department’s offices and programs.
B2.8.2 Benefits
Privacy Compliance conveys the following benefits:
• Compliance with laws and regulations pertaining to the identification and protection from unlawful
disclosure and use of personally identifiable information collected, maintained, or disseminated by
DHS personnel and/or technology
• Auditable requirements, processes, and training that govern a standard approach to privacy
protection of personally identifiable information within DHS
B2.8.3 Considerations
of PIAs and SORNs as well as additional educational materials related to the compliance are available on
the DHS Privacy Office website: www.dhs.gov/privacy.
B2.9.1 Definition
The USA Patriot Act of 2001 defines critical infrastructure as: 33
“Systems and assets, whether physical or virtual, so vital to the United States that the
incapacity or destruction of such systems and assets would have a debilitating impact on
security, national economic security, national public health or safety, or any combination
of those matters.”
Homeland Security Presidential Directive (HSPD)-7, passed on December 17, 2003, establishes a
national policy for Federal departments and agencies to follow in identifying, prioritizing, and protecting
critical infrastructure and key resources throughout the United States. Consistent with these acts and
directives, the DHS Critical Infrastructure Protection (CIP) Program is one of the eight programs
described in the DHS Information Security Program Strategy. It is a DHS program that reports to OMB
annually about functions and services identified and prioritized as critical infrastructure, the assets used,
and programmatic actions and efforts taken by the Component to protect the asset and ensure continuity
during or recovery after disruption. The CIP program follows the guidance of the Federal Executive Agent
(DHS Infrastructure Protection) and is responsible for identifying mission critical functions and services,
determining those which are candidates, and then making the final determination as to whether the
function and/or service is or is not national critical infrastructure.
B2.9.2 Benefits
CIP conveys the following benefits:
• Systems and assets vital to the security, economy, public health, and/or safety of the United States
are identified and prioritized, allowing the implementation of plans to protect them from incapacity,
destruction, and/or to ensure continuity or recovery after disruption.
• A national policy exists to ensure a unified approach to the identification, prioritization, and protection
of vital systems and assets.
B2.9.3 Considerations
Additional information on the CIP program can be found in the DHS Sensitive Systems Handbook
Security Program Policy. Additional information on the DHS CIP program is available from the
organization supporting Continuity Planning for Critical DHS Assets within the DHS Office of the Chief
Information Officer (DHS OCIO). For information at the Component organizational level, contact the CIP
Officer for the specific Component organization of interest.
B2.10.1 Definition
Human factors engineering (HFE) is concerned with optimizing the interaction of people (often referred to
as “end users” or “users”) with the devices, applications, systems, processes, and equipment they must
33
USA PATRIOT Act of 2001 (42 U.S.C. 5195c(e))., SEC. 1016. CRITICAL INFRASTRUCTURES PROTECTION,
October 18th, 2001, from http://fl1.findlaw.com/news.findlaw.com/cnn/docs/terrorism/hr3162.pdf
use in order to minimize errors, time spent performing a task, lost productivity, staff turn-over, and training
costs, while maximizing efficiency, clarity, ease of learning, effectiveness, and productivity. 34
B2.10.2 Benefits
Applying the principles of HFE conveys the following benefits:
• The user-centered design process creates a design that is user-evaluated and altered at several
points early in the project life cycle, resulting in an end-product or service more likely to meet user
needs.
• Cost efficiencies in service/product development can be gained because corrections are made earlier
in the development life cycle when they are less costly than those made later in the life cycle.
B2.10.3 Considerations
• User-centered design requires that project developers:
– Know the user(s), including users with disabilities, 35 and their requirements
– Involve the users early and often in the design process
– Use an iterative approach so that each iteration is targeted to improve a specific facet of the
design, with the total number of iterations determined by usability acceptance criteria and user
priority 36
• A variety of factors in the operational environment affect the importance of “usability” (or “ease of
use”) in the design of a product or service. For example, in products or services affecting human
safety or security, usability is probably a greater priority than in other applications.
• While DHS has no formal policies that specifically mandate the use of HFE by name, HFE concepts
are present in many activities related to the SELC. The user-centered design characteristics of
understanding user needs, involving the user early in design, and using an iterative design process
are analogous to activities in Strategic Planning (e.g., identify desired business capabilities), EA (e.g.,
Business Reference Models, Service Component Based Architecture), and in many facets of
Requirements Engineering (e.g., develop a CONOPS, BIA, ORD, use cases, prototyping).
• HFE should be considered in all design activities. Several standards and other resources are
available to guide designers in this area:
– ANSI/HFS 100-1988, published by the Human Factors and Ergonomics Society (HFES):
American National Standard for Human Factors Engineering of Visual Display Terminal
Workstations
– ISO 9241-Parts 1-17:1997 Ergonomic requirements for office work with visual display terminals
– ISO 9241-110:2006 Ergonomics of human-system interaction
– ISO 13407:1999 Human-centered design processes for interactive systems
– ISO/TR 16982:2002 Ergonomics of human-system interaction – Usability methods supporting
human-centered design
– ISO/TR 18529:2000 Ergonomics – Ergonomics of human-system interaction – Human-centered
lifecycle process descriptions
34
US-VISIT Human Factors Engineering Plan, May 19th, 2006, USVISIT-APMO-CONTHSSCHQ04D0096T004-
PLN060150-D
35
Note that Fitness of Duty requirements do not preclude Section 508 compliance.
36
IEC, International Engineering Consortium; http://www.iec.org/online/tutorials/hmi/topic05.html
B2.11.1 Definition
In 1998, Congress amended the Rehabilitation Act to require Federal agencies to make their Electronic
and Information Technology (EIT) accessible to people with disabilities. Inaccessible technology
interferes with an individual's ability to obtain and use information quickly and easily. Section 508 was
enacted to eliminate barriers in IT, to make available opportunities for people with disabilities, and to
encourage development of technologies that will help achieve these goals. The law applies to all Federal
agencies when they develop, procure, maintain, or use electronic and information technology. Under
Section 508 of the Rehabilitation Act, as amended by the Workforce Investment Act of 1998 (P.L. 105-
220), agencies must give disabled employees and members of the public access to information that is
comparable to the access available to others. 37
B2.11.2 Benefits
The following are benefits of complying with Section 508:
B2.11.3 Considerations
• Each project must engage the DHS Office on Accessible Systems and Technology (OAST) or the
Component Section 508 Coordinator to ensure that it is compliant with all DHS accessibility
requirements. Accessibility reviews may require the project to prepare a plan of remediation and
additional project requirements.
• All DHS IT system development efforts must address Section 508 requirements throughout the life
cycle. Each project must have a Section 508 EIT Accessibility Plan to define its approach to meeting
Section 508 requirements.
• DHS considers accessibility to EIT a priority for all employees and external customers, including
those with disabilities. MD 4010 established OAST within the OCIO and indirectly within the Office of
Civil Rights and Civil Liberties as well as policy regarding EIT accessibility for DHS employees and
customers with disabilities. 38
• Section 508 requirements apply to all DHS Components and to all EIT developed, procured,
maintained, or used by DHS Components. Additional guidance for accessibility is provided by
numerous Public Laws, regulations, and OMB circulars, and directives:
– The Homeland Security Act of 2002, P.L. 107-296 (November 25, 2002), Section 102
– Section 508 of the Rehabilitation Act of 1973, as amended in the Workforce (65 FR 80500,
December 21, 2000; 66 FR 20894, April 25, 2001)
– Electronic and Information Technology (EIT) Accessibility Standards (36 CFR part 1194)
– Federal Acquisition Regulations (FAR) – Subpart 39.2 – Electronic and Information Technology
– OMB Circular A-130, Management of Federal Information Resources (61 FR 6428, February 20,
1996)
37
Federal Section 508 website,http://www.Section508.gov.
38
Department of Homeland Security MD 4010, Section 508 Program Management Office & Electronic and
Information Technology Accessibility
B2.12.1 Definition
Risk management is a process, applied on a continuous basis throughout the SELC, with the objective of
providing a repeatable process for balancing cost, schedule, and performance goals within program
funding. The process is made up of:
• Risk Identification
• Risk Analysis
• Risk Mitigation Planning
• Risk Mitigation Plan Implementation
• Risk Tracking
B2.12.2 Benefits
A properly structured and administered risk management practice will generally help to ensure a
successful acquisition program with the following benefits:
• The ability to anticipate risks before they become issues because of a planned risk management
process integral to the acquisition process, especially to the technical planning processes
• Continuous, event-driven technical reviews to help define risk areas to meet users’ needs within
acceptable risk
• An independent risk perspective because the risk management practice is independent of the Project
Manager
• A defined set of success criteria for performance, schedule, and cost elements
B2.12.3 Considerations
Risks have three components:
39
Price, Gordon, Software Testing Terminology, from http://www.stsc.hill.af.mil/crosstalk/1994/07/xt94d07l.asp.
Original citation credited to IEEE 729/610.12, Glossary of Software Engineering Terminology, New York, 1990.
logistics, system safety and mishap prevention, and requirements definition. It establishes a process that
ensures achieving program objectives for cost, schedule, and performance. That is, risk management is a
primary practice used to ensure that the program is not a failure.
B2.13.1 Definition
Independent Verification and Validation (IV&V) is a specific certification practice. Commonly, IV&V is
performed by an individual or organization that is technically, managerially, and financially independent of
the development organization. 40
B2.13.2 Benefits
• The independent nature of IV&V provides management with insight into the project without conflict of
interest.
• IV&V provides the opportunity for more effective decision making affecting project direction.
B2.13.3 Considerations
The objectives of IV&V are to: 41
• Verifying requirements: Proving that each requirement has been satisfied. Verification can be done
by logical argument, inspection, modeling, simulation, analysis, expert review, test, or demonstration.
• Validating requirements: Ensuring that (1) the set of requirements is correct, complete, and
consistent; (2) a model can be created that satisfies the requirements; and (3) a real-world solution
can be built and tested to prove that it satisfies the requirements.
40
Price, Gordon, Software Testing Terminology, from http://www.stsc.hill.af.mil/crosstalk/1994/07/xt94d07l.asp.
Original citation credited to IEEE 729/610.12, Glossary of Software Engineering Terminology, New York, 1990
41
IEEE, Draft Standard for Software Verification and Validation, IEEE P1012/D12, September 12, 2004, p3.
• Verifying a system: Building the system right: ensuring that the system complies with the system
requirements and conforms to its design.
• Validating a system: Building the right system: making sure that the system does what it is
supposed to do in its intended environment. Validation determines the correctness and completeness
of the end product, and ensures that the system will satisfy the actual needs of the stakeholders.
The requirement for IV&V may be placed on a high risk program by Congress as a condition of release of
funds. When this occurs, the CIO is typically required to certify that the program has an IV&V contract in
place. The DHS CIO provides this certification upon review of supporting documentation from the
program. Certification is based on the following criteria:
• An IV&V contract is in place that includes the subject program within the scope.
• The contractor’s IV&V approach meets IEEE 1012 standards.
• The contractor’s IV&V approach ensures that items are completed and are of sufficient quality and
that all outcomes will meet the needs of the user.
• The contractor’s IV&V technical approach is developed for all the necessary IV&V activities.
• The contractor’s IV&V technical approach identifies a strategy or method for determining which
activities will need to be conducted, how those activities will be performed, and when those activities
will be conducted.
B2.14.1 Definition
National Archives and Record Administration (NARA) regulations affecting Federal agencies and their
records management programs are found in Subchapter B of 36 Code of Federal Regulations Chapter
XII. Part 1234
establishes the basic requirements related to the creation, maintenance, use, and disposition of
electronic records. Electronic records include numeric, graphic, and text information, which may
be recorded on any medium capable of being read by a computer and which satisfies the
definition of a record. This includes, but is not limited to, magnetic media, such as tapes and
disks, and optical disks. Unless otherwise noted, these requirements apply to all electronic
information systems, whether on microcomputers, minicomputers, or main-frame computers,
regardless of storage media, in network or stand-alone configurations. This part also covers
creation, maintenance and use, and disposition of Federal records created by individuals using
electronic mail applications. 42
NARA regulations applicable to electronic records management must be considered by Project Managers
throughout all phases of the SELC. Additional resources and guidance are available at
http://www.archives.gov/records-mgmt/.
B2.14.2 Benefits
According to information from the NARA Records Management website, electronic records management:
• Contributes to the smooth operation of an agency’s acquisitions by making the information needed for
decision making and operations readily available
• Helps deliver services in a consistent and equitable manner
• Facilitates effective performance of activities throughout an agency
42
http://www.archives.gov/records-mgmt/policy/guidance-regulations.html
• Protects the rights of the agency, its employees, and its customers
• Provides continuity in the event of a disaster
• Protects records from inappropriate and unauthorized access
• Meets statutory and regulatory requirements, including archival, audit, and oversight activities
• Provides protection and support in litigation
B2.14.3 Considerations
The Records Management (RM) Profile 43 recommends that agencies embed records management
requirements in the earliest stages of the SELC. For more information, contact the DHS records
management point of contact at NARA at http://www.archives.gov/recordsmgmt/appraisal/work-group-
all.html. Table B2-3 provides a checklist that Project Managers can use to integrate records management
into the SELC stages.
43
Refer to Federal Enterprise Records Management Profile, Sections 4.1.1 through 4.1.6;
http://www.archives.gov/records-mgmt/policy/rm-profile.html.
B2.15.4 Stage 4 - NIEM IEPD Build and Validate / Assemble and Document
If a NIEM IEPD is being developed in support of a inter-component or inter-agency information exchange,
NIEM IEPD lifecycle activities and products prescribed in the Build and Validate and Assemble and
Document phases should be performed in this SELC phase. Those products include:
• Want list
• XML Schemas – exchange, subset, and exchange schemas
• IEPD Metadata
• Main IEPD document including packaged IEPD products as specified in previous phases
Please contact the DHS EDMO for the current list of DHS required NIEM IEPD products and an IEPD
main document outline.
B2.16 SELC and the DHS Service Oriented Architecture (IT Only)
PMs and developers also need to consider the shift in the DHS architectural strategy from one based on
traditional development of IT systems to one based on an SOA, also referred to as Service Component
Based Architecture (SCBA). The impact of this change in strategy is that as DHS transitions to an SOA,
greater emphasis will be placed on service creation, reuse, and modification for reuse of established
service, with IT acquisitions increasingly being analyzed for compliance with SOA principles,
requirements, and technology during project authorization activities.
44
HLS-EA Target Architecture, Version 2.0, October 29, 2004.
In the new architectural environment, DHS systems will consist of a set of loosely coupled services that
will be used internally and exposed externally to other DHS applications through a service registry
mediated by the DHS Enterprise Service Bus (ESB). The requirement for communication through the
ESB does not necessarily include communication between internal components of an application (e.g.,
direct API or SQL calls). DHS SELC Guide requirements reflect DHS architectural standards as well as
those required by other enterprise life cycle processes. In its role of supporting the evolution to SOA, the
DHS SELC Guide will focus more specifically on service creation and reuse. An artifact called the Service
Reuse Plan is required as an entry criterion to the DHS SELC. This plan documents what services a
project will create, modify, or reuse. For more information on DHS’s SOA vision and plan, the DHS
Service Oriented Architecture Framework defines how DHS plans to transition to a service oriented
architecture.
• Defining, developing, and deploying new or enhanced services into the DHS SOA with the primary
purpose of supporting the needs of the sponsoring project
• Defining, developing, and deploying the new or enhanced services with a secondary purpose of
supporting the needs of other/future systems
Acquisitions are encouraged to reuse existing services. However, if the existing service must be
enhanced, it is the requesting project’s responsibility to provide the funding for the enhancement. It is
important to note that acquisitions may consist of one, multiple, or no service development efforts. The
number of tracks will depend on the number of services the project needs to create or enhance. The intent
is that the primary project will break out the smaller service development efforts into separate
(sub-)projects that can be independently managed. It is expected that all IT acquisitions will leverage and
build toward the SOA, which means placing more emphasis on service reuse. The overall structure of the
Program into a set of projects as described in the Directive 102-01 may consider SOA (sub-)projects as
projects to be managed separately for purposes of the APB and the ARP depending on the size, cost,
schedule, distinctness and interdependencies of the services to be reused/enhanced or newly built.
-- Under Development --
Table B4-1 lists the Governing Authority that represents the DHS organization or process that mandates
the development of the artifact, the associated DHS organization to contact for more information, and a
DHS website where more information can be found.
Table B4-2 depicts the SELC products and their update schedule. Each artifact is marked in the
appropriate SELC stage as Create (C), Update (U), or Finalize (F). This indicates the status of each
artifact at each SELC stage and how it should mature throughout the life cycle.
OBTAIN
ANALYZE/
PRODUCE
L
SUPPORT
DEPLOY/
SELECT
NEED
i
n
e
SELC Stages
N
Documents
Implementation
u
Requirements
Operations &
Development
Integration &
Maintenance
Engineering
Disposition
Definition
Planning
m
Solution
Design
Test
b
e
r
1 Mission Need Statement ARP (Dir C F
102-01)
2 Capability Development Plan ARP (Dir C/
(CDP) 102-01) F
3 Acquisition Plan ARP (Dir C U U U U
102-01)
4 CONOPS ARP (Dir 102-01) C/F
5 Analysis of Alternatives ARP (Dir 102-01) C/F
6 Lifecycle Cost Estimate (LCCE) ARP (Dir 102-01) C U U U
7 Operational Requirements Document (ORD) C/F
8 Integrated Logistics Support Plan (ILSP) C U
9 Acquisition Program Baseline ARP (Dir 102-01) C U U
1 Project Tailoring Plan DHS SELC C/F
0
1 Service Reuse Plan DHS SELC C U U U U U U F F
1
1 HLS EA Program Alignment DHS EA Process C U U U F F
2 Decision Request
1 Program Alignment Documentation Matrix C U U U F F
3
1 Map to Business Architecture DHS EA Process C U U U F F
4
1 Map to OCIO Portfolios DHS EA Process C U U U F F
5
1 Section 508 National Security DHS OAST C/F
6 Exception Determination
1 Critical Infrastructure Protection DHS CISO C F
7 Report
1 FIPS 199 Security Categorization DHS CISO C U
8
1 Preliminary Security Risk DHS CISO C/F
9 Assessment
2 Solution Engineering Review DHS SELC C/F
0 Approval Letter
2 Project Management Plan ARP (Dir 102-01) C U U U U U F F
1 (Includes Integrated Master
Schedule) (PMP)
2 Configuration Management Plan DHS SELC C F
OBTAIN
ANALYZE/
PRODUCE
L
SUPPORT
DEPLOY/
SELECT
NEED
i
n
e
SELC Stages
N
Documents
Implementation
u
Requirements
Operations &
Development
Integration &
Maintenance
Engineering
Disposition
Definition
Planning
m
Solution
Design
Test
b
e
r
2
2 Privacy Threshold Analysis (PTA) Privacy Office C/
3 F
2 Section 508 EIT Accessibility DHS OAST C U U U U U F F
4 Plan
2 Risk Management Plan ARP (Dir 102-01) C/
5 F
2 Quality Assurance Plan DHS SELC C/
6 F
2 Data Management Plan DHS SELC C F
7
2 Training Plan DHS SELC C/
8 F
2 Project Planning Review DHS SELC C/
9 Approval Letter F
3 Functional Requirements DHS SELC C U U U U F F
0 Document (FRD)
3 Requirements Traceability Matrix DHS SELC C U U U U F F
1 (RTM)
3 Test and Evaluation Master Plan ARP (Dir 102-01) C U F
2 (TEMP)
Developmental Test Plan (DTP) ARP (Dir 102-01 C U F
3 Security Requirements DHS CISO C U F
3 Traceability Matrix (SRTM)
3 Plan of Action & Milestone DHS CISO C U U F
4 (POA&M)
3 System Security Plan (SSP) DHS CISO C U U U F
5
3 Contingency Plan DHS CISO U F
6
3 Disaster Recovery Plan DHS SELC C U F
7
3 Security Risk Assessment (SRA) DHS CISO C U F
8
3 Security Test & Evaluation DHS CISO C F
9 (ST&E) Plan
4 Map to the Data Architecture DHS EA Process C U U F F
0
4 Map to the Business Architecture DHS EA Process C U U F F
1
OBTAIN
ANALYZE/
PRODUCE
L
SUPPORT
DEPLOY/
SELECT
NEED
i
n
e
SELC Stages
N
Documents
Implementation
u
Requirements
Operations &
Development
Integration &
Maintenance
Engineering
Disposition
Definition
Planning
m
Solution
Design
Test
b
e
r
4 Map to Technology Standards & Products C U U F F
2
4 System Definition Review DHS SELC C/F
3 Approval Letter
4 Service Level Agreements ARP (Dir 102-01) C U F F
4
4 System Requirements Document DHS SELC C U U U F F
5
4 Interconnection Security DHS CISO C/
6 Agreement (ISA) F
4 Logical Design Document DHS SELC C/
7 F
4 Data Architecture Document DHS SELC C/
8 F
4 System Design Document DHS SELC C U U F
9
5 Technology Insertion Decision Request C/
0 F
5 Site Prep Plan DHS SELC C/
1 F
5 Deployment Plan DHS SELC C/
2 F
5 Critical Design Review Approval DHS SELC C/
3 Letter F
5 Training Materials DHS SELC C/
4 F
5 Test Case Specification DHS SELC C/
5 F
5 System Acceptance Test DHS SELC C/
6 Procedures F
5 Test Readiness Review Approval DHS SELC C/
7 Letter F
5 Operators Manuals DHS SELC C F
8
5 Maintenance Manuals DHS SELC C F
9
6 User Manuals DHS SELC C F
0
6 System Test Report DHS SELC C/F
OBTAIN
ANALYZE/
PRODUCE
L
SUPPORT
DEPLOY/
SELECT
NEED
i
n
e
SELC Stages
N
Documents
Implementation
u
Requirements
Operations &
Development
Integration &
Maintenance
Engineering
Disposition
Definition
Planning
m
Solution
Design
Test
b
e
r
1
6 Acceptance Test Report DHS SELC C/F
2
6 Section 508 Assistive Technology C/F
3 Interoperability Test Report
6 Service Insertion Package (SIP) DHS EA Process C U F F
4
6 Security Assessment Report DHS CISO C/F
5 (SAR)
6 Security Accreditation package DHS CISO C/F
6
6 Privacy Impact Assessment (PIA) Privacy Office C/F
7
6 DHS Periodic Reporting CPIC C U U U
8
6 Production Readiness Review DHS SELC C/F
9 Approval Letter
7 Pilot Results Report IRP (MD 1400) C/
0 F
7 Follow on Test Results IRP (MD 1400) C/
1 F
7 Version Description Document DHS SELC C/
2 F
7 Transition To Support Document DHS SELC C/
3 F
7 Critical Infrastructure Protection CIP C/
4 Report F
7 System of Record Notice (SORN) DHS Privacy C/
5 F
7 Authority To Operate (ATO) DHS CISO C/
6 Letter F
7 Operational Readiness Review DHS SELC C/
7 Approval Letter F
7 Performance Reports IRP (MD 1400) U U
8
7 Post Implementation Review (PIR) Results U U
9
8 Disposal Plan DHS SELC C/F C/
0 F
OBTAIN
ANALYZE/
PRODUCE
L
SUPPORT
DEPLOY/
SELECT
NEED
i
n
e
SELC Stages
N
Documents
Implementation
u
Requirements
Operations &
Development
Integration &
Maintenance
Engineering
Disposition
Definition
Planning
m
Solution
Design
Test
b
e
r
8 DHS Periodic Reporting CPIC U U
1
8 Operational Analyses CPIC U U
2
8 Lessons Learned CPIC U U
3
8 FISMA metrics reports DHS CISO U U
4
8 Security Incident reports DHS CISO U U
5
8 C&A Updates (every 3 years or when major U U
6 change is made)
8 Privacy Documentation (updated for systems U U
7 decommissioned)
8 Disposition Approval Request DHS SELC C/
8 F
8 Disposition Plan DHS SELC C/
9 F
9 Archived Data DHS SELC C/
0 F
9 Archived System DHS SELC C/
1 F
PM Project Manager
PMBOK Project Management Body of Knowledge
PMI Project Management Institute
PMO Project Management Office
PMP Project Management Plan, Project Management Professional
POA&M Plan of Action and Milestones
PPBE Planning, Programming, Budgeting and Execution
PPR Project Planning Review
PRR Production Readiness Review
PTA Privacy Threshold Assessment
QA Quality Assurance
RA Risk Assessment
RAD Rapid Application Development
RAP Resource Allocation Plan
RTM Requirements Traceability Matrix
SAR Security Assessment Report
SBU Sensitive But Unclassified
SCBA Services and Components Based Architectures
SDLC System Development Life Cycle
SDR System Definition Review
SEI Software Engineering Institute
SIP Service Insertion Package
SLA Service Level Agreement
SELC Systems Engineering Life Cycle
SME Subject Matter Expert
SO System Owner
SOA Service Oriented Architecture
SORN System of Records Notice
SP Standards Profile
SQL Structured Query Language
SRA Security Risk Assessment
SRD System Requirements Document
SRM Service Reference Model
SRTM Security Requirements Traceability Matrix
SSP System Security Plan
ST&E Security Test and Evaluation
TEMP Test and Evaluation Master Plan
TI Technical Insertion
TRR Test Readiness Review
U Update
U.S.C. U.S. Code
URL Uniform Resource Locator
V&V Validation and Verification
VDD Version Description Document
WBS Work Breakdown Structure
Attachment B6 - Glossary
Baseline Goals Baseline cost, schedule, and performance goals are the standard against which
actual work is measured. They are the basis for the annual report to the Congress
required by the Federal Acquisition Streamlining Act Title V on variances of 10
percent or more from cost and schedule goals and any deviation from
performance goals. OMB must approve the goals and any changes to the goals.
The baseline cost and schedule goals should be realistic projections of total cost,
total time to complete the project, and interim cost and schedule goals. The interim
cost and schedule goals should be based on the value of work performed or a
comparable concept. The performance goals should be realistic assessments of
what the acquisition is intended to accomplish, expressed in quantitative terms if
possible.
Business Continuity Per National Institute of Standards and Technology (NIST) SP 800-34: “The
Planning (BCP) documentation of a predetermined set of instructions or procedures that describe
how an organization’s business functions will be sustained during and after a
significant disruption.”
Business Reference Per OMB Circular A-11, Business Reference Model (BRM) is a function-driven
Model framework used to describe the lines of business and sub-functions performed by
the Federal Government independent of the agencies performing them. IT
investments are mapped to the BRM to identify collaboration opportunities.
Business A requirement that outlines the procedures and information flows, the proposed
Requirement changes to those procedures, the user’s assessment of information needs, a
preliminary description of the desired system, and an outline of the user’s
acceptance requirements.
Capital Planning and A decision-making process for ensuring that investments integrate strategic
Investment Control planning, architecture, security, budgeting, procurement, and the management of
the investment in support of agency missions and business needs. The term
comes from the Clinger-Cohen Act of 1996; while originally focused on IT, it now
applies also to non-IT investments (OMB Circular No. A-11).
Certification and Per OMB Circular A-11, Certification and Accreditation (C&A) is a comprehensive
Accreditation assessment of the management, operational, and technical security controls in an
information system, made in support of security accreditation, to determine the
extent to which the controls are implemented correctly, operating as intended, and
producing the desired outcome with respect to meeting the security requirements
of the system.
Component All the entities that directly report to the Office of the Secretary, which includes the
(organizational) Secretary, Deputy Secretary and his or her staff, Chief of Staff and his or her staff,
and Counselors and their staff. See Management Directive 0010.2.
Component (as An independently deployable unit of software that exposes its functionality through
related to services) a set of services accessed via well-defined interfaces. A component is based on a
component standard, is described by a specification, and has an implementation.
Components can be assembled to create applications or larger-grained
components. (Per SCBA)
Component Based An architecture process that enables the design of enterprise solutions using pre-
Architecture manufactured components. The focus of the architecture may be a specific project
or the entire enterprise. This architecture provides a plan of what needs to be built
and an overview of what has been built already. (Per SCBA. v3.5)
Evaluate Phase Capital planning phase that requires information technology investments to be
reviewed once they are operational to determine whether the investments meet
expectations.
Evaluation A systematic determination of the extent to which an entity meets its specified
criteria. (Per ISO/IEC 12207)
Environment (1) The natural conditions (weather, climate, ocean conditions, terrain, vegetation,
dust, etc.) and induced conditions (electromagnetic interference, heat, vibration,
etc.) that constrain the design definitions for end products and their enabling
products.
(2) External factors affecting an enterprise or project.
(3) External factors affecting development tools, methods, or processes. (Per
ANSI/EIA-632-1998)
Exhibit 300 Business Exhibit 300 business cases are also referred to as capital asset plans. They are
Case required by OMB Circular A-11 and provide budget justification and reporting
requirements for investments. They provide agencies with the format to report on
the budgeting, acquisition, and management of federal capital assets.
Exhibit 53 Exhibit 53s are also referred to as agency IT investment portfolios. They are
required by OMB Circular A-11 and provide summary budget information for all
agency major and non-major IT investments.
Exit Criteria (per Project-specific accomplishments that must be demonstrated satisfactorily before a
Directive 102-01) project can either progress further in the current acquisition phase or transition to
the next acquisition phase. Exit criteria are normally selected to track progress in
important technical, schedule, or management risk areas. Exit criteria shall serve as
gates that, when successfully passed or exited, demonstrate that the project is on
track to achieve its final goals and should be allowed to continue with additional
activities within an acquisition phase or be considered for continuation into the next
acquisition phase. Exit criteria include some level of demonstrated performance
outcome (e.g., level of engine thrust), the accomplishment of some process at
some level of efficiency (e.g., manufacturing yield), the successful accomplishment
of some event (e.g., first flight), or some other criterion (e.g., establishment of a
training program or inclusion of a particular clause in the follow on contract) that
indicates that the particular aspect of the project is progressing satisfactorily.
Federal Enterprise Federal Enterprise Architecture (FEA) is a business-based framework for
Architecture government-wide improvement. It describes the relationship between business
functions and the technologies and information supporting them. The FEA is being
constructed through a collection of interrelated “reference models” designed to
facilitate cross-agency analysis and the identification of duplicative investments,
gaps, and opportunities for collaboration within and across federal agencies. More
information about the FEA reference models is available at http://www.egov.gov.
Financial System Per OMB Circular A-127, the term “financial system” means an information
system, comprised of one or more applications, that is used for any of the
following:
• collecting, processing, maintaining, transmitting, and reporting data about
financial events;
• supporting financial planning or budgeting activities;
• accumulating and reporting cost information; or
• supporting the preparation of financial statements.
Functional A requirement that defines what system products must do and their desired
Requirement behavior in terms of an effect produced, or an action or service to be performed.
(Per ANSI/EIA-632-1998)
Independent Verification and Validation processes performed by an organization with a
Verification and specified degree of technical, managerial, and financial independence from the
Validation (IV&V) development organization. (Per IEEE Std 1012-1988)
Information Security’ Per FISMA, the term “information security” means protecting information and
information systems from unauthorized access, use, disclosure, disruption,
modification, or destruction in order to provide:
(A) Integrity, which means guarding against improper information modification or
destruction, and includes ensuring information non-repudiation and authenticity;
(B) Confidentiality, which means preserving authorized restrictions on access and
disclosure, including means for protecting personal privacy and proprietary
information; and
(C) Availability, which means ensuring timely and reliable access to and use of
information.
Information System Per OMB Circular A-130: The term “information system” means a discrete set of
information resources organized for the collection, processing, maintenance,
transmission, and dissemination of information, in accordance with defined
procedures, whether automated or manual.
Information Any equipment or interconnected system(s) or subsystem(s) of
Technology equipment/software, or any national security system, that is used in the automatic
acquisition, storage, manipulation, management, movement, control, display
(including geospatial technologies), switching, interchange, transmission (wired or
wireless telecommunications), or reception of data, voice, video, or information by
an executive agency. For purposes of this definition, equipment is used by DHS if
the equipment is used by DHS directly or is used by DHS organizational partners
(including other federal agencies, state and local governments and private
contractors) under a contract with DHS which (a) requires the use, to a significant
extent, of such equipment in the performance of a service or the furnishing of a
product. The term IT includes computers; ancillary equipment (including imaging
peripherals, input, output, and storage devices necessary for security and
surveillance); peripheral equipment designed to be controlled by the central
processing unit of a computer, software; firmware and similar procedures; services
(including support services); and related resources. The term IT does not include
any equipment that is acquired by a contractor incidental to a contract or any
equipment that contains imbedded IT that is used as an integral part of the
product, but the principal function of which is not the acquisition, storage, analysis,
evaluation, manipulation, management, movement, control, display, switching,
interchange, transmission, or reception of data or information. For example,
heating, ventilation, and air conditioning equipment, such as thermostats or
temperature control devices, and medical equipment for which IT is integral to
operation, are not IT [Federal Acquisition Regulation 2.101]. The EAB will review
all IT investments, including any investments categorized as non-IT on the E300
but that contain IT components.
Integrated Project A multi-disciplinary team led by a PM responsible and accountable for planning,
Team budgeting, procurement and life-cycle management of the investment to achieve
its cost, schedule and performance goals. Team skills include budgetary, financial,
capital planning, procurement, user, program, architecture, earned value
management, security, and other staff as appropriate. An IPT may include
members from both government (including a contracting officer) and industry, after
award.
Integration Testing An orderly progression of testing of incremental pieces of the software program in
which software elements, hardware elements, or both are combined and tested
until the entire system has been integrated to show compliance with the program
design, and capabilities and requirements of the system. (Per IEEE Std 1012-
1988)
Integrity Per FIPS Publication 199, the term “integrity” refers to guarding against improper
information modification or destruction, and includes ensuring information non-
repudiation and authenticity. [44 U.S.C., SEC. 3542]
Interoperability Ability of systems, personnel, and equipment to provide and receive functionality,
data, information, and/or services to and from other systems, personnel, and
equipment, between both public and private agencies, departments, and other
organizations, in a manner enabling them to operate effectively together.
Investment DHS cost, outlays or expenditure to achieve goals and objectives that results in
the acquisition and/or sustainment of a needed capability (including processes) for
furthering the DHS mission. Examples of investments are expenditures for
personnel, research and development (R&D), capital assets, information
technology (IT), service, operational and maintenance, and decommissioning and
disposal of replaced systems. Investment decisions are a balance of requirements,
risks, and funding. Investment decisions spur and guide acquisition and
contracting decisions and baselines. DHS has categorized major investments as
Levels 1 and 2 and Level 3 IT.
Interoperability Per the E-Government Act of 2002, the term “interoperability” means the ability of
different operating and software systems, applications, and services to
communicate and exchange data in an accurate, effective, and consistent manner.
Life Cycle Cost The total cost to the Federal government of acquiring, operating, supporting, and,
if applicable, disposing of the items being acquired [FAR 7.101]; the sum of all
costs over the useful life of a building, system, or product; the sum total of the
direct, indirect, recurring, nonrecurring, and other related costs incurred or
estimated to be incurred in the design, development, production, operation,
maintenance, support, and final disposition of a major system over its anticipated
useful life span and salvage (resale) value, if any [FAR 52.248-2(b)]. Where
system or project planning anticipates the use of existing sites or facilities,
restoration and refurbishment costs should be included [OMB Circular A-94,
Appendix A].
Life Cycle Model A framework containing the processes, activities, and activities involved in the
development, operation, and maintenance of a software product, spanning the life
of the system from the definition of its requirements to the termination of its use.
(Per ISO/IEC 12207)
Logical Data Model A graphical representation of the information requirements of a business area at a
(LDM) more granular level than a Conceptual Data Model and includes data objects and
their interrelationships. The Logical Data Model contains objects and elements
expressed in business terms and is the basis for developing physical data models.
Major Information Per OMB Circular A-130, the term “major information system” means an
System information system that requires special management attention because of its
importance to an agency mission; its high development, operating, or maintenance
costs; or its significant role in the administration of agency programs, finances,
property, or other resources.
Major Investment At DHS, major investments include all Level 1 and 2 investments, as well as Level
3 IT investments in accordance with the investment thresholds defined in Directive
102-01.
Metadata The information that is stored as the description of a unique piece of data and all
the properties associated with it.
Monitoring An examination of the status of the activities of a supplier and of their results by
the acquirer or a third party. (Per ISO/IEC 12207)
National Information A Federal, State, Local and Tribal interagency initiative providing a foundation for
Exchange Model seamless information exchange. It leverages the data exchange standards efforts
(NIEM) successfully implemented by the Global Justice Information Sharing Initiative
(Global) and extends the Global Justice XML Data Model (GJXDM) to facilitate
timely, secure information sharing across the whole of the justice, public safety,
emergency and disaster management, intelligence, and homeland security
enterprise. NIEM was launched on February 28, 2005, through a partnership
agreement between the U.S. Department of Justice (DOJ) and the U.S.
Department of Homeland Security (DHS) and signed by Chief Information Officers.
National Security Per OMB Circular A-130, the term “national security system” means any
System telecommunications or information system operated by the United States
Government, the function, operation, or use of which (1) involves intelligence
activities; (2) involves cryptologic activities related to national security; (3) involves
command and control of military forces; (4) involves equipment that is an integral
part of a weapon or weapons system; or (5) is critical to the direct fulfillment of
military or intelligence missions, but excluding any system that is to be
administrative and business applications (including payroll, finance, logistics, and
personnel management applications).
Non-Functional Non-functional requirements are requirements which specify criteria that can be
Requirement used to judge the operation of a system, rather than specific behaviors. This
should be contrasted with functional requirements that specify specific behavior or
functions. Typical non-functional requirements are reliability, scalability, availability,
and cost.
Operational Per OMB Circular, A-11, operational (steady state) means an asset or a part of an
asset with a delivered component performing the mission.
Operational Analysis Operational analysis is a method of examining the ongoing performance of an
operating asset investment and measuring that performance against an
established set of cost, schedule, and performance goals. An operational analysis
is, by nature, less structured than performance reporting methods applied to
developmental projects and should trigger considerations of how the investment's
objectives could be better met, how costs could be reduced, and whether the
organization should continue performing a particular function. [OMB Circular A-11]
Basically, operational analysis is used to examine whether an investment in
Operations and Maintenance still meets its intended objectives and yields
expected benefits. See the DHS Operational Analysis Guidance for more
information.
Operational Scenario A sequence of events expected during operation of system products. Includes the
environmental conditions and usage rates as well as expected stimuli (inputs) and
responses (outputs). (Per ANSI/EIA-632-1998)
Operational Test The field test performed under realistic conditions, overseen and evaluated by an
activity independent from the agency developer and user organizations, of any
system or key component of a system for the purposes of determining the
effectiveness and suitability of that system or component when used by typical
users in the expected operating environment.
Periodic Reporting A DHS reporting process for major investments that establishes communication
among investment Program Managers, DHS Component senior leadership, and
DHS oversight entities regarding the health and status of major DHS investments.
The information provided via Periodic Reporting enables DHS to provide oversight
and to ensure compliance with Department and OMB requirements, along with
preparing required reports related to the OMB Information Technology High Risk
Template and the President’s Management Agenda e-Government initiative.
Performance A requirement that defines how well the system products are required to perform a
Requirement function, along with the conditions under which the function is performed. (Per
ANSI/EIA-632-1998)
Personally Identifiable The term “personally identifiable information” or “PII” means any information that
Information permits the identity of an individual to be directly or indirectly inferred, including
any other information which is linked or linkable to that individual regardless of
whether the individual is a U.S. Citizen, Legal Permanent Resident, or a visitor to
the U.S.
Physical Data Model A representation of a data design which takes into account the facilities and
(PDM) constraints of a given database management system. It is typically derived from
the Logical Data Model and may include all the database products required to
create relationships between tables or achieve performance goals, such as
indexes, constraint definitions, linking tables, partitioned tables or clusters. At this
level, the data modeler specifies how the logical data model will be realized in the
database schema (Conceptual, Logical, and Physical Data Models).
Planning Preparing, developing or acquiring the information used to: design the investment;
assess the benefits, risks, and risk-adjusted life-cycle costs of alternative solutions;
and establish realistic cost, schedule, and performance goals, for the selected
alternative, before either proceeding to full acquisition of the capital project
(investment) or useful segment or terminating the investment. Planning must
progress to the point where the project is ready to commit to achieving specific
goals for the completion of the acquisition before preceding to the acquisition
phase. Information gathering activities may include market research of available
solutions, architectural drawings, geological studies, engineering and design
studies, and prototypes. Planning is a useful segment of a capital project
(investment). Depending on the nature of the investment, one or more planning
segments may be necessary.
Plan of Action and As defined in OMB Memorandum 02-01, a plan of action and milestones
Milestones (POA&M), also referred to as a corrective action plan, is a tool that identifies
activities that need to be accomplished. It details resources required to accomplish
the elements of the plan, any milestones in meeting the task, and scheduled
completion dates for the milestones. The purpose of the POA&M is to assist
agencies in identifying, assessing, prioritizing, and monitoring the progress of
corrective efforts for security weaknesses found in programs and systems.
Portfolio Management The management of broad categories of investments linked by their relationship to
the mission to ensure effective performance, correspondence to the DHS EA,
minimization of overlapping functions, and proper funding.
Post-Implementation Evaluation of the investment after it has been fully implemented or terminated to
Review determine whether the targeted outcome (e.g., performance measures) of the
investment has been achieved.
Pre-Select Phase Capital planning phase that provides a process to assess whether information
technology investments support strategic and mission needs.
Privacy Impact Per OMB Circular A-11, Privacy Impact Assessment (PIA) is a process for
Assessment examining the risks and ramifications of using information technology to collect,
maintain and disseminate information in identifiable form from or about members
of the public, and for identifying and evaluating protections and alternative
processes to mitigate the impact to privacy of collecting such information.
Program The totality of activities directed to accomplish specific goals and objectives, which
may provide new or improved capabilities in response to approved requirements
and/or sustain existing capabilities, and which may have multiple projects to obtain
specific capability requirements or capital assets. A Program is funded by one or
more Investments.
Program Manager The responsible agency customer, who, with significant discretional authority, is
uniquely empowered to make final scope-of-work, capital-investment, and
performance acceptability decisions and who is responsible for accomplishing
program objectives or production requirements through the acquisition of any mix
of in-house, contract, or reimbursable support resources. The Program Manager is
responsible for management and oversight of the IPT.
Project A planned undertaking with a definite beginning, objective and ending. A project
involves the definition, acquisition, and fielding of a unique product, service or
result in accordance with specified resources and requirements. A project may be
the whole or a part of a Program, and is funded by those Investments related to
the Program. A project is a basic building block related to a program that is
individually planned, approved, and managed. All investment elements with a start
and end date and producing a defined capability are considered projects.
Project Manager A project manager (PM) is the official assigned responsibility for accomplishing a
specifically designated unit of work effort established to achieve stated or
designated objectives, defined tasks, or other units of related effort on a schedule
and in support of the program mission. The project manager is responsible for the
planning, controlling, and reporting of the project, and for the management of a
specific function or functions, performance of the schedule, formulation of the
budget, and execution of the approved budget. The project manager works
closely with the Program Manager to ensure project objectives meet program
objectives.
Prototype A model (physical, electronic, digital, analytical, etc.) of a product built for the
purpose of a) assessing the feasibility of a new or unfamiliar technology; b)
assessing or mitigating technical risk; c) validating requirements; d) demonstrating
critical features; e) verifying a product; f) validating a product; g) determining
enabling product readiness; h) characterizing performance or product features; or
i) discovering physical principles. (Per ANSI/EIA-632-1998)
Qualification The process of demonstrating whether an entity is capable of fulfilling specified
requirements. (Per ISO/IEC 12207)
Quality Assurance All the planned and systematic activities implemented within the quality system,
and demonstrated as needed, to provide adequate confidence that an entity will
fulfill requirements for quality. (Per ISO/IEC 12207)
Registry A database providing information describing and categorizing objects, but which
does not contain the objects themselves. Registries usually provide information as
to how to access the object they describe. For example, a “Service Registry”
provides information on services. (Per SCBA, v3.5)
Release A particular version of a configuration item that is made available for a specific
purpose (for example, test release). (Per ISO/IEC 12207)
Requirement (1) Something that governs what, how well, and under what conditions a product
will achieve a given purpose.
(2) Normative elements that govern implementation of this Standard, including
certain documents such as agreements, plans, or specifications. (Per ANSI/EIA-
632-1998)
Resource Allocation The Secretary’s formal approval of Components’ RAPs. Resource Allocation
Decision Decisions set resource allocation targets for Components for the FYHSP and
become the basis for the budget.
Resource Allocation In the programming phase of the PPBE, the Components annually develop
Plan (RAP) proposed programs consistent with the IPG. These programs, expressed in the
RAP, reflect systematic allocation of resources required to achieve missions,
objectives, and priorities, and potential alternative methods of accomplishing them.
Resource requirements reflected in RAPs are translated into time-phased funding
requirements. RAPs must account for long-term requirements and resources
including human capital, construction and investments, operating and
maintenance, and potential disposal or termination costs, and program
performance goals.
Reuse Any use of a preexisting software artifact (component, specification, etc). in a
context different from that in which it was created. (Per SCBA, v3.5)
Risk Management An organized process for identifying and assessing risks and for implementing
means to avoid them or mitigate their effect if they occur. (Per ANSI/EIA-632-
1998)
Security Category Per FIPS Publication 199, the characterization of information or an information
system based on an assessment of the potential impact that a loss of
confidentiality, integrity, or availability of such information or information system
would have on organizational operations, organizational assets, or individuals.
Security Controls Per FIPS Publication 199, the term “security controls” refers to the management,
operational, and technical controls (i.e., safeguards or countermeasures)
prescribed for an information system to protect the confidentiality, integrity, and
availability of the system and its information.
Select Phase Capital planning phase used to identify all new, ongoing, and operational
investments for inclusion into the agency’s investment portfolio(s).
Service Discrete unit of functionality that can be requested (provided a set of preconditions
is met), performs one or more operations (typically applying business rules and
accessing a database), and returns a set of results to the requester. Completion of
a service always leaves business and data integrity intact. (Per SCBA, v3.5)
Service Component A self-contained business process or service with predetermined and well-defined
functionality that may be exposed through a well defined and documented
business or technology interface.
Well-designed Service Components are “loosely coupled” and collaborate primarily
by exchanging messages. (Per SCBA, v3.5)
Services and Services and Components Based Architecture (SCBA) leverages the Federal
Components Based Enterprise Architecture (FEA) and builds upon the concepts, principles, and
Architecture benefits of Service Oriented Architecture (SOA). SCBA represents a practical,
results-oriented, approach to modernizing enterprises. It is intended to help
organizations reduce long-term costs, improve quality of service, improve
information sharing, and help achieve a vision of flexible business processes
supported by customer-focused applications, which can be altered in a matter of
days instead of months. SCBA builds upon SOA principles in three ways:
(1) it is tightly integrated with the Federal Enterprise Architecture,
(2) it provides a description of what the architecture is (clarifying the varying
descriptions that exist), and
(3) it identifies the organizational, cultural, and process elements, as well as
technological elements, that need to exist for these architectures to be successful.
The most important aspect of SCBA is its focus on reuse of services and
components – better referred to as Service Components. (Per SCBA, v3.5)
Service Component Per OMB Circular A-11, Service Component Reference Model (SRM) is a common
Reference Model framework and vocabulary used for characterizing the IT and business
components collectively comprising an IT investment. The SRM helps agencies
rapidly assemble IT solutions through the sharing and re-use of business and IT
components. A component is a self-contained process, service, or IT capability
with pre-determined functionality that may be exposed through a business or
technology interface.
Service Level A contract or memorandum of agreement between a service provider and a
Agreement (SLA) customer that specifies, usually in measurable terms, what services the service
provider will furnish. Information technology departments in major enterprises have
adopted the idea of writing a service level agreement so that services for their
customers (users in other departments within the enterprise) can be measured,
justified, and perhaps compared with those of external (sourcing) service
providers. (Per SCBA, v3.5)
Service Oriented (1) Architecture that describes an entity (e.g., application or enterprise) as a set of
Architecture interdependent services. SOA provides for reuse of existing services and the rapid
deployment of new business capabilities based on exploiting existing assets.
(2) Representation of a system where the functionality is provided as a set of
services called by other parts of the system.
(3) Policies, practices and frameworks that enable application functionality to be
provided and requested as sets of services published at a granularity relevant to
the service Requestor, which are abstracted away from the implementation using a
single, standards based form of interface. (Per SCBA, v3.5)
Specification A document that contains specified requirements for a product and the means to
be used to determine that the product satisfies these requirements. (Per ANSI/EIA-
632-1998)
Stage A period within the life cycle of an entity that relates to the state of its description
or realization. (Per IEEE P15288/CD1)
Stakeholder An individual or organization having a right, share, claim, or interest in a system or
in its possession of characteristics that meet their needs and expectations. (Per
IEEE P15288/CD1)
Standard A document that establishes engineering and technical requirements for products,
processes, procedures, practices, and methods that have been decreed by
authority or adopted by consensus. (Per ANSI/EIA-632-1998)
Steady State An asset or part of an asset that has been delivered and is performing the mission.
The steady state phase may also be termed “operational.”
Subsystem A grouping of items that perform a set of functions within a particular end product.
(Per ANSI/EIA-632-1998)
System An aggregation of end products enabling products to achieve a given purpose.
(Per ANSI/EIA-632-1998)
System Of Records Per OMB Circular A-11, System Of Records Notice (SORN) means a statement
Notice providing to the public notice of the existence and character of a group of any
records under the control of any agency from which information is retrieved by the
name of the individual or by some identifying number, symbol, or other identifying
particular assigned to the individual. The Privacy Act of 1974 requires this notice to
be published in the Federal Register upon establishment or substantive revision of
the system, and establishes what information about the system must be included.
System Requirement A requirement derived from one or more functional requirements and stated in
technical terms. (Per ANSI/EIA-632-1998)
System Testing The activities of testing an integrated hardware and software system to verify and
validate whether the system meets its original objectives. (Per IEEE Std 1012-
1988)
Test Case Documentation that specifies inputs, predicted results, and a set of execution
conditions for a test item. (Per IEEE Std 1012-1988)
Test Plan Documentation that specifies the scope, approach, resources, and schedule of
intended testing activities. (Per IEEE Std 1012-1988)
Total Acquisition Cost All costs for acquiring, by contract, interagency agreement (IA), and/or other
funding instruments, supplies and/or services for a designated investment through
purchase or lease, whether the supplies are already in existence or must be
created, developed, demonstrated, and evaluated, and without regard to the
type(s) of funds used, whether appropriated or non-appropriated. Service
contracts that are part of the investment must be considered part of the total
acquisition cost.
Traceability The ability to identify the relationship between various products of the development
process, i.e., the lineage of requirements, the relationship between a design
decision and the affected requirements and design features, the assignment of
requirements to design features, the relationship of test results to the original
source of requirements. (Per ANSI/EIA-632-1998)
Trade-Off Decision-making actions that select from various requirements and alternative
solutions on the basis of net benefit to the stakeholders. (Per IEEE P15288/CD1)
Use Case A use case is a technique for capturing functional requirements of business
systems and, potentially, of an IT system to support the business system.
The use case model uses “Actors” and “use cases.” An Actor is the representation
of a person or system which exists outside the system under study and who (or
which) performs a sequence of activities in a dialogue with the system.
A Use Case represents a single interaction between a primary actor (who initiates
the interaction) and other (secondary) actors, and the system itself. The interaction
is presented as a sequence of simple steps.
User An individual or organization that uses the operational system to perform a specific
function. (Per ISO/IEC 12207)
Unit Testing Testing performed by the Development Team during the Development Stage
(Stage 4) to verify the code or changes to the code within a particular module or
subroutine. This is the lowest level of testing that can be done on a code module
or unit.
Validation Confirmation by examination and provision of objective evidence that specified
requirements have been fulfilled. (Per ISO/IEC 12207)
Verification Confirmation, through the provision of objective evidence, that specified
requirements are well defined. (Per IEEE P15288/CD1)
Attachment B7 - References
1. DHS Privacy Impact Assessments: The Privacy Office Official Guidance, March 2006.
2. DHS ISSM Guide to the DHS Information Security Program, Version 2.0, July 19, 2004.
3. DHS ISSO Guide to the DHS Information Security Program, Version 0.6, July 26, 2004.
4. DHS EAB Governance Process Guide, Version 3.0, September 28, 2006.
5. HLS-EA Target Architecture, Version 2.0, October 29, 2004.
6. DHS NCSD, Security in the Software Lifecycle: Making Software Development Processes—and
Software Produced by Them—More Secure, DRAFT Version 1.1, July 2006.
7. Customs and Border Protection, Systems Engineering Life Cycle Handbook, CIS HB 5500-07B,
Version 1.0, November 9, 2006.
8. ICE System Lifecycle Management, Version 1.0, February 2005.
9. TSA, Systems Development Life Cycle Guidance Document, Version 2.0.4, July 2005.
10. U.S. Coast Guard, Office of Command, Control, Communications, Computers and Information
Technology (CG-6) System Development Life Cycle (SELC), 11 February 2005.
11. CIO Council, Services and Components Based Architectures: A Strategic Guide for Implementing
Distributed and Reusable Components and Services in the Federal Government-Chapter 1:
Executive Strategy, Version 3.5, January 31, 2006.
12. IEEE, Guide to the Software Engineering Body of Knowledge, Version 1.0, May 2001.
13. IEEE. ISO/IEC IEEE P12207/CD1: Systems and Software Engineering — Software Life Cycle
Processes, June 2006.
14. IEEE, ISO/IEC IEEE P15288/CD1: Software and Systems Engineering — Systems Engineering
Life Cycle Processes, June 2006.
15. IEEE, ISO/IEC WD 27478: Systems and software engineering — Life cycle management — Guide
for Life Cycle Management, June 2006.
16. ANSI, ANSI/EIA-632-1998: Processes for Engineering a System, January 7, 1999.
17. Information Technology Infrastructure Library (ITIL) series, 2004.
18. Department of Labor, System Development Life Cycle Management Manual, Exposure Draft,
Version 2.1, December 2002.
19. Department of Defense, DoD 5000 series policy documents, 2003.
20. National Aeronautics and Space Administration, NASA Procedures and Guidelines, NPG: 7120,
November 2002.
21. Internal Revenue Service, Enterprise Life Cycle Guide, Version 2.0, May 2006.
22. Standish Group, International, The CHAOS Report, 1995.
23. Standish Group, International, 2004 Third Quarter Research Report, 2004.
24. U.S. Patent and Trademark Office, Managed Evolutionary Development Guidebook, Second
Edition, June 1993.
25. Department of the Air Force, Software Technology Support Center, Guidelines for Successful
Acquisition and Management of Software-Intensive Systems: Weapon Systems, Command and
Control Systems, Management Information Systems, Condensed Version, February 2003.