<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ProcessDescription xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore"
    xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-xt3VIrbs_wwwe5-Oy-g6iA"
    name="develop_solution,_h2-iAfimEdmugcVr9AdHjQ" guid="-xt3VIrbs_wwwe5-Oy-g6iA"
    version="1.0.0">
  <mainDescription>&lt;h3>&#xD;
    Introduction&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Run this activity as a way to perform a goal-based planning and execution. Work is taken on by developers and work&#xD;
    progress is tracked based on the goals achieved using the designed, developer-tested, and integrated source code.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Context of what is being developed&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    A context can be specified when a requirement is assigned to be developed, thus specifying how broadly a requirement is&#xD;
    to be developed in a iteration. Development may focus on a layer (such as the user interface, business logic, or&#xD;
    database access), on a component, and so on.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Whether a context is specified or not, the developer's responsibility is to create a design and implementation for that&#xD;
    requirement, and also to write and run developer tests against the implementation to make sure it works as designed,&#xD;
    both as a unit and integrated into the code base.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Overview of workflow&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Typical changes require some effort in designing the solution before moving into the implementation, even if it is only&#xD;
    a mental exercise that results in no long-term work product. Trivial changes to the existing implementation to support&#xD;
    some requirement might have their design self-evident in the context of the existing architecture and design.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Once the organization of the technical solution is clear, developer tests are defined that will verify the&#xD;
    implementation. This test-driven approach enforces that design considerations have been done before the solution is&#xD;
    coded. The tests are run up front and, in failing, clearly define the criteria to determine if the implementation works&#xD;
    as intended.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Failed tests lead to the implementation of the solution which upon completion causes the tests to be run again. This&#xD;
    innermost loop is repeated until the tests pass.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Passing the tests does not necessarily mean that the solution is a high-quality, appropriate solution. It is proper to&#xD;
    revisit the design at this point. That path loops back through the process since any changes to the design could affect&#xD;
    the developer tests and implementation.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Once the tests are passing and the design of the solution is deemed appropriate, there is one more possible loopback.&#xD;
    It is best to keep the test-driven, evolutionary design inner loops as tight as possible. Come up with some small-scale&#xD;
    design solution for a part of the work item, define a test or two for the implementation of one part of the solution,&#xD;
    pass that test, verify the quality, and then continue on in a test-first manner until that part of the design is&#xD;
    working. Then in the outermost loop go back to the work item and design another chunk to get closer to completion.&#xD;
&lt;/p></mainDescription>
  <purpose>&lt;ul>&#xD;
    &lt;li>&#xD;
        For developers: To create a solution for the work item for which they are responsible&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        For project managers: To have a goal-based way of tracking project status&#xD;
    &lt;/li>&#xD;
&lt;/ul></purpose>
  <usageNotes>&lt;p>&#xD;
    This activity occurs multiple times during each iteration. Usually, there is one instance for each work item planned&#xD;
    for that iteration. When instantiated in a project plan, the pattern becomes a development task to be taken on by one&#xD;
    or more developers, and it should be renamed to include the actual requirement name. Optionally, the word&#xD;
    &lt;strong>Solution&lt;/strong> may be suppressed, then you can instantiate the pattern this way:&#xD;
&lt;/p>&#xD;
&lt;blockquote>&#xD;
    &lt;p align=&quot;left&quot;>&#xD;
        Develop requirement_name (within context_name context)&#xD;
    &lt;/p>&#xD;
&lt;/blockquote>&#xD;
&lt;p>&#xD;
    If a context is specified, there will be one instance of this pattern for each requirement for each context.&#xD;
&lt;/p>&#xD;
&lt;blockquote>&#xD;
    &lt;p>&#xD;
        &lt;strong>Example&lt;/strong>&#xD;
    &lt;/p>&#xD;
    &lt;ol>&#xD;
        &lt;li>&#xD;
            Develop scenario 1 (within user interface context)&#xD;
        &lt;/li>&#xD;
        &lt;li>&#xD;
            Develop scenario 1 (within business logic and DB access context)&#xD;
        &lt;/li>&#xD;
        &lt;li>&#xD;
            Develop scenario 2&#xD;
        &lt;/li>&#xD;
        &lt;li>&#xD;
            Develop supplemental requirement 1&#xD;
        &lt;/li>&#xD;
    &lt;/ol>&#xD;
&lt;/blockquote>&#xD;
&lt;p>&#xD;
    Note that there are four instances of this pattern in the preceding example:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        The first two are related to the same requirement (scenario 1) but within two different contexts&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The last two are related to different requirements, with no context specified.&#xD;
    &lt;/li>&#xD;
&lt;/ul></usageNotes>
</org.eclipse.epf.uma:ProcessDescription>