Core Process Workflows

Process Representation

The core workflows are described in terms of workers, activities and workflows. The accompanying artifacts are described in the Artifact Overview.

  • A worker defines the behavior and responsibilities of an individual, or a set of individuals working together as a team. This is an important distinction because it is natural to think of a worker as the individual or the team itself. In the Rational Unified Process, the worker is more of a role that defines how the individuals should carry out the work.
  • An activity is the smallest piece of work that is relevant; it is technically an "operation" on a worker. As such, it is not possible to do only part of an activity, although there may be some optional steps within an activity. Dividing the work in this manner makes it easier to monitor development. It is better (easier) to know that the project has completed three out of five activities rather than 60% of one activity.
  • Artifacts are the modeling constructs and documents that activities evolve, maintain, or use as input.

Each worker has a set of associated "cohesive" activities, cohesive meaning that the activities are best performed by one individual. The responsibilities of each worker are usually defined relative to certain artifacts, for example documents. Examples of workers are business-process analyst, designer, architect, and process engineer.

Each worker has its own set of activities and artifacts.

Through the associated set of activities, the worker also implicitly defines the abilities expected to perform the work.

For each core workflow, an activity overview diagram is presented. This diagram shows all activities and workers involved in the workflow.

Sample activity overview diagram, from the business modeling workflow.

For each core workflow, an artifact overview diagram is presented. This diagram shows all artifacts and workers involved in the workflow.

Sample artifact overview diagram, from the business modeling workflow.

For most of the core workflows, you will also find workflow detail diagrams, which show groupings of activities that often are performed "together". These diagrams show workers involved, input and output artifacts, and activities performed. The workflow detail diagrams are there for the following reasons:

  • The activities of a workflow are neither performed in sequence, nor done all at once. The workflow detail diagram shows how you often will work in workshops or team meetings while performing a workflow. You typically work in parallel on more than one activity, and look at more than one artifact while doing that. There are several workflow detail diagrams for a core workflow.
  • It becomes too complex to show input and output artifacts for all activities of a core workflow in one diagram. The workflow detail diagram allows us to show you activities and artifacts together, for one part of a workflow at a time.
  • The core workflows are not completely independent of one another. For example, integration occurs in both the implementation and test workflows, and in reality you never really do one without the other. The workflow detail diagram can show a group of activities and artifacts in the workflow, together with closely related activities in another workflow.

Sample workflow detail diagram, from the business modeling workflow.

To Assign People to Workers Top

Individuals available to a project manager are people with specific sets of abilities.

The project manager will associate these individuals to workers in such a way that a given individual performs a worker's associated activities and behavior, and is responsible for all the artifacts associated with that worker.

Each individual in the project is assigned to one or several workers.

The association of individual to worker is dynamic over time. It is driven by the activities that need be performed at a given time, and constrained by the availability of individuals with adequate competence. This association has several constants, however:

  • An individual may act as several different workers during the same day: Sylvia may be a design reviewer in the morning and a use-case designer in the afternoon.
  • An individual may act as several workers simultaneously: Jane may be both the architect and the designer for a certain class.
  • Several individuals may act as the same worker to perform a certain activity together, acting as a team: Both Paul and Mary may be the use-case designer of the same use case.

When planning the various core workflows and activities, the project manager should try to allocate the individuals in a seamless fashion, that is, minimize as much as possible the hand-off of artifacts from one individual to another.

For example, the designer of a class can also be its implementer. For a given use case, the same individual can act as the use-case specifier and as the use-case designer. This "seamlessness" is again constrained by the range of each individual's abilities.

Core Process Workflows and Models Top

As explained earlier, a core workflow has an associated set of activities and artifacts. The most important artifacts are the models that each core workflow yields: use-case model, design model, implementation model, and test model. The next figure shows the relationship of the core process workflows and models.

Each core process workflow is associated with a particular set of models.

 

Business Modeling Top

The goal of the Business Modeling workflow is to describe the processes of an organization. The organization is described both from an external viewpoint that focuses on what value is delivered to the customer, and from an internal viewpoint that focuses on roles, deliverables, and their relations in the business. These descriptions serve as a "map" system analysts can use when identifying requirements on automation - the systems.

The results of business modeling is a business use-case model, a business object model, and some supplementary specifications of the business.

The business use-case model consists of business actors and business use cases. Business actors represent users of the business, for example, customers, vendors, external systems the business interacts with. Business actors help delimiting the boundaries of the organization we are to describe. Business use cases represent processes performed in the business. The following figure shows a sample business use-case model for airline check-in.

An diagram showing examples of business actors and business use cases.

The business object model consists of business workers and business entities that can be grouped into organization units. It also contains descriptions of how business workers and business entities collaborate to perform business use cases. The next figure shows part of a sample business object model for the airline check-in organization in the business use-case model shown in the previous figure.

