See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/332606732

Descriptive Process Models

Chapter · March 2012

DOI: 10.1007/978-3-642-24291-5_3

CITATION READS

1 4,967

4 authors, including:

Jürgen Münch Ove Armbrust

Hochschule Reutlingen Intel
392 PUBLICATIONS   4,873 CITATIONS    37 PUBLICATIONS   329 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Entrepreneurship Education View project

Spinnovation - Entrepreneurship meets Education View project

All content following this page was uploaded by Jürgen Münch on 24 April 2019.

The user has requested enhancement of the downloaded file.

 124

3 Descriptive Process Models

This chapter introduces descriptive process models as a means of capturing the

processes being pursued by an organization. It first describes some typical goals of
descriptive process modeling efforts and then details a systematic approach for
creating a descriptive process model. In addition, alternatives to a part of the
approach as well as for the complete approach are presented in order to provide a
broader view on the subject. In most process modeling approaches, eliciting
process information through interviews is one of the hardest activities; hence the
chapter gives some guidelines on conducting efficient and effective interviews.
Finally, the chapter introduces some tactics for managing the risks that accompany
descriptive process modeling efforts. Fig. 3.1 gives an overview of the chapter
structure.
Creating Descriptive Process
Descriptive Process Risk
Descriptive Modeling Elicitation
Modeling Goals Management
Process Models Alternatives Guidelines

Fig. 3.1: Chapter structure

3.1 Objectives of this chapter

After reading this chapter, you should be able to

define goals for a descriptive process modeling effort,

plan and conduct a descriptive process modeling effort based on an 8-step

approach,

conduct process elicitation interviews, and

assess and manage the basic risks associated with a descriptive process
modeling effort.
 125

3.2 Introduction

The last chapter explained that one of the main purposes of prescriptive process
models is to provide a reference process framework that an organization can
adopt. Since these process descriptions are usually based on well-proven and
widely accepted practices, their adoption often constitutes a safe path to process
improvement.

The downside of prescriptive models is that, being generic, they cannot exactly fit
the particularities of a specific organization. A number of factors can influence the
way software development activities are shaped in an organization. Obviously, the
strongest of these factors are usually related to the type of product that is being
developed, as well as to the technology involved in producing this product. Still,
even organizations that produce similar, potentially competing software products
often have widely different ways of developing them. These differences can be
related to factors such as their organizational culture and history, the social, legal,
and political contexts in which the organization operates, and the level of skill and
type of education of the people involved, among many others. The result is that, in
practice, no organization exactly follows a generic prescribed process, and no two
organizations operate according to exactly the same process.

The actual processes present in an organization, those that are used in practice to
produce and deliver the organization's products and services, can usually be
counted as one of its main assets. Normally, these processes encompass a good
deal of the experience and knowledge that make an organization successful. For
this reason, managing them appropriately can become a crucial activity for an
organization's long-time survival.

The discipline behind this type of process management is called descriptive

process modeling. As its name implies, this discipline is concerned with producing
an explicit and accurate representation of an organization's actual processes, for
purposes such as documentation, dissemination, analysis, and improvement.
 126

3.3 Goals of descriptive process modeling

Descriptive process modeling can serve a number of goals in an organization. This

section describes some common reasons why organizations decide to describe
their processes explicitly.

3.3.1 Stable and accurate process execution

Software processes can be very complex, involving large numbers of interrelated

activities. For every software development project, these activities must be
carefully orchestrated, so that dependencies are respected and resources are
available where and when they are needed. This complexity makes it very hard to
guarantee that processes are always executed in the same way. Given the large
number of individual activities and their complex interdependencies, there is a
high risk that some activities are not planned, or are skipped because of external
pressure. Also, there is always the risk that people will change the process over
time without even noticing it, maybe eliminating beneficial activities.

A documented process helps to mitigate these risks. 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. Also, a
documented process makes it easier to introduce changes in a controlled fashion,
which leads us to our next point: understanding the process.

3.3.2 Process understanding

Software development processes must change for a number of reasons.

Sometimes, external factors—such as changes in laws and regulations, or
technological progress—force changes in the development process. Very often,
however, the process is changed in order to introduce improvements. In many
organizations, this happens in an organic fashion, because people identify
situations where work can be done in a better way. There is always the risk,
 127

however, that changes that are originally perceived as improvements end up

having unintended, detrimental consequences, which may negatively affect the
overall process performance. For example, tools are often introduced because they
are expected to improve the process by automating parts of it. It may happen,
however, that a particular tool is designed with a process in mind that is too
different from that of the organization. In this case, the tool is likely to introduce
inefficiencies that are not compensated by its potential advantages.

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.

3.3.3 Process propagation

A common problem, present especially in large organizations, is that different

development groups in the organization follow different processes for the same
task. Sometimes, these process differences are related to the fact that different
groups may have different needs. However, it often happens that they work
differently simply because it is difficult for a group to exactly tell what other
groups are doing.

By explicitly describing the processes followed by various organizational units, it

is easier to achieve a unified process. Differences between groups can still exist,
but they are the result of conscious decisions based on analyzing each group's
particular needs. 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.

3.3.4 Process measurement

As an organization reaches a higher degree of process maturity, it becomes

increasingly important to measure process performance. Aspects that are
commonly measured in a process are its productivity (amount of output produced
vs. resources invested into producing it), its ability to deliver results on time, and
 128

its ability to detect and correct product defects as early as possible, among many
others. The reasons for measuring vary widely from one organization to another,
but often include the desire to improve planning and increase the quality of
software products by reducing the number of defects present in them when they
are delivered.

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. In addition, it provides the
basis for comparing two processes with each other: It is only feasible to compare,
for instance, the “duration of code development” if it is known which activities are
contained: only coding, or also unit/integration testing?

3.3.5 Process administration

In the long term, one of the main reasons for explicitly describing an
organization's development processes is to be able to define goals for the process,
and work systematically on achieving them. Doing this involves at least some of
the descriptive process modeling goals explained above, such as process
understanding and process measurement. 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. For example,
many companies are forced by legal regulations, or, simply, by the critical nature
of their products, to comply with existing norms and regulations regarding the
way their products are produced and validated. For these organizations, one
important reason for modeling their processes explicitly is to guarantee that they
comply with whatever norms and regulations are considered relevant. Without a
proper process description, this can be very difficult or even impossible to
achieve.
 129

3.3.6 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.

One area where processes can be supported in a particularly effective way is

information flow. Since process models often contain detailed descriptions of the
product and control flows in a process, a tool can effectively support process
participants by giving them access to the pieces of information that are relevant
for their activities, and by providing appropriate mechanisms for storing new work
products and informing other process performers about their availability and
status. This type of support is especially useful in modern development
environments, where developers are frequently distributed geographically, often
across several time zones.

3.4 Creating a descriptive process model

This section introduces a systematic approach for creating and validating a

descriptive process model.

Process engineers working on describing an organization's processes are

