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 further 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 further, 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.