A diagram showing examples of business workers and business entities.

Workers and Workflow

The following workers are involved in the business modeling workflow:

  • Business-process analyst
  • Business designer
  • Business-model reviewer

Each worker is responsible for a set of activities and behavior. Each core workflow has its own set of workflow details, a logical way in which worker activities progress. The following workflow details are defined for business modeling:

Requirements Top

The goal of the Requirements workflow is to describe what the system should do and allows the developers and the customer to agree on that description. To achieve this, we delimit the system - define its surroundings and the behavior it is supposed to perform. Customers and potential users are important sources of information as well as any system requirements that may exist.

Requirements results in a use-case model and some supplementary requirements. The use-case model is essential for both the customer, who needs the model to validate that the system will become what he expected, and for the developers, who need the model to get a better understanding of the requirements on the system.

The use-case model is relevant to all people involved in the project.

The use-case model consists of actors and use cases. Actors represent the users, and any other system that may interact with the system being developed. Actors help delimit the system and give you a clearer picture of what it is supposed to do.

Use cases represent the behavior of the system. Because use cases are developed according to the actor's needs, the system is more likely to be relevant to the users. The following figure shows an example of a use-case model for a recycling-machine system.

An example of a use-case model with actors and use cases.

Each use case is described in detail. The use-case's flow of events shows how the system interacts step by step with the actors and what the system does.

The use cases function as a unifying thread throughout the system's development cycle. The same use-case model is used during requirements, analysis & design, and test.

Workers and Workflow

The following workers are involved in the requirements workflow:

  • System analyst
  • Use-case specifier
  • User-interface designer
  • Architect
  • Requirements reviewer

Each worker is responsible for a set of activities and behavior. Each core workflow has its own set of workflow details, a logical way in which worker activities progress. The following workflow details are defined for the requirements workflow:

Analysis & Design Top

The goal of the analysis & design workflow is to show how the system will be realized in implementation. You want to build a system that:

  • Performs - in a specific implementation environment - the tasks and functions specified in the use-cases.
  • Fulfills all its requirements.
  • Is structured to be robust (easy to change if and when its functional requirements change).

The use-case model is the basis for design, along with the supplementary specifications.

Analysis & design results in a design model that serves as an abstraction of the source code; that is, the design model acts as a "blueprint" of how the source code is structured and written. Design also results in "inside-view" descriptions of the use cases, or use-case realizations, which describe how the use cases are realized in terms of the participating objects/classes.

The design model consists of design classes structured into design packages; it also contains descriptions of how objects of these design classes collaborate to perform use cases. The next figure shows part of a sample design model for the recycling-machine system in the use-case model shown in the previous figure.

Part of a design model with communicating design classes, and package group design classes.

The design activities are centered around the notion of architecture. The production and validation of this architecture is the main focus of early design iterations. Architecture is represented by a number of architectural views. These views capture the major structural design decisions. In essence architectural views are abstractions or simplifications of the entire design, in which important characteristics are made more visible by leaving details aside. The architecture is an important vehicle not only for developing a good design model, but also for increasing the quality of any model built during system development.

Workers and Workflow

The following workers are involved in the analysis & design workflow:

  • Architect
  • Designer
  • Database Designer
  • Architecture Reviewer
  • Design Reviewer

Each worker is responsible for a set of activities and behavior. Each core workflow has its own set of workflow details, a logical way in which worker activities progress. The following workflow details are defined for analysis & design:

Implementation Top

The system is realized through implementation producing the sources (source-code files, header files, makefiles, and so on) that will result in an executable system. The sources are described in an implementation model that consists of modules structured into implementation packages. The design model is the basis for implementation.

Implementation includes testing the separate classes and/or packages, but not testing that the packages/classes work together. That is described in the next workflow, "Test".

Workers and Workflow

The following workers are involved in the implementation workflow:

  • Architect
  • System integrator
  • Implementer
  • Code reviewer

Each worker is responsible for a set of activities and behavior. Each core workflow has its own set of workflow details, a logical way in which worker activities progress. The following workflow details are defined for implementation:

Test Top

Test verifies the entire system. You first test each use case separately to verify that its participating classes work together correctly. Then you test (certain aspects of) the system as a whole with use cases as input to this test. At the end of test, the system can be delivered.

Workers and Workflow

The following workers are involved in the test workflow:

  • Test designer
  • Integration tester
  • Performance tester
  • System tester
  • Designer
  • Implementer

Each worker is responsible for a set of activities and behavior. Each core workflow has its own set of workflow details, a logical way in which worker activities progress. The following workflow details are defined for test:

 

Display Rational Unified Process using frames

 

© Rational Software Corporation 1998 Rational Unified Process 5.1 (build 43)