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