2.120.3 Product Integration

Manual Transmittal

August 06, 2019

Purpose

(1) This transmits a revised Engineering, Product Integration Process adding Internal Control Section

Material Changes

(1) Updated to current IPM template adding Internal Control Section

Effect on Other Documents

IRM 2.120.3 dated October 14, 2015 is superseded

Audience

The Product Integration Process is applicable to all ACIO areas with responsibility for Product Integration.

Effective Date

(08-06-2019)

Sri Rao
Enterprise Services, Solution Engineering

Program Scope and Objectives

  1. Overview - A process is defined as “A set of related of activities that accomplish a common goal”. The process definition laid out in this document further breaks down these Activities into Tasks, each of which have a complete set of attributes defined such as data and tool specifications and the role(s) responsible for executing the tasks. The document also includes process goal and objectives, metrics, role definitions, policies and other process related attributes.

  2. Purpose - This transmits a revised Engineering, Product Integration Process.

  3. Audience - The Product Integration Process is applicable to all ACIO areas with responsibility for Product Integration.

  4. Policy Owner - The Policy Owner is responsible for implementation and ensuring adherence to the policy. The policy will be reviewed regularly to ensure that it continues to support the business requirements of the enterprise. The policy will be designed and developed based on ROI to the business. Policy metrics will be focused on providing relevant information as opposed to merely presenting raw data.

  5. Program Owner -The Program Owner is responsible for implementation and ensuring adherence to the program. The program will be reviewed regularly to ensure that it continues to support the business requirements of the enterprise. The program will be designed and developed based on ROI to the business. Program metrics will be focused on providing relevant information as opposed to merely presenting raw data.

  6. Primary Stakeholders -The Primary Stakeholder is responsible for ensuring the needs and concerns are considered. These are the specific people or groups who have a stake, or an interest, in the outcome of the project. The stakeholders may be different for each step or activity.

  7. Program Goals - The program goal describes a specific purpose or achievement toward which the efforts of the program are directed. Each program has a specific focus and when combined with the other programs, forms a comprehensive framework for delivering and managing services
    .

Background

  1. A process is defined as “A set of related activities that accomplish a common goal”. The process definition laid out in this document further breaks down these Activities into Tasks, each of which have a complete set of attributes defined such as data and tool specifications and the role(s) responsible for executing the tasks. The document also includes process goal and objectives, metrics, role definitions, policies and other process related attributes.
    [Insert additional information].

Process Description
  1. The Product Integration (PI) Process addresses the integration of product components into more complex product components or into complete products.

Goal
  1. The process goal describes a specific purpose or achievement toward which the efforts of the process are directed. Each process has a specific focus and when combined with the other processes, forms a comprehensive framework for delivering and managing services.

    • [Enter text]

Objectives
  1. Process objectives describe material outcomes that are produced or achieved by the process. The following is a list of objectives for this process:
    [List the objectives of your process].

    • To establish a product integration strategy

    • To establish a product integration environment

    • To establish product integration procedures and criteria

    • To manage product component interfaces

    • To assemble, evaluate, package, and deliver products or product components

Authority

  1. All proposed changes to this document must be submitted in writing, with supporting rationale, to the [Organization Name].

Roles and Responsibilities

  1. Each process defines at least one role. Each role is assigned to perform specific tasks within the process. The responsibilities of a role are confined to the specific process. They do not imply any functional standing within the hierarchy of an organization. For example, the process manager role does not imply the role is associated with or fulfilled by someone with functional management responsibilities within the organization. Within a specific process, there can be more than one individual associated with a specific role. Additionally, a single individual can assume more than one role within the process although typically not at the same time.

    [Identify process roles and provide a brief description in the table. See example below].

    Name Description
    Lead Integrator Responsible for:
    • Planning and executing the integration of system components into a larger system

    Component Designer Responsible for:
    • Integration of system components into larger system components or into the final system

    Developer Responsible for:
    • Creating and/or modifying code

    • Performing own unit testing on the created code and notifying their lead integrator when unit testing is completed

    • Documenting code

    • Ensuring that all development work products are completed

    Stakeholder Responsible for:
    • Ensuring the needs and concerns are considered

    • These are the specific people or groups who have a stake, or an interest, the outcome of the project

    • The stakeholders may be different for each step or activity

    Quality Assurance Responsible for:
    • Verification of the execution of each of the process steps and the work products produced by them

    Operations Personnel Responsible for:
    • Site preparation

    • Product Installation

    • Confirms correct operation of installed system

    Tester Responsible for:
    • Defined verification tests against requirements

    Security Responsible f
    • Security requirements, criteria, and procedures comply with Security standards

