Issue tracking in product lines
by Gabriella Martin
Table of Contents
Many companies organize their product range into product lines, i.e. groups of related products. Products then consist of shared parts (“commonalities”) as well as product-specific parts (“specialties”). This article highlights the challenge of systematic issue tracking in such product lines.
If a defect occurs in one product, other products may also be affected. This is the case when errors have their cause in a component that is used in several products, i.e. belongs to the “commonalities”. Defect management in product lines therefore requires special care.
Example of issue tracking in product lines
In the example in Fig. 1, there are two products A and C in versions A1, A2 and C1, C2, respectively, which are composed of the special parts G and R, respectively, and the shared components B and Y.
If an error is detected in component B in version B1, this will affect components A1, C1 and C2 according to Fig. 2. An error can be corrected with B2, which affects product variant A in version A2. Thus, there are three types of associations between components in this context:
- “component is used in”
- “Fault propagates to” (red lines in Fig. 2).
- “Error propagates to” (green lines in Fig. 2).
Error management modeling
All types of these associations are 1:n, i.e., a defect can have an impact in n products or subproducts. For an impact analysis and for tracking defect rectification, the first association is sufficient; the other two can be derived from it
Translated with www.DeepL.com/Translator (free version)
In order to be able to map the constellation described above with shared product components, you need a system that can
- can distinguish between versions of elements
- can create relationships between elements
- can make relationships between elements traceable even across multiple levels
A prerequisite for an impact analysis is the modeling of the relationships of shared components to the using components. To do this, one can proceed as follows using appropriately configurable issue tracking software or project management software:
A separate project (area) is created for each component.
- In this area, exactly one element of the type “component info” (issue type, issue type) is created hierarchically at the top.
- If the software used does not support versions, these must be managed via an element attribute (e.g. “Release”). Then a component info must be created accordingly for each version, e.g. as a child element of a superordinate collective component info.
- If the sub-component is now used in another component in a specific version, a relationship (link) is created with a corresponding link type.
Mapping of components and products to areas in the issue tracking system
For each component and product, a project or workspace is created first. Here it helps if you have a system that can manage areas hierarchically to keep a better overview (the examples here come from the Allegra project management software).
Abb. 3: Abbildung von Komponenten und Produkten auf Bereiche
In Fig. 3, we have arranged the shared components under the “Platform” area and the products under the “Products” area. If one has a lot of components and products, a further structuring is conceivable.
Create association points in areas
To be able to map the relationships between the elements, an association point is created for each area. This can be a task (item, issue) with a corresponding task type. If the software supports baselines of areas, one association point per area is sufficient. Otherwise, the versions must be mapped via an issue attribute (e.g. “release”) with a corresponding list of versions stored in the issue tracking system.
Abb. 4: Assoziationspunkte für Produkte, Komponenten und Teile
The components and products always belong to a baseline (A in Fig. 4). Within a component or product, the association points have versions (B in Fig. 4). The associations are always version-related.
If the system does not support versioning of operations, you have to create a separate association point for each version under the component or product association points, e.g. under KY-1 in Fig. 4.
Basically, a part of a bill of materials has to be replicated here and it has to be considered whether information from a bill of materials management system can be used to automatically create the relationships in an issue tracking system.
Further information
If you are interested in reading more about help desk software, you can do so here. In this article you can see an overview of ticket systems.