Attachment_J.10_SELC_Guidebook_102-01-103-01.pdf

4/18/20164/18/20164/18/20164/18/20164/18/20164/18/20164/18/20160

04/18/2016 ii

TABLE OF CONTENTS

1 Overview .............................................................................................................................. - 1 -

1.1 Purpose ........................................................................................................................... - 1 -

1.2 Systems Engineering in DHS ........................................................................................ - 2 -

1.3 The Relationship of the DHS SELC to Other DHS Enterprise Governance and Decision-

Making Processes ................................................................................................................. - 11 -

2 SELC Tailoring ................................................................................................................. - 14 -

2.1 Tailoring Overview ...................................................................................................... - 14 -

2.2 When to Tailor ............................................................................................................. - 14 -

2.3 Recommended Tailoring Activities ............................................................................. - 14 -

3 Solution Engineering ........................................................................................................ - 19 -

3.1 Assumptions ................................................................................................................. - 20 -

3.2 Develop a Concept of Operations ................................................................................ - 21 -

3.3 Define Operational Requirements / Features ............................................................... - 23 -

3.4 Identify and Evaluate Potential Solution Alternatives ................................................. - 25 -

3.5 Gather/Obtain Information on Potential Solutions ...................................................... - 31 -

3.6 Assess Technical Maturity of Potential Solutions ....................................................... - 32 -

3.7 Develop Cost Estimating Baseline Document ............................................................. - 35 -

3.8 Develop Life Cycle Cost Estimate ............................................................................... - 36 -

3.9 Develop Integrated Logistics Support Strategy ........................................................... - 38 -

3.10 Refine Program Acquisition Plan .............................................................................. - 40 -

3.11 Establish Acquisition Program Baseline .................................................................... - 41 -

3.12 Create/Update Enterprise and Solution Architectures ............................................... - 42 -

3.13 Conduct Solution Engineering Review ...................................................................... - 45 -

4 Planning ............................................................................................................................. - 47 -

4.1 Assumptions ................................................................................................................. - 48 -

4.2 Develop Program Management Processes and Plans .................................................. - 48 -

4.3 Define Technical Scope ............................................................................................... - 51 -

4.4 Define Program and Project Development Methodology/ies and Tailor the SELC .... - 53 -

4.5 Identify Technical Resources and Management .......................................................... - 53 -

4.6 Develop User/Stakeholder Engagement Strategy ........................................................ - 54 -

4.7 Develop Technical Schedule ....................................................................................... - 55 -

4.8 Define Program’s Technical Management Processes .................................................. - 56 -

4.9 Identify Applicable Design Considerations ................................................................. - 59 -

4.10 Develop Test and Evaluation Master Plan ................................................................. - 65 -

4.11 Conduct Project Planning Review ............................................................................. - 66 -

5 Requirements Definition .................................................................................................. - 68 -

5.1 Assumptions ................................................................................................................. - 68 -

5.2 Identify Interfaces, Inputs, and Outputs ....................................................................... - 69 -

5.3 Develop Functional Requirements ............................................................................... - 69 -iii

5.4 Identify Non-Functional Requirements ....................................................................... - 71 -

5.5 Ensure that Requirements are Complete, Consistent, Testable, and Traceable ........... - 71 -

5.6 Establish a means to trace requirements ...................................................................... - 72 -

5.7 Technical Management Processes within Requirements Definition ............................ - 72 -

5.8 Conduct System Definition Review (or Release Planning Review) ............................ - 74 -

6 Design ................................................................................................................................. - 76 -

6.1 Assumptions ................................................................................................................. - 76 -

6.2 Define Physical Architecture ....................................................................................... - 77 -

6.3 Define System-Level Requirements ............................................................................ - 79 -

6.4 Develop Data Architecture .......................................................................................... - 82 -

6.5 Maintain System Design .............................................................................................. - 84 -

6.6 Design for Verification and Validation ....................................................................... - 86 -

6.7 Begin Developing Deployment Plan ........................................................................... - 87 -

6.8 Develop Site Preparation Plan ..................................................................................... - 88 -

6.9 Develop Service Level Agreements ............................................................................ - 90 -

6.10 Develop Technology Insertion Package .................................................................... - 92 -

6.11 Develop Interconnection Security Agreements ......................................................... - 93 -

6.12 Initiate Privacy Impact Assessment ........................................................................... - 94 -

6.13 Initiate System of Records Notice ............................................................................. - 95 -

6.14 Continue Evaluating Design Considerations ............................................................. - 96 -

6.15 Conduct Design Reviews ........................................................................................... - 96 -

6.16 Technical Management Process Activities within Design ........................................ - 98 -

