Home > Articles > Programming

📄 Contents

  1. 1.1 Chapter Objectives
  2. 1.2 Context
  3. 1.3 Decision Model for Software Engineering
  4. 1.4 Summary
  • Print
  • + Share This
This chapter is from the book

1.3 Decision Model for Software Engineering

For many people, the decision-making process consists of three basic (and usually vague) stages:

  1. Information goes into a decision process.
  2. A person-dependent miracle occurs.
  3. A solution or decision comes out.

Professionals often consider people to be experts or gurus in their fields if they can make good decisions easily. This section gives an overview of a decision model whose purpose is to help software professionals manage their decision processes so that they better understand the solutions they generate.

The PEAK decision model presented in Figure 1-2 does not indicate "what a particular decision should be." It simply implies that stakeholders need to carefully examine their decision processes to help ensure that successful decisions are made. When making decisions, stakeholders should consider the inputs and their relationship to the solution as well as the risk assumed with alternative solutions. The model provides insight into how the inputs and outputs of the decision-making process influence the way in which decisions are made.

Figure 1-2

Figure 1-2 PEAK decision model

The inputs to the decision model are the following elements:

  • (P) Problem: What is the issue to be resolved or the problem to be solved? The problem statement should provide a clear representation of what needs to be solved.
  • (E) Experience: From prior events, what does the decision maker know or know how to do that might help with this problem? Has the decision maker seen or solved a problem like this one before? How appropriate and accurate is the decision maker's historical information?
  • (A) Assumptions: What information is accepted as fact without having evidence? What information about the problem does the decision maker abstract away because the information is not thought to be relevant to the solution?
  • (K) Knowledge: What conceptual understanding or factual basis can help the decision maker with the problem? What has the decision maker learned since last dealing with a problem like this? What facts does the decision maker have about the problem? What is the environment that surrounds this problem? For instance, when looking at military problems to be solved, soldiers might ask, "What is the current situation and terrain?"

The outputs from the model are the following elements:

  • Solution: What do the stakeholders need in order to solve the problem or to resolve the issue? What alternative solutions are feasible, and why? What are the benefits and cost associated with each alternative? Have the relevant stakeholders discussed the issues concerning the alternative solutions and expressed their preferences? The stakeholders may not know whether a solution is successful until they implement it. The results, whether successful or not, of implementing a decision feed back into the model as part of the decision maker's knowledge and experience. In response to a colleague who asked whether he thought himself to be a failure, Thomas Edison said, "Not at all. Now, I definitely know more than a thousand ways for how NOT to make a light bulb" (Rovira and Trias de Bes 2004, 1).
  • Assumed Risk: What is the probability that the solution will not work as envisioned? When a stakeholder makes a decision, the stakeholder assumes some level of risk that the solution or decision will not lead to a successful result. Risk is a consequence of making decisions. What are the risks associated with the alternative solutions? Have the relevant stakeholders discussed these risks with respect to their preferences for the alternatives?

Even if the decision maker is not aware of them, the inputs and outputs of a decision always exist when a decision is being made. To manage their decisions, stakeholders need to identify and manage these inputs and outputs when making decisions. The case studies in the book will describe situations in which most but not necessarily all of the inputs are known. Each case study will present the problem, the assumptions, and many facts. You will bring other knowledge and experience as inputs to the decision model. This book will help you use the inputs and feasible outputs of the model, as they occur in the case studies, to evaluate your decision processes.

So, why do decision makers need a model for evaluating decisions? A model helps decision makers think about the following aspects of their decision processes:

  • Information that should be considered in making decisions
  • The impact that the inputs to the decision process have on the outputs
  • Solutions that are feasible with respect to the nature of the problem
  • The assumed risk associated with alternative solutions
  • Ways to improve the management of decisions

The remainder of this section provides four examples to illustrate how you can apply the model to the decision process. These examples clarify how to apply the model to evaluate alternative solutions and then to make a decision by selecting the best alternative. The first example, "Software Test Rerun Problem," shows how to identify the inputs and outputs to a decision regarding whether to rerun a software test. The second example, "California Bridge Problem," demonstrates how to apply the model to the more complex problem of building a bridge that can withstand earthquakes, a major issue for the California Department of Transportation. This example demonstrates how newly acquired knowledge feeds back into the decision-making process. The third example, "Unfamiliar Legacy Code Problem," highlights the risk that is assumed when making a decision. The last example, "Data-Processing Problem," clarifies why it is important to understand the nature of the real problem before working on a solution. The diagram shown with each story problem summarizes key inputs and outputs for the decision being made.

  • + Share This
  • 🔖 Save To Your Account