<?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="_h6zSEPimEdmugcVr9AdHjQ"
    name="develop_solution,_h2-iAfimEdmugcVr9AdHjQ" guid="_h6zSEPimEdmugcVr9AdHjQ"
    version="1.0.0">
  <mainDescription>&lt;h3>&#xD;
    Introduction&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Run this activity as a way to perform 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 an 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.&amp;nbsp;The developer&amp;nbsp;also writes and runs developer tests against the implementation to make sure that&#xD;
    it works as designed, 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 implementation, even if it is only a&#xD;
    mental exercise that results in no long-term work product. The design for trivial changes to the existing&#xD;
    implementation (to, for example, support some requirement) might be self-evident in the context of the existing&#xD;
    architecture and design.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Once the organization of the technical solution is clear, define developer tests that will verify the implementation.&#xD;
    This test-driven approach ensures that design considerations have in fact taken place before the solution is coded. The&#xD;
    tests are run up front and, if they fail, clearly define the criteria to determine if the implementation works as&#xD;
    intended.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Failed tests lead to&amp;nbsp;an implementation of the solution, upon completion of which you run the tests again. This&#xD;
    innermost loop of implementation and developer testing 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&#xD;
    affect the developer tests and implementation.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Once the tests pass and the design of the solution is appropriate, there is one more possible loopback. It is best to&#xD;
    keep the test-driven, evolutionary design inner loops as tight as possible. Come up with some small-scale design&#xD;
    solution for a part of the work item, define a test or two for the implementation of that 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 of the activity, go back to the work item and design another chunk to get closer&#xD;
    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 you should rename it to include the actual requirement name. Optionally, the words &lt;b>Solution&#xD;
    Increment&lt;/b>&amp;nbsp;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;b>Example&lt;/b>&#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 database 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>