Component Product Acquisition

Definition

Component Product Acquisition

the activity consisting of the cohesive collection of all tasks that are primarily performed to support the acquisition of a cohesive collection of one or more off-the-shelf (OTS) products for incorporation as components into a system or software application

Classification

As illustrated in the preceding figure, Component Product Acquisition is part of the following inheritance hierarchy:

• Type: Abstract
• Superclass: Engineering Activity
• Subclasses:
  • Subsystem Acquisition
  • Hardware Acquisition
  • Software Acquisition:
    • Acquisition of Commercial-Off-The-Shelf (COTS) components
    • Acquisition of free and/or open source components

Responsibilities

The typical Responsibilities of component product acquisition are to:

• Ensure that appropriate components are acquired for incorporation into the architecture:
  • Understand the candidate components and their vendors.
  • Understand the candidate solutions involving these components.
  • Understand the impact of the candidate solutions on the system, application, and business process.
  • Select and acquire the appropriate set of components.
• Monitor the components and their vendors.

Preconditions

Component product acquisition typically may begin when the following conditions hold:

• The potential for OTS acquisition has been recognized.
• Adequate funding and staffing to begin supporting the component product acquisition activity has been allocated.
• The component product acquisition team is adequately:
  • Staffed.
  • Trained or experienced in component product acquisition.

Completion Criteria

Although never truely finished as long as an endeavor is underway, the majority of component product acquisition is typically considered complete when the following postconditions hold:

• The OTS components have been analyzed.
• The OTS components vendors have been analyzed.
• The OTS components have been acquired.

Tasks

Component product acquisition typically involves the component product acquisition team performing the following component product acquisitions tasks in an iterative, incremental, and parallel manner:

• Component Product Acquisition Planning
• Candidate Component Identification
• Candidate Vendor Analysis
• Candidate Component Evaluation
• Candidate Component Solution Identification
• Candidate Component Solution Prototyping
• Candidate Component Solution Evaluation
• Business Process Impact Analysis
• Component Selection
• Business Process Modification
• Component Vendor Monitoring
• Component Monitoring

Component product acquisition tasks are closely related to the following tasks:

• Architecture:
  • Architecture Prototyping
  • Technology Evaluation And Selection
  • Technology Vendor Selection
• Management:
  • Scope Management
• Requirements Engineering:
  • Requirements Analysis (negotiation)

Environments

Component product acquisition is typically performed using the following environment(s) and associated tools:

• Component Evaluation Environment:
  • Documentation tools
  • Test tools

Work Products

Component product acquisition typically results in the production of the following work products:

• Acquired Components
• Component Product Acquisition Plan
• Candidate Vendor Analysis:
  • Vendor Analysis Report
  • Vendor Relationship Plan
  • Product License Agreement
• Candidate Component Evaluation:
  • Evaluation Plan
  • Evaluation Requirements
    Potential (i.e., negotiable) requirements and actual (i.e., non-negotiable) requirements that are specific to the evaluation and that drive the determination of the evaluation criteria.
  • Evaluation Criteria
    Evaluation-specific Operational verification method for determining fulfillment of evaluation requirement.
  • Component Dossier
  • Evaluation Data
  • Evaluation Report

Phases

Component Product Acquisition tasks are typically performed during the following phases as documented in the following table:

Guidelines

• Using off-the-shelf components (e.g., COTS) greatly influences how systems and software applications are developed:
  • Requirements must be negotiated to be compatible with available products.
  • Requirements remain fluid longer.
  • Exectable architectures incorporating the component products are produced earlier.
  • Business processes must be modified to be compatible with selected products.
  • Candidate components and their vendors rapidly evolve, requiring ongoing monitoring and evaluation.
  • The need for broad stakeholder involvement and buy-in is greatly increased.
  • There are many additional risks that need to be managed.
• Use of component product acquisition has a major influence on the tailoring other activities and tasks:
  • Requirements negotiation and the differentiation between potential and actual requirements. Also, even actual requirements can be turned into preferences if the stakeholders understand the