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="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.

Tip

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

Note

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 following mandatory attributes:

expr is the expression of the computation, see Chapter 5, Computation Syntax for more details.
bounds is the interval within which the computation result evaluates to true. The syntax is the same as the one used for defining scaleLevel bounds (see the section called “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["
```

The following optional attributes may also be used:

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}=The complexity is too high (value={0})
```

Prev	Up	Next
Dynamic Action Plans	Home \| ToC	Chapter 5. Computation Syntax