| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.4/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.2.0" xmi:id="-nGaswirSOYturOoUWwGdRw" |
| name="product_quality,3.712584012051524E-306" guid="-nGaswirSOYturOoUWwGdRw" changeDate="2006-11-10T13:10:29.938-0500" |
| version="1.0.0"> |
| <mainDescription><h3>
 |
| <a id="Introduction" name="Introduction">Introduction</a>
 |
| </h3>
 |
| <p>
 |
| If you're serious about producing an excellent product, you face two problems:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| How do you know when the product is good enough?
 |
| </li>
 |
| <li>
 |
| If the product is not yet good enough, how do you assure that the stakeholders involved know that?
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| The answer to the first question lets you release the product. The answer to the second question helps you avoid
 |
| releasing a bad product.
 |
| </p>
 |
| <p>
 |
| You might think: "I don't want to ship a merely good enough product; I want to ship a <i>great</i> product!" Let's
 |
| explore that. What happens when you tell your coworkers, managers, or investors that you have high quality standards
 |
| and intend to ship a great product? If it's early in the project cycle, they probably nod and smile. Everyone likes
 |
| quality. However, if it's late in the project cycle, you're under a lot of pressure to complete the project. Creating a
 |
| great product might require that you perform extensive testing, fix many problems (even small ones), add features, or
 |
| even scrap and rewrite a large part of the code. You will also have to resolve disputes over different visions of good
 |
| quality. Greatness is hard work. Perfection is even harder! Eventually, the people who control the project will come to
 |
| you and say something like: "Perfection would be nice, but we have to be practical. We're running a business. Quality
 |
| is good, but not quality <i>at any cost</i>. As you know, all software has bugs."
 |
| </p>
 |
| <p>
 |
| Greatness can be a motivating goal. It appeals to the pride you have in your work. But there are problems with using
 |
| what amounts to "if quality is good, more quality must be better" to justify the pursuit of excellence. For one thing,
 |
| making such an argument can portray you as a quality fanatic, rather than a balanced thinker. For another thing, it
 |
| ignores the cost factor. A BMW is a nice car, but it costs a lot more than a Saturn. A Saturn may not be the ultimate
 |
| driving experience, but it's nice for the money. In leaving out cost, the <i><b>more is better</b></i> argument also
 |
| ignores diminishing returns. The better your product, the harder it gets to justify further improvement. While you
 |
| labor to gold-plate one aspect of a product, out of necessity you must ignore other aspects of the product or even the
 |
| potential opportunities presented by another project. The business has to make choices every day about the best use of
 |
| its resources. There are factors other than quality that must be considered.
 |
| </p>
 |
| <p>
 |
| The <i><b>good enough quality</b></i> concept (GEQ) is, paradoxically, a more effective argument than <i><b>more is
 |
| better</b></i>, because it provides a target that is either achievable or not achievable, in which case it becomes a de
 |
| facto argument for canceling or rechartering the project.
 |
| </p>
 |
| <h3>
 |
| <a id="GEQParadigms" name="GEQParadigms">Paradigms of Good Enough</a>
 |
| </h3>
 |
| <p>
 |
| Most businesses practice some form of good enough reasoning about their products. The only ones that don't are those
 |
| who believe they have achieved perfection, because they lack the imagination and skill to see how their products might
 |
| be improved.
 |
| </p>
 |
| <p>
 |
| Here are some models of <i><b>good enough</b></i> that have been tried. Some of them are more effective than others,
 |
| depending on the situation:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <b>Not too Bad</b> <i>("we're not dead yet") -</i> Our quality only has to be good enough so we can continue to
 |
| stay in business. Make it good enough so that we aren't successfully sued.<br />
 |
| <br />
 |
| </li>
 |
| <li>
 |
| <b>Positive Infallibility</b> <i>("anything we do is good") -</i> Our organization is the best in the world.
 |
| Because we're so good, anything we do is automatically good. Think about success. Don't think about failure because
 |
| "negative" thinking makes for poor quality.<br />
 |
| <br />
 |
| </li>
 |
| <li>
 |
| <b>Righteous Exhaustion</b> <i>("perfection or bust") -</i> No product is good enough; it's effort that counts. And
 |
| only our complete exhaustion will be a good enough level of effort. Business issues are not our concern. We will do
 |
| everything we possibly can to make it perfect. Since we'll never be finished improving, someone will have to come
 |
| in and pry it from our fingers if they want it. Then they will bear the blame for any quality problems, not
 |
| us.<br />
 |
| <br />
 |
| </li>
 |
| <li>
 |
| <b>Customer is Always Right</b> <i>("customers seem to like it") -</i> If customers like it, it must be good
 |
| enough. Of course, you can't please everybody all the time. And if a current or potential customer doesn't like the
 |
