Developers can exploit the knowledge documentation during changes, to estimate change impacts. The node-link diagram, tree, list, and matrix views can be used for change impact analysis (CIA). ConDec colors the knowledge elements in these views according to the likelihood that they are affected by a change in the selected element. Darker elements have a high estimated impact value, whereas bright elements have a low impact value. The knowledge graph visualization and change impact analysis supports the developers to make new decisions consistent with the requirements and former decisions.
Knowledge tree (indented outline) with change impact highlighting. Issues and decisions are shown that a change in the root element (starting impact set) might impact. The color indicates the likelihood of change impacts: A change probably impacts darker elements more. The tooltip explains the estimated impact value.
During change impact analysis, each knowledge element (i.e. node/vertex) in the knowledge graph is given an impact value (i.e. impact factor).
Developers can choose to include new links recommended by ConDec in the CIA calculation.
High impact values indicate that the element is highly affected by the change and needs to be changed as well.
The impact value of an element (elementImpact) is calculated using the following equation:
elementImpact = (1 - decayValue) * linkTypeWeight * ruleBasedValue * recommendationScore
where decayValue is the decay per iteration step, linkTypeWeight is a link type specific decay value between 0 and 1 of the traversed edge between the parent/ancestor element and the current element, ruleBasedValue is the normalized sum of all enabled rules
ruleBasedValue = (∑N(ruleValuei * ruleWeighti -〚ruleWeighti < 0〛ruleWeighti)) / ∑NruleWeighti
where N is the number of enabled rules, and
-〚ruleWeighti < 0〛ruleWeighti denotes that the subtraction is only done for negative rule weights to reverse the effect.
The variable recommendationScore is the link recommendation score of the current element, if the element was recommended.
The following rules are available:
- Boost when element is the link target
- Boost when element has the same creator as the selected element
- Boost when element is textual similar to the selected element
- Boost when element is assigned to the same component
- Boost when element is assigned to the same decision group
- Boost when element was quickly finished
- Boost when element has more outbound than inbound links
- Boost when element has a large amount of distinct update authors
- Boost when element received updates in the same timeframe (i.e. is timely coupled)
- Boost when element has the same knowledge type
- Boost when element is a decision problem
- Boost when element is a solution option
The element is included in the estimated impact set (EIS) if elementImpact >= threshold.
Developers can see an explanation for the impact factor of each node via a tooltip.
The rationale manager can set the default parameters for the change impact analysis, e.g. the decay value, threshold and default ruleset. In addition, they can set a weight value for each rule. A high weight value indicates a rule being more important than usual and increases the impact of that rule accordingly. Furthermore, the developer can change the default values during the usage of change impact analysis. If new links are being recommended, developers can further adjust whether recommendations are being included in CIA.
Change impact analysis configuration page
The following class diagram gives an overview of relevant backend classes for the change impact analysis.
The class ChangeImpactAnalysisRest provides the interface to the frontend.
ChangeImpactAnalysisService serves as the main hub that connects all relevant CIA classes.
To achieve CIA, Calculator is called first. This class calculates the change impact of each element and uses KnowledgeElementWithImpact to store the result.
It uses the ChangeImpactAnalysisConfig to get the configuration information for a project when a request is received. The configuration includes weight value, decay, threshold and a list of ChangePropagationRule. Each rule stores an enum ChangePropagationRuleType and the corresponding weight value. Each of these enums has a distinct ChangePropagationFunction that is implemented by twelve available classes:
BoostWhenLinkTarget, implements a function that defines that a change impact is stronger propagated if the traversed element in the knowledge graph is the link target.BoostIfTextualSimilar, implements a function that defines that a change impact is stronger propagated if the traversed element in the knowledge graph is similar to the selected element.BoostWhenEqualComponent, implements a function that defines that a change impact is stronger propagated if the traversed element in the knowledge graph is assigned to the same component.BoostWhenEqualDecisionGroup, implements a function that defines that a change impact is stronger propagated if the traversed element in the knowledge graph is assigned to the same decision group.BoostWhenMoreOutboundLinks, implements a function that defines that a change impact is stronger propagated if the traversed element in the knowledge graph has more outbound elements than inbound elements.BoostWhenQuicklyFinished, implements a function that defines that a change impact is stronger propagated if the traversed element in the knowledge graph was quickly finished.BoostWhenHighAmountOfDistinctAuthors, implements a function that defines that a change impact is stronger propagated if the traversed element in the knowledge graph has a large amount of distinct update authors.BoostWhenTimelyCoupled, implements a function that defines that a change impact is stronger propagated if the traversed element in the knowledge graph is coupled with the source element, i.e. if both have received updates in the same timeframe.BoostWhenEqualCreator, implements a function that defines that a change impact is stronger propagated if the traversed element in the knowledge graph has the same creator, reporter or assignee.BoostIfSolutionOption, implements a function that defines that a change impact is stronger propagated if the traversed element in the knowledge graph is of type solution option.BoostIfDecisionProblem, implements a function that defines that a change impact is stronger propagated if the traversed element in the knowledge graph is of type decision problem.BoostWhenEqualKnowledgeType, implements a function that defines that a change impact is stronger propagated if the traversed element in the knowledge graph has the same type.
Once the calculation completes, either a VisGraph, Matrix or TreeViewer view object is created using the results. Then, Colorizer is called. This class utilizes the impact score to colorize each VisNode, MatrixNode or TreeViewerNode of the previously created object accordingly.
Once complete, Tooltip is called. This class utilizes all gathered information to generate and attach a distinct tooltip to each node. ChangeImpactAnalysisService then returns the view object, therefore concluding the CIA process.
Overview class diagram for the change impact analysis
The Java code for the change impact analysis can be found here:
The UI code for the change impact analysis can be found here:
The knowledge was exported via ConDec's knowledge export feature.
Which metrics/rules do we use for change impact analysis (CIA)?
discarded: Number of past updates
Is already included in a different metric
If solution option- If decision problem
- Ratio between outbound and inbound links
- Low average age
- Same decision group
- Same creator
- Same component
- Same knowledge type
- Textual similarity
- Number of distinct update authors
- Outbound links only
- discarded: Number of changes to the artifact compared to total number of changes to all artifacts
- Time-consuming calculation due to iteration over all elements in a project