Unit2 1 Descriptive Model

Descriptive Process
Modeling
Goals of Descriptive Process Modeling
• Stable and Accurate Process Execution
With a proper process description at hand, both project planners and
project performers can make sure that they are performing all
important and expected activities, and that they are taking into account
all relevant interrelations between those activities.
• Process Understanding
Understanding the process is fundamental for managing this risk. An

explicit process representation makes it much easier to assess the
overall impact of process changes, thus allowing better management of
process changes.
• Process Propagation
A unified process is important because it allows for practices that
are widely accepted as being beneficial, to be propagated to all units in
a large organization.
• Process Measurement
• Measuring a process involves acquiring quantitative information
about the actual activities, products, and resources involved.
• This is a hard task requiring high levels of discipline in order to yield
satisfactory results, and which therefore must be carefully planned
and executed.
• A proper process description greatly facilitates such planning by
making it easier to identify appropriate measurement objects and to
specify the procedures necessary to measure them.
• Process Administration
Long-term goals for a process are often related to improvement (e.g.,

increase product quality, reduce time dedicated to product rework, etc.),
but may be related to other process aspects.
• Process Automation
It happens quite often that once a process has been properly described and stabilized,
opportunities for supporting parts of it with automated tools become evident.
Analyzing a detailed process description is probably one of the best ways to determine the
exact requirements of new process-supporting tools.
This type of support is especially useful in modern development environments, where

developers are frequently distributed geographically, often across several time zones.
Creating a Descriptive Process Model
• Process engineers working on describing an organization’s processes
are confronted with two main challenges.
process elicitation, namely, collecting information about how the
process is actually performed.
storing the process knowledge for future use, the process-
related information must be expressed in a clear and unambiguous way
that is amenable to the goals of the modeling effort.
Approach Overview
• a set-up phase configuring the modeling approach for the
organization, the
1. State objectives and scope
2. Select or develop a process modeling scheme
3. Select (a set of) process modeling formalisms
4. Select or tailor tools modeling goals and context;
• an execution phase performing the actual modeling.
5. Elicitation
6. Create the process model
7. Analyze the process model
8. Analyze the process
Step 1: State Objectives and Scope
The scope of the effort must also be clearly stated. This includes
specifying
– Who will use the process model
– What these people expect of the model
– Which processes should be covered
– Which processes are explicitly excluded from the model
Step 2: Select or Develop a Process Modeling
Schema
– Activity
– Work product
– Role
– Product flow between activities and work products, i.e., which
products are inputs or outputs to which activities
– Assignment of roles to activities, i.e., which roles are responsible for
performing which activities
Step 3: Select (a Set of) Process Modeling
Formalisms
• – Graphical vs. textual. Some notations rely mainly on text, whereas others are
mainly graphical. Some combine these aspects to various extents.
• – Formal vs. informal. Some notations rely on mathematically defined elements,
which can only be combined according to strict rules, whereas others rely on
natural language text and loosely defined graphical elements. Formal elements
are often combined with informal ones to achieve a richer description that is
easier to understand.
• – Fine grained vs. coarse grained. Some notations are intended to describe
processes at a macro level, whereas others provide support for producing very
detailed descriptions.
• – Predetermined vs. extensible. Some notations are intended to be used “as-is,”
with no modifications whatsoever, whereas others allow for extensibility.
Extensibility, in turn, may range from very basic, allowing only for simple tailoring
that is useful only in certain common cases, to very advanced, allowing for
tailoring that can handle almost any practical situation imaginable.
Step 4: Select or Tailor Tools
• Supporting the use of the chosen modeling notation.
• Storing large models or model collections in a convenient and safe
way.
• Producing alternative representations of models.
Step 5: Elicitation
• The elicitation step is intended to collect all information necessary for
actually describing the target software process.
- The process entities. These include activities, roles, work
products, tools, and, potentially, many others.
- Relationships between entities.
-Behavioral properties of the process entities.
Step 6: Create the Process Model
The information collected during the elicitation step can now be used to
create a model using the chosen modeling notation.
– Start by modeling products, because they are usually the easiest
process entities to identify.
– Continue with the activities and the product flow.
– When activities are modeled, attach associated roles to the
activities or the products.
– Model further entity types, such as resources, as needed.
– As a last step, model behavioral restrictions associated with entities,
such as the preconditions that must be met before an activity can
start.
Step 7: Analyze the Process Model
The purpose of the process model analysis step is to detect such
defects and correct them. The following list contains a few examples of
possible process model defects:
– Dangling reference
– Inconsistent precondition
– Inconsistent references
– Orphan entity
– Dependency cycle
– Incomplete descriptions
Step 8: Analyze the Process
To use the process model, to track or analyze process performance,
depending on the process modeling objectives stated in step 1.
Qualitative analyses aim at identifying weaknesses of the
processes.
Quantitative analyses aim at identifying correlations between
process attributes

Unit2 1 Descriptive Model

Uploaded by

Copyright:

Available Formats

Unit2 1 Descriptive Model

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit2 1 Descriptive Model

Uploaded by

Copyright:

Available Formats

Descriptive Process

Understanding the process is fundamental for managing this risk. An

Long-term goals for a process are often related to improvement (e.g.,

This type of support is especially useful in modern development environments, where

You might also like