# PROCESS PURPOSE
The purpose is to ensure that the reused (work) products are analyzed, verified, and approved for their target context.
# PROCESS OUTCOMES
O1
Products for reuse are selected using defined criteria.
O2
The products for reuse are analyzed for portability and interoperability.
O3
The limitations for reuse are defined and communicated.
O4
The products for reuse are verified.
O5
The products for reuse are provided to affected parties.
O6
A communication mechanism is established with the reuse product provider.
# BASE PRACTICES
BP1
Select products for reuse. (
O1 )
Select the products to be reused using defined criteria. Note 1: Products for reuse may be (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.), (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) or (Software component = Software component in design and implementation-oriented processes: The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model. Software component in verification-oriented processes: The implementation of a SW component under verification is represented, e.g., as source code, object files, library file, executable, or executable model.), third party components or legacy components.
BP2
Analyze the reuse capability of the products. (
O2 )
Analyze the designated target architecture and the products to be reused to determine their applicability in the target architecture according to relevant criteria. Note 2: The target architecture may be, e.g., (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) architecture, (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) architecture or software architecture. Note 3: Examples for criteria can be requirements compliance, verifiability of the products to be reused in the target architecture, or portability/interoperability.
Linked Knowledge Nuggets: arrow_forward "What key aspects must be considered when reusing components in development projects?"
personAuthor: Process Fellows
Here comes an exemplary list of aspects to be considered when re-using an already existing component for a new system development:
Compatibility:
The reused component must be technically and functionally compatible with the new system environment. This includes interfaces, data formats, protocols, and performance characteristics.
Requirements Alignment:
The component must fulfill the current system’s requirements. Even if it worked in a previous context, it may not meet the specific needs or constraints of the new system. Example: Maybe there are now higher expectations regarding performance of some functions, while this was not so important in previous developments.
Traceability and Documentation:
Clear documentation and traceability of the component’s design, behavior, and limitations are essential. This helps in understanding how it fits into the new system and supports verification and validation.
Licensing and Intellectual Property:
Legal aspects such as licensing terms, usage rights, and intellectual property must be checked, especially when using third-party or open-source components.
Quality and Maturity:
The component should have a proven quality level and maturity. Reusing a component with known issues or insufficient testing can introduce risks. Especially in automotive industry, consider safety aspects: Is it possible to re-use the component in the new environment, if it was development in the past on a "lower" safety integrity level?
Change Management:
If the reused component is updated or modified, changes must be managed carefully to avoid unintended side effects in the new system.
Integration and Testing:
Even if a component is reused, it must be integrated and tested within the new system context to ensure it behaves as expected.
BP3
Define the limitations for reuse. (
O3 )
Define and communicate the limitations for the products to be reused. Note 4: Limitations may address parameters of the operational environment.
BP4
Ensure the qualification of the products for reuse. (
O4 )
Provide evidence that the products for reuse are qualified for the intended use of the (Deliverable = Any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase, or project. Often used more narrowly in reference to an external deliverable, which is a deliverable that is subject to approval by the project sponsor or customer.). Note 5: Qualification may be demonstrated by verification evidence. Note 6: Verification may include the appropriateness of documentation.
BP5
Provide the products for reuse. (
O5 )
Make available the products to be reused to affected parties. Note 7: Refer to HWE.3, SWE.5 or SYS.4 for more information on integration of (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.), software, or (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) components.
BP6
Communicate information about the effectiveness of the reuse activities. (
O6 )
Establish a communication and notification mechanism about experiences and technical outcomes to the provider of reused products. Note 8: The communication with the provider of a reused product may depend on whether the product is under development or not.
# OUTPUT INFORMATION ITEMS
13-52
Communication evidence (
O6 )
Evidence of interpersonal communication.Identifies:
Scope of information
Need for feedback, for example an expected confirmation within one week
Meta data, for example time when communication was done or how information was distributed.
Includes:
Personal information
Work-flows, for example within tools
Examples and References:
E-mails and other forms of memos
Verbal statements
Meeting minutes, for example in standups
Electronic media, for example webcasts, blog posts intranet forum
Chat protocols
Wiki pages
Photo protocol
Used by these processes:
ACQ.4 Supplier Monitoring
HWE.1 Hardware Requirements Analysis
HWE.2 Hardware Design
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements
MAN.3 Project Management
MLE.1 Machine Learning Requirements Analysis
MLE.2 Machine Learning Architecture
MLE.3 Machine Learning Training
MLE.4 Machine Learning Model Testing
PIM.3 Process Improvement
REU.2 Reuse of Products
SUP.1 Quality Assurance
SUP.11 Machine Learning Data Management
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design and Unit Construction
SWE.4 Software Unit Verification
SWE.5 Software Component Verification and Integration Verification
SWE.6 Software Verification
SYS.1 Requirements Elicitation
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
SYS.4 System Integration and Integration Verification
SYS.5 System Verification
VAL.1 Validation
Used by these process attributes:
PA2.1 Process performance management process attribute
04-02
Domain architecture (
O2 )
High-level design and structure specific to a domain.Identifies:
Domain model(s) tailored from
Asset specifications
Definition of boundaries and relationships with other domains, for example within a Domain Interface Specification
Domain vocabulary
Domain representation standard
Includes:
Justifying rationale for the chosen architecture
Functions and features
Capability and concepts of the domain
Used by these processes:
REU.2 Reuse of Products
13-53
Qualification evidence (
O4 )
Evidence that the products for reuse are qualified for the intended use of the (Deliverable = Any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase, or project. Often used more narrowly in reference to an external deliverable, which is a deliverable that is subject to approval by the project sponsor or customer.).Identifies:
Qualification checklist
Passed items
Failed items
Pending items
Problems identified during qualification
Recommendation of actions
Conclusions of qualification
Includes:
(Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) analysis
(Approval = Written statement that a deliverable is fit for its intended use, compliant with defined criteria.)
Applicable standards
Used by these processes:
REU.2 Reuse of Products
15-07
Reuse analysis evidence (
O2, O3 )
Evaluation of suitability for an existing component, requirement, design element, or process to be used in a new (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources requirements.).Identifies:
Constraints for reuse, for example known defects and vulnerabilities
Related change of infrastructure and environment
Functional fit
Compatibility
Dependencies
Maturity
Includes:
Regulatory and standard differences
Characteristics of domain specific architecture
Examples and References:
Reuse of an off-the-shelf component within a different product line.
Used by these processes:
REU.2 Reuse of Products
12-03
Reuse candidate (
O1, O5 )
Description of a product that might be reused.Identifies:
Name of the product
Person responsible for the product
Reuse goals and objectives
List of reuse assets
Issues/ (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) of reusing the product
Person responsible for the qualification of the product to be reused
Type of the product's provision, for example storage location or delivery details
REU.2
Reuse of Products
