Key Concepts
Basic concepts in the Rational Unified
Process
A process is a set of partially ordered steps intended to reach a goal; in
software engineering the goal is to build a software product, or to enhance an
existing one; in process engineering, the goal is to develop or enhance a
process.
Expressed in terms of business modeling, the software development process is
a business process; the Rational Unified Process (RUP) is a generic business process
for object-oriented software engineering. It describes a family of related
software engineering processes sharing a common structure, a common process
architecture. It provides a disciplined approach to assigning tasks and
responsibilities within a development organization. Its goal is to ensure the
production of high-quality software that meets the needs of its end users,
within a predictable schedule and budget. The RUP captures
many of the best practices in modern software development in a form that can be
tailorable for a wide range of projects and organizations.
When a software system is developed from scratch, development is the process
of creating a system from requirements. But once the systems has taken form (or
in our terms, once the system has passed through the initial development cycle),
any further development is the process of conforming the system to the new or
modified requirements. This applies throughout the system's lifecycle.
The software-engineering process is the process of
developing a system from requirements, either new (initial development cycle) or
changed (evolution cycle).
The most central concept in the
Process is that of a role. A role defines the behavior and
responsibilities of an individual, or a set of individuals working together as a
team, within the context of a software engineering organization. The Roles Overview
provides additional information on roles.
The organization of roles and their
activities in the treebrowser
Note that roles are not individuals; instead,
they describe how individuals should behave in the business and the
responsibilities of an individual. Individual members of the software
development organization will wear different hats, or perform different
roles. The mapping from individual to role, performed by the project manager
when planning and staffing the project (see Activity:
Acquire Staff), allows different individuals to act as several different
roles, and for a role to be played by several individuals.
Roles have activities that define the work they perform. An activity is something that a
role does that provides a meaningful result in the context of the project. See
Activity: Capture a Common
Vocabulary for an example of an activity.
A typical role, showing its activities
in the treebrowser
An activity is a unit of work that an individual playing the described
role may be asked to perform. The activity has a clear
purpose, usually expressed in terms of creating or updating some
artifacts, such as a model, a class, a plan. Every activity is assigned to a
specific role. The granularity of an activity is generally a few hours to a
few days, it usually involves one 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 would have to be expressed in terms of an activity’s parts.
Activities may be repeated several times on the same artifact, especially
when going from one iteration to another, refining and expanding the system, by
the same role, but not necessarily the same individual.
Activities are broken down into steps. 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 artifacts, and formulates the
outcome.
- Performing steps: where the individual performing the
role creates or updates
some artifacts.
- Reviewing steps: where the individual performing 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 alternate flows.
Example of steps:
The Activity: Find use cases and actors decomposes
into the steps:
- Find actors
- Find use cases
- Describe how actors and use cases interact
- Package use-cases and actors
- Present the use-case model in use-case diagrams
- Develop a survey of the use-case model
- 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.
Activities may have associated Work Guidelines, which present
techniques and practical advice that is useful to the role performing the
activity. Applicable work guidelines are hyperlinked from the activity
description itself. The Work
Guidelines Overview also summarizes the available set of work guidelines,
and is accessible from the top level of the treebrowser.
Activities have input and output
artifacts. An artifact is a work product of the process: roles use artifacts to perform activities, and produce artifacts in the course
of performing activities. Artifacts are the responsibility of a single role and promote the idea that every piece of information in the process must be the
responsibility of a specific person. Even though one person may "own"
the artifact, many other people may use the artifact, perhaps even updating it
if they have been given permission.
Major artifacts in the process, and the
approximate flow of information between them.
The diagram above shows how information flows through the project, via the
artifacts; the arrows show how changes in one artifact ripple through other
artifacts along the arrows. For clarity, many artifacts are omitted (e.g. the
many artifacts in the design model are omitted, being represented by the
Artifact: Design Model).
To simplify the organization of artifacts, they are organized into
"information sets", or artifact sets. An artifact set
is a grouping of related artifacts that tend to be used for a similar purpose.
The Artifact Overview presents
more information on artifacts and artifact sets.
Artifacts and artifact sets in the
treebrowser
Artifacts may take various shapes or forms:
Note that "artifact" is the term used in the RUP. Other processes use terms such as work product,
work unit, and so on, to denote the same thing. Deliverables
are only the subset of all artifacts that end up in the hands of the customers
and end-users.
Artifacts are most likely to be subject to version control and
configuration management. This is sometimes only achieved by versioning
the container artifact, when it is not possible to do it for the elementary,
contained artifacts. For example, you may control the versions of a whole design
model, or design package, and not of individual classes they contain.
Artifacts are typically not documents. Many processes
have an excessive focus on documents, and in particular on paper documents.
The RUP discourages the systematic production of paper
documents. The most efficient and pragmatic approach to managing project
artifacts is to maintain the artifacts within the appropriate tool used
to create and manage them. When necessary, you may generate documents
(snapshots) from these tools, on a just-in-time basis. You should also consider
delivering artifacts to the interested parties inside and together with the
tool, rather than on paper. This approach ensures that the information is always
up-to-date and based on actual project work, and it shouldn’t require any
additional effort to produce.
Examples of artifacts:
- A design model stored in Rational Rose.
- A project plan stored in Microsoft Project.
- A defect stored in Rational ClearQuest.
- A project requirements database in Rational RequisitePro.
However, there are still artifacts which have to be plain text documents, as
in the case of external input to the project, or in some cases where it is
simply the best means of presenting descriptive information.
Templates are "models," or
prototypes, of artifacts. Associated with the artifact description are one or
more templates that can be used to create the corresponding artifacts. Templates
are linked to the tool that is to be used.
For example:
- Microsoft Word templates would be used for artifacts that are documents,
and for some reports.
- Rational SoDA templates for Microsoft Word or FrameMaker would extract information
from tools such as Rational Rose, Rational RequisitePro, or Rational
TeamTest.
- Microsoft FrontPage templates for the various elements of the process.
- Microsoft Project template for the project plan.
As with guidelines, organizations may want to customize the templates prior
to using them by adding the company logo, some project identification, or
information specific to the type of project. Templates are organized in the
treebrowser beneath their associated artifact. They are also summarized in a
separate treebrowser entry showing all templates.
Expanded portion of the treebrowser,
showing the different kinds of templates in the RUP.
Models and model elements, may have
reports associated with them. A report extracts information about models and
model elements from a tool. For example, a report presents an artifact or a set
of artifacts for a review. Unlike regular artifacts, reports are not subject to
version control. They can be reproduced at any time by going back to the
artifacts that generated them. Reports are organized in the treebrowser beneath
the artifact on which they report.
Artifacts typically have associated guidelines and checkpoints which present
information on how to develop, evaluate and use the artifacts. Much of the
substance of the Process is contained in the artifact guidelines; the activity
descriptions try to capture the essence of what is done, while the artifact
guidelines capture the essence of doing the work. The checkpoints provide a
quick reference to help you assess the quality of the artifact.
Both guidelines and checkpoints are useful in a number of contexts: they
help you decide what to do, they help you to do it, and they help you to decide
if you've done a good job when you're done. Guidelines and checkpoints related
to each specific artifact are organized along with that artifact in the
treebrowser. Artifact guidelines are also summarily presented in the Artifact
Guidelines Overview.
A typical artifact in the treebrowser, with checkpoints and
guidelines expanded.
A mere enumeration of all roles, activities and artifacts does not
constitute a process; we need a way to describe meaningful sequences of
activities that produce some valuable result, and to show interactions between
roles. A workflow is a sequence of activities that produces a result of
observable value.
In UML terms, a workflow can be expressed as a sequence diagram, a
collaboration diagram, or an activity diagram. We use a form of activity
diagrams in the RUP. For each discipline, an activity
diagram is presented. This diagram shows the workflow, expressed in
terms of workflow details.
Sample activity diagram, from the requirements discipline,
showing workflow details and transitions.
One of the great difficulties of describing the process is that there are
many ways to organize the set of activities into workflows. We have organized
the RUP using:
- Disciplines
- Workflow details
A discipline is a collection of related activities that are related to
a major 'area of concern' within the overall project. The grouping activities
into disciplines is mainly an aid to understanding the project from
a 'traditional' waterfall perspective - typically, for example, it is
more common to perform certain requirements activities in close coordination
with analysis and design activities. Separating these activities into
separate disciplines makes the activities easier to comprehend but
more difficult to schedule.
Disciplines in the treebrowser
Like other workflows, a discipline's workflow is a semi-ordered sequence of
activities which are performed to achieve a particular result. The
"semi-ordered" nature of discipline workflows emphasizes that the discipline workflows cannot present the real nuances of scheduling "real work",
for they cannot depict the optionality of activities or iterative nature of real
projects. Yet they still have value as a way for us to understand the process by
breaking it into smaller 'areas of concern'.
Each 'area of concern' or discipline has associated with it one or more
'models', which are in turn composed of associated artifacts. The most important
artifacts are the models that each discipline yields: use-case model, design
model, implementation model, and test model.
Each discipline is associated with a particular set of
models.
For each discipline, an activity overview is also
presented. The activity overview shows all activities in the discipline along with
the role that performs the activity. An artifact overview
diagram is also presented. This diagram shows all artifacts and roles involved
in the discipline.
Sample artifact overview diagram, from the business
modeling discipline.
It is useful to note that the 'discipline-centric' organization of artifacts is
sometimes, though not always, slightly different from the artifact set
organization of artifacts. The reason for this is simple: some artifacts are
used across disciplines; a strict discipline-centric grouping makes it more
difficult to present an integrated process. If you are using only a part of the
process, however, the discipline-centric artifact overviews may prove more useful.
For most of the disciplines, you will also find workflow detail
diagrams, which show groupings of activities that often are performed
"together". These diagrams show roles 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 discipline.
- It becomes too complex to show input and output artifacts for all
activities of a discipline 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 disciplines are not completely independent of one another. For
example, integration occurs in both the implementation and test disciplines,
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 discipline,
together with closely related activities in another discipline.
Sample workflow detail diagram, from the business
modeling discipline.
Activities, steps, and associated guidelines provide general guidance to the
practitioner. To go one step further, tool mentors are an additional
means of providing guidance by showing how to perform the steps using a specific
software tool. Tool mentors are provided in the RUP,
linking its activities with tools such as Rational Rose, Rational RequisitePro,
Rational ClearCase, Rational ClearQuest, Rational Suite TestStudio. The tool mentors almost completely
encapsulate the dependencies of the process on the tool set, keeping the
activities free from tool details. An organization can extend the concept of
tool mentor to provide guidance for other tools.
An example of Tool mentors and their
organization in the treebrowser
Some of the key concepts of the process, such as iteration, phase, risk,
performance testing, and so on, are introduced in separate sections of the
process, usually attached to the most appropriate discipline.
An example of Concepts and their
organization in the treebrowser
Copyright
© 1987 - 2001 Rational Software Corporation
| 
Overview >
Key Concepts
