Activities

Roles have activities, which define the work they perform. An activity is a unit of work that an individual in that role may be asked to perform and that produces a meaningful result in the context of the project. The activity has a clear purpose, usually expressed in terms of creating or updating artifacts, such as a model, a class, or a plan. Every activity is assigned to one specific role.

The granularity of an activity is generally a few hours to a few days. It usually involves one person in the associated role and affects one or only a small number of artifacts. An activity should be usable as an element of planning and progress; if it is too small, it will be neglected, and if it is too large, progress will have to be expressed in terms of the activity's parts .

Activities may be repeated several times on the same artifact, especially from one iteration to another as the system is refined and expanded. Repeated activities are performed by the same role but not necessarily the same individual.

In object-oriented terms, the role is an active object, and the activities that the role performs are operations performed by that object. The following are examples of activities:

• Plan an iteration: performed by the Role: Project Manager

• Find use cases and actors: performed by the Role: System Analyst

• Review the design: performed by the Role: Design Reviewer

• Execute a performance test: performed by the Role: Performance Tester

Activities are often prefixed with the word Activity, as in Activity: Find use case and actors. Chapters 7 through 15 give an overview of all activities in the Rational Unified Process.

Activity Steps

Activities are broken into steps. Steps fall into three main categories:

• Thinking steps

  The person playing the role understands the nature of the task, gathers and examines the input artifacts, and formulates the outcome.

• Performing steps

  The person playing the role creates or updates some artifacts.

• Reviewing steps

  The person playing the role inspects the results against some criteria.

Not all steps are necessarily performed each time an activity is invoked, so they can be expressed in the form of alternative flows.

For example, the Activity: Find Use Cases and Actors decomposes into these seven steps:

1. Find actors.

2. Find use cases.

3. Describe how actors and use cases interact.

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 through 3) requires some thinking; the performing part (steps 4 through 6) involves capturing the result in the use-case model; the reviewing part (step 7) requires the role to evaluate the result to assess completeness, robustness, intelligibility, and other qualities.