| <?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="--NZMnDuKFchwZm3rFJv1jg" |
| name="develop_solution,_h2-iAfimEdmugcVr9AdHjQ" guid="--NZMnDuKFchwZm3rFJv1jg" |
| 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.&nbsp;The developer&nbsp;also writes and runs developer tests against the implementation to make sure that
 |
| 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 implementation, even if it is only a
 |
| mental exercise that results in no long-term work product. The design for trivial changes to the existing
 |
| implementation (to, for example, support some requirement) might be self-evident in the context of the existing
 |
| architecture and design.
 |
| </p>
 |
| <p>
 |
| Once the organization of the technical solution is clear, the development and testing of the implementation ensues.
 |
| This development and testing can be done as a tight, innermost loop of the activity until the developer 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 pass and the design of the solution is appropriate, there is one more possible loopback. It is best to
 |
| keep the&nbsp;implementation and&nbsp;evolutionary design inner loops as tight as possible. Come up with some
 |
| small-scale design solution for a part of the work item, implement and test&nbsp;that one part of the solution, verify
 |
| the quality, and then continue on until that part of the design is working. Then, in the outermost loop of the
 |
| activity, 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> |
| <alternatives>This pattern allows for tests to be created before the implementation, while implementation is carrying on, or after code
 |
| has been implemented; some organizations might want to apply a pattern that is more prescriptively test-first or
 |
| test-after.&nbsp; Additionally, it is healthy to revisit the design after some working code has been written; this idea is
 |
| not explicitly captured in this pattern.</alternatives> |
| <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 words
 |
| <strong>Solution Increment</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> |
