| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription 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" xmi:id="_zaqENNnmEdmO6L4XMImrsA" name="task,7.624729048911575E-305" guid="_zaqENNnmEdmO6L4XMImrsA" changeDate="2006-04-27T15:39:25.282-0700"> |
| <mainDescription><a id="XE_ACTIVITY__KEY_CONCEPTS" name="XE_activity__key_concepts"></a> |
| <h3> |
| Definition |
| </h3> |
| <p> |
| A Task describes a unit of work. Every Task is performed by specific Roles. The granularity of a Task is generally a |
| few hours to a few days. It usually affects one or only a small number of Work Products. Tasks are not necessarily used |
| as&nbsp;a basis for planning and tracking progress - they are often too fine-grained for that purpose; Activity |
| groupings of Tasks are often the better units for planning and tracking. |
| </p> |
| <p> |
| A Task has a clear purpose, usually expressed in terms of creating or updating some Work Products, such as models, |
| classes, or&nbsp;plans. Within a Task, each performing Role achieves a well defined goal. A Task provides complete |
| step-by-step explanations of doing all the work required to achieve this goal. This description is complete, |
| independent of when in a process lifecycle the work would actually be done. Therefore, it does not describe when you do |
| what work at what point of time, but describes all the work that gets done throughout the development lifecycle that |
| contributes to the achievement of the Tasks' goal. |
| </p> |
| <p> |
| When a Task is being applied in a Process, a reference object defined as Task Descriptor provides information, which |
| includes what elements of the Task will actually be performed at that point in time. This assumes that a Task will |
| usually be performed in the Process over and over again, but each time with a slightly different emphasis on different |
| steps or aspects of the Task description&nbsp;as well as perhaps different or additional performing roles or different |
| input/output (also refer to <a class="elementLink" |
| href="./../../../base_concepts/guidances/concepts/introduction_to_uma,_94_eoO8LEdmKSqa_gSYthg.html" |
| guid="_94_eoO8LEdmKSqa_gSYthg">Key Capabilities of the Unified Method Architecture (UMA)</a> for the difference between |
| Method Content and Process). |
| </p> |
| <h3> |
| Steps |
| </h3> |
| <p> |
| Tasks can be broken down into sections of Steps. A Step describes a meaningful and consistent part of the overall work |
| described for a Task. Steps fall into three main categories: |
| </p> |
| <ul> |
| <li> |
| <b>Thinking</b> Steps: where the individual performing the Role understands the nature of the Task, gathers and |
| examines the input Work Products, and formulates the result. |
| </li> |
| <li> |
| <b>Performing</b> Steps: where the individual performing the Role creates or updates some Work Products. |
| </li> |
| <li> |
| <b>Reviewing</b> Steps: where the individual performing the Role inspects the results against some criteria. |
| </li> |
| </ul> |
| <p> |
| Not all Steps are necessarily performed each time a Task is invoked, so they can be expressed in the form of alternate |
| flows (similar to Use Cases). |
| </p> |
| <h3> |
| Examples |
| </h3> |
| <h4> |
| A Typical Task |
| </h4> |
| <p> |
| A typical Task&nbsp;to "Develop Use-Case Model" would describe all the work that needs to be done to develop a complete |
| use-case model. This would consist of the following: |
| </p> |
| <ul> |
| <li> |
| The identification and naming of use cases and actors |
| </li> |
| <li> |
| The writing of a brief description |
| </li> |
| <li> |
| The modeling of use cases and their relationships in diagrams |
| </li> |
| <li> |
| The detailed description of a basic flow |
| </li> |
| <li> |
| The detailed description of alternative flows |
| </li> |
| <li> |
| Performing of walkthroughs, workshops and reviews, etc. |
| </li> |
| </ul> |
| <p> |
| All of these parts contribute to the development goal of developing the use case model, but the parts will be performed |
| at different points in time in a Process. Identification, naming, and brief descriptions would be performed |
| <strong>early</strong> in a typical development process versus the writing of detailed alternative flows which would be |
| performed much <strong>later</strong>. All these parts or Steps within the same Task define the "method" of developing |
| a use-case model. Applying such a method in a lifecycle is defining which Steps are done when going from one iteration |
| to the next. |
| </p> |
| <h4> |
| A Task and its Steps |
| </h4> |
| <p class="example"> |
| A&nbsp;typical Task to "Find Use Cases and Actors"&nbsp;would be decomposed into the following Steps: |
| </p> |
| <blockquote> |
| <blockquote> |
| <ol> |
| <li> |
| Find actors |
| </li> |
| <li> |
| Find use cases |
| </li> |
| <li> |
| Describe how actors interact with use cases |
| </li> |
| <li> |
| Package use cases and actors |
| </li> |
| <li> |
| Present the use-case model in use-case diagrams |
| </li> |
| <li> |
| Develop a survey of the use-case model |
| </li> |
| <li> |
| Evaluate your results |
| </li> |
| </ol> |
| </blockquote> |
| </blockquote> |
| <p class="example"> |
| The finding part [Steps 1 to 3] requires some thinking; the performing part [Steps 4 to 6] involves capturing the |
| result in the use-case model; the reviewing part [Step 7] is where the individual performing the Role evaluates the |
| result to assess completeness, robustness, intelligibility, or other qualities. |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |