In this chapter, we've talked about operational profiles, a quantitative description of frequency of use of use cases and scenario. Let's review: Operational profiles allow an engineering team to allocate time, effort, and resources in proportion to the traffic use cases and scenarios are expected to receive. In doing so, the engineering team focuses their efforts on those use cases and scenarios most likely to have defects in operational use by the customer. The result is a good return on investment in reliability per development and test dollar spent. Decision graphs are a common technique for describing operational profiles and are well suited for describing the operational profile of scenarios that make up a use case. A simple, straightforward technique for describing the operational profile of a package of use cases is to estimate the number of times each use case is expected to be used in some unit of time, say daily, and then calculate the relative frequency of each. UML generalize, include, and extend use cases can be accommodated in this approach, though include and extend make it a tad more complicated. In building an operational profile without empirical results from the field or usability studies, the probabilities you use in your use case decision tree will likely be "guesstimates." The Pareto Principle can often be used to help you get over the "analysis paralysis" of agonizing over probabilities. With an initial guesstimate in place, you can then step back and let your gut instinct help you tweak the numbers. Some use cases don't fit well into the frequency of use model of reliability: the level of reliability we require from a use case that controls an air bag is not proportionate to its frequency of use. Use case criticality can be addressed by extending the operational profile to include the risk exposure of each use case: the likelihood of use case failure multiplied by the expected severity. We have talked about reliability a lot in this chapter, but have not really defined it. In the next chapter, we'll look at a concrete way to talk about reliability allowing us to measure it, set goals in terms of it, and track it in testing. |