Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

Introduction System engineering is an interdisciplinary, methodical approach for developing a system that can meet stakeholder needs and remain affordable and sustainable over its entire life cycle. DHS uses the Systems Engineering Life Cycle (SELC) framework to guide the technical side of program and project management. It is a set of interrelated activities that enable the design and development of products - both hardware and software - to meet operational needs. The SELC framework focuses on balancing cost and schedule with technical performance, and is based on government and industry best practices and standards. Like the acquisition life cycle, the SELC progresses through a series of activities. Throughout the life cycle, technical reviews monitor progress and manage risk. This lesson describes each activity of the SELC and how it relates to the acquisition life cycle. For more detail, refer to DHS Guidebook 102-01-103-01, Systems Engineering Life Cycle which may be found on the Office of Program Accountability and Risk Management (PARM) website. You may print the Systems Engineering Life Cycle lesson or save it for future reference.

Page 1 of 35

A project is a basic building block, related to a program, which is individually planned, approved, and managed. It has a distinct mission and a definite beginning and end. A program is a directed and funded acquisition that provides new, improved, or continuing systems or services in response to an approved need. A program may have multiple projects. Each program or project has a corresponding program or project manager. Large programs have a program manager overseeing multiple projects, each led by a project manager.

Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

Objectives Upon completion of this lesson, you should be able to: • Identify the key activities of the DHS Systems Engineering Life Cycle (SELC) • Identify the key DHS policy provisions that relate to how systems engineering is performed in DHS • Identify the role of systems engineering in balancing cost, schedule, and performance throughout the life cycle • Identify the purpose of specific technical reviews and their relationship to the acquisition process

Page 2 of 35

Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

SELC Overview The SELC applies to all acquisition programs, regardless of their type (e.g., capital asset, enterprise service, information technology, and so on). The SELC guides the many activities required to plan, define, design, develop, implement, operate, and ultimately dispose of a system. Unless specifically exempted, the SELC process applies to all programs and projects in DHS, both IT and non-IT. The SELC provides a framework for developing and managing both hardware and software for IT systems. This approach is designed to: • Standardize the systems life cycle across DHS Components • Ensure that technology solutions are efficiently and effectively developed • Ensure that appropriate activities are planned and implemented in each activity of the life cycle to increase the program's success Before a program enters the SELC, it must satisfy two criteria: 1. Approved Mission Needs Statement (MNS) to validate the gap in capability 2. Signed Acquisition Decision Event 1 (ADE-1) Acquisition Decision Memo (ADM) to formally initiate the acquisition program These criteria ensure that the program has a clearly defined mission and direction, as well as authorization to proceed. Lack of system engineering leads to performance deficiencies, cost overruns, and schedule delays.

Page 3 of 35

Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

SELC Activities The SELC consists of nine major and two recommended activities that run in parallel with the Acquisition Lifecycle Framework (ALF). Major SELC Activities

Recommended SELC Activities

• Solution Engineering

• Integration and Test

• Technology Development (R&D)

• Planning

• Implementation

• Needs Analysis

• Requirements Definition

• Operations and Maintenance

• Design

• Disposition

• Development

The outputs from the activities are recorded in documents that are placed under configuration management control. Many documents are created during one activity and updated in subsequent activities as additional details become available. Throughout the SELC, reviews are held at appropriate points in time to assess a program’s progress towards planned activities. In this lesson, you will learn about each activity. Instruction 102-01-103, Systems Engineering Life Cycle, and the DHS Guidebook 102-01-103-01, Systems Engineering Life Cycle provide more detail and are the authority for DHS policy and guidance on the SELC. Both documents are available from the Office of Program Accountability and Risk Management (PARM) website.

Page 4 of 35

Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

Key Roles and Responsibilities in the SELC

DHS CIO

Select each button to learn about each role.

Component CIO Component LTA Component CAE Component SE Program/Project Manager IT Portfolio Manager Program/Project Sponsor LBA

Page 5 of 35

DHS CIO The DHS Chief Information Officer (CIO) is responsible for ensuring DHS IT programs/projects/systems are aligned with DHS strategic business objectives, and that system development projects comply with DHS policies. The DHS CIO is also responsible for the proper level of oversight over IT projects and for IT architecture.

Component CIO The Component CIO acts to implement the policies of the DHS CIO. This includes compliance of IT programs/projects with the DHS SELC. In the case of IT programs/projects, the Component CIO is the Lead Technical Authority (LTA).

Component LTA The Component Lead Technical Authority (LTA) is a mandatory participant for all SELC technical reviews. The LTA is responsible for the technical aspects of the program (e.g., systems engineering and domain-specific engineering), and is the empowered individual within the Component to represent agency-wide technical considerations and recommendations to the program manager and CAE or Component head. The LTA for non-IT programs is the Component Systems Engineer or equivalent, as designated by the Component Acquisition Executive (CAE) or Component head. In the case of IT programs/projects, the LTA is the Component CIO. The LTA is responsible for: • Ensuring that all SELC Review exit criteria are satisfied • Ensuring the necessary activities have been satisfactorily completed as planned • Concurring with the SELC Technical Review Completion Letter

Component CAE A desired, but not required participant in SELC reviews, the CAE is responsible for establishing the processes that enable SELC review and ensuring the processes are adhered to by programs. The CAE is also responsible for ensuring Components have adequate functional lines of business (e.g., systems engineering, logistics, etc.) and that they support the program SELC reviews.

Component SE The systems engineer (SE) is the person or organization functionally responsible for the Component’s overall systems engineering. If the Component does not have a dedicated systems engineer, then the organization (external to the program management office) with responsibilities closest to the definitions above is substituted and designated by the CAE/Component head. For non-IT programs/projects, the Component SE is also the LTA.

Program/Project Manager A program manager is the 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). The program manager is also 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 Acquisition Program Baseline (APB). The program manager is responsible for: establishing the team; completing the documentation set; presenting the business case and program status through all phases of the review and approval process; scheduling, conducting, and coordinating the SELC reviews; and, managing the performance of the program throughout the life cycle.

IT Portfolio Manager The IT portfolio manager acts as an agent of the DHS CIO in managing an assigned IT portfolio, regardless of funding sources, across a number of IT programs and projects. The primary responsibilities of the IT portfolio manager are to: • • • • • •

Apply DHS IT portfolio management processes Provide oversight of investments/projects within the portfolio Support budget formulation Review portfolio acquisitions and performance Support the development and implementation of EA targets Develop and review IT business cases

Program/Project Sponsor The program/project sponsor represents the operational needs of the business unit and the system users and participates in all life cycle major activities to ensure that the system meets the requirements and business need.

LBA The Lead Business (or Operational) Authority (LBA) is a mandatory participant in all SELC reviews. The LBA represents the end-users of the capability throughout the acquisition and development of the solution. The LBA is expected to provide continuous feedback to the program on behalf of the user community. The LBA also provides feedback to those developing the operational requirements in order to ensure the product accurately reflects the user needs. The LBA has to be recognized and empowered by the Component head or CAE to speak for the user community. The LBA is a representative of the program/project sponsor.

Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

SELC in Relation to the Acquisition Lifecycle Framework The graphic below shows the activities of the SELC and how they relate to the ALF. Note the arrows indicating the iterative nature of several sections of the process. This graphic is consistent with the DHS Guidebook 102-01-103-01, Systems Engineering Life Cycle. You will learn about each element in this graphic later in the lesson. Some outputs from SELC reviews may be entrance criteria for the ADEs of the ALF. Refer to the management directive DHS Instruction 102-01-001, Rev 01 Acquisition Management Instruction (aka MD-102) for more details. For example, the Operational Readiness Review (ORR) conducted at the end of Implementation would provide input to the ADE-3 decision to deploy the system.

D

Select the image to view an enlargement Select the D-link to read a detailed explanation of the graphic

Page 6 of 35