confronted with two main challenges. The first of these challenges is the so-called
process elicitation, namely, collecting information about how the process is
actually performed. This can be done by working together with the actual process
performers, by observing their work, or by analyzing the results of their work,
such as the documents produced during past development projects. Through
interviews, direct observation of people's work, and analysis of documents and
final products, among other techniques, process engineers gain a detailed
understanding of the process.

The second challenge process engineers face is storing the process knowledge for
future use. The process-related information must be expressed in a clear and
 130

unambiguous way that is amenable to the goals of the modeling effort (e.g.,
process measurement, improvement, analysis, etc.). A number of notations and
modeling tools are available to facilitate this task. Notations allow expressing
processes using a predefined, standardized set of concepts. They can be formal or
graphical in nature, with graphical notations being preferred in recent years
because they facilitate communication with process stakeholders. Tools, in turn,
help process engineers to deal with the complexity of process models, which, in
practice, may easily grow to contain hundreds or even thousands of individual
elements.

Normally, descriptive process modeling is performed in an iterative fashion, with

the elicitation and modeling phases being interwoven. Process engineers work to
gain some initial knowledge of the modeled process, describe this knowledge
using an appropriate process notation, and then discuss this initial description with
the process stakeholders. This discussion often leads to additional knowledge
being collected, which can be incorporated into the description and validated again
with the stakeholders. This cycle can be repeated until satisfactory levels of detail
and accuracy of the process description have been achieved.

The following sections detail a systematic approach to creating a descriptive

process model for an organization. It is based on the 8-step approach presented in
[1]. In addition to the approach described in this section, section 3.5.1 describes an
alternative to steps 5 and 6, whereas section 3.5.2 introduces a complete
alternative to creating a descriptive process model.

3.4.1 Approach overview

The approach consists of two major phases: a set-up phase configuring the
modeling approach for the organization, the modeling goals and context; and an
execution phase performing the actual modeling. The set-up phase consists of
these four steps:

1. State objectives and scope

2. Select or develop a process modeling scheme

 131

3. Select (a set of) process modeling formalisms

4. Select or tailor tools

The execution phase consist of these four steps:

5. Elicitation

6. Create the process model

7. Analyze the process model

8. Analyze the process

In theory, these steps should be repeated for every process modeling effort in
order to achieve optimal results. In practice, however, the process modeling
scheme, formalisms, and tools are likely to be rather stable across different
modeling efforts, because in a real-world setting, it is usually not feasible to
frequently switch them due to cost reasons. Nevertheless, every modeling effort
should clearly state its objectives and scope, because they will likely not be stable
across different modeling efforts. Steps 5 through 8 will have to be repeated in any
case.

The eight steps are explained in detail in the following sections, illustrated by
three different case studies highlighting different contexts and goals of a
descriptive process modeling effort. Although the case studies are fictitious, they
reflect the realities of common process modeling efforts. The general settings in
which each of the case studies take place are as follows.

Case Study 1: The Defect Management Process at DocVault

DocVault is a small software development company, with about 50 employees and

six years in the market. DocVault's main product is an Internet-based document
management system that is made available to clients through a subscription-based
model (software-as-a-service). The company already has more than 30 corporate
customers and good prospects for acquiring several more in the upcoming months.

Since DocVaults´s product is already quite large and complex, it is relatively

common for clients to be affected by defects in the system that were not detected
by the quality assurance procedures used by the company (mainly testing). Until
 132

now, the company has relied on email as the main mechanism for clients to report
problems they might have found. This simple mechanism has served the company
well so far, but with the number of customers quickly increasing, the need for a
more elaborate and potentially automated solution is becoming urgent.

For this reason, DocVault wants to start by modeling its defect management
process. This process involves not only the actual problem reporting by users, but
also the classification of problem reports by company staff, the assignment of
potential defect-fixing tasks to developers, and the follow-up of defect fixes until
they are released to clients, among other tasks.

Case Study 2: Software Development at Selene Aerospace Systems

Selene Aerospace Systems specializes in building complex data transmission and

storage systems for satellites and other spacecraft. Selene was founded almost 20
years ago, and currently has about 700 employees, about 250 of whom perform
tasks related to software development.

The development process at Selene has evolved from the company's long
experience in aerospace systems and can be considered quite stable at this time.
Since Selene´s systems are very often very complex and often subject to strong
reliability requirements, the development processes at the company are very
elaborate and complex, involving a large number of steps for tasks such as
requirements management and quality assurance.

The complexity of Selene´s development process can easily become problematic:

The only way to make sure that processes are executed as desired is by involving
highly experienced project managers and developers in each project. The company
keeps growing, however, which makes it impossible to find enough experienced
people for all new projects. For this reason, the company is considering modeling
its complete set of development processes in order to make them more accessible
to less experienced developers and project managers.

Case Study 3: Software Customization at Soster

Soster Inc.'s product is an Enterprise Resource Planning (ERP) system oriented

towards small and medium-sized companies. Soster is a about 10 years old, and
 133

has about 200 employees. Over the years, Soster has developed a solid, highly
customizable core system implementing most of the required ERP functionality.
For this reason, its current business centers on customizing this system for specific
customers.

Soster´s system has already been customized for more than 250 customers, which
is a pretty large number given the company´s relatively small size. This has been
possible because the customization process is very streamlined, consisting mostly
of creating a set of UML models for each client, which are used to generate code
automatically. The generated code often has to be complemented by hand-written
code, but the size of this manually created code can be kept quite small.

Since Soster's revenue comes mostly from customization, the company is

especially interested in optimizing this process. In particular, it is important to
maximize product quality and project predictability. For this reason, the company
has decided to start a modeling effort to describe this particular process.

3.4.2 Step 1: State objectives and scope

Section 3.3 described a variety of possible goals a descriptive process modeling

effort may have. In order to properly plan and later manage the process modeling
effort, it is thus important to state its goals clearly before any modeling has started.
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, and

which processes are explicitly excluded from the model.

With this information as a basis, it is possible to specify the scope more

concretely. For example, knowing the general goals of the effort as well as
people's concrete expectations makes it possible to determine which processes to
model in which detail in order to better fulfill the stated goals and meet the stated
expectations.
 134

The following subsection explains how this first step was performed in the
exemplary case studies.

Case Study 1: DocVault

The modeling effort at DocVault is restricted to the defect management process.

This means that the scope is relatively narrow:
Modeling is limited to the defect management process. It includes taking
problem reports from users, classifying them, assigning accepted reports to
responsible people in the company, and following them up until fixes are
released. Technical processes related to the actual fixing of defects, such as
determining the causes of particular failures, designing and implementing
code fixes, and testing fixed code, are excluded, however.

The main users of the description are the developers of the automated defect
management system. Notice that these are likely to be not the same people
developing DocVault's product, since DocVault will probably subcontract the
defect management system to another company. DocVault's clients, as well as
the software developers and quality management team at DocVault, are
considered secondary users, as they may use the process description for their
own purposes, such as guidance while actually handling problem reports.

The developers of the defect management system (primary users) expect a

detailed description they can use as an initial set of requirements for
implementing the process automation. The secondary users, on the other
hand, expect a clear description that can be used for guiding internal users at
DocVault.

Case Study 2: Selene

