Decision trees

By -

Decision trees

57.1 Purpose

A decision tree is a two-dimensional graphic representation of the decisions, events, and consequences associated with a problem. Decision trees are decision science tools typically used to determine probabilities and/or expected values and to illustrate alternative system strategies. They can also be used to plan or document all possible paths through a series of nested decisions.

57.2 Strengths, weaknesses, and limitations

When an algorithm involves more than two or three nested decisions, a decision tree gives a clear and concise picture of the logic. Such algorithms are difficult to describe using logic flowcharts (Chapter 55), Nassi-Shneiderman charts (Chapter 56), pseudocode (Chapter 59), or structured English (Chapter 60).

Decision trees are not useful for planning or documenting non-decision algorithms. Many technical people are unfamiliar with decision science, so a decision tree might not be an effective communication tool.

57.3 Inputs and related ideas

Before creating a decision tree, the designer must understand the algorithm or procedure. The necessary information might be compiled from direct observation, extracted from existing documentation, or derived from the problem definition (Part II) and/or analysis (Part IV) stages of the system development life cycle.

Other tools for documenting or planning routines or processes include logic flowcharts (Chapter 55), Nassi-Shneiderman charts (Chapter 56), decision tables (Chapter 58), pseudocode (Chapter 59), structured English (Chapter 60), and input/process/output (IPO) charts (Chapter 64). A routine usually exists in the context of a larger program. Tools for documenting or planning program structure include structure charts (Chapter 63) and HIPO (Chapter 64).

57.4 Concepts

Decision trees are decision science tools that can be used to plan or document nested decision logic.

57.4.1 Decisions, events, and outcomes

Imagine a company has an opportunity to purchase for $500,000 exclusive rights to market a new product. If the product succeeds, the company stands to make $1,000,000. On the other hand, if the product fails, the company loses its entire investment.

The decision tree pictured in Figure 57.1 graphically represents the problem. The tree starts (on the left) with an act fork (a small box) that indicates a decision. Emanating from it are two branches representing the two choices:buy or do not buy the rights.

Move along the buy branch. The circle represents an event fork. An event is an occurrence that is not entirely subject to the decision-maker’s control. (In other words, an event carries risk.) Coming from the event fork are branches representing all possible consequences (or outcomes) of the decision. (In this case, the product is either a success or a failure.) At the far right, each branch terminates in an outcome. If the product is successful, the company stands to make $1,000,000. If it fails, the company loses $500,000.

57-01
Figure 57.1  A decision tree.

Go back to the act fork. Before the decision is made, the company has an option not to buy the rights. Clearly, this decision will cost nothing. There are no consequences associated with this choice, so the outcome is zero whether the product is successful or not.

The oval symbols at the right of the decision tree list all possible outcomes. At this point, a management scientist or decision scientist might associate probabilities with each outcome, compute the expected values, and determine whether or not rights should be purchased.

57.4.2 Nested decisions

Decision trees can also be used to model nested decisions. Assume, for example, that the men’s basketball coach wants to look through the student records and produce a list of all full-time male students who are at least 6 feet 5 inches (or 77 inches) tall and who weigh at least 180 pounds. The algorithm consists of a series of four nested questions or decisions (Figure 57.2), each one represented as a box (an act fork).

Start with the first question: Is the student at least 77 inches tall? There are only two possible answers. If the student is less than 77 inches tall, he or she is rejected. If the student is greater than or equal to 77 inches tall, a second question is asked, and so on. Follow each branch on the tree to its logical outcome. Note that a student’s name and address are listed only if the student meets all four criteria.

57.4.3 Decision algorithm efficiency

Once a decision tree is drawn, probabilities can be associated with each branch and the expected values of the outcomes computed. The systems analyst can take advantage of this idea to improve the efficiency of an algorithm.

57-02
Figure 57.2  A decision tree can be used to model nested decisions.

