Roles

The central concept in the process is that of a role. A role defines the behavior and responsibilities of an individual or of a group of individuals working together as a team. The behavior is expressed in terms of activities the role performs , and each role is associated with a set of cohesive activities. "Cohesive" in this sense means activities that are best performed by one person. The responsibilities of each role are usually expressed in relation to certain artifacts that the role creates, modifies, or controls.

Roles are not individuals, nor job titles. You can play the Project Manager role for an hour , then play the architect role for the rest of the morning, and switch from coder role to tester role during the afternoon. Your colleagues Joe, Stefan, and Mary might all play simultaneously the Design Reviewer role in your review later in the afternoon.

The following are examples of roles:

• System Analyst

  An individual acting as a system analyst leads and coordinates requirements elicitation and use-case modeling by outlining the system's functionality and delimiting the system.

• Designer

  An individual acting as a designer defines the responsibilities, operations, attributes, and relationships of one or more classes and determines how they should be adjusted to the implementation environment.

• Test Designer

  An individual acting as a test designer is responsible for the planning, design, implementation, and evaluation of tests, including generating the test plan and test model, implementing the test procedures, and evaluating test coverage, results, and effectiveness.

Note that roles are not individuals; instead, they describe how individuals should behave in the business and the responsibilities of each individual. Individual members of the software development organization wear different hats or play different parts or roles. ^[1] The mapping from individual to role is performed by the project manager when planning and staffing the project, and it is based on the skills and competencies associated with the role and the actual skills and competencies of the members of the team. This mapping allows an individual to act several roles and for a role to be played by several individuals.

^[1] However, we often write, "The designer of class X does this" when, strictly speaking, we should write, "The person playing the designer role for class X does this."

In the example in Figure 3-2, one individual, Sylvia, can be a Database Designer in the morning and act as a Design Reviewer in the afternoon. Paul and Mary are both Designers, although they are likely responsible for different classes or different design packages.

Figure 3-2. People and roles

Each role is associated with a set of skills required to perform the activities of the role. Sylvia must understand how to design a use case and how to review a part of the design.

Roles are organized in five main categories:

1. Analyst roles

2. Developer roles

3. Tester roles

4. Manager roles

5. Production and support roles

There are a few generic roles that are used as placeholders for activities that may be done by a variety of people. See Appendix A for a complete "cast of characters ."

Roles are usually denoted in the RUP prefixed with the word Role, as in Role: Integration Tester. Appendix A lists all roles defined in the Rational Unified Process.