The modeling effort at Selene has a very wide scope, covering all software
development processes in the company:
The main objective of the modeling effort is to provide guidance for all roles
in the organization. This involves describing the processes at a level of detail
that allows for processes to be performed reliably even by people who were
only recently trained and still lack experience with a particular process.
 135

All processes related to software development are covered, with no exception.

The level of detail is expected to be high.

The users are all roles participating in development, again with no exception.

Case Study 3: Soster

Soster's modeling effort is narrower than that at Selene, since it involves only one
process. This process, however, is relatively large and complex and has to be
covered in a very detailed way:
The main objective of the modeling effort is to support improvement. In
particular, enough information must be available in the model to make it
possible for product quality and project predictability to be optimized. Notice
that the goal of the modeling effort is to provide the necessary information for
process analysis, but not to perform the actual improvements on the process.

Processes related to customization are covered, such as requirements

elicitation and management, model creation and validation, quality assurance,
customization of the generated system through manually written code, and
system deployment. The processes related to the development and
maintenance of the core system are explicitly excluded.

The target users of the resulting model are the members of Soster's SEPG,
since they are responsible for the improvement effort. Other roles at the
company, such as developers and project managers, are explicitly excluded.

3.4.3 Step 2: Select or develop a process modeling schema

The second step of descriptive process modeling consists of identifying the set of
concepts that will be used to describe processes. The following (very simplified)
example illustrates how this step may be done in practice.

Example: An organization decides that it will model its processes based on the
following informal description:

“We see processes in our company as consisting of a number of individual

activities (such as Requirements Elicitation, Design Specification, Module
 136

Implementation, etc.). Each of these activities has a set of inputs, which are work
products of different kinds (e.g., Functional Requirements Specification, High
Level Class Diagram, Module Source File, etc.). The goal of an activity is to
produce a set of outputs based on the inputs it receives. The outputs, of course, are
also work products. In this way, activities are interconnected through their
associated work products: The outputs of an activity can be inputs to the
subsequent activities. Finally, activities are associated to particular people's roles
(e.g., Requirements Engineer, Software Architect, Programmer, etc.) This means
that the people occupying these roles are responsible for the corresponding
activities.”

From this description, it is possible to identify a number of basic concepts that are
important for describing processes in the organization:
activity,

work product,

role,

product flow between activities and work products, i.e., which products are
inputs or outputs to which activities, and

assignment of roles to activities, i.e., which roles are responsible for

performing which activities.

Usually, a set of concepts such as this used to model processes is called a process
schema.

Although identifying an appropriate set of modeling concepts may appear to be

quite simple from this small example, it is, in practice, a very difficult task, and
one that deserves very careful consideration given its importance for the success
of the subsequent modeling steps. As a minimum, the following requirements
should be taken into account while choosing a process schema:
The concepts must cover those aspects of a process that are relevant for the
current modeling effort. The general concept of a model is related to
conveniently representing certain specific aspects of reality, while
purposefully ignoring those that are irrelevant for a specific purpose. Process
 137

models are no exception in this respect. The chosen set of concepts must
cover those aspects of the process that are necessary for achieving the stated
modeling goals. For instance, if reducing time to market for new products is a
stated modeling goal, modeling the amount of time required by different
activities will be fundamental. The chosen process schema must be able to
represent this information.

The concepts must allow for an adequate level of detail and formalism.
Achieving an appropriate level of detail and precision while modeling can be
very important. Too much detail may be as inadequate as too little detail,
depending on the particular situation. For example, a model that is intended
for personnel training may be more detailed and informal than one that is
intended to provide fine-grained support for process enactment. A set of
concepts that does not allow for the level of detail or formalism required by a
particular modeling effort, or that requires too much of any of them, will be
inadequate and must be adjusted.

The concepts must facilitate modeling. A process schema that appears

adequate at first sight may indeed be very difficult to use in practice. For
example, it may happen that common situations are difficult to express, and
end up requiring too many entities or a convolved structure of the entities in
order to be described appropriately. For this reason, it is important to test
modeling concepts in advance before committing to them for a large
modeling effort. Trying to model a few, well-known processes or process
excerpts may greatly help to assess the relative easiness or difficulty of
modeling the complete process.

Modeling results must be accessible for their intended audience. If process

models are intended for people to use, this obviously means that these people
must be able to properly read and understand them. If the chosen set of
modeling concepts is too complex or unintuitive, chances are that users will
be confused when they try to make sense of a model, no matter how careful
process engineers were while producing the model.
 138

Designing a set of concepts “from scratch” that fulfills all of these requirements
can be a difficult task even for experienced process engineers. The main problem
lies in the fact that one cannot determine by simple observation whether a
particular schema fulfills any of the criteria. Normally, a schema must be
extensively tried in practice before all of its disadvantages become apparent.

For this reason, it is strongly advisable to use an existing schema whenever

possible. Fortunately, there are enough schemata available that cover most
common modeling needs, and that have been extensively tested in practice and are
already known to have withstood the proverbial “test of time”. If tailoring of a
schema is necessary, it should be performed by sufficiently experienced process
engineers, and the result thoroughly tested before being used in any significant
modeling efforts.

Case study 1: DocVault

Given the narrow scope of its modeling effort, DocVault can live with a small set
of modeling concepts: task, artifact, and role. Also, modeling more specific
dependencies among entities of these types is not necessary, because the involved
work flows are relatively simple. For this reason, a produces and a consumes
relationship, together with a relation to associate roles to tasks are enough for this
modeling effort.

Cvase study 2: Selene

Due to the size and level of detail of its modeling effort, Selene requires a large set
of concepts. Because of its complexity, only the most important concepts of the
Selene schema will be covered:
Processes with several levels of refinement: activity, task, step.

Deliverables, also with several refinement levels: deliverable, part, chapter,

etc.

Individual (e.g., Project Manager, Tester) and group roles (Change

Management Board).

A number of secondary concepts associated to the primary ones mentioned

above, such as
 139

generic methods used to perform an activity or task,

templates for deliverables, used to facilitate the creation of new

documents,

level of training and experience required to occupy a role,

etc.
A complex set of relationships between concepts, including

grouping and hierarchy,

dependencies,

associations between main and secondary concepts,

etc.

Many of the elements in this schema have textual attributes that allow describing
them in detail.

Case study 3: Soster

The modeling scope at Soster does not require a schema with the level of
complexity required at Selene. Still, a number of concepts are necessary:
Processes with two levels of refinement: activity, subactivity.

Non-hierarchical deliverables and roles.

Specialized entity types for modeling project planning and control activities,
as well as for modeling quality control activities. These are necessary in order
to provide finer-grained modeling for the most relevant concepts, namely,
those related to project predictability and product quality.

Relations to connect the special entities with the basic entities and among
themselves:

processes used to plan a given development activity,

processes used to monitor the execution of a given development activity,

processes used for quality assurance of a particular deliverable,

 140

etc.

3.4.4 Step 3: Select (a set of) process modeling formalisms