7 Development .................................................................................................................... - 100 -

7.1 Assumptions ............................................................................................................... - 100 -

7.2 Finalize Detailed Subsystem/Configuration Item Specifications .............................. - 101 -

7.3 Develop a Software Development Environment ....................................................... - 101 -

7.4 Build, Construct/Assemble, Code, and Configure System ........................................ - 103 -

7.5 Develop Supporting Documentation ......................................................................... - 104 -

7.6 Technical Management Process Activities within Development ............................... - 105 -

7.7 Conduct Integration Readiness Review ..................................................................... - 106 -

8 Integration and Test ....................................................................................................... - 108 -

8.1 Assumptions ............................................................................................................... - 108 -

8.2 Define Method for V&V ............................................................................................ - 108 -

8.3 Plan for Integration .................................................................................................... - 111 -

8.4 Verification Planning ................................................................................................. - 112 -

8.5 Prepare for and Conduct Developmental Test and Evaluation of Individual Subsystems or Configuration Items ........................................................................................................ - 115 -

8.6 Prepare for and Conduct Developmental Test and Evaluation of System (or Increment to be Delivered) ....................................................................................................................... - 116 -

8.7 Conduct Acceptance Testing ..................................................................................... - 118 -

8.8 Technical Management Process Activities within Integration and Test ................... - 118 -

8.9 Conduct Production Readiness Review ..................................................................... - 120 -iv

9 Implementation ............................................................................................................... - 122 -

9.1 Assumptions ............................................................................................................... - 122 -

9.2 Obtain and Deploy Low Initial Rate Production Units (if applicable) ...................... - 122 -

9.3 Complete Site Preparation and Deployment .............................................................. - 123 -

9.4 Develop Operational Test and Evaluation Plan ......................................................... - 124 -

9.5 Conduct Operational Test Readiness Review ............................................................ - 125 -

9.6 Perform Operational Test and Evaluation ................................................................. - 126 -

9.7 Make Changes to System for Production .................................................................. - 128 -

9.8 Coordinate Changes to Corresponding Business Practices ....................................... - 128 -

9.9 Convert Existing Data for Use in the New System ................................................... - 129 -

9.10 Publish SORN and Obtain Privacy Office Affirmation ........................................... - 130 -

9.11 Obtain Authority to Operate Letter .......................................................................... - 130 -

9.12 Technical Management Process Activities within Implementation ......................... - 131 -

9.13 Conduct Operational Readiness Review .................................................................. - 132 -

10 Operations and Maintenance ....................................................................................... - 134 -

10.1 Assumptions ............................................................................................................. - 134 -

10.2 Operate System and Update System Documentation .............................................. - 134 -

10.3 Identify and Make System Enhancements ............................................................... - 136 -

10.4 Disaster Recovery Testing ....................................................................................... - 137 -

10.5 Conduct Post-Implementation Review .................................................................... - 138 -

10.6 Conduct Operational Analyses ................................................................................ - 139 -

10.7 Develop Lessons Learned ........................................................................................ - 142 -

10.8 Perform Continuous Monitoring and Security Activities ........................................ - 143 -

10.9 Technical Management Processes within Operations and Maintenance ................ - 145 -

11 Disposition ..................................................................................................................... - 147 -

11.1 Assumptions ............................................................................................................. - 148 -

11.2 Disposition and Decommissioning .......................................................................... - 148 -

11.3 Conduct Disposition Review (Recommended) ........................................................ - 149 -

Appendix A: Acronyms ........................................................................................................ - 150 -

Appendix B: SELC Artifact Matrix .................................................................................... - 155 -

Appendix C: SELC Technical Review Stakeholder Roles and Responsibilities ............. - 158 -

Appendix D: Bibliography ................................................................................................... - 162 -v

Figures

Figure 1-1: SELC Framework (with Acquisition Lifecycle Framework and Enterprise

Architecture Decisions) .............................................................................................................. - 3 - Figure 4-1: Interrelationships and Sequencing of Solution Engineering Activities ................ - 20 - Figure 6-1: Requirements Decomposition Example ................................................................ - 71 -

Tables

Table 1-1: Recommended Lead Technical Authorities………………………………………..- 8 - Table 11-1: O&M Security Monitoring, Security Updates, and Security Reporting ............ - 143 -

- 1 -

Value Added and Improvements from SELC Guidebook, version 2.0

Incorporates best practices and guidance from:

o DHS Components o Department of Defense (DOD) o National Aeronautics and

Space Administration (NASA) o International Council on

Systems Engineering

(INCOSE)

o Industry

Focuses more on performing activities and less on developing documents

Provides a clear message that programs need to engage in critical thinking

