Trigger-Based Action Plans

If you want to use a combination of metrics to trigger action plans instead of relying on prioritising findings, Squore allows building your own specification of triggers for action items. The following is an example of a Decision Bundle where an action item is based on specific triggers:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<Bundle>
	<DecisionCriteria>
		<DecisionCriterion dcId="DR_FU_UNTESTABLE" categories="SCALE_PRIORITY.MEDIUM" roles="DEVELOPER;PROJECT_MANAGER" targetArtefactTypes="FUNCTION">
			<Triggers>
				<Trigger>
					<Test expr="IS_CRITICAL_COMPONENT" />
					<Test expr="VG" bounds="[20;[" descrId="UNTESTABLE_VG" p0="#{MEASURE.VG}" />
					<Test expr="NEST" bounds="[4;[" descrId="UNTESTABLE_NEST" p0="#{MEASURE.NEST}" />
					<Test expr="NPAT" bounds="[800;[" descrId="UNTESTABLE_NPAT" p0="#{MEASURE.NPAT}" />
				</Trigger>
				<Trigger>
					<Test expr="VG" bounds="[50;[" descrId="UNTESTABLE_VG" p0="#{MEASURE.VG}" />
				</Trigger>
			</Triggers>
		</DecisionCriterion>
	</DecisionCriteria>
</Bundle>

A DecisionCriterion is an action item definition. At least one Trigger must be true to trigger the automatic generation of an action item on an artefact whose type is defined in the targetArtefactTypes attribute of a DecisionCriterion. A trigger is true when all its tests evaluate to true.

When using the roles attribute for a DecisionCriterion, you limit the visibility of the Action Items defined to the project roles listed only. If the attribute is not present, then the action item is visible to all users who can view the project.

Remember that a decision criterion will evaluate its Triggers using OR, whereas a trigger will evaluate its Tests using AND.

Writing a test

Writing a test, requires using the mandatory expr attribute, which is the expression being tested for, in the form of a computation. See Expressions Syntax for more details about the syntax to use.

The following optional attributes may also be used:

bounds (optional, default: "[1;[") is the interval within which the computation result evaluates to true. If omitted, it defaults to [1;[, meaning that your test evaluates to true if it returns any positive value and false if it returns 0 or a negative value. The syntax is the same as the one used for defining scaleLevel bounds (see Scales), but you can also use some computations via the following syntax:
1. For constants: C.<constantId>
2. For measures: <measureId>
3. For application-level measures: APP(<measureId>)
  
  As an example, the following bound definition is valid to trigger an action item:
  bounds="[APP(LC);C.CST_X["
descrId is description identifier used to set the description of this test.
p{x} defines parameters of the description, use for example:
```
p0="#{MEASURE.VG}"
```
and the description:
```
TST.{descrid}.name=The complexity is too high (value={0})
```