Process modeling not only requires an appropriate set of concepts but a concrete
notation in which these concepts can be expressed. A variety of modeling
notations have been used over time, with significant differences in formalism and
expressive power. Of course, the notation chosen for a particular modeling effort
must be able to express the concepts identified in the previous step. Additionally,
process notations can be characterized along a number of dimensions:
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.

Taking these dimensions into account, it is possible to choose a notation that is

appropriate for the needs of a particular modeling effort. For instance, if the main
modeling goal is to support automated enactment, a formal and fine-grained
notation would be desirable. On the other hand, if the main purpose is to support
personnel training, a more informal and coarser-grained notation would likely be
 141

enough. Notice that, for both of these examples, the notation could be either
graphical or textual, as long as the necessary levels of formality and detail are
achieved.

Similar to the identification of modeling concepts discussed in the previous step,

selecting an appropriate notation is a demanding task. Indeed, a set of
requirements analog to the one presented for the previous step applies here as
well:
The notation must cover the concepts selected in the previous step.

The notation must allow for an adequate level of detail and formalism.

The notation must facilitate modeling.

The modeling results (as represented in the chosen modeling notation) must
be accessible to their intended audience.

As in the previous step, these requirements make it very advisable to stick to

existing notations whenever possible, and to reduce their tailoring to a minimum.

Given the difficulty of finding appropriate modeling notations, this step is often
interwoven in practice with the previous one, that is, the detailed set of modeling
concepts and the notation are selected simultaneously. Still, thinking of both steps
as conceptually separate remains useful. In particular, by thinking about the
necessary modeling concepts in advance, one can guarantee that a notation was
chosen because it was appropriate for the modeling effort at hand. Otherwise,
there is a high risk that a notation is chosen because it appears convenient (e.g.,
because it is supported by well-known vendors and/or popular tools) and not
because it offers a set of modeling concepts that fulfill the needs of the process
stakeholders.

Case study 1: DocVault

Since DocVault's aim is to automate the defect management process, they require
a process description that is essentially free of imprecision and ambiguity. For this
reason, the process modeling team decides to define a formal, yet simple process
notation. This textual notation allows for defining instances of the concepts
mentioned in the last section. While defining a process, entities must be given
 142

unique identifiers that can later be used for referring to them from other elements,
such as relations. Additionally, a formula notation can be used to express pre- and
post-conditions for tasks. These conditions can later be used by the programmers
automating the process.

Case Study 2: Selene

In order to provide detailed guidance to a variety of process performers, Selene

largely requires using natural language text for describing processes. Maintaining
a purely informal description of the large and complex set of processes at Selene
would be very difficult, however. As seen in the previous section, Selene's schema
involves a significant number of relations between elements. Making these
relations explicit in a natural-language description is cumbersome, and verifying
them or updating them after changing the model becomes very difficult, because
of the need to search for them in a mostly manual way.

For this reason, Selene decided to add a formal structure to the plain-text
description. This structure is used to organize the elements in appropriate
hierarchies as well as to explicitly represent the many relationships among
elements. Individual entities inside this structure are still mainly described using
natural-language text, but this text is integrated in the formal structure so that it
can be more easily managed. In particular, when the text references model entities
other than the one being described, these references use explicit, model-unique
identifiers. This way, they can later be traced and corrected when the model is
updated.

Case study 3: Soster

For Soster, the ability to identify inefficiencies in their customization processes is

an absolute priority, so they wanted a notation that is especially amenable to
analysis. For this reason, they decided to express their schema concepts using a
graphical representation. This representation makes it convenient for process
experts to look at the process, identify potential inefficiencies, and discuss
potential improvements.
 143

3.4.5 Step 4: Select or tailor tools

Tool support is usually necessary to effectively model complex processes. Among

other things, in a descriptive modeling effort, tools are useful for:
Supporting the use of the chosen modeling notation. The more complex the
chosen modeling notation, the higher the need for an editing tool that supports
it explicitly. Editing tools not only facilitate creating and changing models,
but often help guarantee that the notation is being used properly.

Storing large models or model collections in a convenient and safe way.

Depending on the technology used, modeling efforts may end up producing
large numbers of interrelated objects. Tools often help to manage these
objects so that they can be conveniently accessed and changed in a safe,
controlled way. This type of functionality may be integrated in the modeling
tool itself, or it can be provided by separate tools, such as a version
management system.

Producing alternative representations of models. In many cases, different

process stakeholders have different needs regarding the way a process model
is presented. For instance, project managers may require an overview of the
activities involved in a process, whereas the people working on specific
activities will need to see the details of how such activities must be
performed.

One important aspect about tools is that they do not have to be specialized process
modeling tools in order to be adequate for a particular modeling effort. In many
cases, standard office tools (word processor, spreadsheet) and/or generic
diagramming tools can be effectively used to model processes, as long as the
chosen notation is simple enough for them and the models are small and need only
little maintenance. Specialized tools, on the other hand, can provide specific
support for particular notations and model maintenance, which can be a deciding
factor when very large or complex models are involved. Of course, such tools are
often accompanied by higher license and user training costs.

Case study 1: DocVault

 144

The relatively small size of DocVault's defect management process as well as the
selected, text-based notation make it possible to conduct the modeling without
using advanced modeling tools. For this reason, DocVault decided to use standard
programming text editors for creating and maintaining the model.

Case Study 2: Selene

For its modeling effort, Selene had to edit a significant amount of text. Moreover,
this text must be properly formated, included typical rich text features such as
titles, numbering and bullet lists, use of various fonts for highlighting, etc. As
explained before, however, Selene's needs are not restricted to editing text, but
also involve organizing the edited text into a complex model structure.

In order to support these needs, Selene chose a commercial tool that stores the
model structure and text context in a shared, relational database, but uses a
standard word processor as its front-end. Process engineers can then use the word
processor to comfortably create rich text (including, for example, graphics and
tables) and then store it the database for later processing. Formal elements of the
model, such as relations between entities, are entered in the word processor using
special templates, which are later processed by the tool in order to create the
actual relations in the database.

Case study 3: Soster

Soster's emphasis on a graphical process display led them to choose a commercial

graphical model editor as their main modeling tool. This editor can be adapted to
support a variety of schemata, so they started by customizing it to support their
chosen schema.

3.4.6 Step 5: Elicitation

The elicitation step is intended to collect all information necessary for actually
describing the target software process. Mainly, the necessary information
comprises:
 145

The process entities. These include activities, roles, work products, tools, and,
potentially, many others. Oftentimes, entities form hierarchies. For example,
major activities can be decomposed into smaller tasks, and tasks, in turn, can
be decomposed into individual steps.

Relationships between entities. For example, information about which

activities produce or consume which products, which tools are necessary for
performing a task, or which tasks compose an activity is expressed through
relationships.

Behavioral properties of the process entities, e.g., which conditions must hold
in order for an activity to be started (preconditions), or which criteria a work
product must fulfill in order to be accepted.

The information items listed above can be obtained from a number of sources:
individual interviews with process performers.

group-oriented workshops with process performers.

direct observation of people at work.

analysis of preexisting work products.

analysis of other data left by the execution of a process, e.g., meeting minutes,
electronic discussions, issue/bug reports, software version history, etc.

