| <?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.3/uma.ecore" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="_h6zSEPimEdmugcVr9AdHjQ" name="develop_sr_within_scope,_h2-iAfimEdmugcVr9AdHjQ" guid="_h6zSEPimEdmugcVr9AdHjQ" version="1.0.0"> |
| <mainDescription><h3> |
| Introduction |
| </h3> |
| <p> |
| Project managers use this Capability Pattern&nbsp;as a way to&nbsp;perform a goal-based planning and management. Work |
| is assigned to developers and work progress is tracked&nbsp;based on the goals to be achieved using the designed, |
| unit-tested, and&nbsp;integrated&nbsp;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&nbsp;may focus&nbsp;on a layer (such as the user interface, business logic, |
| or&nbsp;database access),&nbsp;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, then to&nbsp;write and run unit tests against the implementation to make sure the&nbsp;implementation |
| works as designed, both as a unit&nbsp;and&nbsp;integrated into the code base. |
| </p> |
| <h4> |
| Overview of workflow |
| </h4> |
| <p> |
| To accommodate major changes or&nbsp;major functionality to be developed, architecture may have to be refined. Small |
| changes and functionality may reflect changes on the design only, with no need to refine the architecture. For trivial |
| changes and functionality to be developed, only the source code may be affected. |
| </p> |
| <p> |
| In any case, there is no strict sequence for how writing code and creating or running &nbsp;developer tests should |
| happen, because they can happen in parallel.&nbsp;You may choose to create developer tests and run them before the actual |
| code is created or the reverse sequence. |
| </p></mainDescription> |
| <purpose><ul> |
| <li> |
| For developers: To create a solution for the requirement assigned to them |
| </li> |
| <li> |
| For project managers: To have a goal-based way of assigning work and tracking project status |
| </li> |
| </ul></purpose> |
| <usageNotes><p> |
| This Capability Pattern occurs multiple times during each iteration. Usually, there is one instance for each |
| requirement planned for that iteration. When instantiated in a project plan, the pattern becomes a development task to |
| be assigned to a developer, and it should be renamed to include the actual requirement name.&nbsp;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&nbsp;a context&nbsp;is specified, there will be one instance of this pattern for each requirement&nbsp;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> |