Methods & Tools Software Development Magazine

Software Development Magazine - Project Management, Programming, Software Testing

Scrum Expert - Articles, tools, videos, news and other resources on Agile, Scrum and Kanban

A Decision Table Based Methodology for the Analysis of Complex Conditional Actions - Page 2

D. Robert Baker

Taking Action: Decision Table Methods for Describing Policy

Given that we have:

  • a method of expressing policy that is
  • concise,
  • comprehensive,
  • rigorous, and
  • easy to use and understand, and
  • a mechanism for machine translation directly from this expression to executable code that implements the policy,

How do we get from the messy real world of policy to a nice, neat, unambiguous decision table in a spreadsheet ready for machine translation?

Step 1: Determine Policy Scope

A project without a predefined scope is subject to peril in the forms of:

  • Scope creep Project goals will naturally expand without anything to constrain them. Because of human nature and project politics, more and more desired results will find their way under the project umbrella.
  • Lack of definition of project completion criteria To meet project completion schedules and budget goals, it must be possible to objectively determine whether and when the project is finished. This is only possible if all parties clearly understand beforehand the project completion criteria. Without a clear predefined scope, an objective evaluation of project completion cannot be accomplished.

It is often difficult to define terms for project scope that are unambiguous and easily determinable to meet the needs of all parties. The use of decision tables makes this a very straightforward task.

The scope of a policy project is determined by delineating all the policy that to be implemented. In decision table terms, policy implementation is expressed by actions. The project itself consists of determining and expressing the conditions under which these actions will be taken.

The scope of a decision table-based policy project is determined by enumerating all the actions that may possibly be taken. Such an enumeration is simple, unambiguous and clearly defines the boundaries of the project beyond argument.

Figure 5 a typical statement of scope for the policy expressed in Figure 1

Step 2: Determine Policy Authority

What are our policies, anyway? Where do we find them? Are they all written in point form in a big book somewhere? Is there one person in an office somewhere who knows them all and can explain them on demand? Probably not.

In most organizations, the sum total of policy is known and maintained by an intricate network of documentation and subject matter experts. It’s rare to find a single source.

Additionally, personnel come and go. Expertise is gained and lost. Documentation is constantly in a state of flux. New policy is added and old policy is phased out. There is usually a lag time in the maintenance of the corresponding documentation, often with documentation in different locations being updated at different times, if ever.

A definitive authority must be established for each area of policy of interest. This authority may be:

  • A statement of policy Simple, straightforward policy may be interpreted directly without the aid of an subject matter expert. It must not be possible to debate the interpretation of the policy. There must not be different versions of the policy available. If there are different versions, either in different locations or from different points in time, one must be designated as the authority or a definitive version created from the variants.
  • A subject matter expert If the policy has any ambiguity or is at all subject to interpretation, it is necessary to designate someone as the authority. This authority must have the power to speak for the organization as to the definitive interpretation of the policy.
  • A group of subject matter experts Commonly, policy crosses boundaries of intra-organizational expertise. It may be necessary to designate a committee with empowered representatives from each area concerned with the policy to represent their areas’ interests in the interpretation of the policy. The committee may debate policy issues as they see fit. As in the case of a single subject matter expert, the committee’s final conclusion must have the authority to make the definitive interpretation of the policy.

The more complex, indefinite, and ambiguous the policy, the more important it is to have properly constituted authority designated to interpret, and if necessary, more rigorously define it. Someone must have the final word.

Fuzzy logic in policy can be dealt with in decision tables as easily as in any other implementation. This is not to be confused with "fuzzy policy", which needs to be clarified by the appropriate authority before any implementation is possible.

Figure 6 a note on fuzzy logic

Step 3: Partition Policy

Policy should generally be partitioned in the interests of analytical efficiency. Different groups of analysts and subject matter experts can pursue work in different partitions in parallel. Bases for policy partitioning include:

  • The separate actions identified in Step 1This is the simplest basis for partitioning but may result in too many partitions to be efficient.
  • The subject matter areas identified in Step 2 This is the most natural basis for policy partitioning. A subject matter expert group will naturally have jurisdiction over areas of policy related by their expertise. Partitioning in this way allows the analyst to work with one group on a larger section of related policy as a unit.
  • Organizational divisions Policy may be neatly divided along organizational lines or it may be completely orthogonal. If there is a strong correspondence between natural policy areas and organizational areas, it may be more efficient to partition policy based on these work areas. Interdepartmental political issues can thus be avoided and access to policy experts localized.