Clarifies how to tailor the SELC to be commensurate with a program’s or project’s characteristics

Contains detailed process discussions that include the steps, analysis, and artifacts that are necessary to execute a program along with related reference materials

Provides cross-references to other sections to show process linkages across activities

Shows the concurrent and dependent nature of SELC activities

Stresses early evaluation of advanced science and technology in the early phases of program definition along with continuous technology maturation and assessment

Recognizes the proliferation of IT elements and defines “embedded-IT” as IT elements within non-IT systems

1 Overview The Department of Homeland Security (DHS)

Systems Engineering Life Cycle (SELC) is a technical framework that enables consistent management and supports the efficient and effective delivery of capabilities to end users. It is flexible and can be modified, or “tailored,” to suit program characteristics and development methodology.

The SELC is established under Management Directive

(MD) 102-01-103, Systems Engineering Life Cycle, and is implemented through this Guidebook. The

SELC is applicable to all DHS programs and projects1 whose purpose is to deliver a DHS capability.2

The DHS SELC Guidebook provides a comprehensive reference guide for practitioners who are responsible for planning and executing systems engineering activities. It is written to a target audience of Program

Management Office (PMO) personnel and contains detailed discussions of systems engineering activities, artifacts, and related reference materials.

1.1 Purpose

The purpose of the SELC Guidebook is to:

Implement MD 102-01-103, Systems

Engineering Life Cycle

Provide a common understanding of the purpose, goals, objectives, and systems engineering processes at DHS

Integrate systems engineering and its principles with other programmatic and organizational processes

Strengthen the guidance promoting a systems engineering discipline and practices across

DHS

Place the relationship of the SELC framework into context with other DHS enterprise governance and decision-making processes

1 The SELC applies to all acquisition programs, regardless of their type

(e.g., capital asset, enterprise service, etc.).

2 Management Directive 102-01-103, Systems Engineering Life Cycle.

- 2 -

1.2 Systems Engineering in DHS

1.2.1 DHS SELC Framework Overview

The SELC framework is based on systems engineering best practices. It is comprised of two recommended preliminary activities, nine major activities, and a set of technical reviews. See

Figure 1-1: SELC Framework (with Acquisition Lifecycle Framework and Enterprise

Architecture Decisions), found on Page 3, for details.

The major SELC activities represent the specific activities that all programs need to consider, regardless of the program’s development methodology. Each major SELC activity has associated artifacts to record or document the results of the activities performed. SELC technical reviews are conducted to assess a program’s progress towards planned activities. Programs are required to document their specific approach for complying with the intent of the SELC activities, artifacts, and technical reviews in a program-specific SELC Tailoring Plan.3 See Section 2 for details on how to tailor the SELC.

3 MD 102-01-001, Acquisition Management Instruction/Guidebook.

- 3 -

Figure 1-1: SELC Framework (with Acquisition Lifecycle Framework and Enterprise Architecture Decisions)

Note: The philosophy of the SELC is to encourage tailoring for specific engineering needs and to accommodate all development methodologies. SELC activities may be conducted concurrently, in parallel, or sequentially, with multiple feedback loops and iterations, as appropriate. SELC technical reviews may also be combined, modified, or omitted based on a program’s specific characteristics and/or selected development methodology.

- 4 -

1.2.2 SELC Activities

This subsection provides a short description of the objectives and purpose of each of the SELC activities and the corresponding SELC technical reviews.

Note: SELC activities may be conducted concurrently, in parallel, or sequentially, with multiple feedback loops and iterations, as appropriate. The scope, content, and schedule of SELC technical reviews may vary based on a program’s chosen development methodology.

1.2.2.1 Recommended Preliminary SELC Activities

1. Technology Development: The purpose of Technology Development is to conduct research and development (R&D) to mature technologies and/or create knowledge products that can be used to close or mitigate mission gaps (that were identified during Mission Analysis).

Guidance on the transition of R&D technologies into acquisition programs is found in the supplemental guidance, DHS Technology Transition and Demonstrators.

2. Needs Analysis: This recommended activity is conducted after a capability gap has been identified. The purpose of this activity is to analyze and determine whether a materiel solution4 is necessary to close or mitigate the capability gap, or portions of it. Preliminary concepts of operations may also be developed at this point. Guidance for this activity is found in MD 102-01-001, Acquisition Mangement Instruction/Guidebook.

Initial Technical Review (ITR): Recommended review to determine whether an appropriate level of analysis was conducted, whether this analysis supports the capability gaps identified in the Mission Need Statement (MNS), and whether the Capability Development Plan (CDP) clearly reflects the next set of activities to be performed in order to address the capability gaps. The ITR directly supports the Acquisition Life Cycle Framework (ALF) Acquisition