Consider, for example, the basketball problem. Rank the tests from most to least discriminating. The height requirement will eliminate all but a handful of the students. Significantly less than half the students will meet the 180-pound requirement. The gender question (male or female) will eliminate roughly half the students. The credit hour question is the least discriminating because, on a residential campus, most students take at least twelve hours, and on a commuter campus, most students do not.

If the height requirement is tested first, only perhaps 5 percent of the records will pass and thus be subject to subsequent tests. If, on the other hand, the credit hour test is conducted first, as many as 90 percent of the students (on a residential campus) might pass the first test and thus be subject to additional tests. In general, performing the most discriminating test first, the second most discriminating test second, and so on results in fewer total tests actually being executed.

57.5 Key terms
Act fork —
A point on a decision tree (represented by a box) where a decision is made.
Event —
An occurrence that is not entirely subject to the decision-maker’s control.
Event fork —
A point on a decision tree (represented by a circle) where subsequent branches identify the consequences (or possible outcomes) of a decision.
Outcome —
On a decision tree, a final result of a series of decisions and/or outcomes.
57.6 Software

The decision trees in this chapter were prepared using Visio. Other charting programs (such as Micrografx’s Flowcharter) can also be used.

57.7 References
1.  Brown, R. V., Kahr, and Peterson, Decision Analysis for the Manager, Holt, Rinehart & Winston, New York, 1974.
2.  Davis, W. S., Systems Analysis and Design: A Structured Approach, Addison-Wesley, Reading, MA, 1983.

Comments

Post a Comment

Popular posts from this blog

The Conversion Cycle:The Traditional Manufacturing Environment

By -
Image
The Traditional Manufacturing Environment The conversion cycle consists of both physical and information activities related to manufacturing products for sale. The context-level data flow diagram (DFD) in Figure 7-1 illustrates the central role of the conversion cycle and its interactions with other business cycles. Production is triggered by customer orders from the revenue cycle and/or by sales forecasts from marketing. These inputs are used to set a production target and prepare a production plan, which drives production activities. Purchase requisitions for the raw materials needed to meet production objectives are sent to the purchases procedures (expenditure cycle), which prepares purchase orders for vendors. Labor used in production is transmitted to the payroll system (expenditure cycle) for payroll processing. Manufacturing costs associated with intermediate work-in-process and finished goods (FG) are sent to the general ledger (GL) and financial reporting system. Dependin...
Read more

The Revenue Cycle:Manual Systems

By -
Image
Manual Systems The purpose of this section is to support the system concepts presented in the previous section with models depicting people, organizational units, and physical documents and files. This section should help you envision the segregation of duties and independent verifications, which are essential to effective internal control regardless of the technology in place. In addition, we highlight inefficiencies intrinsic to manual systems, which gave rise to modern systems using improved technologies. SALES ORDER PROCESSING The system flowchart in Figure 4-12 shows the procedures and the documents typical to a manual sales order system. In manual systems, maintaining physical files of source documents is critical to the audit trail. As we walk through the flowchart, notice that in each department, after completion of the assigned task, one or more documents are filed as evidence that the task was completed. Sales Department The sales process begins with a customer cont...
Read more

Nassi-Shneiderman charts

By -
Image
Nassi-Shneiderman charts 56.1 Purpose Nassi-Shneiderman charts were developed by Nassi and Shneiderman as an alternative to traditional logic flowcharts. Their intent was to provide a structured, hierarchical, graphical view of the flow of logic through a program, a routine, a module, or a process. Nassi-Shneiderman charts are used to document, plan, and design detailed program logic. 56.2 Strengths, weaknesses, and limitations A properly prepared Nassi-Shneiderman chart can illustrate the flow of logic through a module or routine at a glance. Nassi-Shneiderman charts are useful for describing or planning relatively small modules, routines, or processes. They can be used to clearly show nesting and recursion, and are easily converted to structured code. Nassi-Shneiderman charts should not be used for documenting complete programs or large routines. As a general rule, Nassi-Shneiderman charts should be limited to a single page with no more than 20 subdivisions. For larger rout...
Read more