Figure 7 a simple partitioning of the policy scope of Figure 5

Step 4: Elicit Conditions Associated with Actions and Policy Logic

With a firm scope (list of actions to be implemented) and the authorities to definitively interpret policy, the next step is to elicit from these authorities the conditions which affect the actions and the logic used to determine the actions given the conditions.

What form does this specification take? Asking subject matter experts at this point in the process to produce completed decision tables for the actions in their jurisdictions would be placing unnecessary expectations of sophistication upon them. In addition, it is desirable to collate interim results from all policy areas to gain efficiencies over the entire project.

At this stage, we need to gather two things for each of our partitions from our subject area authorities:

  • A list of questions to ask to determine what action to take We want to know which data determines which action to take. Policy experts do not generally think in terms of data. Experience shows that the use of a question format tends to elicit more concise and useful responses from subject matter experts than inquiries after "input data".

Subject matter experts should be asked "What questions would you need answered in order to decide on a course of action?". The source of the answers is unimportant. The answers to these questions may come from users, internal tables, instruments, or even distant databases. We are really looking for the data on which actions depend. For each question (datum) elicited, we need the following metadata:

  • the type of answers that could be used to respond to the question The analyst needs to determine the logical type of all answers that may be given in response to each question. i.e. String, Integer, Enumerated, etc, so that variables may later be set up to contain this information for use of the logic in determining the proper action.
  • the range of answers that could be used to respond to the question The analyst needs to determine all the acceptable answers that may be given in response to each question. i.e. 5 characters, -16.14 to +24.05, one of {brown, black, blue}, etc, so that unacceptable answers can be rejected or ignored and so that we can be sure that some action will be taken for all combinations of acceptable answers.
  • a default answer that will be used to populate the answer variable should an acceptable answer not be forthcoming Whether a user refuses to answer or a data connection is offline, a good implementation of policy will still yield some decision even if it’s "No decision is possible because...". To accomplish this, some data must be used to feed the logic. It is better to have the subject matter expert ponder and decide on this than it is to have the analyst make something up.
  • any dependencies in the order of questions asked e.g. Do the types, ranges, or default answers of any of the questions depend on the answers to other questions? Is the very asking of a question conditional on the answers to other questions? Note that a question may depend on the answers to many other questions and that many questions may depend on the answer toone question.

The question format shows its value here. It makes it clear to the subject matter experts that actions are based on specific pieces of information and helps them to isolate these data.

Figure 8 annotated question list for Partition A and Partition B from Figure 7.

Note: subject matter experts have chosen default values to minimize the chances of serving free drinks should some information not be available!

Note: the default value for question B2 is dependent on the answer to question B1. This implies an order dependency of questions. This dependency must be kept track of for future reference.

Note: policy authorities must sign off on these analyses before proceeding.

A description of the logic used to decide on the actions based on the input data (answers given to the questions) The form of this logic is open. The best method of presentation is that which is at the same time:

  • most comfortable to the subject matter expert,
  • unambiguous, and
  • comprehensible to both the analyst and the subject matter expert.

The policy logic may be delivered in any form that meets these criteria, including those used in Figures 1, 2, 3, 4, or 9. The analyst must show his skill and creativity here in communicating with the subject matter experts to elicit, organize, and present this logic.

The analyst must ensure that:

  • all questions are assigned types, ranges, and default values.
  • the answers to all questions are used in the process of arriving at an action,
  • no action depends on answers to questions not present, and

Having gathered this information, the analyst must:

  • organize it in a tabular format (See Figure 8),
  • fill in any remaining blanks,
  • represent and explain its meaning to the subject matter experts, and
  • restate the associated policy logic to the subject matter experts for verification (See Figure 9).

These authorities then must either sign off this representation of the policy area as correct and authorized or make such changes as necessary to complete this signoff.

Figure 9 Still another method of expressing policy logic

Page 1    Page 3   Back to the archive list

Methods & Tools
is supported by


Testmatick.com

Software Testing
Magazine


The Scrum Expert