Graphic depicting the entire systems engineering life cycle (SELC) framework and how it overlays with the ALF, also showing key event-based technical reviews and acquisition decision events (ADEs). The process begins with Mission Analysis, which is a DHS activity that happens before and outside of both the SELC and the ALF. The first activity of the SELC is Needs Analysis, which occurs during the Need Phase of the ALF. It begins with ADE-0 and includes the recommended Initial Technical Review (ITR). The second SELC activity is Solution Engineering, which includes the Study Plan Review (SPR) and Solution Engineering Review (SER). Solution Engineering occurs during the Analyze/Select Phase of the ALF, which starts with ADE-1 and ends with ADE-2A. The third SELC activity is Planning, which includes the Project Planning Review (PPR). The PPR contains the SELC tailoring plan. Planning occurs during the Obtain Phase of the ALF, between ADE-2A and ADE-2B. Technology and Development, which includes R&D, happens simultaneously with the first three SELC activities. This activity is iterative between Needs Analysis and Solution Engineering. The next three major SELC activities occur during the Obtain Phase of the ALF between ADE-2B and ADE-2C. The fourth SELC activity is Requirements Definition, which includes the System Definition Review (SDR). The fifth is Design and this SELC activity includes two documents, the Preliminary Design Review (PDR) and the Critical Design Review (CDR). The sixth is Development, which includes the Integration Readiness Review (IRR). Integration and Test activities of the SELC occur simultaneously and iteratively with Requirements Definition, Design, and Development. Integration and Test concludes with the Production Readiness Review (PRR). The next SELC activity also overlaps with the Obtain Phase of the ALF. Implementation takes place between ADE-2C and ADE-3. Implementation includes two key documents, the Operational Test Readiness Review (OTRR) and the Operational Readiness Review (ORR). The last two SELC activities take place during the Produce/Deploy/Support/Dispose Phase of the ALF, post ADE-3. The first one is Operations and Maintenance, which includes the Post Implementation Review (PIR). The final SELC activity is Disposition.

Intermediate Systems Acquisition Course

Glossary

Lesson 3.1 Systems Engineering Life Cycle (SELC)

Acronyms

Back

Links

Next

Knowledge Review Match the activities of the SELC with the phase of the ALF. Activity

Phase of the ALF

        

Design, and Integration and Test Operations and Maintenance Implementation Solution Engineering, and Technology Development (R&D) Development, and Integration and Test Disposition Needs Analysis, and Technology Development (R&D) Requirements Definition, and Integration and Test Planning, and Technology Development (R&D) That's correct. View the correct answers.

Page 7 of 35

Activity

Phase of the ALF

Design, and Integration and Test

Obtain Phase

Operations and Maintenance

Produce/Deploy/Support/Dispose Phase

Implementation

Obtain Phase

Solution Engineering, and Technology Development (R&D)

Analyze/Select Phase

Development, and Integration and Test

Obtain Phase

Disposition

Produce/Deploy/Support/Dispose Phase

Needs Analysis, and Technology Development (R&D)

Need Phase

Requirements Definition, and Integration and Test

Obtain Phase

Planning, and Technology Development (R&D)

Obtain Phase

Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