Program Management and Review

  1. Policies outline a set of plans or courses of action that are intended to influence and determine decisions or actions of a process. Policies provide an element of governance over the process that provides alignment to business vision, mission and goals.

    Process Management  
    Statement: The [Process Name] process will have a single Process Owner and a separate Process Manager responsible for implementation and ensuring adherence to the process. The process will be reviewed regularly to ensure that it continues to support the business requirements of the enterprise. The process will be designed and developed based on ROI to the business. Process metrics will be focused on providing relevant information as opposed to merely presenting raw data.
    People:  
    Statement: Roles and responsibilities for the process must be clearly defined and appropriately staffed with people having the required skills and training. The mission, goals, scope and importance of the process must be clearly and regularly communicated by upper management to the staff and business customers of IT. All IT staff (direct and indirect users of the process) shall be trained at the appropriate level to enable them to support the process.
    Rationale: It is imperative that people working in, supporting or interacting with the process in any manner understand what they are supposed to do. Without that understanding [Process Name] will not be successful.
    Process:  
    Statement: Modifications to the [Process Name] process must be approved by the Process Owner. The design of the process must include appropriate interfaces with other processes to facilitate data sharing, escalation and workflow. The process must be capable of providing data to support real-time requirements as well as historical/trending data for overall process improvement initiatives. The process must be fully documented, published and accessible to the various stakeholders of the process. The process will be reviewed on a periodic basis in order to ensure it continues to support organizational goals and objectives (continuous improvement). The process must include Inputs, Outputs, Controls, Metrics, Activities, Tasks, Roles and Responsibilities, Tool and Data requirements along with documented process flows. The process will be kept straight forward, rational, and easy to understand.
    Rationale: The process must meet operational and business requirements.
    Technology and Tools:  
    Statement: All tools selected must conform to the enterprise architectural standards and direction. Existing in-house tools and technology will be used wherever possible, new tools will only be entertained if they satisfy a business need that cannot be met by current in-house tools. The selection of supporting tools must be process driven and based on the requirements of the business. Selected tools must provide ease of deployment, customization and use. Automated workflow, notification and escalation will be deployed wherever possible to minimize delays, ensure consistency, reduce manual intervention and ensure appropriate parties are made aware of issues requiring their attention.

    The tools used by this process are the following:
    [Identify and list the technology and/or tools used in process].
    • [Enter text]

    Rationale: Technology and tools should be used to augment the process capabilities, not become an end themselves.

Program Control

  1. Activities involved in ensuring a process is predictable, stable, and consistently operating at the target level of performance

Controls
  1. Process controls represent the policies and guiding principles on how the process will operate. Controls provide direction over the operation of processes and define constraints or boundaries within which the process must operate.

    [Identify and provide a brief description of your process controls. See example below].

    Name Description
    Product Integration Policy Product Integration is a required activity mandated by the IRS CTO.
    Scope The Product Integration process is limited to all ACIO areas with responsibility for Product Integration.
    Scope The Product Integration process is limited to all ACIO areas with responsibility for Product Integration.
    Process Metrics The Product Integration Process Monitors will continuously verify to what degree the Product Integration Process is being used.
