Software Development for Small Teams: A RUP-Centric Approach (The Addison-Wesley Object Technology Series)

RUP is a software engineering process that describes the "general order" of "who" needs to "do what" in order to "create what." The key concepts are shown in Figure A.2.

^[*] 2003 Rational Software Corporation. All rights reserved. This graphic is used with permission of IBM Corporation.

Roles

RUP refers to the "who" entities as roles . RUP identifies over 30 roles that fall under broader categories such as Analysts, Developers, Testers, and Managers. The same person on a project can fill many roles. For example, the Project Manager can serve as a Use-Case Specifier, Requirements Reviewer, and a Testing Professional. On large projects, several people might perform the tasks described by one role; for example, your team might include several architects .

Activities

The "do what" part is covered in RUP as activities. Activities are associated with roles (see Figure A.3), and have inputs and outputs. Activities are often composed of steps that help the role achieve the purpose of the activity. The purpose of activities is to achieve observable results by creating, changing, or reviewing "artifacts." RUP provides guidelines and checkpoints that help you perform specific activities.

^[*] 2003 Rational Software Corporation. All rights reserved. This graphic is used with permission of IBM Corporation.

Artifacts cover the "create what" aspect of RUP as a software engineering process. Sets of artifacts are associated with each discipline and the workflows and workflow details that describe the discipline. For example, there is a set of Requirements artifacts, and similarly there are Deployment artifacts. RUP artifacts are typically models, model entities, tool-generated reports , and documents. Figure A.4 shows the artifacts that belong to the Analysis & Design discipline in RUP. Although artifacts are associated with particular roles, those in other roles may be able to modify artifacts as required when performing their given activities.

^[*] 2003 Rational Software Corporation. All rights reserved. This graphic is used with permission of IBM Corporation.

The "general order" in which activities are to be performed is described in the activity diagrams of each workflow. Figure A.5 is an activity diagram of the Requirements Workflow. Depending on your specific needs, there are a number of ways you can navigate through the activity diagram (which you read like a flowchart). Each visiting point is a "workflow detail."

^[*] 2003 Rational Software Corporation. All rights reserved. This graphic is used with permission of IBM Corporation.

Workflow details within each workflow show groupings of activities that can be performed simultaneously . These diagrams show the roles involved, input and output artifacts, and activities performed. Figure A.6 is a workflow detail for Perform Architectural Synthesis.

^[*] 2003 Rational Software Corporation. All rights reserved. This graphic is used with permission of IBM Corporation.

The key RUP role associated with Perform Architectural Synthesis is the Software Architect, who is responsible for performing the three activities shown. However, none of these are mandatory, and may depend on when in the development cycle the workflow detail is invoked. The workflow detail shows the associated artifacts, and other information to help you understand the scope and context of the workflow detail.