Alignment with the DHS CPIC The Capital Planning and Investment Control Process (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.

Select the image to view an enlargement

The Department's portfolio of capital Select the D-link to read a detailed investments/acquisition programs is comprised of explanation of the graphic acquisitions that have been determined to provide the requisite mission capability through the DHS acquisition review process, and they have been approved for funding through the DHS Planning, Programming, Budgeting and Execution (PPBE) process. CPIC uses information from acquisition reviews and SELC-approved documentation to complete its reporting and evaluation requirements. It is the intent of DHS to interlink key decision support systems in order to provide a common data set for Departmental reporting and review. CPIC is related to the SELC process because outputs from SELC activities will influence investment decisions and support development of the OMB Major IT Business Case. D Page 8 of 35

The OMB Major IT Business Case contains the Department's detailed IT investment budget and management information for major IT investments. Guidance may be found in the OMB Circular A-11, Parts 55.6 and 55.7.

Reprise of the SELC graphic showing the CPIC process overlaid. The CPIC Pre-Select process coincides with the Need Phase of the ALF and the Needs Analysis activities of the SELC. The CPIC Select process begins right after pre-select, and continues until the end of the ALF and the SELC, after Produce/Deploy/Support/Dispose. The CPIC Control process begins with the Obtain Phase of the ALF, and the Planning activity of the SELC, and continues until the end. The CPIC Evaluation process begins and ends with the final ALF phase, Produce/Deploy/Support/Dispose.

Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

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 Directive 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 and programs through the PPBE process and SELC framework to guide decision-makers towards alignment with shared target architectures through the Enterprise Architecture Board (EAB) governance process.

Select the image to view an enlargement Select the D-link to read a detailed explanation of the graphic

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

Page 9 of 35

The Homeland Security Enterprise Architecture strategic framework has two main inputs, national security strategy and the quadrennial homeland security review. These encompass the areas of security, resilience, and customs and exchange. These three areas in turn encompass several other objectives: preventing terrorism and enhancing security, securing and managing our borders, enforcing and administering our immigration laws, safeguarding and securing cyberspace, ensuring resilience to disasters, providing essential support to national and economic security, and maturing and strengthening DHS. The framework itself is portrayed as a tube with many layers. The center core starts with information sharing and safeguarding, surrounded by the elements of screening, securing, law enforcement, domain awareness, benefits administration, and incident management. The first layer is intelligence, and the second is Continuity of Operations (COOP). These two top layers are part of the Enterprise Mission Services. There are four more layers. Enterprise Business Services includes asset management, information governance, knowledge management, and management services. Enterprise Human Capital Management includes human capital and training. Enterprise Financial Management includes acquisition, financial assistance, and financial management. Enterprise Information Technology (IT) services include communication, identity credential and access management, IT infrastructure, and security. The entire HLS EA framework is guided by the DHS collaborative architecture methodology (DCAM), which has six steps. First is initiate and validate, second is research and leverage, third is define, fourth is plan, fifth is invest and execute, and sixth is perform and measure.

Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

Tailoring the SELC The philosophy of the SELC is to encourage tailoring for specific engineering needs and to accommodate all development methodologies. Tailoring the SELC increases a program/project's likelihood of success by applying critical thinking to determine what is "enough" in terms of 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. 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. Program managers must select the acquisition strategy and development methodology best suited to their program and projects within it. The program manager 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 should begin during Needs Analysis, and must be submitted and approved no later than Planning. For major acquisitions, the SELC tailoring plan is approved by the Executive Director, Office of Program Accountability and Risk Management (PARM). The DHS Office of the Information Officer (OCIO)/Enterprise Business Management Office (EBMO) will co-approve for IT acquisitions. Page 10 of 35

Intermediate Systems Acquisition Course

Glossary

Lesson 3.1 Systems Engineering Life Cycle (SELC)

Acronyms

Back

Links

Next

The SELC Tailoring Plan Tailoring decisions are a joint effort between program managers 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. The SELC allows a program/project to employ any development methodology that it chooses as long as there is a reasonable basis for choosing the selected development methodology, and the choice of development methodology and rationale for its selection have been appropriately documented in the program/project SELC Tailoring Plan. The SELC Tailoring Plan represents the agreement between the program/project and applicable acquisition decision authorities concerning the basic technical approach for the program/project. Tailoring activities include the following: • Understand the program and project(s) • Review SELC tailoring examples • Select an appropriate development methodology • Tailor SELC technical reviews, artifacts, or activities • Develop the SELC tailoring plan • Obtain approval and endorsement of the SELC tailoring plan • Update the SELC tailoring plan throughout the acquisition process Page 11 of 35

Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

Knowledge Review The Department of Homeland Security System Engineering Life Cycle (SELC) framework interacts with and supports several other key DHS policy provisions and processes. Which list below identifies those policies? A. Acquisition Lifecycle Framework (ALF), Capital Planning and Investment Control Process (CPIC), Homeland Security Enterprise Architecture (HLS EA) B. Acquisition Lifecycle Framework (ALF), SELC Tailoring Plan, Homeland Security Enterprise Architecture (HLS EA) C. Acquisition Lifecycle Framework (ALF), Capital Planning and Investment Control Process (CPIC), Office of Management and Budget (OMB) Major IT Business Case D. Acquisition Lifecycle Framework (ALF), Capital Planning and Investment Control Process (CPIC), Homeland Security Enterprise Architecture (HLS EA), SELC Tailoring Plan

Correct! The key DHS policies that support the SELC are the Acquisition Lifecycle Framework (ALF), the Capital Planning and Investment Control Process (CPIC), and the Homeland Security Enterprise Architecture (HLS EA). Page 12 of 35

Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

Recommended Preliminary SELC Activities

Needs Analysis is a recommended activity of the SELC. It begins along with the Need Phase of the ALF after a capability gap has been identified. The purpose of Needs Analysis is to determine whether a materiel solution is necessary to close or mitigate the capability gap, or portions of it. A preliminary or initial concept of operations (CONOPS) may also be developed at this point. The Initial Technical Review (ITR), if conducted, happens during Needs Analysis. The purpose of Technology Development, should a program choose this path, 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. D

Page 13 of 35

The Initial Technical Review (ITR) is a 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 ADE-1 decision.

Reprise of the SELC graphic highlighting Needs Analysis and Technology Development (R&D). Needs Analysis is the in the Need Phase of the ALF. Technology Development (R&D) overlaps with the ALF phases of Need, Analyze/Select, and the beginning part of Obtain.

Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

Solution Engineering

Solution Engineering takes place during the Analyze/Select Phase of the ALF, following ADE-1. The purpose of Solution Engineering is to identify, analyze, and objectively select the preferred solution alternatives to solve the problem defined in the Mission Needs Statement (MNS). The next screen contains the activities of SELC included with Solution Engineering. The activities are listed according to their section number within the DHS Guidebook 102-01-103-01, Systems Engineering Life Cycle document. D

Page 14 of 35

Reprise of the SELC graphic highlighting Solution Engineering, which is in the Analyze/Select Phase of the ALF.

Intermediate Systems Acquisition Course

Glossary

Lesson 3.1 Systems Engineering Life Cycle (SELC)

Acronyms

Back

Links

Next

Solution Engineering Activities Section 4.2

Select each button to learn more.

Section 4.3 Section 4.4 Section 4.5 Section 4.6 Section 4.7 Section 4.8 Section 4.9 Section 4.10 Section 4.11 Section 4.12 Section 4.13

Page 15 of 35

Section 4.2 Develop a CONOPS A concept of operations communicates high-level, conceptual, current and future business and mission operations to the program sponsors, end-users, developers, planning and design teams, testers, and other stakeholders. It also allows stakeholders to visualize how the proposed solution operates in a real world operational environment and understand the associated organizational impacts. A concept of operations also assists the Analysis of Alternative (AoA)/Alternative Analysis (AA) team to assess the impact of proposed solutions on non-materiel factors, and vice versa.

Section 4.3 Define Operational Requirements/Features Operational requirements/features capture the top-level operational user needs without regard to the technical aspects of the solution. Operational requirements/features, along with non-functional requirements, define the program's vision or purpose. Operational requirements/features trace to one or more of the capability gaps identified during Needs Analysis. They do not presume any specific system design or overly constrain the design. Operational requirements are documented in an ORD.

Section 4.4 Identify and Evaluate Potential Solution Alternatives The Study Plan Review (SPR) is conducted for the purpose of reviewing the ground rules and assumptions as well as the plans, scope, criteria, and methods to be used in the Analysis of Alternative (AoA)/Alternative Analysis (AA). The AoA/AA supports the selection of an optimum, or preferred, solution for closing or mitigating the capability gap(s) identified in the MNS, and provides a complete and compelling justification for choosing this approach. An AoA/AA is a systematic and objective analytical comparison of the operational effectiveness, operational suitability, life cycle cost, and risks associated with alternative solutions that satisfy the capability needs described in the MNS and fit a user-approved CONOPS.

Section 4.5 Gather/Obtain Information on Potential Solutions The assessment team requires critical information including performance data, physical characteristics, current operational doctrine, tactics, techniques, procedures, and potential threat characteristics (including threat tactics for terrorist or criminal activities) in order to properly assess them.

Section 4.6 Assess Technical Maturity of Potential Solutions The challenges to developing/maturing a new technology to the point that it can be employed in a practical solution can be significant and require a detailed assessment of a technology's current capabilities, risks, costs, maturity timeline, ability to be integrated with other technologies, ability to be operationally effective and suitable, and ability to be manufactured in useful quantities based on the application of that technology. The DHS technology readiness level assessment process uses technology readiness levels (TRLs) to assess the maturity of critical technology elements.

Section 4.7 Develop Cost Estimating Baseline Document A Cost Estimating Baseline Document (CEBD) is a single, comprehensive document that defines the technical, programmatic, and schedule description of an acquisition program. It provides information on development, testing, procurement, integration, program security and protection, installation and replacement, operations and maintenance, planned upgrades, and disposal. The program manager is responsible for developing, maintaining, and approving the CEBD. Inputs from stakeholders such as system engineers, design experts, schedulers, test and evaluation experts, and operators are required when developing and maintaining the CEBD. The technical and programmatic descriptions in the CEBD are naturally expected to become more definitive and detailed as the program progresses from ADE-2A through ADE-3.

Section 4.8 Develop Life Cycle Cost Estimate A LCCE is an exhaustive and structured accounting of all resources and associated cost elements required to develop, produce, deploy, secure and protect, sustain, and dispose of a particular system. LCCEs encompass all past, present, and future costs for every aspect of a system, regardless of the funding source. A LCCE reflects a program's documented requirements, and the results are compared to budget authority and resources to determine a program's affordability. For level 1 and 2 programs, an LCCE is a requirement at ADE-2A, ADE-2B, ADE-2C, and ADE-3. LCCEs also support the budgetary process by providing an accounting of all costs related to a program. A LCCE allows program managers to perform trade-off analyses through the identification of cost drivers and identify the biggest "bang for the buck" in the face of limited resources.

Section 4.9 Develop Integrated Logistics Support Strategy The integrated logistics support (ILS) strategy is a high-level strategy for providing system supportability and sustainment and is documented in the integrated logistics support plan (ILSP). The ILS strategy serves as the basis for all other supportability and sustainability analyses, plans, and artifacts. It provides critical insight into the approach, schedule, and funding required for integrating supportability requirements into the systems engineering process to ensure the solution is sustainable throughout its expected life cycle.

Section 4.10 Refine Program Acquisition Plan An acquisition plan (AP) documents a program's plan for acquiring or procuring services or products in support of meeting a defined program need (or portion of a need) through one or more acquisitions. It is a comprehensive plan that provides the background necessary to understand the program and how each acquisition (in the case of multiple acquisition programs) supports the program. The AP is a means to describe the acquisition process and document the decisions made prior to processing each contractual action to ensure that federal and DHS regulations and guidance are followed, and required resources can be obtained and are available when needed across the entire life cycle of the acquisition.

Section 4.11 Establish Acquisition Program Baseline An Acquisition Program Baseline (APB) formally documents the program's critical cost, schedule, and performance parameters in measurable, quantitative terms. By tracking and measuring actual program performance against this formal baseline, program managers are alerted to potential problems and have the ability to take early corrective action. The scope of the APB encompasses the entire planned execution of the program. Its parameters trace back to the mission gaps expressed in the Mission Need Statement (MNS), key performance parameters (KPPs), and applicable operational requirements.

Section 4.12 Create/Update Enterprise and Solution Architectures DHS policy requires all DHS IT systems to align with the Department's Enterprise Architecture (EA). EA represents the enterprise's key business, information, application, and technology strategies/trends and their impact on business functions and processes. Solution Architecture (SA) is an integrated composite representation of organizations, products, and processes that provide a capability to satisfy a stated need or operational objective. SA helps to visualize who and how the mission is executed, and is applicable to IT and non-IT systems.

Section 4.13 Conduct Solution Engineering Review A Solution Engineering Review (SER) is held at the completion of Solution Engineering, towards the end of the Analyze/Select Phase of the ALF. An SER provides a focal point for assessing engineering activities conducted during Solution Engineering, and ensures the program is ready to proceed to an ADE-2A decision. It includes an overview of the preferred alternative, its general design, its key technologies and their readiness levels (technical maturity, manufacturing maturity, integration maturity, etc.), and approaches to mitigate risks of immature technologies, unauthorized dissemination of program information, and malicious intrusions.

Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

Knowledge Review Which solution engineering activity results in a single, comprehensive document that defines the technical, programmatic, and schedule description of an acquisition program? A. Develop the Integrated Logistics Support (ILS) Strategy B. Develop a Concept of Operations (CONOPS) C. Develop the Life Cycle Cost Estimate (LCCE) D. Develop the Cost Estimating Baseline Document (CEBD)

Correct! The CEBD provides information on development, testing, procurement, integration, program security and protection, installation and replacement, operations and maintenance, planned upgrades, and disposal.

Page 16 of 35

Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

Planning

The purpose of Planning is to perform sufficient analysis of the program (and its projects) across the entire program life cycle, define and implement the management processes needed to ensure a cohesive and integrated management approach to execute the program, and plan ahead for key activities. All facets of the program are analyzed to ensure that the cost, scope, and schedule are technically feasible and acceptable to stakeholders. All programs need to conduct Planning activities, regardless of the development methodology selected. D

Page 17 of 35

Reprise of the SELC graphic highlighting Planning, which occurs at the beginning of the Obtain Phase of the ALF between ADE-2A and ADE-2B.

Intermediate Systems Acquisition Course

Glossary

Lesson 3.1 Systems Engineering Life Cycle (SELC)

Acronyms

Back

Links

Next

Planning Activities Section 5.2

Select each button to learn more.

Section 5.3 Section 5.4 Section 5.5 Section 5.6 Section 5.7 Section 5.8 Section 5.9 Section 5.10 Section 5.11

Page 18 of 35

Section 5.2 Develop Program Management Processes and Plans Program planning includes: developing a Work Breakdown Structure (WBS) and an Integrated Master Schedule (IMS); defining an overarching Configuration Management (CM) approach and process; identifying key stakeholders; identifying the program's independent verification and validation (IV&V) approach; defining and developing a risk management approach and action tracking system; and, developing other plans and processes that may be necessary to manage and control the program.

Section 5.3 Define Technical Scope Proper planning for the technical effort requires a comprehensive understanding of the technical scope of the effort. The AOA/AA completed during Solution Engineering provides a conceptual solution(s) for the program to pursue.

Section 5.4 Define Program and Project Development Methodologies and Tailor the SELC Here the program manager critically evaluates the particular characteristics of the program and determine how to best apply the SELC activities to the particular program. The program manager selects a development methodology, and develops a program-level SELC Tailoring Plan, and a project-specific SELC Tailoring Plan for each associated project to document the tailoring decisions of the program/project.

Section 5.5 Identify Technical Resources and Management Successful program execution rests on identifying and securing the necessary technical resources (people, tools, and equipment) that have the required knowledge, skills, or capabilities to execute the program's technical activities. It is also critical that the technical team is adequately trained, and that technical team's roles and responsibilities, management structure, and accountability are defined and clearly understood.

Section 5.6 Develop User/Stakeholder Engagement Strategy Identifying and understanding all stakeholders, their specific interests, and when and how often they are engaged is essential to successfully defining a complete set of requirements and providing an acceptable solution.

Section 5.7 Develop Technical Schedule Developing the technical schedule is done concurrently with developing the overall program Integrated Master Schedule, and is based on a sound WBS that defines all elements of the program. The program manager also performs a schedule risk assessment to identify major points in the schedule where schedule breakage that impacts overall program objectives is possible.

Section 5.8 Define Program's Technical Management Processes Technical management processes are managed and integrated by the systems engineering team to support the program manager in managing the technical development of the system (including any supporting or enabling systems). There are eight technical management processes, one of which includes Technical Planning, an activity conducted during Planning. The remaining seven technical management processes are as follows: Requirements Engineering, Risk Management, Configuration Management, Interface Management, Decision Analysis, Technical Assessment, and Technical Data Management.

Technical Management Processes • Requirements Engineering The three major requirements engineering steps are planning, development, and management. The DHS Requirements Engineering User’s Guide details requirements engineering steps, activities, and methods for performing those steps. • Technical Risk Management This is the general approach to identifying and managing the technical risks associated with the program. • Technical Configuration and Change Management For each of the technical baselines, the systems engineering team identifies the planned or established artifacts that constitute that baseline, and outlines the process the program uses to change the technical baseline/configuration. • Interface Management Interface management control processes ensure that all interface requirements (internal and external) are properly documented and any changes are communicated to all affected configuration items. • Decision Analysis Decision analysis is a discipline that employs many procedures, methods, and tools for identifying, representing, and formally assessing the important aspects of alternative decisions, and provides the basis for evaluating and selecting the best possible decision given cost and technical constraints. • Technical Assessment Technical assessments compare the actual versus planned technical development and design. They are used to track and report the progress of meeting system performance requirements. • Technical Data Management Technical data is defined as recorded information of a technical or scientific nature, other than computer software. Technical data management processes apply policies, procedures, and IT to plan for, acquire, access, manage, protect, and use technical data to support the total life cycle of the system. • Technical Planning The program manager and engineering team continually assess performance of the program against the plans and processes initially discussed in the PMP and SELC Tailoring Plan, ensure that plans are updated to reflect changes in the program, and make applicable changes as necessary to bring the program to a successful conclusion.

Section 5.9 Identify Applicable Design Considerations Many requirements and design considerations cannot fully coexist in a single design, hence the need for rigorous systems engineering processes, with trade-offs, to develop a balanced solution. While some design considerations may have been addressed during Solution Engineering, all design considerations are reevaluated to determine applicability to the approved program. The program manager is aware that some considerations are mandated by laws and regulations while others are mandated by the user in the program's capability document. These mandates need to be optimally balanced in the design process.

Section 5.10 Develop Test and Evaluation Master Plan A Test and Evaluation Master Plan (TEMP) is the "top-level" planning document for all T&E related to a particular program across its entire life cycle. Its primary purpose is to describe the program's specific T&E strategy to determine the system's technical performance and to evaluate the system's operational effectiveness and suitability. The TEMP is reviewed and updated as required throughout the life cycle if significant changes in T&E strategy, schedule, or resource requirements occur.

Section 5.11 Conduct Project Planning Review A Project Planning Review (PPR) is held at the completion of Planning and looks at executability of program/project schedule and scope, along with the continuity and appropriateness of planning artifacts. The PPR ensures that program and project resources, activities, schedules, and tools are allocated and baselined, and that exit criteria have been met prior to beginning the next set of planned activities. Particular emphasis is placed on evaluating the proposed approach to acquiring the system and tailoring of SELC activities, artifacts, and technical reviews. The evaluation ensures that adequate critical analysis was performed and is documented in the program's SELC Tailoring Plan, and that the analysis justifies the proposed approach (including selection of the appropriate development methodology, staffing, application of technical management processes, and tailoring). For programs planning to implement an incremental software development methodology, each project requires a PPR and ALF ADE-2B.

Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

Requirements Definition

The purpose of Requirements Definition is to gather, analyze, and document functional and nonfunctional performance and data requirements. The activities performed and artifacts created during Requirements Definition result in an approved functional baseline. The functional baseline will be updated as needed throughout Design, Development, and Integration and Test. The Requirements Definition activities are fundamental activities that all programs conduct. The manner in which these activities are conducted may vary depending upon the development methodology that the program has implemented. For incremental and iterative programs, Requirements Definition activities would typically be conducted for each identified increment or iteration, respectively. For programs implementing an incremental software development methodology, Requirements Definition activities continue during release planning as features and user stories are defined. D

Page 19 of 35

Reprise of the SELC graphic highlighting Requirements Definition, which is in the Obtain Phase of the ALF after ADE-2B.

Intermediate Systems Acquisition Course

Glossary

Lesson 3.1 Systems Engineering Life Cycle (SELC)

Acronyms

Back

Links

Next

Requirements Definition Activities Section 6.2

Select each button to learn more.

Section 6.3

Section 6.4

Section 6.5

Section 6.6

Section 6.7

Section 6.8

Page 20 of 35

Section 6.2 Identify Interfaces, Inputs, and Outputs All programs, regardless of development methodology, develop a context diagram to support the further decomposition of requirements. A context diagram treats the system as a black box and identifies all of the external entities that interact with the system, as well as the system inputs and outputs.

Section 6.3 Develop Functional Requirements Initial operational requirements are identified during Solution Engineering activities. Operational requirements are further decomposed into functional requirements which later serve as the foundation for the definition of system requirements. Programs implementing an incremental software development methodology may conduct release planning instead of traditional functional analyses.

Section 6.4 Identify Non-Functional Requirements Non-functional requirements specify criteria used to judge the operation of a system rather than specific behaviors. They place constraints on the product being developed and specify external constraints the product has to meet. As with functional requirements, non-functional requirements are objective and testable. Non-functional requirements for this SELC activity include system-level requirements in the following areas: • • • • • • • • • • • •

Security Privacy Accessibility Interface Human systems integration Interoperability Infrastructure Reliability Availability Maintainability Recordkeeping Survivability

Section 6.5 Ensure that Requirements are Complete, Consistent, Testable, and Traceable At this point the requirements management team verifies and validates that functional and non-functional requirements are complete, consistent, testable, and traceable.

Section 6.6 Establish a Means to Trace Requirements Requirements traceability facilitates the association of requirements with related requirements, system elements, tasks, and verification steps. It improves the integrity and accuracy of all requirements, from the system-level down to the lowest configuration items, and supports easier maintenance and change implementation of the system in the future.

Section 6.7 Technical Management Processes within Requirements Definition This SELC activity includes several sub-activities: • • • • • • • •

Requirements Engineering Technical Risk Management Technical Configuration and Change Management Interface Management Decision Analysis Technical Assessment Technical Data Management Technical Planning

Section 6.8 Conduct System Definition Review (or Release Planning Review) The objective of the System Definition Review (SDR) is to assess the value, priority, traceability, and continuity of the functional and non-functional requirements. A successful SDR establishes the functional baseline of the system and ensures the requirements are sufficiently mature and in a form that can be legally measured from a contractual perspective. Programs implementing an incremental software development methodology conduct a Release Planning Review (RPR), rather than a System Definition Review. The RPR determines whether a program/project has conducted sufficient planning, and has clearly broken down the work necessary in order to successfully deliver and deploy that release's minimum viable product by the end of that release. An RPR is conducted before the start of each release.

Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

Design

The objective of Design is to transform requirements into system designs and architectures to efficiently and effectively guide, or contract for, the fabrication, assembly, coding, integration, testing, and delivery of the system. Design activities are typically conducted in an iterative fashion. Design activities are done concurrently with Integration and Test activities, and are often done iteratively with Development activities (particularly in incremental software development methodologies). D

Page 21 of 35

Reprise of the SELC graphic highlighting Design, which is in the Obtain Phase of the ALF.

Intermediate Systems Acquisition Course

Glossary

Lesson 3.1 Systems Engineering Life Cycle (SELC)

Acronyms

Back

Links

Next

Design Activities Section 7.2

Select each button to learn more.

Section 7.3 Section 7.4 Section 7.5 Section 7.6 Section 7.7 Section 7.8 Section 7.9 Section 7.10 Section 7.11 Section 7.12 Section 7.13 Section 7.14 Section 7.15 Section 7.16

Page 22 of 35

Section 7.2 Define Physical Architecture The process of developing a physical architecture is iterative and conducted in parallel with defining systems requirements. Functional analysis decomposes and allocates functions to components and subsystems in order to define a physical architecture that identifies system elements and physical interfaces. System performance requirements are then allocated so that end-to-end performance requirements are met. The result is a description of the solution in terms of what it does functionally and the performance that is required. In DHS, this decomposition stops at discrete points during the requirements engineering process to permit formal review before more funding and time are committed to developing a solution.

Section 7.3 Define System-Level Requirements System-level requirements are derived from the functional requirements, allocated, and further decomposed as necessary to fully define the physical system. They state what the item/system and its fundamental subsystems do in terms of capability, function, and operation. Programs implementing an incremental software development methodology may define system-level requirements through user stories developed and refined during a release.

Section 7.4 Develop Data Architecture The data architecture describes the data and data relationships required for the proposed solution, as well as the approach for data storage, access, reporting, continuity, and implementation. The data architecture also defines how information for the proposed solution is exchanged, shared, and reused.

Section 7.5 Maintain System Design A system design defines all elements of the solution to the lowest level of granularity required to facilitate development and satisfy requirements. During system design, the allocation of requirements to configuration items (hardware, software, etc.), and then to the components of the CIs, is documented. The design includes completed drawings and other "build-to" documentation for the components. The program manager ensures the program team continually assesses cost, schedule, and performance against the detailed design.

Section 7.6 Design for Verification and Validation During Design, it is critical that the design team also ensure that the system is designed to support Verification and Validation. The purpose of verification is to confirm that a product, service, or system meets the design requirements and specifications. Validation is intended to prove, with a high degree of assurance, that a product, service, or system fulfills those requirements.

Section 7.7 Begin Developing Deployment Plan It is the responsibility of the program manager to understand how, when, and where the user deploys the solution. Assets may include IT platforms, hardware systems, software, and supporting architectures. A deployment plan provides the details necessary to ensure these required resources are identified and provided to operate and sustain the new asset or capability when it arrives at the deploying locations. Deployment planning is completed at the end of Development or Integration and Test.

Section 7.8 Develop Site Preparation Plan A site preparation plan describes the resources and activities needed to prepare the intended operating sites or environments for installation and operation of the intended solution. As the system design begins to take shape, the team needs to begin developing a site preparation plan. This permits early assessment and preparation of the deployment locations.

Section 7.9 Develop Service Level Agreements Whether for purchase of a service, design/development, or operation, service level agreements (SLAs) are a critical element of any acquisition. SLAs create and formalize agreements between the producers and consumers of services or systems, and contain a specific definition of consumer expectations, how those expectations are measured, and what happens if they are not met. SLAs contain a set of agreed to performance metrics between a producer (provider) and consumer (user), and typically include prescribed actions, either incentives or penalties, if the producer is or is not meeting the SLA.

Section 7.10 Develop Technology Insertion Package Technology insertion packages are prepared to support decisions related to the insertion of new or upgraded technologies and standards into the HLS EA. The technology insertion decision request process involves identifying, analyzing, reviewing, and approving decisions related to the content of the DHS EA Technical Reference Model (TRM), particularly the standards profile.

Section 7.11 Develop Interconnection Security Agreements A system interconnection is the direct connection of two or more systems for the purpose of sharing data and other information resources by passing data between each other via a direct system-to-system interface without human intervention. Interconnecting systems may strengthen ties among participating organizations by promoting communication and cooperation. The program manager may begin developing Interconnection Security Agreements (ISAs) during Requirements Definition when system interface requirements are identified. Development of required ISAs has to be consistent with DHS4300A, Sensitive Systems Handbook, Attachment N – Preparation of Interconnection Security Agreements.

Section 7.12 Initiate Privacy Impact Assessment A privacy impact assessment (PIA) serves as the primary mechanism for conducting and documenting a privacy analysis, thus describing the ability of a system to protect and secure personally identifiable information (PII), such as social security numbers, birthdates, and home addresses. Each section of the PIA includes a list of specific questions, all of which focus on identifying the information in the system, as well as the different ways that information is used and shared. The PIA is completed by the program manager and approved by the DHS Chief Privacy Officer prior to system implementation. A PIA need not be completed at the end of Design, but it has to be completed by the end of Integration and Test.

Section 7.13 Initiate System of Records Notice A system of records notice (SORN) is required when a system has considerable impacts upon the public. The DHS Privacy Office coordinates a determination as to whether a SORN is required for the collection of information related to the system. Part of this determination includes a review of existing SORNs to identify any that either may already cover the data, or could/has to be updated.

Section 7.14 Continue Evaluating Design Considerations Many requirements and design considerations cannot fully coexist in a single design. As design continues to lower levels of detail, additional design, safety, or manufacturing standards may become applicable.

Section 7.15 Conduct Design Reviews Design reviews, also called systems engineering technical reviews, are independent reviews of programs conducted for the benefit of the program manager. The primary focus of each design review is on the technical risks and issues of the program; however, these reviews do not exclude cost and schedule considerations when necessary to exercise sound judgment on technical risks and proposed solutions. Two technical reviews are typically conducted during Design, the Preliminary Design Review (PDR) and the Critical Design Review (CDR).

Section 7.16 Technical Management Process Activities within Design This SELC activity includes the same sub-activities for technical management as in Requirements Definition: • • • • • • • •

Requirements Engineering Technical Risk Management Technical Configuration and Change Management Interface Management Decision Analysis Technical Assessment Technical Data Management Technical Planning

Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

Development

The objective of Development is to build, manufacture, code, and begin testing the components, products, and functionality that make up the system/solution that delivers the capability defined in the ORD and APB. Activities also take place to establish a secure development environment for software development, develop user documentation (e.g., operations and maintenance manuals), and develop end-user training. Development activities are done concurrently with Integration and Test activities, and are often done iteratively with Design activities (particularly in incremental software development methodologies). While the Government may perform Development activities, most of this effort is typically performed by contractors/vendors, with supervision and oversight by program staff. It is important for program managers to understand development activities and expectations so they can monitor and oversee the development team activities, and ensure their efforts and products lead to a successful product delivery. D

Page 23 of 35

Reprise of the SELC graphic highlighting Development, which is in the Obtain Phase of the ALF just before ADE-2C.

Intermediate Systems Acquisition Course

Glossary

Lesson 3.1 Systems Engineering Life Cycle (SELC)

Acronyms

Back

Links

Next

Development Activities Section 8.2

Select each button to learn more.

Section 8.3

Section 8.4

Section 8.5

Section 8.6

Section 8.7

Page 24 of 35

Section 8.2 Finalize Detailed Subsystem/Configuration Item Specifications The development contractor completes the development of detailed specifications for the design and manufacturing of the system/subsystem/components, as necessary. These specifications trace back to the developmental baseline and applicable industry standards (e.g., manufacturing standards that may not have been specified in the SRD). The design includes all hardware and software components. Programs implementing an incremental software development methodology may conduct Design and Development activities within a release/iteration.

Section 8.3 Develop a Software Development Environment The term software development environment refers to the collection of hardware and software tools a system developer uses to build software systems. An effective software development environment requires adequate tools that can be used for application lifecycle management, change management, collaboration, development, test, build and deployment automation, and continuing integration.

Section 8.4 Build, Construct/Assemble, Code, and Configure System This activity involves fabricating hardware components, coding software components, and acquiring all other components, including commercial items, that are used by the subsystems, components, and configuration items. This effort is typically conducted entirely by the development vendor. The program manager ensures the program team works with the development vendor to continually assess cost, schedule, and performance against the evolving developmental baseline. The program manager ensures that the program team is managing the design requirements, and planning corrective action for any discovered hardware and software deficiencies.

Section 8.5 Develop Supporting Documentation Documentation must be written containing a full description of the system components, enduser information, and troubleshooting information as the system progresses through Development and Integration and Test.

Section 8.6 Technical Management Process Activities within Development This SELC activity includes the same sub-activities for technical management as in Requirements Definition and Design: • • • • • • • •

Requirements Engineering Technical Risk Management Technical Configuration and Change Management Interface Management Decision Analysis Technical Assessment Technical Data Management Technical Planning

Section 8.7 Conduct Integration Readiness Review (IRR) An integration readiness review (IRR) is held at the completion of Development. The IRR assesses system development efforts and subsystem, component, or configuration item testing results to ensure the system is ready for integration and comprehensive developmental test and evaluation (DT&E). It also 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 the IRR will focus primarily on DT&E preparations and readiness.

Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

Knowledge Review During Development activities of the SELC, the system components are built, coded and/or manufactured, and tested. During this work, what is the role of the program staff? A. Program staff perform Development activities B. Program staff oversee contractors/vendors C. Program staff may perform Development activities, or may oversee contractors/vendors D. The Government establishes a secure development environment

Correct!

During Development activities of the SELC, program may staff may perform some activities themselves, or they may oversee contractors/vendors who do the work, or both.

Page 25 of 35

Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

Integration and Test

The primary purpose of Integration and Test is to integrate the systems, subsystems, component, and configuration items that have been built during Development, and to demonstrate that the integrated system satisfies all defined requirements. To be able to properly test a complete system, it is necessary to consider integration and testing when developing requirements during Requirements Definition and during Design. It is also necessary to ensure the system is designed to support both Developmental (DT&E) and Operational Test and Evaluation (OT&E) by designing for Verification and Validation (V&V) during Design. D

Page 26 of 35

Reprise of the SELC graphic highlighting Integration and Test, which is in the Obtain Phase of the ALF between ADE-2B and ADE-2C. Integration and Test is underneath the SELC activities Requirements Definition, Design, and Development.

Intermediate Systems Acquisition Course

Glossary

Lesson 3.1 Systems Engineering Life Cycle (SELC)

Acronyms

Back

Links

Next

Integration and Test Activities Section 9.2

Select each button to learn more.

Section 9.3

Section 9.4

Section 9.5

Section 9.6

Section 9.7

Section 9.8

Section 9.9

Page 27 of 35

Section 9.2 Define Method for V&V The purpose of verification is to confirm that a product, service, or system meets the design requirements and specifications. Validation is intended to prove, with a high degree of assurance, that a product, service, or system accomplishes those requirements. This often involves acceptance by end-users and other stakeholders. It is critical to define the method of system verification and validation (V&V) properly. Equally, the subsequent design needs to include the applicable test points or design elements to enable proper V&V of the system (this is addressed in Design).

Section 9.3 Plan for Integration Planning during Integration and Test takes into consideration strategies developed during earlier SELC activities, current resources, schedules, and all associated risks. Development and Integration and Test activities are highly interactive. As the system is being built, it is incrementally evaluated at different key points during assembly to verify that its various elements provide the required functionality, meet specifications, and satisfy system requirements. The key evaluation points are defined during Planning. An incremental approach to integration and testing also minimizes the amount of time and level of re-work necessary if a defect is found.

Section 9.4 Verification Planning Verification planning began earlier during Planning and Requirements Definition for system element(s). The earlier planning is documented in the Systems Engineering Plan (SEP) and TEMP, and addresses the scope of verification during Integration and Test. The purpose of the verification process during Integration and Test is to verify that the newly integrated element(s) function and perform as intended.

Section 9.5 Prepare for and Conduct Developmental Test and Evaluation of Individual Subsystems or Configuration Items Developers prepare for and demonstrate the physical, electrical, software, and other characteristics of the individual subsystems, components, and configuration items that make up the system. Special attention is placed on the integration and testing of commercial components within the subsystems. Early component-level testing may not require the same level of review as the final, system-level tests. The program team manages the design requirements and plans for corrective actions, including expected resolution dates and dates to re-test for any discovered hardware and software deficiencies.

Section 9.6 Prepare for and Conduct Developmental Test and Evaluation of System (or Increment to be Delivered) Preparation for integration testing, comprehensive developmental test and evaluation (DT&E) of the system (or increment) to be delivered, operational assessments, and integrated tests (combined developmental and operational) are initiated during Development. These preparations include working with the developmental test team, vendors, applicable testing facilities, and other stakeholders (including the OTA and users) to develop detailed test plans, and coordinate the resource requirements and scheduling of test events.

Section 9.7 Conduct Acceptance Testing Acceptance testing is formal testing conducted to determine whether or not a system satisfies its acceptance criteria. Acceptance testing is conducted to determine if the requirements of a specification or contract are met. It may involve chemical tests, physical tests, or performance tests. Acceptance testing generally involves running a suite of tests on the completed system. The test environment is usually designed to be identical, or as close as possible, to the anticipated user's environment, including extremes of such. These test cases must each be accompanied by test case input data, or a formal description of the operational activities (or both) to be performed, and a formal description of the expected results. Results are reviewed by the program manager and documented in an acceptance test report that is provided to the contracting officer to determine acceptance.

Section 9.8 Technical Management Process Activities within Development This SELC activity includes the same sub-activities for technical management as in the other SELC activities: • • • • • • • •

Requirements Engineering Technical Risk Management Technical Configuration and Change Management Interface Management Decision Analysis Technical Assessment Technical Data Management Technical Planning

Section 9.9 Conduct Production Readiness Review A production readiness review (PRR) is held at the completion of Integration and Test. The objective of a PRR is to review the results of Integration and Test to validate that the system developed meets the defined requirements, and assesses system and manufacturing readiness for the move to limited production. This limited production may be to support OT&E and/or low rate initial production (LRIP). Note that PRRs may be conducted on various system elements depending upon the structure of the program.

Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

Implementation

The purpose of Implementation is to prepare the system, operational environment, organization, and users for the intended use of the new solution, and to prepare for the remaining operational test events required to fully determine the operational effectiveness and suitability of the system. LRIP or initial introduction of a system or increment may be conducted as part of the acquisition strategy. The set and order of activities is decided and documented in the SELC Tailoring Plan. D

Page 28 of 35

Reprise of the SELC graphic highlighting Implementation, which is at the end of the Obtain Phase of the ALF between ADE2C and ADE-3.

Intermediate Systems Acquisition Course

Glossary

Lesson 3.1 Systems Engineering Life Cycle (SELC)

Acronyms

Back

Links

Next

Implementation Activities Section 10.2

Select each button to learn more.

Section 10.3 Section 10.4 Section 10.5 Section 10.6 Section 10.7 Section 10.8 Section 10.9 Section 10.10 Section 10.11 Section 10.12 Section 10.13

Page 29 of 35

Section 10.2 Obtain and Deploy Low-Rate Initial Production Units (if applicable) This effort is intended to result in the completion of manufacturing development. LRIP units allow the prospective operator to thoroughly test the new system in order to gain a reasonable degree of confidence as to whether the system actually performs to the agreed-upon requirements before an ADE-3 decision to pursue full-rate production is made. At the same time, manufacturers can use the LRIP to develop the assembly line models that would eventually be used in mass production.

Section 10.3 Complete Site Preparation and Deployment The purpose of this activity is to prepare operational sites to receive and install the system. Any interface and IT data conversion constraints are documented, including recommended workarounds and/or required modifications to the original plan. If constraints have a significant impact on component resource requirements or schedules for fielding, then the revised plan is submitted to the CAE or executive steering committee (ESC) for review and approval. Activities related to site preparation and deployment include: • • • •

Human systems integration Identification and resolution of necessary re-design User and operator training Development and implementation of a formal transition plan to Operations and Maintenance

For Level 1 and 2 programs, an ADE-3 occurs prior to entering into Operations and Maintenance.

Section 10.4 Develop Operational Test and Evaluation Plan Planning for Operational Test and Evaluation (OT&E) begins well before Implementation, beginning with development of the TEMP during Planning, and continues during Development and Integration and Test. The TEMP is finalized during Implementation.

Section 10.5 Conduct Operational Test Readiness Review (OTRR) The Operational Test Readiness Review (OTRR) is led by the CAE or designee, and is conducted in a manner that ensures everything is ready to enter OT&E, including assessing the system's readiness (i.e., performance, supportability, and training), evaluating the status of OT&E planning, resources (e.g., test items, operators, maintainers, data collectors, instrumentation, spare parts, manuals, and test venues), and ensuring that the fielded system is ready for OT&E. The program manager facilitates user participation in OT&E and ensures they are adequately trained. The OTA is responsible for determining how it plans to get user feedback. The training of the end-users on the new system replicates the training to be offered to all users. Test plans are reviewed to ensure that testing follows the CONOPS scenarios and tasks, and enables evaluation of operational requirements. As applicable, OT&E may include testing to ensure security, accessibility, and privacy requirements have been met.

Section 10.6 Perform Operational Test and Evaluation (OT&E) Operational Test and Evaluation (OT&E) is conducted to assess operational effectiveness and operational suitability, to identify deficiencies, and to determine if modifications are needed to meet operational requirements. Operational effectiveness is the ability of a system to accomplish a mission when used by representative users in the expected environment. Operational suitability is the degree to which a system is deployable and sustainable in the field, and takes into account reliability, maintainability, availability, interoperability, logistic supportability, training, and safety.

Section 10.7 Make Changes to System for Production After OT&E is conducted, the contractor or the Government needs to address potential design or configuration changes to address OT&E issues, and finalize the manufacturing process and fielding of the system. There are often a myriad of production engineering issues and design engineering change proposals as the producer begins delivering systems for low-rate production, and prepares to ramp up for full-rate production.

Section 10.8 Coordinate Changes to Corresponding Business Practices Business processes may need to be changed or implemented with the new system. Improvements to processes, practices, training, doctrine, tactics, techniques, procedures, and regulations are planned, scheduled, and executed in time to be ready for implementation with the fielded system. Organizational change management is primarily the responsibility of the Lead Business Authority (LBA) and end-users, but the program team tracks the business process changes.

Section 10.9 Convert Existing Data for Use in the New System Existing data stored or used by the new system must be converted into new structures and formats required by the new system. Security and privacy policies are adhered to throughout the process. Converting legacy data and loading them to a production environment may take considerable time and may need to be started before Implementation.

Section 10.10 Publish SORN and Obtain Privacy Office Affirmation A system of records notice (SORN) is a publicly published document that describes the type of data a system collects, if and how that data is stored, 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 (e.g., social security number). The Privacy Act requires each agency to publish notice of its systems of records in the Federal Register. Prior to implementation, the program receives an affirmative statement from the DHS Privacy Office that all privacy compliance requirements are met.

Section 10.11 Obtain Authority to Operate Letter For IT or embedded-IT systems where information access or exchange is involved, the program completes a security assessment and accreditation and obtains an authority to operate (ATO) letter. If the system is required to connect to a DHS system, or otherwise connect to a public network as part of testing, an ATO is required prior to the commencement of testing. The ATO letter is signed by the Authorizing Official, finalizing the accreditation process.

Section 10.12 Technical Management Process Activities within Implementation This SELC activity includes the same sub-activities for technical management as in the other SELC activities: • • • • • • • •

Requirements Engineering Technical Risk Management Technical Configuration and Change Management Interface Management Decision Analysis Technical Assessment Technical Data Management Technical Planning

Section 10.13 Conduct Operational Readiness Review (ORR) An Operational Readiness Review (ORR) is conducted by the program manager at the conclusion of Implementation to evaluate whether the system, as implemented, meets the mission need and operational requirements, possesses the required manufacturing and logistics support capabilities and capacities, and is ready to be moved into full-rate production, fielding, and operation after an ADE-3 decision.

Intermediate Systems Acquisition Course

Glossary

Lesson 3.1 Systems Engineering Life Cycle (SELC)

Acronyms

Back

Links

Next

Operations and Maintenance

The objectives of Operations and Maintenance are to: fully deploy the new capabilities to reach full operational capability; operate, maintain, and make minor enhancements to the system; conduct operational analyses, evaluations, and post-implementation reviews; and, conduct periodic reviews (e.g., security reviews) of system performance. An initial operational evaluation occurs in Implementation during OT&E. Operations and Maintenance is on-going and does not have a technical review or formal exit criteria. Operations and Maintenance ends when the useful life of the system ends and the system moves into Disposition. D

Page 30 of 35

Reprise of the SELC graphic highlighting Operations and Maintenance, which is in the Produce/Deploy/Support/Dispose Phase of the ALF following ADE-3.

Intermediate Systems Acquisition Course

Glossary

Lesson 3.1 Systems Engineering Life Cycle (SELC)

Acronyms

Back

Links

Next

Operation and Maintenance Activities Section 11.2

Select each button to learn more.

Section 11.3

Section 11.4

Section 11.5

Section 11.6

Section 11.7

Section 11.8

Page 31 of 35

Section 11.2 Operate System and Update System Documentation Sub-activities include: ensuring the system is operating properly; correcting problems; providing routine maintenance; training operators and maintainers; securing facilities; supplying the system; and, maintaining configuration control. Regular maintenance schedules are documented and adhered to in order to ensure optimum system performance. Baseline documentation is regularly maintained and updated, as appropriate.

Section 11.3 Identify and Make System Enhancements In many cases it is necessary to make minor enhancements (or fixes) to deployed systems. Any changes to capabilities that are outside the scope of the approved MNS or ORD require a new program to be created. All system changes (e.g., engineering change proposals) are reviewed and approved by the system's configuration control board before implementation, in accordance with the program's configuration management plan. Any functional or performance enhancements are fully coordinated with the program management office so as not to disrupt developmental activities or implement changes without proper configuration and investment control and consideration. All enhancements adhere to the SELC framework.

Section 11.4 Disaster Recovery Testing Disaster recovery is one part of a comprehensive business continuity strategy to ensure critical business functions are available following a natural or man-made disaster. Disaster recovery plans (DRP) for IT systems and services are tested during Operations and Maintenance since the system has to be up and running to test this capability. To the extent possible, testing is accomplished by simulating actual conditions. Users and operators are trained during Implementation to prepare for and respond to disasters. Problems identified during testing or exercises, along with optimum solutions, are discussed and disseminated to appropriate parties as lessons learned. Disaster recovery testing is performed at regular, periodic intervals in order to create and maintain a sense of awareness and preparedness among personnel. System documentation and procedures are updated to reflect anything identified and changed as a result of these exercises.

Section 11.5 Conduct Post-Implementation Review (PIR) The required Post-Implementation Review (PIR) serves to determine if the benefits of the system have been realized in terms of improved processes, a sound business case, return-on-investment, architecture, and security, among others. The PIR is conducted within six to eighteen months after initial operating capability (IOC). The PIR focuses on three areas: • Impact to stakeholders and customers • Delivery of expected capability • Achievement of baseline goals (e.g., MNS goals and objectives and KPPs)

Section 11.6 Develop Lessons Learned Lessons learned define opportunities for improving enterprise processes based on the experience of the acquisition team and other stakeholders during the total life cycle of the acquisition. The content for the lessons learned report comes from PIR findings, operational analysis (OA), exercises, after-action reports, various reviews, and required activities during the life cycle. The objective is to make lessons learned from DHS acquisitions available throughout the Department to increase the probability of success for future acquisitions through the improvement of processes, tools, and other program-related entities.

Section 11.7 Perform Continuous Monitoring and Security Activities Security activities conducted during Operations and Maintenance include security administration, oversight and monitoring of security controls on an on-going basis, and notification of the Authorizing Official when changes that may impact the security of the system occur. While this section applies primarily to IT, it may also be useful for embedded-IT systems.

Section 11.8 Technical Management Process Activities within Operations and Maintenance This SELC activity includes the same sub-activities for technical management as in the other SELC activities: • • • • • • • •

Requirements Engineering Technical Risk Management Technical Configuration and Change Management Interface Management Decision Analysis Technical Assessment Technical Data Management Technical Planning

Intermediate Systems Acquisition Course

Glossary

Lesson 3.1 Systems Engineering Life Cycle (SELC)

Acronyms

Back

Links

Next

Knowledge Review Match the technical review from the SELC with the correct SELC activity. Technical Review

SELC Activity

           

Operational Readiness Review (ORR) Study Plan Review (SPR) Critical Design Review (CDR) Initial Technical Review (ITR) System Definition Review (SDR) Integration Readiness Review (IRR) Solution Engineering Review (SER) Operational Test Readiness Review (OTRR) Project Planning Review (PPR) Post Implementation Review (PIR) Preliminary Design Review (PDR) Production Readiness Review (PRR) That's correct. View the correct answers.

Page 32 of 35

Technical Review

SELC Activity

Operational Readiness Review (ORR)

Implementation

Study Plan Review (SPR)

Solution Engineering

Critical Design Review (CDR)

Design

Initial Technical Review (ITR)

Needs Analysis

System Definition Review (SDR)

Requirements Definition

Integration Readiness Review (IRR)

Development

Solution Engineering Review (SER)

Solution Engineering

Operational Test Readiness Review (OTRR)

Implementation

Project Planning Review (PPR)

Planning

Post Implementation Review (PIR)

Operations and Maintenance

Preliminary Design Review (PDR)

Design

Production Readiness Review (PRR)

Integration and Test

Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

Disposition

Disposition and/or decommissioning is the act of eliminating from service all or parts of a system to include IT (e.g., shutting down databases) and non-IT (e.g., decommissioning helicopters, ships, physical portions of systems) elements. The emphasis in Disposition is to ensure that the system (or parts of the system), data, procedures, records, and documentation are archived, transferred, or disposed of in accordance with the DHS and Federal policies. Another objective is to dispose of capital assets properly and cost-effectively. A disposition plan (or disposal/decommissioning plan) is required to address all facets of archiving/retaining, transferring, and disposing of all or part of a system and its corresponding data and records. Decommissioning and disposal need to be accomplished with no adverse impact on the health and safety of any personnel involved or the public. D

Page 33 of 35

Reprise of the SELC graphic highlighting Disposition, which is at the end of the Produce/Deploy/Support/Dispose Phase of the ALF.

Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

Disposition (continued)

Initial Disposition planning begins as part of program definition during Solution Engineering and is included in the ILSP. More detailed planning occurs during Development and is included as part of the final logistic support planning. A formal disposition plan is normally prepared during Operations and Maintenance. For IT systems, particular emphasis is given to proper preservation of the data processed by the system so that it is effectively migrated to another system, or archived in accordance with applicable records management regulations and policies for potential future access. A Disposition Review (DR) is recommended, and is conducted by the program manager prior to decommissioning/disposition of the system to evaluate whether the system is ready for final disposition. D

Page 34 of 35

Reprise of the SELC graphic highlighting Disposition, which is at the end of the Produce/Deploy/Support/Dispose Phase of the ALF.

Intermediate Systems Acquisition Course Lesson 3.1 Systems Engineering Life Cycle (SELC)

Glossary

Acronyms

Back

Links

Next

Summary The DHS Systems Engineering Lifecycle Framework (SELC) contains a set of major and recommended interrelated activities enabling the design and development of products to meet operational needs. The SELC balances cost and schedule with technical performance, and is based on government and industry best practices and standards. Each part of the SELC involves specific activities, but these do not need to be done in order; tailoring of the SELC is not only allowed, it is encouraged. Program managers should use all available knowledge resources, combined with their best judgement, to make tailoring decisions, and document these in the SELC Tailoring Plan. The SELC interacts with and supports several other key DHS policy provisions and processes. The Capital Planning and Investment Control Process (CPIC) uses information from acquisition reviews and SELC-approved documentation to complete reporting and evaluation requirements, and the Homeland Security Enterprise Architecture (HLS EA) uses information produced via the SELC framework to guide decision-makers towards alignment with shared target architectures.

Select the image to view an enlargement Select the D-link to read a detailed explanation of the graphic For more detail, refer to DHS Guidebook 102-01-103-01, Systems Engineering Life Cycle which may be found on the Office of Program Accountability and Risk Management (PARM) website. You may print the Systems Engineering Life Cycle lesson or save it for future reference. D Page 35 of 35

Reprise of the SELC graphic depicting how it overlays with the ALF, and also showing key event-based technical reviews and Acquisition Decision Events (ADEs).