The techniques used to elicit information are a central success factor for a
descriptive process modeling effort. Depending on the organization's culture, for
example, either individual interviews, group workshops, or a combination of both
may be the best option for obtaining direct information from process participants.

One delicate and often very critical aspect of process elicitation is that process
engineers should avoid issuing judgments about the process they are eliciting, or
about the people performing it. The fear of being judged frequently moves people
to describe an ideal process that they expect will be accepted better. Of course,
this is a very undesirable situation, because the main goal of descriptive process
modeling is to produce an accurate representation of the actual process. This
 146

aspect of descriptive process modeling will be discussed in more detail in section

3.8.1 below.

Case study 1: DocVault

DocVault used three information sources for elicitation:

interviews with members of the quality assurance team.

interviews with staff members of one large customer, who had reported
several problems over the years.

archived e-mail messages from various problem reports.

Case Study 2: Selene

In order to cover their large scope, Selene required a comprehensive interview

program, covering all roles in the organization. In order to improve the
completeness and accuracy of the resulting model, it was decided to conduct
separate interviews with several people in the same role whenever possible.
Although this additional effort actually helped to collect more complete and
detailed information about the process, it also caused difficulties because,
oftentimes, several somewhat contradictory or otherwise inconsistent views arose.
Solving these inconsistencies required significant effort on the part of the
elicitation team, often involving special meetings for discussing the details of a
particular activity or set of activities with process participants.

Case study 3: Soster

The elicitation effort at Soster relied on two main information sources:

Interviews with engineers in charge of the customization process.

Documentation from old and current customization projects.

3.4.7 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. It is advisable to collect the
information in the following general order [2]:
 147

Start by modeling products, because they are usually the easiest process
entities to identify. In contrast to activities, which are often only implicitly
defined, a set of products usually explicitly exists in an organization and can
be directly modeled.

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.

Here again, there is a conceptual separation between the elicitation and the actual
modeling steps, although, in practice, they are normally interwoven. Once an
initial model is available based on elicited information, it must be reviewed by the
process participants. Such a review will often result in additional elicitation
activities and successive model refinements. In most cases, several
elicitation/modeling cycles will be necessary to achieve an adequate level of
agreement about the process model.

Case study 1: DocVault

The model creation work at DocVault was conducted by two process engineers,
who prepared detailed step sequences in a regular programming text editor using
the defined formal notation. In order to review the resulting model, a workshop
was conducted where selected members of DocVault's Quality Assurance team
worked together with the process engineers. The process engineers presented the
model, while the QA members were encouraged to criticize it and make
suggestions. Issues were written down during the workshop and corrected
afterwards.

Case Study 2: Selene

After the interview phase was completed at Selene, the process engineers moved
on to creating the model. They proceeded in two main steps:
 148

1. Create a high-level model. This model contained the basic structure and
relations, but no detailed text descriptions. Meetings with small groups of
process performers were conducted in order to validate this high level
model.

2. Add textual descriptions. When the high-level structure was considered

sufficiently stable, detailed textual descriptions were added. The process
engineering team used the help of technical writers to conduct this step.

When the model was completed, an Electronic Process Guide was generated from
the model and validated with selected performers in small focused meetings.

Case study 3: Soster

The use of a graphical notation and editor had a particular advantage for Soster:
Initial versions of the process models for particular activities could be created
“live” during interviews with process participants. This made it easier to
determine whether the interviewer's view of the process matched that of the
interviewee. After the interviews, the process engineers proceeded to merge these
views into a single, unified, graphical model.

3.4.8 Step 5: Analyze the process model

As process models become complex, there is an increasing risk of defects being

inadvertently introduced into the model by the process engineers. The purpose of
the process model analysis step is to detect such defects and correct them.

Depending on the notation used, there are many possible types of defects that may
arise in practice. The following list contains a few examples of possible process
model defects:
Dangling reference: An entity references another, undefined entity, e.g., an
activity description mentions an input work product that has no definition of
its own in the model.

Inconsistent precondition: The start conditions stated for an activity are

contradictory and cannot be fulfilled in practice.
 149

Inconsistent references: The same entity is mentioned in the model using

different, inconsistent names.

Orphan entity: An entity is defined in the model, but is not referenced by any
other entity in a meaningful way.

Dependency cycle: An activity depends on a particular input product in order

to start, but, according to the model, this input product cannot be produced
unless the activity has already been finished.

Incomplete descriptions: Important entity attributes, such as activity or

product descriptions, are missing or empty in some or all of the process
entities.

The analyses that can be performed to detect defects such as those listed above
roughly fall into three categories:
Completeness analyses. Even if a model correctly describes a process, the
level of detail or the amount of information in the description could be
insufficient. Completeness analyses are concerned with making sure that all
relevant information is available and at a sufficient level of detail. Checking
for empty fields in entity description forms, and making sure that all activities
in a process are refined to the level of individual tasks, are two examples of
possible completeness analyses.

Consistency analyses. This type of analysis is related to making sure that

elements of the model do not contradict each other. An example of a
consistency analysis is to make sure that all products mentioned by the natural
language description of an activity are modeled explicitly as inputs or outputs
of the activity, and that they are mentioned using the same name used in the
corresponding product description.

Dynamic analyses. These analyses are concerned with problems that may
arise when the process described by the model is executed. A typical dynamic
analysis is to search for potential deadlocks that may occur while executing
the process.
 150

Depending on the levels of formality and detail of the chosen process model
notation, process analysis can be automated. Indeed, this is one of the main
benefits of using a formal modeling notation. Automated model checks can be
described in a declarative fashion as rules (e.g., for all entities of the type
“Activity”, the attribute “description” must not be empty) or as arbitrary programs
that navigate the model elements checking for particular conditions.

In many cases, however, automation is not possible, either because the

information is not formal enough (e.g., it is available only as natural language
text) or because checking for a particular property may be beyond the ability of a
computer algorithm (in certain cases, making sure that a model does not contain
deadlocks is equivalent to solving the halting problem for a non-trivial computer
program). For these cases, manual model reviews must be conducted, possibly
using disciplined inspection techniques similar to those intended for inspecting
software programs.

Case study 1: DocVault

Since DocVault's model ended up being relatively small, most checks were
conducted by manually inspecting the model. However, the process engineering
team also created a simple syntax checker to make sure that a set of minimal
syntactic requirements was fulfilled by the text-based specifications.

Case Study 2: Selene

At the end of the initial modeling effort, Selene's model contained almost 1000
separate entities, and several thousand relations. It was absolutely necessary to
check this model for potential errors. Most checks were achieved automatically by
writing simple programs that checked the structural properties of the model by
consulting the model database and looking for potentially problematic elements or
constructs.

Case study 3: Soster

For checking, Soster relied mainly on the built-in capabilities of the graphical
model editor they were using. The editor allowed for defining a set of basic
 151

correctness and consistency rules, and Soster used those to detect basic problems
in the model.

3.4.9 Step 8: Analyze the process

