<?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="-Z2AbfOEPERSqcoRYjsQm9g" name="new_supporting_material,_3cIZQEmsEdyW-KKcGeoYtA" guid="-Z2AbfOEPERSqcoRYjsQm9g" changeDate="2007-08-21T07:45:25.000-0400">
  <mainDescription>&lt;p>
    Every asset in a product line development effort should be validated, preferably before it is put into widespread use.
&lt;/p>
&lt;p>
    A product line organization produces assets of many types besides code. Architectures and requirements models are not
    as executable as the code but do have standardized syntax. Scoping documents, business cases, and other text documents
    do not have a standard syntax. A variety of techniques are required to validate each of these assets.
&lt;/p>&lt;br />
&lt;p>
    Techniques include both static and dynamic activities. These techniques have typically gone under the names:
&lt;/p>
&lt;p>
    &lt;strong>review&lt;/strong> - Investigates the form and some of the substance of an artifact by human reading of the
    artifact.
&lt;/p>
&lt;p>
    &lt;strong>inspection&lt;/strong> - Investigates the semantics of the artifact by human reading or automatically applying a
    set of rules. Design pattern recognition and some architecture conformance tools are examples.
&lt;/p>
&lt;p>
    &lt;strong>test&lt;/strong> - Investigates the quality of an asset by automatic means. Executing a program or running a
    simulation of an architecture are examples.
&lt;/p>&lt;br />
&lt;p>
    A product line organization should employ all three of these techniques. In the testing tasks described here we will
    also show how a testing perspective can be applied no matter which of the three techniques are used.
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
