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