The final step of descriptive process modeling is perform a process analysis, i.e.,
to use the process model to track or analyze process performance, depending on
the process modeling objectives stated in step 1. One possibility is to track the
process by asking process performers to log, for example, the start and finish
times for their activities. Another option is to make “snapshots” by asking people
about their current activities at regular intervals. The resulting data can be used for
qualitative or for quantitative analyses.

Qualitative analyses aim at identifying weaknesses of the processes, e.g., when too
many responsibilities are pinned to a single role, or when too many roles are
assigned to a single person, or when feedback loops become so excessive that they
consume more time than productive project work.

Quantitative analyses aim at identifying correlations between process attributes,

e.g., when the number of requirements is more than 30% higher than average, the
number of defects rises by 70%.

Both kinds of analysis results can then be used to modify the process (in order to
remove the weaknesses), or the process model (in case it does not fit the process
after all), or to influence project planning (e.g., allocate more resources to
requirements reviews when the number of requirements is more than 30% higher
than average).

Case study 1: DocVault

Although the defect management process at DocVault had been handled manually
for the most part, it actually left traces in a number of data repositories. First, a
good portion of the communication and software defects happening between
customers, QA people, and developers were reported via email, and those
messages were archived. And, second, changes made to the software because of
 152

defects found were always registered in the version management system, together
with a log entry explaining the reason for the change.

The process group then proceeded to isolate a number of defect-fixing cases, and
to identify email messages and entries in the version management system that
were relevant to each case. By looking at this data, the process engineers were
able to create detailed profiles for these cases, identifying the people involved, the
activities that were conducted, and the time for each event.

With these profiles at hand, the process group then proceeded to check their
models. The basic question was to determine whether the process model could be
instantiated for each one of the particular cases, and how difficult this would be.
Together with the primary users (developers of the defect management system)
and the secondary users of the model (developers of the defect management
system and DocVault's clients, as well as the software developers and quality
management team at DocVault), they decided that the model adequately describes
the process, and proceeded with the implementation of the automated defect
management system.

Case Study 2: Selene

Since Selene’s primary objective was to provide guidance for all roles in the
organization with respect to its processes, the process itself was of secondary
interest. However, Selene instructed all performers to watch for potential problems
or inconsistencies and to report them actively. An issue report system was set up
to collect these reports, and the SEPG conducted regular meetings to evaluate the
reports and follow up as necessary.

Case study 3: Soster

Since Soster’s goal was to gather information for improvement, a detailed process
analysis was conducted. A number of influence factors for product quality and
project predictability was identified, including the frequency of requirements
changes and the time available for reviews (quantitative data); as well as role
assignments, people overloading, and tool availability (qualitative data). From the
data gathered, Soster’s SEPG developed a strategic improvement plan, covering 3-
month Quick Wins and long-term goals to be realized within three years.
 153

3.5 Descriptive process modeling alternatives

This section presents two alternatives to the approach described in section 3.4. The
Multi-View modeling method [3] replaces steps 5 and 6 with an approach that
collects and integrates multiple views on the same process, and the Elicit method
[4] completely replaces the 8-step approach with a perspective-based tactic.

3.5.1 Multi-view process modeling

Multi-view process modeling [3] provides a specific way to conduct the elicitation
step and build a model based on it (steps 5 and 6 described in sections 3.4.6 and
3.4.7). The main assumption behind multi-view process modeling is that, given
the complexity of actual software processes, no single process participant has a
complete, unified, and sufficiently detailed view of the process. Quite on the
contrary, participants are normally experts in rather narrow areas of the process.
For this reason, multi-view modeling starts by modeling the process as understood
by individual participants. This results in separate, role-specific process views that
contain potentially detailed but partial process information. In a later step, the
individual views are systematically integrated to form a single, complete process
model. This procedure is illustrated in Fig. 3.2.
 154

Implicit Real-World
Process
A D
B
C

View View View View

A B C D

View Integration
Comprehensive
Process Model

Fig. 3.2: Multi-view process modeling overview

The integration of role-specific views is an iterative process comprising four steps:

1. Modeling. In the modeling step, role-specific views are created by

independently interviewing participants. The resulting views are partial process
models that contain all activities performed by a role, together with related process
entities such as work products or other roles with which the analyzed role
interacts. Role-specific views are expected to be internally consistent, but they are
not guaranteed to be consistent with each other.

2. Similarity analysis. In this step, the various role-specific views are analyzed to
identify common objects, such as shared activities or work products. Notice that,
due to the fact that each view comes from a different person or group of persons,
there may be inconsistencies in naming and other modeling aspects. For this
reason, a combination of manual and automated techniques is used to find
matching entities.
 155

3. Inter-view consistency checking. Once matching elements have been identified,

a number of consistency checks are performed between interrelated views in order
to detect potential inconsistencies between them. Whenever inconsistencies are
found, they are resolved by changing the views as necessary.

4. Integration. At this point, the separate views are consistent enough to be

merged into a single, integrated process model.

As originally proposed, the Multi-View Modeling method is based on the MVP-L

process language. In practice, however, most of it is independent of a specific
modeling language and can be applied in a quite general way.

Steps 2 and 3 of Multi-View Modeling can be particularly challenging. In the case

of similarity analysis (Step 2), as already noted above, matching entities in
different views can be named differently and will certainly be described using
different words. In order to deal with such inconsistencies, it is possible, for
example, to search for names that are similar (although not identical) or to use
advanced text analysis techniques to identify pairs of descriptions that speak (with
different words) about the same entity. Also, similarities in the structure of a
product flow can be used to suggest possible matching areas. It is important to
note that all of these techniques are potentially imprecise and susceptible to
reporting non-matching entities as matching (false positives) and to missing actual
pairs of matching entities (false negatives). For this reason, all results obtained
automatically must be verified manually.

Regarding inter-view consistency (Step 3), a number of consistency rules can be

applied once matching entities have been found. For example, matching entities in
all views must have the same name, whereas entities that do not match any other
entity should have a unique name. Depending on the set of modeling concepts
used, more advanced rules can be devised.

3.5.2 Elicit

Elicit [4] is a general framework for process elicitation. Its main difference to the
general, 8-step approach presented in this chapter is that it does not expect the
 156

organization to select a schema, a modeling language, or a set of modeling tools.

Elicit provides all of these elements, together with a set of methodological steps
for using them, thus making its application somewhat simpler.

Elicit works by looking at the process from a variety of viewpoints, which are
later consolidated into an unified view. The Elicit schema is structured as a set of
five so-called perspectives, together with three types of properties that must be
described for each perspective. The Elicit perspectives are artifacts, process steps,
roles, resources, and constraints, and the property types are descriptive, static, and
dynamic. The combination of a perspective and a property is called a view in
Elicit. This means that there are 15 possible views (5 perspectives times 3 property
types). For each of these views, Elicit provides a set of so-called attributes. For
example, the descriptive view of the artifacts perspective contains the following
attributes:
Identifier

Has purposes

Stored in formats

Is of artifact type

Characterized by artifact description

 157

Fig. 3.3: The steps of the Elicit method

 158

Models are created by providing values for these and similar attributes in all
views.

As already mentioned above, Elicit provides a set of steps for producing

