The Basic Elements
The basic elements of a process website are:
-
Work product: what is produced
-
Task: how to perform the work
-
Role: who performs the work
-
Process: used to define work breakdown and workflow
-
Guidance: templates, checklists, examples, guidelines. concepts, …
These "basic elements" are the building blocks from which processes are composed.
Organizing Elements
The basic elements are organized/grouped using the following elements: a method library, which includes method plug-ins and method configurations.
Plug-ins consist of roles, tasks, work products, guidance, capability patterns and delivery processes. Plug-ins may be futher organized using content packages. For
example, all content related to a specific content area may be placed in the same content package. Each of these
packages might be further divided into sub-packages representing sub-topics. For example, within a specific
development content package, you may want to have a sub-package that includes specific information about
visual modeling.
From the end-user perspective, a method configuration is a selection of method elements to be published. The published configuration is often loosely
referred to as a process website. Internally, configurations are a selection of plug-ins and content packages,
along with (optionally) a set of navigation views. Taking the earlier example a little futher, you can add or
remove visual modeling specifics from a configuration by just including or excluding the visual modeling
content package to/from the configuration.
Details and Examples
The following provides more detail about the basic elements and provides some examples.
Work product
Work products may take various shapes or forms, such as:
-
Documents, such as a Vision, or a Project Plan.
-
A model, such as a Use-Case Model or a Design Model. These can contain model elements (sub-artifacts) such as
Design Classes, Use Cases, and Design Subsystems.
-
Databases, spreadsheets, and other information repositories.
-
Source code and executables.
Work products can be classified as "artifacts" if they are concrete things, "outcomes" if they are not concrete, and
"deliverables" if they are a packaging of artifacts.
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.
Note that roles are not individuals; instead, roles describe responsibilities. An individual will typically take on
several roles at one time, and frequently will change roles over the duration of the project.
Some examples:
-
Analyst - Represents customers and end users, gathers input from stakeholders and
defines requirements.
-
Developer - Develops a part of the system, including designing, implementing, unit testing, and
integrating.
Task
A task is work performed by a role. It is usually defined as a series of steps
that involve creating or updating one or more work products.
Some examples:
-
Develop a vision - Develop an overall vision for the system, including capturing the problem to be
solved, the key stakeholders, the scope/boundary of the system, the system's key features, and any constraints.
-
Plan Iteration - Define the scope and responsibilities of a single iteration.
Guidance
Guidance can be associated to any method element and comes in a number of different
varieties, each with their own specific characteristics (e.g., checklist, concept, example, guideline, practice, report, reusable asset, roadmap, supporting material, template, term definition, tool mentor, white paper, etc.)
Process
Processes pull together tasks, work products, and roles, and add structure and
sequencing information. Tasks or work products can be grouped into higher level activities, called a work breakdown structure(WBS). Activities or tasks can be marked as "planned"
to identify work that you expect to assign and track.
Figure 1: Example Work Breakdown
Diagrams can be added to providing sequencing information. The following example shows an initial activity, "Plan
Test Cycle", followed by two activities that go in parallel, "Monitor and Control Test" and "Test".

Figure 2: Example Activity Diagram
Note that a reusable partial process is sometimes referred to as a capability pattern, whereas a more complete, end-to-end process is sometimes
referred to as a delivery process.
|