Metrics
  1. Metrics are used for the quantitative and periodic assessment of a process. They should be associated with targets that are set based on specific business objectives. Metrics provide information related to the goals and objectives of a process and are used to take corrective action when desired results are not being achieved and can be used to drive continual improvement of process effectiveness and efficiency.
    Management will regularly set targets for process performance, gather quantifiable data related to different functions of the Product Integration process, and review that data in order to make informed decisions and take appropriate corrective action, if necessary. All Measurements will have a defined data dictionary, map to the organizational strategic goals, and be documented in a Process Measurement Plan. The Process Measurement Plan template is available in the IT PAL..

Tailoring Guidelines
  1. The tailoring guidelines identify the allowable variations of the IT organization’s standard process as needed for adjustments (adding, deleting, modifying) relative to specific operational or functional needs of another organization. Process tailoring is about roles and procedures, not the standard process or major activities defined in this process. All tailoring request, with supporting rationale, must be submitted in writing to and approved by the Product Integration owner.
    [Enter tailoring guideline instructions].

Terms/Definitions/Acronyms

  1. Terms/Definitions/Acronyms

Terms and Definitions
  1. Terms and Definitions

    [Enter terms and definitions identified in this document. See example below].

    Term Definition
    RACI The RACI model is based on the principle that people act in one of four ways when executing a task. It accounts for the fact that more than one role may be active in performing a specific task while clearly defining specific responsibilities for that role. While many roles may be involved in a task only one is Accountable for the results. The actions are: R Responsible for the action (may do the task) A Accountable for the action (including approval) C Required to be Consulted on the action I Required to be Informed of the action If a task does not have an Accountable role indicated then the Responsible role is assumed to be accountable for the task.
Acronyms
  1. Acronyms

    [Identify and list the acronyms and definitions identified in this document. See example below].

    Acronyms Description
    API Application Programming Interface
    BSRR Business System Requirements Report
    CMMI Capability Maturity Model Integrated
    DSR Design Specification Report
    ELC Enterprise Life Cycle
    GEL Government Equipment List
    ICD Interface Control Document
    IPM Integrated Process Management
    IRM Internal Revenue Manual
    IRS Internal Revenue Service
    ITIL Information Technology Infrastructure Library
    ITSM Information Technology Service Management
    PAL Process Asset Library
    PD Process Description
    PI Product Integration
    PIA Privacy Impact Assessment
    PMI Project Management Institute
    QA Quality Assurance
    RACI Responsible, Accountable, Consulted and Informed
    TS Technical Solution

Related Resources

  1. [Cite sources that were used to develop and/or support this process].

Training

  1. Process training involves training all stakeholders about key processes that are crucial for an organization to deliver business objectives. Training provides clarity to employees on a set of procedures that needs to be carried out as part of the process and the best possible way to do them. List below the training resources available for this process:
    [Identify and list training resources].

    • Product Integration Overview, ELMS course #52794

Workflow

  1. A workflow consists of Activities and Tasks, Inputs and Outputs, Roles, and Flow Diagrams. It describes the tasks, procedural steps, organizations or people involved, required input and output information, and tools needed for each step of the process.

Main Process Diagram

  1. Product Integration Process

    Figure 2.120.3-1

    This is an Image: 59978001.gif
     

    Please click here for the text description of the image.

Inputs

  1. Process inputs are used as triggers to initiate the process and to produce the desired outputs. Users, stakeholders or other processes provide inputs. The following is a list of inputs for this process:

    [Complete process input table. See examples below].

    Name Description Supplier
    Design Specification Report The DSR documents the logical and physical design of a proposed solution from all applicable perspectives. The DSR is created in the Preliminary Design phase (MS 3) and is updated with physical design details during the Detailed Design phase (MS 4A). Technical Solution Process
    Government Equipment List The GEL provides a complete listing of equipment to be installed for use in various system environments. The system environments needing a GEL are: Development, Unit Test, Integration, Production and Disaster Recovery. The purpose of the GEL is to identify and track the incremental hardware and software required by a project for the proposed system. Technical Solution Process
    Interface Control Document The ICD defines the details for boundary conditions and data at the design solution interfaces. The purpose of the ICD is to establish an agreement of responsibilities among the organizations owning the interfacing entities. The ICD is first created in the Preliminary Design phase (MS 3) and is subsequently updated during the Detailed Design phase (MS 4A). Technical Solution Process
    Business System Requirements Reports (BSRR) The BSRR documents a feasible, quantified, verifiable set of requirements that define and bound the business system or subsystem(s) being developed or enhanced by the project. These requirements form the basis for the business system design, development, integration, and deployment. The requirements in the BSRR document the nature and scope, or boundary, of the business system Requirements Management Process