Decision Event (ADE)-1 decision.

1.2.2.2 Major SELC Activities

1. Solution Engineering: Conducted following ALF ADE-1, the objective of Solution

Engineering is to identify, analyze, and objectively select the preferred solution alternatives via a formal Analysis of Alternatives (AOA)/Alternatives Analysis (AA) to meet the approved mission needs. In addition, key acquisition artifacts are created to prepare the program to enter the Obtain Phase of the ALF.

Study Plan Review (SPR): Conducted at the overall program level for the purpose of reviewing the ground rules and assumptions as well as the plans, scope, criteria, and methods to be used in the AOA/AA.

Solution Engineering Review (SER): Conducted towards the end of the Analyze/Select

Phase of the ALF. The SER evaluates the results of the AOA/AA and the completeness and content of related acquisition and technical artifacts to support formal program approval. The

SER directly supports the ALF ADE-2A decision.

4 Materiel solution also includes the acquisition of services.

- 5 -

2. Planning: The purpose of Planning is to create plans with the appropriate level of detail for the chosen development methodology. Facets of the program (and any projects) are analyzed to ensure that the cost, scope, and schedule are technically feasible and acceptable to stakeholders.

Project Planning Review (PPR): Assesses the feasibility of the program’s and projects’ (if any exist) schedules and scopes, along with the continuity and appropriateness of associated artifacts. The result of this review is an assessment of the program’s readiness to proceed into development/procurement of the solution. This review supports an ALF ADE-2B decision.

3. Requirements Definition: The purpose of Requirements Definition is to gather, analyze, and document functional and non-functional performance and data requirements.

System Definition Review (SDR): Focuses on the value, priority, traceability, and continuity of the functional and non-functional requirements. At this review the technical description of the system and top-level architecture is approved to establish the functional baseline for the system.

4. Design: The objective of Design is to make decisions that transform requirements into system designs and architectures in order to efficiently and effectively guide (or contract for) fabrication, assembly, and/or coding.

Preliminary Design Review (PDR): Reviews and approves the allocation of functional and non-functional requirements from the functional baseline to one or more Configuration Items

(CIs) in the physical architecture, thereby defining the allocated baseline and physical architecture for the system.

Critical Design Review (CDR): Reviews and approves the system and subsystem detailed designs to determine whether system requirements have been properly allocated, thereby establishing the developmental baseline for the system.

5. Development: The objective of Development is to build and begin testing the components, products, and functionality that make up the system/solution that will deliver the capability defined in the Operational Requirements Document (ORD) and Acquisition Program

Baseline (APB).

Integration Readiness Review (IRR): Assesses system development efforts and subsystem, component, and/or CI test results to ensure the system is ready for integration and comprehensive developmental test and evaluation (DT&E). Ensures that DT&E planning has been completed and test planning and infrastructure is adequate to support comprehensive

DT&E. If development is done by a single development contractor, by the Government directly, or in a highly integrated government and contractor team, then the IRR may not be necessary or will focus primarily on DT&E preparation and readiness.

6. Integration and Test: The primary purpose of Integration and Test is to integrate the systems, subsystems, components, and CIs that have been built and to demonstrate that the integrated system satisfies all defined requirements. Development and Integration and Test activities are highly interactive.

Production Readiness Review (PRR): Conducted to review the results of Integration and

Test to validate that the developed system meets defined requirements, and assesses system

- 6 -and manufacturing readiness for the move to limited production. This review supports an

ALF ADE-2C decision.

7. Implementation: The objective of Implementation is to prepare the system, operational environment, organization, and users for the intended use of the new solution and to conduct operational test and evaluation (OT&E) to evaluate whether the system meets mission needs and operational requirements.

Operational Test Readiness Review (OTRR): Conducted to ensure the system is ready to enter OT&E.

Operational Readiness Review (ORR): Assesses the system’s operational effectiveness and suitability. The ORR also ensures that the system possesses the required manufacturing and logistics support capabilities and capacities, and is therefore ready to be moved into production, fielding, and operation. The ORR supports an ALF ADE-3 decision.

8. Operations and Maintenance: The objective of Operations and Maintenance is to operate and maintain the system, make minor enhancements to the system, and conduct periodic reviews (e.g., security, system performance, obsolescence, and mission gaps). Operations and maintenance personnel monitor the current system, identify problems to be fixed, and identify ways to improve the system.

Post Implementation Review (PIR): Documents deployment/implementation and coordination issues, how they were resolved, and how they could be prevented in the future.