descriptive models. These steps are illustrated in Fig. 3.3 (adapted from [4]) and
can be summarized as follows:

1. Understand organizational environment. This step consists of understanding

key aspects of the organization, such as its size, management structure,
number and size of the running projects, common roles played by people in
projects, etc. Understanding these issues is considered fundamental for
process engineers to be able to do their job in later steps.

2. Define objectives. This includes defining the exact scope of the model—e.g.,
its granularity and the degree of consistency, completeness, accuracy, and
clarity that must be achieved—and setting goals for the modeling effort
itself, such as its targeted costs and time frame.

3. Plan the elicitation strategy. Given the set of goals produced in the previous
step, it must be defined how to achieve these goals. A key aspect of this step
is to allocate appropriate resources for the modeling effort. For example, it
must be decided which people will be interviewed, when reviews are going
to be conducted, etc.

4. Develop process models. This step involves collecting information according

to the Elicit process schema, as explained above. The collected information
is then used to create models using process modeling tools, and submitted for
review. If reviews find deficiencies in the model, further information
collection and modeling must be performed.

5. Validate process models. The main objective of this step is to have the models
validated by their intended recipients. This includes checking that the models
represent the actual process in an appropriate way, and, generally, validating
the models against the modeling objectives stated originally.

In addition to these five steps, which are concerned with modeling itself, the Elicit
method contains some steps that are intended to learn from the overall process
 159

modeling effort and package this experience for the benefit of future modeling
efforts. These steps are represented by the feedback arrows (pointing upwards) in
Fig. 3.3.

Originally, the Elicit method proposed the use of two modeling tools, namely a
specialized Elicit modeling tool and the simulation tool Statemate. Although the
Elicit tool is not available commercially, the method can be supported with
generic modeling tools.

3.6 Guidelines for process elicitation interviews

Interviews are a central component of process elicitation. Thus, this section

provides some basic guidelines regarding how to conduct elicitation interviews in
a software organization.

3.6.1 Interview preparation

Before conducting a set of elicitation interviews in an organization, a number of

preparation steps should be taken:
Get to know the organization. As a minimum, interviewers should have basic
knowledge about the organizational structure, the roles played by their
interviewees in that structure, and the software domain in which the
organization works. It is also advisable to begin the interviews with quality
assurance people or with project managers, since they will be able to provide
a better overall view of the organization.

Find out if the organization is being restructured or was restructured recently.

Large changes in the organization's structure normally have an impact on the
software process and on people's roles. If restructuring is recent or is in
progress, the interviewer must find out in advance which version of the
process he is being told about.
 160

Take a look at existing documents and other work products. This not only
helps the interviewer to acquire a general idea of how the process is executed,
but it makes it easier to speak with interviewees about their usual tasks.

Before conducting interviews, it is important to make sure that the interviewees

were selected according to the requirements of the elicitation effort. It is to be
expected that the people who are most knowledgeable about a process are also
most likely to be busy. For this reason, there is always the risk that interviewers
will be “diverted” to less critical, but also less knowledgeable people. It is
important to make sure that your interviewees are knowledgeable and experienced
enough to provide you with the necessary information. Otherwise, insist on
interviewing the right person.

3.6.2 Beginning the interview

The first minutes of an interview are crucial, because during this time, a proper
relationship with the interviewee must be established. In particular, it is important
to create an environment of confidence and teamwork. The interviewee must
understand that s/he is not being evaluated and that the purpose of the interview is
to achieve a better understanding of the actual process. In order to create this
positive environment, it is advisable to:
Make sure that the interviewee has proper knowledge regrding the overall
elicitation process, i.e., how it is being conducted, who is taking part, and
what its general objectives are.

Explain the goals and purposes of the interview. Let the interviewee know
why s/he is being interviewed and why her/his knowledge is important for the
overall elicitation effort.

If necessary, make a confidentiality agreement with the interviewee. Explain

clearly how the information acquired during the interview is going to be
handled in terms of privacy and security (if relevant). In some cases, it may be
appropriate to present interview results anonymously. If this is your intention,
make sure that you mention it.
 161

Formulate some general questions about the interviewee and her/his role in
the process. In particular, try to confirm any knowledge you may have
previously acquired about the interviewee and his/her job.

3.6.3 The main interview

After the introduction, you can concentrate on its actual purpose: eliciting process
information. Some general guidelines are:
Behave neutrally. It is fundamental that the interviewer avoids being
judgmental about the process. Any remark in this direction may destroy the
confidence created with the interviewee and cause the interview to fail.
Remember that you are there for understanding the process, not for criticizing
it. Also, take into account that aspects of the process that, at first sight, may
appear outlandish or even nonsensical may be supported by very good
justifications that you do not yet understand.

Ask first about products. As already explained, products are sometimes easier
to identify for software engineers, so it may be wise to start by asking people
which work products they usually work on and in which exact ways they are
involved with their creation. When asking about products, take into account
that different organizations may use widely different words to refer to process
work products. Document, system, program, module, and report, to mention
but a few, are terms that may be used to refer to work products in practice.

Ask about processes. After a clear view of the documents has been created,
you can move to ask about the processes related to producing these products.
Some of the relevant questions are: Which inputs are necessary? Which other
roles participate in the processes? Which conditions must be met in order to
start creating the product? When is the product considered finished? Who
reviews the product and how?

Look for typical deviations. If the interviewee has not spoken of deviations
already, make sure to ask about them. What are typical problems that happen
during this process? How are they normally handled?
 162

Try to identify variants. Processes are often subject to variation depending on

factors such as the availability of certain resources (e.g., “if the project budget
allows for a separate test team, we do X, otherwise we do Y”), the presence of
specific product requirements (e.g., “if the product is intended for the
international market, we conduct an additional internationalization review...”),
or particular customer characteristics (“when the customer is a government
institution, we have to produce an additional accounting report as required by
current law...”).

When conducting the interview, always try to make sure that you are getting a
consistent picture of the process. In particular, make sure that you ask questions
even in those cases when you only see small ambiguities: It often happens that
major deficiencies in understanding are hidden behind an apparently minor issue.

3.6.4 Interview closure

The final part of the interview should help to involve the interviewee in the whole
elicitation effort. Before you finish the interview:
Speak about future steps. Explain to the interviewee which steps will follow.
In particular, make clear how the information obtained in the interview will
be used during the remainder of the elicitation process. If the interviewee is
expected to actively participate in further steps of the elicitation effort such as
a review, this may be a good time to clarify the schedule.

Thank your interview partner. Make sure that you stress the importance of the
interviewee's contribution to the overall elicitation process, and thank her/him
for that.

When further steps of the elicitation process are completed, it is advisable to

inform all participants of the progress and to let them know how their individual
contributions are shaping up into a detailed picture of the software process. In
particular, interview results can be written down, summarized, and presented to
the interviewees for revision.
 163

3.7 Managing risk in descriptive process modeling efforts

Modeling a process is a potentially highly complex task, which involves

dedicating a significant amount of work and time to it. It is hence not surprising
that many risks are involved in a process modeling effort. In order for such an
effort to be successful, these risks must be taken into account and mitigated
whenever possible. This section explains the most common risks and possible
countermeasures.