Outputs

  1. Each process produces tangible outputs. These outputs can take the form of products or data and can be delivered to a user or stakeholder or they can be used as inputs to other processes. Outputs are measurable in terms of quantity and quality.

    [Complete process output table. See example below].

    Name Description Recipient
    Product Integration Strategy The product integration strategy describes the approach for receiving, assembling, and evaluating the product components that comprise the product.
    • Solution Engineering

    • Enterprise Operations

    Product Integration Environment The environment for product integration can either be acquired or developed. To establish an environment, requirements for the purchase or development of equipment, software, or other resources will need to be developed. These requirements are gathered when implementing the processes associated with the Requirements Development process area. The product integration environment can include the reuse of existing organizational resources. The decision to acquire or develop the product integration environment is addressed in the processes associated with the Technical Solution process area.
    • Solution Engineering

    • Enterprise Operations

    Product Integration Procedure Product Integration procedures for the integration of the product components can include such things as the number of incremental iterations to be performed and details of the expected tests and other evaluations to be carried out at each stage.
    • Solution Engineering

    • Enterprise Operations

    Product Integration Criteria Product Integration criteria indicate the readiness of a product component for integration or its acceptability
    • Solution Engineering

    • Enterprise Operations

    Delivered Products Products installed at the operational site and confirmed to operate correctly.
    • Enterprise Operations

Activities

  1. An activity is a major unit of work to be completed in achieving the objectives of the process. A process consists of a sequence of related activities that transforms inputs into outputs and performed by the roles defined in the process. Identify the activities in the process and provide a brief description. The activities must correspond with the high-level process flow diagram above.

    [Complete process activities table. See examples below].

    ID Name Description
    PI 1.0 Prepare for Product Integration
    • Establish and maintain a product integration strategy that describes the approach for receiving, assembling, and evaluating the product components and aligns with the technical approach.

    • Establish and maintain the environment needed to support the integration of product components.

    • Establish and maintain procedures and criteria for integration of te product components.

    PI 2.0 Review Interface Descriptions for Completeness The purpose of this step is to ensure that implemented interfaces are complete and compatible.
    PI 3.0 Manage Interfaces The purpose of this step is to manage the interfaces to ensure consistency of the interfaces throughout the life of the system, compliance with architectural decisions and constraints, and resolution of conflict, noncompliance, and change issues.
    PI 4.0 Confirm Readiness of System Components for Integration The purpose of this step is to ensure that the properly identified system component that meets its description can actually be assembled according to the product integration strategy and procedures.
    PI 5.0 Assemble System Components The purpose of this step is to assemble system components according to the product integration strategy and procedures.
    PI 6.0 Evaluate Assembled System Components The purpose of this step is to ensure the compatibility of the interfaces. This evaluation involves examining and testing assembled product components for performance, suitability, security, and readiness using the product integration procedures, criteria, and environment.
    PI 7.0 Package and Deliver the System or System Components The purpose of this step is to assemble the system for independent testing.

Procedure

  1. Procedure

