Friday, January 19, 2018

Risk Assessment Tool

At
my current client, we use a Change Request approach to Maximo changes.
A Change Request is created describing the new functionality desired.
Developers work on these changes in separate Subversion branches.
Change Requests are chosen for a Release, then merged together, tested,
and deployed. The merged changes are then merged back into our Trunk
and the process repeats. Change Requests are not necessarily deployed
during the next Release. It can be several Releases before a Change
Request is deployed.

When it is decided to include a Change in a Release, a risk
assessment is performed. Two common questions are “What has this change
touched,” and “Does it require regression testing.” The intent is not
to get into the details of the change, but to provide a rough overview
that can help QA get an idea of the scope of the change.

We have recently introduced a Risk Assessment Tool modeled on the FAA’s Flight Risk Assessment Tool. It is available on GitHub. We are looking for a better acronym than MRAT or RAT when referring to this tool. I welcome any input on the matter.

It is simply a list of development activities that are weighted depending on their potential impact.

Once development on a Change Request is complete, the developer
creates a copy of the Risk Assessment Tool specific for their change.
The developer goes through and places a “1” in the Applicable column for
anything that applies. An overall score for the page is calculated
automatically.

The development activities are then grouped together into more general types of changes and provides an overall score.

The end product is an overall summary of what has been changed (e.g.
Screen, Database, Coding, etc.) and a score that gives an idea of the
size of the change. A bigger number means a bigger change means bigger
risk and implies more testing.

The Considerations column contains notes to the developer to check
common mistakes associated with a change. For example, a consideration
for adding a database column that is part of an Object Structure is that
it has the potential of affecting external systems that consume that
Object Structure. The consideration column also contains notes to QA
about what should be tested. When an Mbo save method is modified, the
Consideration is that testing should include saving a record.

The Score calculation is simply Weight × Applicable. The common
usage is to place a “1” in the Applicable column. In the beginning we
toyed around with the idea of using larger numbers to represent larger
changes. For example, if two Mbo classes were modified, then place a
“2” in the Applicable column. We felt this had the potential of
overweighting changes. We decided to go with ranges — 1 file, 2 to 5
files, etc — each with a different weight.

Where the FAA Flight Risk Assessment Tool gives meaning to the
calculated scores — 0-10 Not Complex Flight, 11-20 Exercise Caution,
20-30 Area of Concern — we haven’t yet determined appropriate ranges and
what those ranges might mean, so any outside thoughts or input would be
welcome.
There are some obvious areas that are missing from this tool, such as
Work Flow. We don’t use it, so we don’t have a section for it. So any
thoughts or input would be welcome here as well.

The Risk Assessment Tool is a simple approach that gives an overview of
where changes took place and how much of an impact they might have.