Although it is impossible to predict every possible problem that may arise during a
process modeling effort, experience collected over the years allows us to
enumerate some issues that are likely to be present. The remainder of this section
discusses these issues as well as potential countermeasures.

3.7.1 Resistance of participants

A disciplined, detailed process modeling effort can easily awaken resistance in an

organization. Considering how the modeling effort may be seen by process
participants, the reasons for this become obvious:
Participants may see the process experts as the people who are placing their
daily work “under the microscope”. They fear that, as soon as their work
practices are made explicit, they will be judged for any deficiencies or
limitations of the process that may become visible through process analysis.
In a similar vein, participants may see the renewed interest in their daily work
activities solely as a way to control them.

Participants may perceive a defined process as a way to constrain them. They

may fear that, once a defined process is in place, they will have no freedom to
change and adjust the way they work according to their needs.

Participants may generally perceive processes as bureaucratic. They may

expect explicitly defined processes to introduce significant additional
administrative overhead that will divert them from the technical and
managerial tasks they are pursuing.
 164

Finally, participants may simply not see any added value in the process
modeling effort, and may thus be reluctant to put time or work into it.

In order to mitigate the risk of a process modeling effort failing because of

resistance—or even active sabotaging—from process participants, it is important
that the processes and their definition are “owned” by the participants themselves.
Acquiring deeper knowledge about the process should never be seen as a means of
control, but rather as a way to improve project execution and product quality, with
obvious benefits for everyone involved.

Some ways to put the process modeling effort “into the hands” of the process
participants are:
Promote the benefits of proper process management. Better process
management can significantly contribute to improving a participant's work
life. For example, better project planning can reduce or eliminate the need for
working long hours, and better product quality can reduce the stress
associated with unexpected product failures. Before a process modeling effort
starts, process participants should know the potential benefits and properly
understand how process modeling can contribute to achieving them.

Whenever possible, involve process participants in the definition of the goals

for the modeling effort. A process modeling effort (and, in general, a process
improvement effort) that is only intended to benefit an organization's
management is much more likely to meet resistance from the people at lower
organizational levels, since they do not see any direct, personal benefits.
When participants are involved from the bottom up in the definition of goals
for the effort, they can pursue their own goals while contributing to the effort,
making it much more likely to succeed.

Actively involve process participants in all process modeling activities. Apart

from goal definition, interested participants can be engaged in various
activities, ranging from detailed elicitation to high-level process description
and review. This is not only likely to turn these engaged participants into
“process proponents”, but will help guarantee that the resulting process
represents the views and goals of all stakeholders.
 165

Make the modeling effort as open as possible. Make sure that the results of
the modeling effort are visible and that participants have a voice if they
disagree. For example, it is advisable to provide an official mechanism for
reporting problems with the process definition and to make sure that such
reports are promptly reviewed and answered, too, either by correcting the
process definition or by providing an explanation of why changes will not be
made.

By taking these and similar measures, it is possible to achieve much higher

commitment by the process participants, consequently increasing the chances that
the process modeling effort will be successful.

3.7.2 Inaccurate reporting

When participants are interviewed about the way they work, there is a significant
risk that their description of their own activities will not fit reality to a certain
extent. Reasons for why this may happen include self-protection, forgetting
process details, and idealization of the process.

As explained in the previous subsection, people may fear that a process modeling
effort will immediately expose them to judgment and criticism. For this reason,
and in order to protect themselves, they may try to “embellish” the process in
ways that they expect to be more satisfactory to external observers than “the naked
truth” about how things are done. As also explained in the previous section, active
involvement of the process participants in the modeling effort is probably the best
way to minimize this problem.

A related problem may arise when process participants are discontent with their
organization or management. In this case, they may tend to present the process
worse than it really is, in order to stress the problems they are currently going
through. Although such an attitude is a clear signal of potential process-related
problems and should not be dismissed, there may still be strengths to the actual
process that are being unnecessarily downplayed by disgruntled process
participants.
 166

Even when participants have a positive attitude towards their organization and the
modeling effort, they may end up reporting incomplete or outright false
information about a process. This may be caused by people forgetting details,
which should not be surprising given the high complexity and variability of many
software-related processes. Also, people who are fond of a particular procedure
may tend to idealize it, and to present it as being simpler and more straightforward
than it really is.

The usual way to deal with problems of this type is to gather information
redundantly from various sources whenever possible in order to spot possible
inconsistencies caused by missing or (either deliberately or inadvertently) false
information. Redundancy can be achieved, for instance, by interviewing many
participants who play the same role, or by comparing the process described by
people with the actual work products that resulted from past instances of the
process.

3.7.3 Underestimating necessary investments

Descriptive process models involve potentially large investments. First of all, it

should be clear from the modeling steps discussed in section 3.5 that modeling the
whole set of software development processes in an organization represents a
significant amount of work. In particular, the elicitation step requires the
involvement of a possibly large number of people in the organization. In order for
the process modeling effort to be successful, these people must dedicate
considerable time to interviews, reviews, and other process-related activities.

Additionally, it often happens that the improved understanding of the process

brought on by process modeling triggers changes to a process, sometimes in an
immediate fashion. Although these changes are likely to eventually bring
improvements, in the short term they may involve increased operation costs, for
example due to a temporary reduction in productivity.

Underestimating these costs is, of course, a serious risk for a process modeling
effort. An effort can easily fail if the organization's management is not conscious
 167

of its potential costs. Proper planning is, thus, necessary to properly estimate these
costs from the ground up and guarantee appropriate commitment of the
organization's management.

3.7.4 Underestimating process model complexity

When planning a process modeling effort, it is easy to underestimate the

complexity of the final model. Process model complexity is mainly related to the
number of entities and entity relations in it, and less so to the number of concepts
in the selected process schema. Since estimating the number of entities in a model
before creating it is difficult, the risk of underestimation during planning can be
high.

For this reason, descriptive process models should not overemphasize accuracy,
but rather concentrate on achieving a level of detail that is adequate for the stated
modeling goals. Also, organizations that lack process modeling experience should
start with pilot modeling efforts that are restricted to relatively small and well
delimited processes. The experience obtained from such pilot efforts should help
to estimate the potential model size (and involved modeling effort) for larger and
more complex processes.

3.8 References

[1] Becker U, Hamann D, Verlage M (1997) Descriptive Modeling of Software

Processes, ISERN Report 97-10, Fraunhofer Institute for Experimental Software
Engineering IESE, Kaiserslautern, Germany
[2] Bröckers A, Differding C, Threin G (1996) The Role of Software Process Modeling
in Planning Industrial Measurement Programs. In: Proceedings of the Third
International Software Metrics Symposium, Berlin, March 1996
[3] Verlage M (1994) Multi-view modeling of software processes. Lecture Notes in
Computer Science 772(1994):123-126
[4] Madhavji NH, Holtje D, Hong W, Bruckhaus T (1994) Elicit: A Method for
Eliciting Process Models. In: Proceedings of the Third International Conference on
the Software Process (ICSP 3), Reston, VA, USA

View publication stats