PI 1.0: Prepare for Product Integration
    • Establish and maintain a product integration strategy that describes the approach for receiving, assembling, and evaluating the product components and aligns with the technical approach.

    • Establish and maintain the environment needed to support the integration of product components.

    • Establish and maintain procedures and criteria for integration of the product components.

    There can only be 1 Role that is Responsible for a Task. See example below for the first Activity.

    ID Task Name and Description Role RACI
    PI 1.1

    Identify the system components to be integrated.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.2 Identify the verifications to be performed during the integration of the system components. This identification includes verifications to be performed on interfaces.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.3 Identify alternative system component integration strategies. Developing an integration strategy can involve specifying and evaluating several alternative integration strategies or sequences.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.4 Select the best integration strategy.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.5 Periodically review the product integration strategy and revise as needed.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.6 Record the rationale for decisions made and deferred.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.7 Identify the requirements for the product integration environment.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.8 Identify verification procedures and criteria for the product integration environment.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.9 Decide whether to make or buy the needed product integration environment.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.10 Develop an integration environment if a suitable environment cannot be acquired.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.11 Maintain the product integration environment throughout the project.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.12 Dispose of those portions of the environment that are no longer useful.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.13 Establish and maintain criteria for system component integration and evaluation.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.14 Establish and maintain criteria for validation and delivery of the integrated system.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

     

Prepare for Product Integration Cross Functional Flow Diagram
  1. PI 1.0 Prepare for Product Integration Cross Functional Diagram

    Figure 2.120.3-2

    This is an Image: 59978002.gif
     

    Please click here for the text description of the image.

2.0 Review Interface Descriptions for Completeness
  1. The purpose of this step is to ensure that implemented interfaces are complete and compatible.

    Figure 2.120.3-3

    ID Task Name and Description Role RACI
    PI 2.1 Review interface data for completeness and ensure complete coverage of all interfaces.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    PI 2.2 Ensure that system components and interfaces are marked to ensure easy and correct connection to the joining system component.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    PI 2.3 Periodically review the adequacy of interface descriptions.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    PI 2.4 Conditional Activity: If interface issues are discovered, advise the Technical.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    PI 2.5 Solution (TS) Process practitioner return to TS Process Step 4 in order to correct the issues. When the interface issues have been corrected, resume Product Integration Step 2.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

Review Interface Descriptions for Completeness Cross Functional Flow Diagram
  1. Review Interface Descriptions for Completeness Cross Functional Flow Diagram

    Figure 2.120.3-4

    This is an Image: 59978003.gif
     

    Please click here for the text description of the image.

3.0 Manage Interfaces
  1. The purpose of this step is to manage the interfaces to ensure consistency of the interfaces throughout the life of the system, compliance with architectural decisions and constraints, and resolution of conflict, noncompliance, and change issues.

    Figure 2.120.3-5

    ID Task Name and Description Role RACI
    PI 3.1 Ensure the compatibility of the interfaces throughout the life of the system.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 3.2 Resolve conflict, noncompliance, and change issues.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 3.3 Create and maintain a repository for interface data accessible to all project participants.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 3.4 Update Configuration Item information if required.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

Manage Interfaces Cross Functional Flow Diagram
  1. Manage Interfaces Cross Functional Flow Diagram

    Figure 2.120.3-6

    This is an Image: 59978004.gif
     

    Please click here for the text description of the image.

4.0 Confirm Readiness of System Components for Integration
  1. The purpose of this step is to ensure that the properly identified system component that meets its description can actually be assembled according to the product integration strategy and procedures.

    Figure 2.120.3-7

    ID Task Name and Description Role RACI
    PI 4.1 Track the status of all system components as soon as they become available for integration.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    PI 4.2 Ensure that system components are delivered to the product integration environment in accordance with the product integration strategy and procedures.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    PI 4.3 Confirm the receipt of each properly identified system component.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    PI 4.4 Ensure that each received system component meets its description.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    PI 4.5 Check the configuration status against the expected configuration.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    PI 4.6 Perform a pre-check (e.g., by a visual inspection, using basic measures) of all the physical interfaces before connecting system components together.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    PI 4.7 Conditional Activity: If system component design issues are discovered, advise the Technical Solution (TS) Process practitioner return to TS Process Step 5 in order to correct the issues. When the system component design issues have been corrected, resume Product Integration Process Step 2.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    PI 4.8 Conditional Activity: If system component implementation issues are discovered, advise the Technical Solution (TS) Process practitioner return to TS Process Step 7 in order to correct the issues. When the system component implementation issues have been corrected, resume Product Integration Process Step 2.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