9. Disposition: The emphasis in Disposition is to ensure that the system (or parts of it), data, procedures, and documentation are packaged, archived, transferred, or disposed of in an orderly fashion. Conducting a Disposition Review (DR) is recommended. See Subsection

11.3.

1.2.3 SELC Technical Reviews

SELC technical reviews provide a mechanism for management to assess how well a program has completed planned activities and its readiness to continue to the next planned activity. The SELC supports both event-based technical reviews and periodic time-based reviews. The standard

SELC event-based technical reviews are based on pre-defined entrance and exit criteria and are shown in Figure 1-1.

The scope, content, and schedule of the standard SELC event-based technical reviews may be tailored. For example, programs/projects implementing certain development methodologies

(such as those employed in software development or facilities/construction projects) may use methodology-specific reviews in lieu of the standard SELC technical reviews as long as the program’s/project’s SELC Tailoring Plan reflects these changes. See Section 2 for a comprehensive discussion of SELC Tailoring.

SELC technical reviews include, at a minimum, the PM, Lead Technical Authority (LTA), and

Lead Business Authority (LBA). For embedded-IT programs, the LTA includes the Component

Chief Information Officer (CIO) in the SELC technical review process. The LTA and LBA are responsible for signing-off that the program has satisfied the applicable event-based SELC technical review exit criteria (or as tailored) and is ready to proceed to the next planned activity.

- 7 -

The PM is expected to coordinate, in advance, with other relevant offices (e.g., Office of

Program Accountability and Risk Management (PARM), Enterprise Business Management

Office (EBMO), Office of Systems Engineering, Office of Test and Evaluation, Office of

Accessible Systems and Technology (OAST), and the Office of the Chief Security Officer

(OCSO)) to evaluate the completion of activities and compliance with exit criteria and participate in technical reviews. The PM is also responsible for arranging, coordinating, and completing the SELC technical reviews.

Factors critical to successful SELC technical reviews include:

Satisfactory completion of all preceding activities and artifacts for each event-based technical review (if technical reviews have been tailored, then satisfactory completion of all preceding activities and artifacts, as reflected in the program’s/project’s SELC

Tailoring Plan)

Satisfactory completion of any additional criteria required by the Component Acquisition

Executive (CAE), PM, Component Systems Engineer, and/or Component CIO

Evidence clearly substantiating the fulfillment of the exit criteria for the technical review

(or as tailored in the program’s/project’s SELC Tailoring Plan). Fulfillment of exit criteria is based upon the quality and content of the evidence produced, and not simply by the evidence of the document/artifact itself.

The PM reviews any significant issues identified, assesses the impact to the program, and determines if proceeding to the next planned activity is supported by the technical review results.

At the completion of each technical review, the combined concurrence of these three stakeholders (i.e., the PM, LTA, and LBA) is documented in a technical review completion letter along with any actions taken during the technical review from the other Component and

Department participants as the formal record of the technical review.

For major5 programs, within 30 days of completing a technical review, the approved completion letter along with any updates to the program’s SELC Tailoring Plan or program management plan (including program schedule) is uploaded to the DHS program reporting system of record, Next Generation Periodic Reporting System (nPRS) or its successor. Some reviews unique to specific development methodologies may not be required to provide completion letters, or require submission to the DHS program reporting system of record within 30 days; these reviews need to be identified in the program’s SELC Tailoring Plan.

Non-major6 programs follow the intent of the SELC technical review process, but tailor the formality and size of the SELC technical reviews based on the specific needs of the program and

Component-specific policies.

The PM may also conduct periodic time-based reviews (e.g., monthly/quarterly/annual reviews), as necessary. These periodic reviews ensure that issues are being identified, discussed, and actions to resolve are initiated throughout the execution of the program/project.

5 As defined by MD 102-01-001, Acquisition Management Instruction/Guidebook.

6 Ibid.

- 8 -

See the DHS Technical Review Guide for a comprehensive discussion of the technical review process, participants, and entrance and exit criteria.

1.2.4 SELC Artifacts

SELC artifacts are the evidence of critical thinking and analysis. Programs/Projects develop a set of artifacts based on their tailored approach, as reflected in their SELC Tailoring Plans. In DHS, artifacts are evaluated based on the quality of the content, and not simply on an artifact’s mere existence or its length or format.

Appendix B contains the SELC artifact matrix. The matrix lists common artifacts used in the systems engineering life cycle and are considered the baseline for documenting tailoring efforts.

Programs are advised to first understand the purpose of each artifact and develop them accordingly and only where necessary. This list is not comprehensive, and other artifacts may be developed.

NOTE: Some acquisition artifacts are required under MD 102-01-001, Acquisition Management

Instruction/Guidebook, and may not be tailored out. These artifacts may also require approved updates due to program breaches or changes, or as part of ADEs.

