| <?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><h3>
 |
| Introduction
 |
| </h3>
 |
| <p>
 |
| Run this activity as a way to perform 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 an 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, define developer tests that will verify the implementation.
 |
| This test-driven approach ensures that design considerations have in fact taken place before the solution is coded. The
 |
| tests are run up front and, if they fail, clearly define the criteria to determine if the implementation works as
 |
| intended.
 |
| </p>
 |
| <p>
 |
| Failed tests lead to&nbsp;an implementation of the solution, upon completion of which you run the tests again. This
 |
| innermost loop of implementation and developer testing 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 pass and the design of the solution is 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 that 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 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> |
| <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 you should rename it to include the actual requirement name. Optionally, the words <b>Solution
 |
| Increment</b>&nbsp;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>
 |
| <b>Example</b>
 |
| </p>
 |
| <ol>
 |
| <li>
 |
| Develop scenario 1 (within user interface context)
 |
| </li>
 |
| <li>
 |
| Develop scenario 1 (within business logic and database 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> |