Confirm Readiness of System Components for Integration Cross Functional Flow Diagram
  1. Confirm Readiness of System Components for Integration Cross Functional Flow Diagram

    Figure 2.120.3-8

    This is an Image: 59978005.gif
     

    Please click here for the text description of the image.

5.0 Assemble System Components
  1. The purpose of this step is to assemble system components according to the product integration strategy and procedures

    Figure 2.120.3-9

    ID Task Name and Description Role RACI
    P1.5.1 Ensure the readiness of the product integration environment.
    • Component Designer

    • Developer

    • R

    • C

    P1.5.2 Conduct integration in accordance with the product integration strategy, procedures, and criteria.
    • Component Designer

    • Developer

    • R

    • C

    P1.5.3 Record all appropriate information (e.g., configuration status, serial numbers of the system components, types, calibration date of the meters).
    • Component Designer

    • Developer

    • R

    • C

    P1.5.4 Revise the product integration strategy, procedures, and criteria as appropriate.
    • Component Designer

    • Developer

    • R

    • C

    .

Assemble System Components Cross Functional Flow Diagram
  1. Assemble System Components Cross Functional Flow Diagram

    Figure 2.120.3-10

    This is an Image: 59978006.gif
     

    Please click here for the text description of the image.

6.0 Evaluate Assembled System Components
  1. The purpose of this step is to ensure the compatibility of the interfaces. This evaluation involves examining and testing assembled product components for performance, suitability, security, and readiness using the product integration procedures, criteria, and environment

    Figure 2.120.3-11

    ID Task Name and Description Role RACI
    P1 6.1 Conduct the evaluation of assembled system components following the product integration strategy, procedures, and criteria.
    • Lead Integrator

    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    • C

    P1 6.2 Record the evaluation results.
    • Lead Integrator

    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    • C

    P1 6.3 Conditional Activity: If issues are discovered regarding the assembled components, advise the Technical Solution (TS) Process practitioner return to TS Process Step 7 in order to correct the issues. When the issues regarding assembled components have been corrected, resume Product Integration Process Step 2.
    • Lead Integrator

    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    • C

    .

Evaluate Assembled System Components Cross Functional Flow Diagram
  1. Evaluate Assembled System Components Cross Functional Flow Diagram

    Figure 2.120.3-12

    This is an Image: 59978007.gif
     

    Please click here for the text description of the image.

7.0 Package and Deliver the System or System Components
  1. The purpose of this step is to assemble the system for independent testing.

    Figure 2.120.3-13

    ID Task Name and Description Role RACI
    P1. 7.1 Review the requirements, design, system, verification results, and documentation to ensure that issues affecting the packaging and delivery of the system are identified and resolved.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    P1. 7.2 Use effective methods to package and deliver the assembled system.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    P1. 7.3 Satisfy the applicable requirements and standards for packaging and delivering the system.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    P1. 7.4 Prepare the operational site for installation of the system.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    P1. 7.5 Preparing the operational site may be the responsibility of the customer or end users.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    P1. 7.6 Deliver the system and related documentation and confirm receipt.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    P1. 7.7 Install the system at the operational site and confirm correct operation.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    P1. 7.8 Conditional Activity: If target environment integration issues are discovered, advise the Technical Solution (TS) Process practitioner return to TS Process Step 1 in order to correct the issues. When the target environment integration issues have been corrected, resume Product Integration Process Step 2.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

Package and Deliver the System or System Components Cross Functional Flow Diagram
  1. Package and Deliver the System or System Components Cross Functional Flow Diagram

    Figure 2.120.3-14

    This is an Image: 59978008.gif
     

    Please click here for the text description of the image.