1.2.5 SELC Governance and Key Players

The overall concept for SELC governance is a model whereby the PM retains responsibility for the overall outcome of the program. Oversight stakeholders participate in the technical reviews as a means to provide the PM with inputs on technical matters and to obtain information that can be used to support decision-making during ALF ADEs.

The primary oversight stakeholders participating in technical reviews are the LTA and the LBA7.

Error! Reference source not found. lists the recommended LTA for each type of program.8 The

M, LTA, and LBA are assigned no later than the SER or ALF ADE-2A.

Table 1-1: Recommended Lead Technical Authorities

*For embedded-IT programs, the Component Systems Engineer needs to coordinate with the Component Chief Information Officer

(CIO) on SELC technical review decision-making.

Embedded-IT is defined as:

[Information technology (IT)] that is used as an integral part of the product, but the principal function of which is not the acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information. For example, HVAC (heating, ventilation, 7 May also be referred to as Lead Operational Authority.

8 MD 102-01-103, Systems Engineering Life Cycle.

Program Type Recommended LTA

IT Component Chief Information Officer

Non-IT/Embedded-IT Component Systems Engineer*

- 9 -and air conditioning) equipment such as thermostats or temperature control devices, and medical equipment where information technology is integral to its operation, are not information technology.9

Follow-on governance of the SELC technical review actions is managed by CAE staff to ensure that actions are appropriately closed out and technical issues are raised to the ARB, as required.

See Appendix C for a full list of the key DHS stakeholders and descriptions of their roles in the technical reviews.

1.2.6 DHS Operational and Technical Baselines

While changes during a program should be expected, baselines are still necessary. Baselines define system requirements and other attributes and enable configuration management as the design evolves. Baselines are also used to measure performance and progress and provide traceability back to earlier baselines. Baselines include approved artifacts (such as design documentation, databases, and drawings that describe the system) and contain the level of detail commensurate with the solution's development progress. For incremental programs, baselines reflect the level of detail expected at that point in the program and should be updated as the program progresses and the system design matures. One operational baseline and four technical baselines have been identified. These baselines and/or the artifacts contained therein may be tailored so long as there is an equivalent artifact or set of artifacts that meets the intent of the baseline or artifact being tailored. The following provides a description of each baseline and identifies the point in the SELC technical review process at which each baseline is typically established.

1.2.6.1 Operational Baseline

The operational baseline represents the set of operational requirements and the applicable source documents that define the system's behavioral characteristics from a user perspective. This baseline includes the MNS, Operational Requirements Document (ORD), and CONOPS, at a minimum. If developed, additional reference source material, including the AOA/AA final report, white papers, studies, models, and calculations that form the basis for the operational requirements are included. The intent of this baseline is to communicate the operator’s needs unambiguously and completely in operational, not technical, terms. This baseline, along with the functional baseline, is used during OT&E to validate the operational suitability and effectiveness of a system. The operational baseline is established at the Solution Engineering Review (SER) and is owned by the program sponsor or LBA.

1.2.6.2 Technical Baselines

Programs also develop four technical baselines, each of which are described below.

1.2.6.2.1 Functional Baseline

The functional baseline is represented by the set of artifacts that defines the system's behavioral characteristics, including functional, non-functional, interface, and interoperability requirements, 9 65 FR 80500, Electronic and Information Technology Accessibility Standards, 12/21/2000.

- 10 -as well as the means of verification required to demonstrate that these characteristics have been realized. The functional baseline defines what the system has to perform, but not how. It includes the functional and non-functional requirements, functional analysis results, initial interface control document (ICD), and any reference materials (e.g., white papers, studies, models, and calculations that form the basis of the functional requirements). This baseline, along with the

ORD, is used during OT&E to validate the operational suitability and effectiveness of a system.

This baseline is used during Developmental Test and Evaluation (DT&E) to support of system integration and full system demonstration testing. The functional baseline is established at the

System Definition Review (SDR) and owned by the program office.

1.2.6.2.2 Allocated Baseline

The allocated baseline is represented by the set of artifacts that defines the architecture of the system and consists of the configuration items (CIs) that comprise the system as well as their interrelationships and primary interfaces. The allocated baseline defines the requirements allocated to each CI and, as such, defines the top-level design of the system. This baseline documents the allocation of the system's functions (from the functional baseline) to the design representing the physical system architecture. This baseline includes the updated FRD, functional baseline, draft system requirements document (SRD), or equivalent, draft component or CI specifications, ICD, and any functional analysis artifacts used to document the allocation of functions to specific physical elements of the system. The draft SRD and draft component, or CI specifications, while not final, are complete with all requirements defined and not a to-be-determined requirements list. It also includes white papers, studies, models, and calculations that form the basis of the allocated design. This is a "design-to" baseline that is established at the