| product, it's up to them to let us know. We can't read their minds.<br />
 |
| <br />
 |
| </li>
 |
| <li>
 |
| <b>Defined Process</b> <i>("we follow a Good Process") -</i> Quality is the result of the process we use to build
 |
| the product. We have defined our process and we think it's a good process. Therefore, as long as we follow the
 |
| process, a good enough product will inevitably result.<br />
 |
| <br />
 |
| </li>
 |
| <li>
 |
| <b>Static Requirements</b> <i>("we satisfy the Requirements") -</i> We have defined quality in terms of objective,
 |
| quantifiable, noncontroversial goals. If we meet those goals, we have a good enough product, no matter what other
 |
| subjective, non-quantifiable, controversial goals might be suggested.<br />
 |
| <br />
 |
| </li>
 |
| <li>
 |
| <b>Accountability</b> <i>("we fulfill our promises") -</i> Quality is defined by contract. We promise to do certain
 |
| things and achieve certain goals. If we fulfill our contract, that's good enough.<br />
 |
| <br />
 |
| </li>
 |
| <li>
 |
| <b>Advocacy</b> <i>("we make every reasonable effort") -</i> We advocate excellence. Throughout the project, we
 |
| look for ways to prevent problems, and to find and fix the ones we couldn't prevent. If we work faithfully toward
 |
| excellence, that will be good enough.<br />
 |
| <br />
 |
| </li>
 |
| <li>
 |
| <b>Dynamic Tradeoff</b> <i>("we weigh many factors") -</i> With respect to our mission and the situation at hand, a
 |
| product is good enough when it has sufficient benefits, no critical problems, its benefits sufficiently outweigh
 |
| its non-critical problems, and it would cause more harm than good to continue improving it.<br />
 |
| <br />
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| <a id="IsHighQualityExpensive" name="IsHighQualityExpensive">Is High Quality Necessarily More Expensive?</a>
 |
| </h3>
 |
| <p>
 |
| Depending on a lot of factors, such as process, skill, technology, tools, environment, and culture, you may be able to
 |
| produce a much higher quality product for the same cost. A more testable and maintainable product will cost less to
 |
| improve and other costs are specifically associated with poor quality, such as support costs and costs to the customer.
 |
| </p>
 |
| <p>
 |
| The cost of quality is a complex issue and it's difficult to make broad generalizations. However, you can say with
 |
| certainty that you can always spend more time on much better tests, much more error handling, and more fixing or
 |
| rewriting of every part of the product. No matter how good you are, that costs something. And if you can't think of
 |
| more improvements to make, it's more likely that you've reached the upper limit of your imagination, not of quality.
 |
| </p>
 |
| <p>
 |
| In the software industry GEQ is inspired more as a response to one particular cost than any other: the cost of not
 |
| releasing the product <i>soon enough</i>. The specter of the market window, or the external deadline, imposes penalties
 |
| upon us if we can't meet the challenge. That's why the ends of projects are so often characterized by frenzied triage.
 |
| If you want to know what an organization really believes is good enough, and how well prepared they are for it, witness
 |
| the last three days of any six-month software project. See what happens when a new problem is reported on the last day.
 |
| </p>
 |
| <h3>
 |
| <a id="Quantification" name="Quantification">Wouldn't Quantification Help?</a>
 |
| </h3>
 |
| <p>
 |
| It can be tempting to reduce quality to a number, then set a numerical threshold that represents good enough quality.
 |
| This is a problem, because you can only measure factors that <i>relate</i> to quality. You can't measure quality
 |
| itself. This is partly because the word "quality" is just a label for a relationship between a person and a thing.
 |
| "This product is high in quality" is just another way of saying "Somebody values this product". It's a statement about
 |
| the product, but also a statement about people and the surrounding context. Even if the product stays the same, people
 |
| and situations change, so there can be no single, static, <i>true</i> measure of quality.
 |
| </p>
 |
| <p>
 |
| There are many measures you might use to get a sense of quality, even if you can't measure it completely and
 |
| objectively. Even so, the question of what quality is good enough requires sophisticated judgment. You can't escape
 |
| from the fact that, in the end, people have to think it through and make a judgment. For a simple product, that
 |
| judgment might be easy. For a complex, high-stakes product, it's very difficult.
 |
| </p>
 |
| <h3>
 |
| <a id="FurtherInfo" name="FurtherInfo">Further Information</a>
 |
| </h3>
 |
| <p>
 |
| To assist you with evaluating product quality, the following types of information are available for most of the
 |
| artifacts included in the Unified Process:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Artifact Guidelines and Checkpoints: information on how to develop, evaluate, and use the artifact.
 |
| </li>
 |
| <li>
 |
| Templates: "models" or prototypes of the artifact, providing structure and guidance for content.<br />
 |
| </li>
 |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
