Key Concepts
Basic concepts in the Rational Unified Process
Software Engineering
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 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 Rational Unified Process 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).
Worker
The most central concept in the Process is that of a worker. A worker 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 worker represents a role played by individuals on a project, and defines how they carry out work. The Workers Overview provides additional information on Workers.
The organization of Workers and their Activities in the treebrowser
Note that workers 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 play different parts or roles. The mapping from individual to worker, performed by the project manager when planning and staffing the project (see Activity: Staff Project), allows different individuals to act as several different workers, and for a worker to be played by several individuals.
Activity
Workers have activities, which define the work they perform. An activity is something that a worker 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 worker, showing its activities in the treebrowser
An activity is a unit of work that an individual playing the role described by the worker 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 worker. The granularity of an activity is generally a few hours to a few days, it usually involves one worker, 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 worker, but not necessarily the same individual.
Steps
Activities are broken down into steps. Steps fall into three main categories:
- Thinking steps: where the worker understands the nature of the task, gathers and examines the input artifacts, and formulates the outcome.
- Performing steps: where the worker creates or updates some artifacts.
- Reviewing steps: where the worker 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 worker evaluates the result to assess completeness, robustness, intelligibility, or other qualities.
Work Guideline
Activities may have associated Work Guidelines, which present techniques and practical advice that is useful to the worker 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.
Artifact
Activities have input and output artifacts. An artifact is a work product of the process: workers use artifacts to perform activities, and produce artifacts in the course of performing activities. Artifacts are the responsibility of a single worker, to 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:
- A model, such as the Use-Case Model or the Design Model, which contains other artifacts.
- A model element, i.e. an element within a model, such as a Design Class, a Use Case or a Design Subsystem
- A document, such as Business Case or Software Architecture Document
- Source code and executables (kinds of Components)
- Executables
Note that "artifact" is the term used in the Rational Unified Process. 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 Rational Unified Process 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 ClearQuest.
- A project requirements database in 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.
Template
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.
- SoDA templates for Microsoft Word or FrameMaker would extract information from tools such as Rational Rose, RequisitePro, or 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 Rational Unified Process.
Report
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.
Artifact Guidelines and Check-points
Artifacts typically have associated guidelines and check-points 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 check-points provide a quick reference to help you assess the quality of the artifact.
Both guidelines and check-points 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 check-points 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 check-points and guidelines expanded.
Workflows
A mere enumeration of all workers, 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 workers. 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 Rational Unified Process. For each core workflow, an activity diagram is presented. This diagram shows the workflow, expressed in terms of workflow details.
Sample activity diagram, from the requirements workflow, 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 Rational Unified Process using:
- Core workflows
- Workflow details
Core Workflows
A core workflow is a collection of related activities that are related to a major 'area of concern' within the overall project. The grouping activities into core workflows 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 core workflows makes the activities easier to comprehend but more difficult to schedule.
Core Workflows in the treebrowser
Like other workflows, a core workflow is a semi-ordered sequence of activities which are performed to achieve a particular result. The "semi-ordered" nature of core workflows emphasizes that the core 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 core workflow 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 core workflow yields: use-case model, design model, implementation model, and test model.
Each core workflow is associated with a particular set of models.
For each core workflow, an activity overview is also presented. The activity overview shows all activities in the workflow along with the worker that performs the activity. An artifact overview diagram is also presented. This diagram shows all artifacts and workers involved in the workflow.
Sample artifact overview diagram, from the business modeling workflow.
It is useful to note that the 'workflow-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 core workflows; a strict workflow-centric grouping makes it more difficult to present an integrated process. If you are using only a part of the process, however, the workflow-centric artifact overviews may prove more useful.
Workflow Details
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.
Other Concepts
Tool mentor
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 Rational Unified Process, linking its activities with tools such as Rational Rose, RequisitePro, ClearCase, ClearQuest, 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
Concepts
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 core workflow.
An example of Concepts and their
organization in the treebrowser