Preliminary Design Review (PDR). The allocated baseline is used during the Functional

Configuration Audit (FCA), if performed, to verify that the functional and allocated baselines have been met.

1.2.6.2.3 Developmental Baseline

The developmental baseline is represented by the set of artifacts that defines the final design of the system as it proceeds through development. This baseline consists of the SRD and system design document (SDD), or equivalent, for software, applicable vendor-developed specifications, and detailed design drawings. It also includes white papers, studies, models, and calculations that form the basis of the design. It is established at the Critical Design Review (CDR) and is the

"build-to" (or “code-to”) baseline, which results in the physical realization of the system. The developmental baseline is owned by the program office, but is maintained under the developer's configuration control process.

1.2.6.2.4 Production Baseline

The production baseline is represented by the set of artifacts that defines the configuration of the system and each of its CIs as delivered for production, deployment, and operational support. The production baseline is the culmination of the evolution of the developmental baseline. It is the

"as-built" version of the system whose CIs have undergone any required qualification testing and operational testing (OT) and has been determined to be ready for production. This is the mature developmental baseline and is established following the Physical Configuration Audit (PCA).

- 11 -

1.2.7 Baseline Configuration Control

Technical baselines are typically managed by the person or organization performing the systems engineering functions (with support from various teams, as appropriate). PMs and the lead systems engineer of a program maintain strict configuration control of a baseline once it has been established. A typical way of carrying out this function is through a defined configuration management (CM) process that includes a configuration control board (CCB). The formality of the process, however, depends on program characteristics (e.g., risk, scope, size, and complexity) and other established organizational processes and procedures.

1.3 The Relationship of the DHS SELC to Other DHS Enterprise

Governance and Decision-Making Processes

As one of the foundational elements of the DHS acquisition process, the objective of the DHS

SELC Guidebook is to provide a framework to guide enterprise-wide capability delivery.

Understanding the relationship between the DHS SELC framework and other DHS enterprise governance and decision-making processes is essential to this objective. The primary applicable

DHS governance and decision-making processes include: Capital Planning and Investment

Control (CPIC) process; Enterprise Architecture Program; and Acquisition Review Process

(ARP), which is mandated by MD 102-01 as part of the ALF. The alignments of these processes with the SELC framework are illustrated from a sequential point of view in Figure 1-1: SELC

Framework (with Acquisition Lifecycle Framework and Enterprise Architecture Decisions).

The combination of the three life cycles into one “Golden Path” emphasizes the linkages between them and was created as illustrative guidance to help PMs navigate the three life cycles.

The Golden Path is further alluded to in Section 2, SELC Tailoring, and SELC Tailoring

Examples for Selected Types of DHS Acquisition Programs, which includes examples of how the

SELC can be tailored to accommodate different development methodologies and acquisition types.

1.3.1 Alignment with the DHS Acquisition Life Cycle Framework

The DHS Acquisition Life Cycle Framework (ALF) focuses on investment analysis and establishes governance processes (i.e., ARP) and bodies (e.g., Acquisition Review Board) to ensure the oversight, control, reporting, and review of acquisition10 programs/projects.

Acquisition reviews may result in conditions being levied on, or cancellation of, an acquisition.

The ALF is supported by the technical analyses performed under the SELC framework. Event-based SELC technical reviews are aligned with ALF ADEs and provide opportunities for senior decision-makers to gain valuable technical insight and make more fully informed acquisition decisions. The ARP in conjunction with the SELC provides the structure, process, and oversight to monitor and evaluate acquisitions. See MD 102-01-001, Acquisition Management

Instruction/Guidebook for additional details.

Note: The ALF requires program to develop certain artifacts throughout the program’s life cycle. Some of these artifacts are also discussed within the SELC Guidebook. If programs choose

10 MD 102-01-001 defines acquisitions as any capital investment program/project, service contract, or interagency agreement used for the purpose of delivering Homeland Security capabilities, and categorizes investments according to investment levels.

- 12 -to tailor out or modify ALF-required artifacts, then the program needs to coordinate with PARM and clearly document such changes in its SELC Tailoring Plan and present it at ADE-2B for approval.

1.3.2 Alignment with the DHS CPIC Process

The CPIC decision-making process, as described in the DHS Capital Planning and Investment

Control Guide, integrates strategic planning, enterprise architecture, portfolio management, privacy, security, budgeting, procurement, and the management of assets. CPIC is a calendar-driven process, occurring annually, and emphasizes the selection, management, and control of capital investments or assets.

