Definition

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 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.

A Task has a clear purpose, usually expressed in terms of creating or updating some Work Products, such as models, classes, or 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.

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 as well as perhaps different or additional performing roles or different input/output (also refer to Key Capabilities of the Unified Method Architecture (UMA) for the difference between Method Content and Process).

Steps

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:

• Thinking Steps: where the individual performing the Role understands the nature of the Task, gathers and examines the input Work Products, and formulates the result.
• Performing Steps: where the individual performing the Role creates or updates some Work Products.
• Reviewing Steps: where the individual performing the Role inspects the results against some criteria.

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).

Examples

A Typical Task

A typical Task 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:

• The identification and naming of use cases and actors
• The writing of a brief description
• The modeling of use cases and their relationships in diagrams
• The detailed description of a basic flow
• The detailed description of alternative flows
• Performing of walkthroughs, workshops and reviews, etc.

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 early in a typical development process versus the writing of detailed alternative flows which would be performed much later. 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.

A Task and its Steps

A typical Task to "Find Use Cases and Actors" would be decomposed into the following Steps:

1. Find actors
2. Find use cases
3. Describe how actors interact with use cases
4. Package use cases and actors
5. Present the use-case model in use-case diagrams
6. Develop a survey of the use-case model
7. Evaluate your results

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.