The Department's portfolio of capital investments/acquisition programs is comprised of acquisitions that have been determined to provide the requisite mission capability through the

DHS ARP, and they have been approved for funding through the DHS Planning, Programming, Budgeting and Execution (PPB&E) process, as mandated in MD 1330, Planning, Programming, Budgeting and Execution. CPIC utilizes information provided in the ARP and SELC approved documentation set to complete its reporting and evaluation requirements. It is the intent of DHS to interlink key decision support systems, to provide a common data set for Departmental reporting and review.

The documentation generated through the review processes supports the OMB Major IT

Business Case. OMB Major IT Business Case is an OMB report used for budget formulation purposes. Investments/ programs are initially selected through the ARP and reselected annually via that process regardless of the program phase. As noted above, however, 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.

CPIC levies several requirements on investments. Depending on the CPIC investment thresholds and the operational state of the investment (e.g., development, steady-state), it requires PMs to:

Complete an annual OMB Major IT Business Case

Complete an annual OMB Agency IT Portfolio Summary (for IT investments only)

Conduct monthly periodic reporting (for IT investments only)

Conduct annual operational analysis (OA) (after deployment)

Additional information on CPIC can be obtained in MD 4200.1.

1.3.3 Alignment with the DHS EA Program

Enterprise architecture is a management practice to maximize the contribution of an agency’s resources, IT investments, and system development activities to achieve its goals. This practice is identified in MD 103-02, Enterprise Architecture Management. This Directive is applicable to IT and embedded-IT programs.

The Homeland Security Enterprise Architecture (HLS EA) documents and presents interrelated business, data, and technology architecture for the current state and future target state as well as the transition methodology for achieving the Department-wide goal of “One DHS.” The DHS

Enterprise Architecture Center of Excellence (EA COE) works closely with DHS Components

- 13 -and programs through the PPB&E process and SELC framework to guide decision makers towards alignment with shared target architectures through the Enterprise Architecture Board

(EAB) governance process.

For those programs requiring EAB approval before an ADE, the two processes are combined to streamline the governance of the program to the maximum extent possible.

- 14 -

2 SELC Tailoring The purpose of this section of the SELC Guidebook is to provide a high-level view of the critical thinking needed to tailor the SELC for a specific program or project. All programs/projects, regardless of development methodology, need to conduct the SELC tailoring activities discussed below. This section is not meant to be a prescriptive step-by-step process, but rather a general approach to guide PMs and their project teams through the tailoring process.

2.1 Tailoring Overview

DHS has established a single, flexible SELC framework that is based on government and industry best practices and standards. The SELC framework features key systems engineering activities, artifacts, and technical reviews that need to be considered; however, the specific activities and technical reviews conducted and artifacts created may be tailored to be commensurate with a program/project’s characteristics.

Tailoring the SELC increases a program/project’s likelihood of success by applying critical thinking to determine how much is required regarding formal engineering activities, documentation and reviews and to strike a balance between the systems engineering effort required and the risks, cost, and schedule of the program/project.

The PM develops a program-level SELC Tailoring Plan, and if applicable, a project-specific

SELC Tailoring Plan for each associated project to document the tailoring decisions of the program/project.

Tailoring decisions are a joint effort between PMs and the program’s technical staff to determine the appropriate systems engineering activities to be performed, products to be produced, and reviews to be conducted (both in number and formality). They also need to coordinate on any modifications to the overall tailoring approach subsequent to each event-based SELC technical review.

Note: Best practices for development change and evolve, and the SELC is meant to encourage programs to make use of contemporary approaches. The SELC provides a framework of key systems engineering activities that are always considered, but may be tailored to support emerging practices.

2.2 When to Tailor

Begin to think about tailoring as early as possible, ideally during Needs Analysis, but no later than Planning. The CDP functions similarly to the SELC Tailoring Plan, and can be used to document tailoring considerations or agreements that precede the development of the SELC

Tailoring Plan. (The CDP and SELC Tailoring Plan need to be consistent with one another).

2.3 Recommended Tailoring Activities

The following subsections discuss key activities that are conducted when tailoring. These activities may be conducted concurrently.

- 15 -

2.3.1 Understand the Program and Project/s

When beginning the tailoring process, several fundamental issues are considered. These include, but are not limited to:

Program and project/s: goals, size, scope, acquisition approach, and complexity

Project dependencies, interfaces, or integration issues

Contractual requirements for system engineering processes and/or products

Cost constraints

Technology or system maturity

Risks (program, project, and mission)

Security Categorization

Level of program security and protection

Staff experience and skill sets

These characteristics help to form the boundaries of project tailoring and serve as…