Supporting Software Processes Using Knowledge Management

Abstract

In this paper, we describe how software processes can be supported using knowledge management, concentrating on the creative manual tasks performed bydevelopers. The main support needed by developers is the availability of the knowledge about the development processes relevant to their task. As a result, software process modeling can be considered as a knowledge management task.
The paper provides an overview of the knowledge needed by developers. It then reviews various approaches to knowledge representation including artificial intelligence, structured plain text, and software process modeling approaches, to identify representation schemes suitable for software processes. Finally, the paper looks at the management aspects of software process knowledge.

Full text

Handbook of Software Engineering and Knowledge Engineering
Vol. 2
f
c World Scientic Publishing Company
SUPPORTING SOFTWARE PROCESSES
USING KNOWLEDGE MANAGEMENT
RALF KNEUPER
Transport-, Informatik- und Logistik-Consulting (TLC) GmbH
Kleyerstrasse 27, 60326 Frankfurt/M, Germany
Email: ralf.kneuper@gmx.de
URL: http://www.kneuper.de
In this paper we describe how software processes can be supported using knowledge
management, concentrating on the creativemanual tasks performed bydevelopers. The
main support needed bydevelopers is the availability of the knowledge about the devel-
opment processes relevant to their task. As a result, software process modeling can b e
considered as a knowledge managementtask.
The paper provides an overview of the knowledge needed by developers. It then
reviews various approaches to knowledge representation including articial intelligence,
structured plain text, and software process modeling approaches, to identify representa-
tion schemes suitable for software processes. Finally, the paper looks at the management
aspects of software process knowledge.
Keywords
: Software process; Software process modeling; Knowledge management;
Knowledge representation;
XML
1. Introduction
1.1.
Software Processes
Software processes are all the processes that are used to create software, in-
cluding analysis, programming, conguration management, etc. Based on [49], we
distinguish various kinds of software processes, see Fig. 1.
Software processes can be explicitly dened, or implicit pro cesses that are used
without thinking much about the process as such.
Reasons for dening (modeling) software processes are [24, p. 5][53]:

dened processes put structure into software development

good software processes support developers in their work. Using the software
process, developers knowwhich step to take next, and they have templates for
the results to be produced. As a result, they can concentrate their creativity
on solving technical problems, rather than re-inventing the wheel, and solving
problems that are caused by unclear cooperation with their colleagues.

they form a basis for improvement and learning, including process monitoring
and pro cess simulation as well as process validation and verication.
1

2
Handbook of Software Engineering and Knowledge Engineering
Software processes
Product engineering
processes
Process engineering
processes
technical managerial Improvement processes
Req. engineering
Design
Coding
Verification
Product mgmt.
Project mgmt.
Quality assurance
Project data mgmt.
Integration
Validation
Modeling and planning
processes
Measurement processes
Reuse processes
Fig. 1.
Software processes (based on [49])

they makedevelopment more predictable. This is particularly importantfrom
the management perspective, since it helps to estimate correctly the time and
cost needed for developing a system, and the resulting product quality.

computer-supported software processes additionally allow pro cess enforce-
ment, automation, and guidance.
Examples of dened software process models are the (Rational) Unied Process
(RUP, see [38]) or the German V-Model (see [56, 52]), which both dene fairly
complete software process models including the various phases as well as supporting
activities such as project management and quality assurance. On a rather coarse-
grained level, there are various process models (also called phase models or life-cycle
models) such as the waterfall model [51] or the spiral mo del [13] (see [15] for an
overview of the dierent life-cycle models).
These models dene the top level of a process model hierarchy (see Fig. 2). An
organization typically does not use such a standard process model \as-is", but tailors
it to its own special needs, assigning roles to departments, adding information about
tools to be used for some process steps, adding specic or leaving out irrelevant
steps. From this organizational process model an individual pro ject then derives
its project plan, again leaving out irrelevant steps (e.g. all steps that concern the
creation of a database if the application does not include a database) and adding
(project-) specic steps (e.g. create some artifact only required by this customer),
and also iterating steps as appropriate (e.g. repeating the step \describ e dialogue"
four times since there are four dialogues in the application). Finally, of course, a
project plan must include information about eort planned for the individual tasks,

Supporting SoftwareProcesses Using Knowledge Management
3
milestones, etc.
This does not imply that all three levels must always be present. Many or-
ganizations dene their pro cess model directly, without recourse to any standard
model. Occasionally, a project plan is derived directly from some standard model,
for example because the customer demands the use of this model. Many project
plans are not based on any process model at all | this is quite common but falls
outside the scope of this paper. And (last and least) some pro jects are run without
any pro ject plan at all.
organisational
tailoring
project-specific
tailoring
Standard
process
model
Process
plan
Organizational
process
model
Fig. 2.
Process model hierarchy
Current issues in software processes research are (cf. [24, Sec. 1.8])
process formalisms and process mo deling languages
focused on creating no-
tations to describ e software processes, usually to b e \read" byvarious tools
used for

analysis, such as consistency checking (\Is every artifact that is used
by an activity created by an earlier activity?" \Is every dened role
assigned at least one task?") or for improvement\Whichof these two
ways of achieving a certain result is more ecient?")

process supp ort, such as tailoring a general process to a specic project,
or pro cess workowsupport
process-centred environments,
called
process-sensitive software engineering en-
vironment
(PSEE) by [24], go one step further, integrating the various devel-
opmenttoolsinto one environment under the control of some form of process
engine. E.g. if a developer is assigned the task to create an entity/relationship
model and starts this task, the appropriate editor for entity/relationship mo d-
els is started up automatically.
software pro cess improvement (SPI)
is concerned with ways to dene con-
crete process models for an organization, to introduce them into the day-
to-daywork of the organization (whichtendstobemuch more dicult than
creating the model in the rst place), and nally to continuously improveand
adapt these models.
In contrast to the previous two items, SPI has little technical contents but fo-
cuses on soft factors such as management, organizational change, psychology,
etc.

4
Handbook of Software Engineering and Knowledge Engineering
Probably the best known approach to SPI is the Capability MaturityModel
(CMM) [18, 52, 53] (
http://www.sei.cmu.edu/cmm/cmm.html
), which de-
nes ve maturitylevels and thus provides an improvement path for organi-
zations developing software. SPICE [50] is based on similar ideas and working
on an ISO standard 15504 [35] for assessing the maturity of software develop-
ing organizations.
An approach specically targeted at introducing CMM is IDEAL (Initiating,
Diagnosing, Establishing, Acting, Leveraging) [41].
Other approaches to SPI include Basili's Experience Factory and the Quality
ImprovementParadigm [7, 8, 9] as well as approaches from quality manage-
ment in general, not specic to software, such as ISO 9000 (with its software-
specic interpretation, ISO 9000-3), Kaizen, and Total Quality Management.
denition of software process,
nally, is concerned with creating concrete soft-
ware process models, either as a general standard, such as the German V-
Modell, as a de-facto standard such as the (Rational) Unied Process, or as
an internal, company-specic process model (see e.g. [6, 43]). ISO 12207 [34]
provides a lot of input on the contents of such a process model.
A good overview of the topic of software processes and the research questions
involved, covering mainly process formalisms, process modeling languages, and
process-centred environments, is given by [24] and [49], the current state of the
art can be found in the pro ceedings of the European Workshop on Software Pro cess
Technology series (EWSPT, e.g. [27, 21]) and the International Conference on the
Software Process series (ICSP).
More information on SPI can e.g. be found in [49], or, with a strong CMM bias,
on the SEI web pages (
http://www.sei.cmu.edu
), or the proceedings of the annual
SEPG (Software Engineering Process Group) and European SEPG conferences.
Another way to view software processes is that they are a form of knowledge.
Managing software processes is a special case of knowledge management. The cur-
rent paper follows this view to identify what can be learned from knowledge mana-
gement for the support of software pro cesses.
The remainder of this introduction will analyze how much support software
process technology can give (see Sec. 1.2), and then dene the basic concepts of
knowledge
(see Sec. 1.3) and
knowledge management
(see Sec. 1.4).
After that, in Sec. 2, we discuss the knowledge that is needed in the sp ecial case of
software processes. Sec. 3 describes some approaches to knowledge representation
and looks at their suitability for the kind of knowledge considered here. Since
dealing with software pro cess knowledge is a managementtaskeven more than a
technical problem, Sec. 4 looks at the management aspects of process knowledge
and their implications on software process technology. Finally, in Sec. 5, wedraw
some conclusions.

Supporting SoftwareProcesses Using Know ledge Management
5
1.2.
Technology to support software processes
Software development consists of a number of dierent kinds of tasks including

creative tasks,

administrative tasks, and

communication tasks.
A common feature of these tasks is that they require a fairly large amount of
knowledge.
Software process technology should therefore emphasize support for human de-
velopers in their task.
The obvious question nowis what software process supp ort human develop-
ers need for software development. The suggestion of this paper is that the main
support needed is to provide
knowledge
to the developers, e.g. in the form of de-
scriptions of tasks and artifacts (results) (cf. Sec. 2.2), or, more advanced, in the
form of advice and guidance. Phrased dierently, software process support should
be considered as a
knowledge management
task [23].
Knowledge
management
is quite a dierent concept from knowledge
representa-
tion
as a topic of Articial Intelligence, even though there is some overlap. Knowl-
edge management is a management task mainly dealing with humans, while knowl-
edge representation is concerned with formal representation of knowledge typically
used for certain algorithms (such as reasoning and planning).
This is very dierent from the current paradigm in software process technology
which concentrates on the attempt to automate software pro cesses [49], as suggested
in particular by Osterweil [46]. The basic assumption b ehind this approach is, obvi-
ously, that software developmentcontains large tasks that are suciently simple to
be formalized, or, put dierently, it restricts attentiontosuch tasks (compare [57]).
This emphasis on automation and formalization results in a number of requirements
that are important for the industrial use of software process support but are not
satised by many software process support tools (see [36]).
The dierence between the two paradigms (software process support as automa-
tion of software processes or as support for human knowledge workers) is not just of
academic or scientic interest but has practical implications since software process
models, like all models, are a form of reality construction. They are not neutral
descriptions but have a purpose or bias. As a result, they help to create a mental
model of software processes, be it as creative, mental processes or as a mechaniz-
able, menial task. Suchamental mo del (or paradigm, see [39, Postscript Chap. 4])
inuences the waywe see the world and interpret the external stimuli. This is one of
the reasons why it is importanttohave a paradigm that leads in a useful direction.
Conradi et. al. in [20] argue similarly that automation in this context is of limited
value. About software process research, they say:
\Quite often, wewanttoprovide automatic support to activities that
simply do not need to be supported `that far'. For instance, while it is

6
Handbook of Software Engineering and Knowledge Engineering
certainly useful to clearly describe the steps in a design method, it is
purposeless to formally model it to support its detailed enactment (e.g.,
by indicating which steps in the method have to be carried out and in
which order). Developers will never accept a tool that operates at that
level of detail. Moreover, it would be useless. You can use a design
method eectively only if you `know' it so deeply that it is part of your
mental habit, and not just because `someone else' mandates what you
are supposed to do at any time." [20, pp. 102f]
Quality management approaches such as CMM and ISO 9000 also movetowards
putting more structure into the software development process. However, this is not
to be confused with automation of the processes | these approaches are mainly
concerned with dening the manual processes, describing the steps to b e performed
(such as reviews) and the responsibility for these steps.
Coming back to the question of support of software processes using knowledge
management: necessary tasks in the use of software processes that could be sup-
ported byknowledge management are

dene pro cesses (knowledge elicitation and representation)

introduce pro cesses into the day-to-daywork of the developers | just dening
the processes and making the denition available is rarely enough

apply or live a process

improve and adapt the pro cesses since they will never be perfect, and the
environmentkeeps changing (new technology, better qualied developers, etc.)

tailor and instantiate the processes to turn them into a pro ject plan
Since the tasks in this list are processes that work on the software pro cesses, they
are also called meta-pro cesses. These meta-processes need to b e closely co ordinated
with the software processes themselves since the meta-process can lead to a change
of the process, possibly while the process is running (e.g. a pro cess improvement
that is introduced during the lifetime of a pro ject, see [48]).
1.3.
What is Knowledge?
Following Davenport and Prusak, we distinguish the concepts of data, informa-
tion and knowledge. The following denitions are based on [23, pp. 2{6]:
Data
are a set of discrete, ob jective facts. A typical example of data in soft-
ware pro cess modeling is \an entity-relationship diagram consists of boxes
representing entities and lines between the boxes, representing relationships
between entities".
Information
is data that `makes a dierence' to the receiver. Put dierently, in-
formation is data with added value, e.g. by putting it into context, by mathe-
matical or statistical analysis, or by summarizing it in a more concise form. In

Supporting SoftwareProcesses Using Know ledge Management
7
software process modeling, examples for information are \developing a soft-
ware system consists of the following tasks .... In task
X
1
, the artifact
Y
is
produced and used as input for task
X
2
".
Knowledge
\is a uid mix of framed experience, values, contextual information,
and expert insight that provides a framework for evaluating and incorporat-
ing new experiences and information" [23, p. 5]. Knowledge can be considered
as information with added value, suchas the relationship between dierent
pieces of information, or the implications of that information on decisions and
actions. Examples of knowledge in software process modeling are \Step
A
is
not needed for Java applications developed for customer
C
." \If you have
experienced developers, it is better to do step
A
before step
B
, while inexpe-
rienced developers havetodo it the other way round." \Artifact
Y
is very
important for complex applications but superuous for simple applications."
Part of the diculty of applying suchknowledge is that it depends on judge-
ments about the current situation (Is developer
D
experienced? The answer
to this question depends both on the developer and the tasks at hand | a
developer may be an experienced Cob ol programmer but know nothing about
Java.)
Other authors, especially in the AI community, e.g. [26], dene the term \knowl-
edge" much wider, including what we called information. This leads to dierent
answers to the question whether in software pro cess modeling, we are dealing with
knowledge
or whether it really is
information
(or even data). According to the def-
inition used here, a software process model itself does not contain knowledge but
(at best) information. The challenge now is to present the model in suchaform
that the users (developers) are able to turn this information into knowledge |
they have to \understand" the model. This implies providing sucient information
about context and implications, but also representing the model in a waysuchthat
it is easy to understand.
The same statement actually applies to any form of knowledge representation,
whether in the form of a knowledge base, text book, process model, or other. The
very act of representing knowledge turns it into data or information. Providing
more such information about context and implications does not necessarily help
to make this transition to knowledge; on the contrary,too much information can
lead to information overload and the information turns into data since users can no
longer cope with it.
1.4.
Knowledge Management
Knowledge management is the management discipline that is concerned with
creating, preserving and applying the knowledge that is available within an orga-
nization. Typically, this is done using techniques such as training, process mod-
eling, experience (data) bases, and networking of experts. For a very practi-
cal, hands-on report on applying knowledge managementata software house see

8
Handbook of Software Engineering and Knowledge Engineering
e.g. [17]. For a large collection of references on knowledge management see e.g.
http://www.bcs-sges.org/kmreport/bibliography.htm
.
As stated above, knowledge
management
is quite a dierent concept from knowl-
edge
representation
as a topic of Articial Intelligence, even though there is some
overlap. Knowledge management is a management task mainly dealing with hu-
mans, while knowledge representation is concerned with formal representation of
knowledge typically used for certain algorithms (such as reasoning and planning).
Hansen, Nohria and Tierney [28] distinguish two dierent approaches to knowl-
edge management based on the importance they put on formalization:
the codication strategy
puts the main emphasis on making tacit knowledge of
the organization explicit, e.g. in a process model.
the personalization strategy
concentrates on support for person-to-person know-
ledge transfer, leaving knowledge tacit but making it available bycommunica-
tion between people. Atypical technique here is to describe
who
knows ab out
a certain topic, rather than describing the topic itself in sucient detail for
someone else to read and apply it.
The main focus of the current article is on software process modeling and therefore
on the codication strategy. Depending on context and the task at hand, either
strategy can be useful.
However, it is importanttokeep in mind that knowledge essentially is human-
based. If people (such as developers) need knowledge to solve a problem, they
usually tend to ask their colleagues rather than search a database. The challenge
for software process technology is to make the tools suciently useful for developers
to prefer to use the tools rather than asking their colleagues.
For common tasks, this is a (within limits) achievable goal because it is more
ecient to describe a common task once and use the description many times after-
wards. For uncommon or very dicult tasks, this is not true and it makes more
sense to direct the developer to an expert in the eld under consideration. Therefore,
software pro cess models should not only provide information about the processes
themselves but also about the experts to ask when going beyond the limits of the
dened pro cess.
Probst [47] has dened a structure for knowledge management, called the \build-
ing blocks" of knowledge management, see Fig. 3.
In the special case of software pro cesses, these building blo cks essentially repeat,
in a more structured way, the process support tasks mentioned in Sec. 1.2 above.
We will look at them in more detail in Sec. 4.
2. Knowledge Needed
In this section, we describe the knowledge needed to support software processes
in more detail.
Before we can do so, we need to dene
who
needs the knowledge we are talking
about. First of all, this includes the developers themselves and their project leaders,

Supporting SoftwareProcesses Using Know ledge Management
9
Knowledge
Measurement
Knowledge
Use
Knowledge
Preservation
Knowledge
Distribution
Knowledge
Development
Knowledge
Acquisition
Knowledge
Identification
Knowledge
Goals
Feedback
Fig. 3.
Building blocks of knowledge management[47]
but also supporting personnel suchastechnical writers who write the user do cumen-
tation, quality assurance personnel, etc. Furthermore, for customer-specic software
(as opposed to o-the-shelf software) the customer of the software developed will
often require knowledge ab out the pro cesses used b efore signing a contract, and
during a project to be able to provide or sign-o input such as requirements or
domain knowledge. Similarly, management needs knowledge about the processes
used in order to judge and optimize their eectiveness.
The knowledge needed includes an overview of the processes used (Sec. 2.1,
descriptions of the tasks to be performed and the artifacts to be pro duced (Sec. 2.2),
the development method used (Sec. 2.3), knowledge about best practices and lessons
learned (Sec. 2.4), and other knowledge needed for software development (Sec. 2.5).
2.1.
Overview of Processes Used
First of all, everyone involved needs an overview of the software processes used.
This describes the type of life cycle used (waterfall, V-shaped, incremental, spiral,
...) as well as the phases in the life cycle together with their main goals, activities
and results.
While for some groups, such as the customer, this maybe all the knowledge
needed about the software process, most users will need the overview to identify
where their own piece of work ts in, which interfaces to other people or groups
they have in the development process, to set priorities in case of conict, etc.

10
Handbook of Software Engineering and Know ledge Engineering
2.2.
Description of Tasks and Artifacts
This is the core part of software process support and includes templates for
the various artifacts (such as a pro ject plan or an entity-relationship model) to be
developed as well as descriptions of the steps to be performed for a task, plus their
pre- and post-conditions, and checklists to ensure completeness of the tasks.
Pre- and Post-Conditions
Pre-conditions of a task are conditions that haveto
be satised at the beginning of the task, typically the previous existence of
a certain artifact or the previous performance of a certain other task. For
example, before programming of a component is started, the specication of
the component should be complete.
Post-conditions, on the other hand, are conditions that are guaranteed to be
satised at the end of a task, such as the existence of a certain artifact created
by the task. Another typical usage of pre- and post-conditions concerns the
status of an artifact. E.g. the pre-condition of a review typically requires the
existence of the result to be reviewed in status \draft" or similar. The post-
condition states that the contents of the artifact has not changed, but that
the artifact now has the status \accepted" or \rejected".
These dependencies between dierent tasks are one of the main diculties in
tailoring a process model to a specic context, since if one adds or deletes a
task, all pre- and post-conditions of other tasks still have to be satised.
Knowledge about pre- and post-conditions is used in planning a project (pre-
and p ost-conditions impose a partial order on the tasks to be p erformed,
or even imply that a certain task needs to be added in order to satisfy the
pre-condition of a later task) as well as in performing a given task, since the
post-condition succinctly describes what is to be achieved by the task (\create
artifact
X
"; \promote artifact
Y
from status `draft' to status `released')".
Finding a suitable sequence of tasks such that the pre-conditions of all tasks
are guaranteed to be satised by post-conditions of earlier tasks is a typical
example of a planning problem in AI [26, 30].
Description of Steps and Artifacts
The description of the steps to be p erfor-
med and the artifacts pro duced is the central part of software process support
for developers. This description typically includes the methods(s) used, any
sub-steps, and templates for the artifacts produced.
Usage of these descriptions of steps and artifacts can vary a lot between devel-
opers: let's say they have a certain task, such as the specication of a dialogue
with given functionality. Then depending on their experience, developers may
follow the process described step by step, or they just get the template for the
artifact needed and ll in the blanks. One of the problems in the latter case
is, of course, to ensure that the developer at least gets the currentversion of
the template and does not reuse an older one. A necessary, but not sucient,

Supporting SoftwareProcesses Using Know ledge Management
11
condition for this is to makeitvery easy to get the template from the standard
repository.
Other developers may just want to review the main steps to remind themselves
of the general process, e.g. because they have not performed this particular
task for some time, while yet others just need the details of one particular
step. Software process technology has to support all these dierent uses and
therefore present the relevantknowledge on dierent levels of detail.
2.3.
Development Method Used
For the development method used, essentially the same applies as for the tasks
and artifacts described above, since a development method can be described as
a collection of tasks and artifacts. The main dierence is the dierent level of
abstraction: a metho d tends to be more high-level (when to perform a certain
step?), while the description of a single task or artifact tends to contain a lot more
detail.
2.4.
Best Practices and Lessons Learned
Best practices and lessons learned involve knowledge about approaches, tech-
niques, etc. that haveproven useful in other contexts and might therefore be helpful
for the developer to know about, even though it has not (yet) been expressed as a
general process. Best practices can come from within the own organization or from
the outside, i.e. practices that are used in other companies.
Knowledge about best practices and lessons learned is typically presented in
the form of case studies, since it has not been or cannot be made fully explicit or
suciently general to be included in the dened software processes. See [44, p. 55f]
or [45] for some examples of knowledge bases containing lessons learned and best
practices.
[45] also describes a number of diculties with best-practice knowledge bases:

Where do you nd knowledge about best practices? This is often not publicly
available but has to be searched out.

Best practices are constantly changing. Even if you have well-documented,
useful best practices today, the same practices might be completely inadequate
tomorrow, due to technology changes or market changes (e.g. time-to-market
or qualitylevel of the product is no longer acceptable).

An active approach is needed; it is not sucient to just gather knowledge
about best practices, but best practices have to be created in the rst place.
All these diculties apply to all process mo del knowledge bases, not just to those
containing best practices.

12
Handbook of Software Engineering and Know ledge Engineering
2.5.
General Software Engineering Knowledge
The following knowledge is also needed for software development but not usu-
ally considered part of software process models. The main dierence between the
knowledge listed here and the knowledge contained in a software process model is
that the process model describ es or prescribes the steps performed and the results
created. The knowledge listed here helps the developers but does not state what
they havetodo.
[42, p. 292] list the following relevantsoftware engineering knowledge:

domain knowledge

requirements knowledge

design knowledge

implementation knowledge

programming knowledge

quality factors

design rationale (see the Chapter on Rationale Management by Dutoit and
Paech in this Handb o ok)

historical knowledge
Other knowledge needed includes

development and target environment, tools: this is an aspect that is quite im-
portant for developers, although it is not really part of the software process as
such. During their development tasks, developers need reference material on
issues such as the programming language and the compiler, the DBMS used,
middleware and operating system (for development and target environment),
etc. This reference material has to be integrated into the development en-
vironment so that for anydevelopment process step, the necessary reference
information is immediately available.

measurement data: in order to continually improve the software processes,
measurement data about properties such as software size and cost, productiv-
ity,number of defects found, etc., must be stored and made available.

developer skills

support information and typical problems

market data (mainly, but not only, needed for creating o-the-shelf software
products, as opp osed to customer-specic software).

Supporting SoftwareProcesses Using Know ledge Management
13
This kind of knowledge has to be handled byknowledge management [17] but will
not be considered in this context since it is not really part of the software process
itself.
2.6.
Administrative information
In addition to the knowledge listed above, some administrative information needs
to be stored with the process knowledge, suchasauthororowner of a pro cess, release
date, version, scope or area of applicability, etc. In this context, we will ignore such
administrative information.
3. Knowledge Representation for Software Pro cess Support
In the following wewillanalyze some approaches to knowledge representation
and their usability for the kind of knowledge described above. Based on an analysis
of the requirements on such a knowledge representation notation in Sec. 3.1, we
will look at AI approaches to knowledge representation (Sec. 3.2), software process
modeling notations (Sec. 3.3), business process modeling notations (Sec. 3.4), and
various forms of structured plain text (Sec. 3.5). In the summary (Sec. 3.6), a short
comparison between the dierent approaches is given.
One should note that strictly speaking, we are not really talking about
knowl-
edge
representation since, as described above, only people can haveknowledge, not
machines. If knowledge is represented in some form of knowledge repository, it
turns into data or, at best, information. To turn these data backinto knowledge
requires a human who is able to interpret the data and make sense of it. However,
following standard usage we will still talk about knowledge representation.
Many knowledge representation notations were created for use by automated
reasoning and inference engines and not really designed to support humans in their
work. Not surprisingly, they often turn out to be unsuitable for this task, partly
because they do not support free text, explaining e.g. the steps to be p erformed to
create a certain results.
3.1.
Requirements on Know ledge Representation
Finlay and Dix [26, Ch. 1.4] suggest the following characteristics to assess knowl-
edge representation schemes. Note that these criteria were originally intended for
judging knowledge representation notations in articial intelligence, to be used for
automated deduction and similar algorithms, and are therefore less well-suited for
judging notations for knowledge representation for human users. The denitions
have therefore been slightly adapted for our purposes.
expressiveness:
a representation notation must be able to representthevarious
types of knowledge we wish to represent, on the appropriate levels of granu-
larity.
The types of knowledge wewant to represent in order to support software pro-
cesses have been described in the previous section. One of the diculties lies

14
Handbook of Software Engineering and Know ledge Engineering
in the necessary combination of well-structured knowledge, such as \activity
A
takes artifact
X
1
as input and produces
X
2
as output", with ill-structured
knowledge such as \to create a class model, it is usually best to start by ...".
As a result, a notation that is used to representknowledge for human users
must allow ill-structured descriptions, i.e. free text.
eectiveness:
for structured knowledge, eectiveness implies that a representation
scheme must provide a means for inferring new knowledge from old. Since in
our case the emphasis is on making knowledge available to the human user
rather than an inference engine, eectiveness means that users can nd and
use the knowledge needed for their work. This implies that appropriate search
and selection mechanisms must be available, see below.
One waytomake a knowledge representation notation more eective is the
possibility to provide dierent views on the knowledge represented, e.g. for
dierent groups of users (developer, manager, customer, automated tool, etc.)
or for dierent kinds of projects (structured or ob ject-oriented development,
large or small project, high-risk or low-risk, etc.).
eciency:
in our case, eciency means that the user must be able to nd the
knowledge needed within a reasonably short time frame, and be able to nd
and use it with acceptable eort.
Generally speaking, any measures that make a representation more eective
by making it easier to nd and use the knowledge represented, also make the
representation more ecient. For example, good search and selection algo-
rithms or the possibilitytoprovide dierent views help to increase eciency
as well as eectiveness.
An exception to this rule would be a measure that reduced user eort and time
to nd and use the knowledge, but that increased computer eort and time so
much that the overall eort and time increased, e.g. due to particularly long
searches.
explicitness:
a representation scheme mustbeabletoprovide an explanation of
its inferences.
While for inferred (structured) knowledge this can be taken literally, ill-
structured knowledge is considered explicit if for any knowledge found, a more
detailed description of this knowledge is available. Put dierently, a represen-
tation notation is considered explicit if it allows dierentlevels of detail or
abstraction.
Example: a pro ject leader has found in the process mo del that in order to
create a project plan, he needs to analyze, among (many) other tasks, the risks
involved in the pro ject. The process model will now (upon request) showwhat
needs to be done for a risk analysis, covering technical risks, nancial risks,
etc. The project leader mightnow \drill down" to nd out more about typical
nancial risks and how to handle them.

Supporting SoftwareProcesses Using Know ledge Management
15
In [36], the author listed a number of requirements on software process technology,
some of which are relevant in the currentcontext as well. These are requirements
that have a focus on the industrial use of a process model.
accessibility:
the representation must be accessible from dierent technical envi-
ronments, and publication must be possible both in electronic and in paper
format. This is less a requirement on the knowledge representation notation
as such, but on the tool used to presenttheknowledge.
modiability:
the representation must support easy modications of the process
described, to support continuous improvement and adaptation to a changing
environment (cf. Sec. 1.2 on meta-processes). Among other things, this im-
plies that some kind of consistency checking must be available, to prevent
modications from introducing inconsistencies.
understandability:
the representation must be easy to understand for developers.
Their main objectiveis to understand the pro cesses described and perform
them. If developers havetothink about the representation rather than the
represented process, they will tend to ignore the dened process.
This requirement re-enforces the argument made above that knowledge rep-
resentation notations for use byhumans need to allow knowledge represented
by free text, to make the more formal or structured knowledge easier to un-
derstand.
Search and Selection Mechanisms
When describing software processes, one
quickly runs into the problem that developers cannot nd the description of a certain
task when they need it. Toovercome this problem, searching and selection must b e
provided as part of the software process support used. Typical mechanisms for this
purpose are

keyword search and full-text search

dierent views based on various criteria such as role or project phase

tailoring / only showing relevant detail

intelligentagents [44, p. 59]

visualization models [44, p. 60], suchasPersp ecta
(
http://www.perspecta.com
) and InXight(
http://www.inxight.com
)

Ellmer et. al. [25] describe asearch strategy specically suited for a process
library, based on neural networks (self-organizing maps).

16
Handbook of Software Engineering and Know ledge Engineering
3.2.
Articial Intelligence Approaches to Knowledge Representation
Standard approaches in articial intelligence to representing knowledge are pred-
icate calculus, production rules, semantic networks, frames, and scripts [26]. A
newer approach to structuring knowledge and nding it again once it has b een
captured in a knowledge base is the use of ontologies [45].
Analysis of these approaches quickly shows that all of them are quite suitable
for structured knowledge to be used for automated reasoning, but do not support
the representation of knowledge for use byhuman readers. In particular, they do
not allowfreetext, and are therefore not suciently expressive for our purposes.
On the other hand, dealing with pre- and post-conditions of tasks is clearly a strong
point of AI notations.
Similarly, they tend to be fairly eective and ecient for structured knowledge
(since they were designed for that purpose) but less eective and quite inecient for
human users, looking for ill-structured knowledge. Even for structured knowledge,
however, they are not ideal since they cannot easily handle the dierent kinds of
entities used in software process modeling, such as tasks, artifacts, roles, etc.
The explicitness of software process models in AI notation depends on the de-
tailed approach and the tools used | no general answer can be given. Accessibility
is typically low since the notation is supported by a single tool.
Modication of described pro cesses is possible but not easy since it is dicult
to understand the consequences of the modications. More generally, it is dicult
to understand a process model and its interactions if the mo del is described using
AI notations. However, this is eased by the fact that these notations allow exper-
imentation and asking questions about the mo del, such as \what are the possible
steps (i.e. applicable rules) once I have created artifact
X
?".
3.3.
Software Process Modeling Approaches
The following discussion is based on [24, 49, 55] which all contain an overview
of software process modeling languages and approaches.
Software process modeling languages such as Appl/A [54], MSL (Marvel Strategy
Language) [6, 12], and TEMPO [10, 11] are all very formal languages, used for
automatically enacting or checking the processes, but not to be used by human
users for their development tasks. Although SLANG [5] and Statemate [29, 33] are
graphical representations of the software processes, they do not score much better
regarding understandability. Only MVP-L (multi-view pro cess modeling language)
[16, 49] puts more emphasis on the human user and is therefore somewhat easier to
understand | but still far from the kind of process model one would liketogiveto
developers to tell them howtheyought to perform a certain pro cess.
These software process modeling languages are, to some extent, based up on ideas
from AI knowledge representation, and therefore share many of their advantages
and disadvantages. For example, they both are similarly eective and ecient
for structured knowledge, and similarly ineective and inecient for unstructured

Supporting SoftwareProcesses Using Know ledge Management
17
knowledge.
However, concepts such as tasks, artifacts and roles are fundamental to software
process modeling languages and therefore well supported, improving the expressive-
ness for structured knowledge.
Explicitness of software process models as well as the ease with which they can
be modied depend on the actual mo deling language used.
3.4.
Business Process Modeling Approaches
Since software processes are a special case of business processes, techniques for
business process mo deling can also be applied to software processes. Typically,
business processes are modeled using some graphical, easy-to-understand represen-
tations suchasowcharts or Petri nets [1], or use cases and other UML notation
[40], with attributes such as roles, eort, etc. included as hypertext. (See [19, p. 50]
for further references.)
This approach can also be applied for software processes, although manyofthe
attributes, such as the duration of a pro cess step, often cannot usefully be lled in
since software processes have less structure than typical business processes. As a
result, many of the standard process analysis techniques cannot be applied.
When applying this approachtosoftware processes in order to support develop-
ers, one has to make sure that lengthy free text explanations are possible | many
tools only allow a few lines of explanation.
Since business process modeling languages are usually more geared towards anal-
ysis and simulation of the processes modeled, there is little support for the people
actually performing the process, such as making software process knowledge avail-
able to them.
Since analysis and simulation is typically performed byasmallnumber of peo-
ple (the
Process Engineer
or the
Software Engineering Process Group
), there is
little emphasis in the to ols on making the model available within a heterogeneous
environment, although sometimes a Web interface is provided.
Business pro cess models tend to be quite explicit in that there are dierentlevels
of the model, with atomic tasks on one level being further broken down on the level
below.
Modication of a business process model is quite easy,withvarious checks avail-
able to ensure that no inconsistency is introduced.
3.5.
Structured Plain Text
Structured plain text is the approachtorepresenting software process mo dels
that is used most often in practice, see for example the German V-Mo dell [56] or the
(Rational) UniedProcess
, which additionally includes links to supporting to ols, see
[38] and
http://www.rational.com
.
Other common formats for representing software process models are HTML and
document databases such as Lotus Notes. In particular, these formats score fairly

18
Handbook of Software Engineering and Know ledge Engineering
XML
document
SPML
description
program
task
description developer
SPM tool
XML preprocessor
XML preprocessor
Fig. 4.
Combining software process modeling languages (SPML)/tools with developer support
using XML
high in accessibility, since they do not need special tools but use to ols that many
developers will have on their desk anyway,suchasabrowser.
XML
A fairly recent approach to structure text is the use of the
Extensible Markup
Language
XML [14]. XML was heavily inuenced by SGML and HTML,
allowing for more complex markup than HTML with individual tags, but at
the same time being considerably less dicult to handle than SGML (see
http://www.w3.org/XML/
,
http://www.xml.com
and
http://www.oasis-open.org
for more information about XML).
XML allows dierent views on the same data, such as dierentlevels (b egin-
ner, advanced, check list, detailed reference), for dierent user types (devel-
opers, automated tools), or for dierent project types (small or large pro jects;
customer-specic or o-the-shelf software;)
To some extent, it is possible, using XML, to combine software process mod-
eling approaches with additional descriptions in natural language that can be
given to developers to help them perform their tasks. A pre-processor then has
to remove these descriptions before the process model can be handled by the
relevant enactment or analysis tools. Alternatively, the pre-processor removes
the tool-specic parts to get a description of the software processes to be read
and used by developers (Fig. 4). Some work in this direction is currently
underway at the Fraunhofer Institute for Experimental Software Engineering
(IESE) in Kaiserslautern.
Process Patterns
were rst introduced by Coplien [22] and described more ex-
tensively byAmbler [2, 3, 4] (see also
http://www.ambysoft.com/processPatternsPage.html
for more resources
on pro cess patterns).

Supporting SoftwareProcesses Using Know ledge Management
19
Each process pattern describes one problem in software development processes
and suggests a solution to it. \A pattern is a general solution to a common
problem or issue, one from which a specic solution may be derived" [2, p. 3].
Such a process pattern is described using the following structure:

Problem

Context

Forces

Solution

Resulting context

Design rationale (this item is included by Coplien but not byAmbler)
Ambler distinguishes process patterns at dierent levels of detail, namely task,
stage and phase process patterns. Together, these process patterns can be used
to describe a full process model. On the other hand, individual patterns are
particularly suited to describing best practices.
Process patterns are easy to understand and modify, but there is no support
ensuring that the model is still consistent.
Since process patterns dene a structure for the denition of software processes
but no technical format, an arbitrary (hyper-) text format can be used; as a
result, it is easy to provide access to the process denition from whatever
environment is needed.
As an approach to software pro cess modeling, process patterns are quite dif-
ferent from XML (or Document Management Systems, see below), since they
are concerned with the
logical
structure of process descriptions, while XML is
concerned with their
physical
or technical structure. As a result, it is quite
natural to combine process pattern with XML, where process patterns provide
the chapter structure for process descriptions, and XML provides the syntax
to denote the chapters and their contents, plus hypertext links as needed. A
very simple example of a process pattern represented using XML is given in
Fig. 5.
One of the strong points of XML is that it is easily accessible in a hetero-
geneous environment, including paper printout. Modication of XML docu-
ments is also easy, with some consistency checking possible (depending on the
DTD and the tools used). Understanding an XML document itself, including
the tags, is possible but not easy. However, one would not usually want to
read the XML document itself, but only its presentation as dened byastyle
sheet. Assuming an appropriate style sheet, the presentation becomes easy to
read.
QualityPatterns
are quite similar to process patterns, but specic to solving
quality-related problems and documenting quality-related experience. They

20
Handbook of Software Engineering and Know ledge Engineering
<?xml version="1.0" standalone="yes"?>
<processpattern>
<name>Form Follows Function</name>
<alias>Aggregate Roles into Activities</alias>
<problem>A project lacks well-defined roles.</problem>
<context>You know the key atomic process
activities.</context>
<forces>Activities are too small, and ...</forces>
<solution>Group closely related activities
...</solution>
<resultingcontext>A partial definition of roles for a
project. ...</resultingcontext>
<designrationale>The quality of this pattern needs to
be reviewed. ...</designrationale>
</processpattern>
Fig. 5.
Example process pattern (from [22, Ch. 5]) using (simple) XML
were developed by Houdek et. al. [31, 32] and use amore elab orate pattern
structure than process patterns, see Fig. 6. However, there is no obvious rea-
son why this pattern structure should be specic to quality-related experience
and not be used for process patterns in general.
Document Management Systems
Software pro cess models described as plain
text can naturally be structured as a collection of documents. An obvious
choice for storing such documents are do cument management systems (DMS)
which support storage, retrieval and versioning of documents. Atypical tool
used here is Lotus Notes, although its support for versioning of documents is
rather weak. Lotus Notes, like some other do cument management systems,
additionally has groupware capabilities that can be used for discussions and
feedback mechanisms on the process model.
DMS support representation of both structured and unstructured knowledge
and are therefore quite expressive. However, retrieval of represented knowl-
edge is usually only supported bysearch and selection algorithms, while infer-
ence of new knowledge from existing (structured) knowledge is not available.
A strong point of DMS is the administration of links between dierent knowl-
edge items, making it easy to provide more detail as needed (explicitness).
Access to the knowledge represented using a DMS is only via this DMS, but
most providers of DMS make an eort to provide versions that run on dierent
platforms and can be used in an heterogeneous environment.
Modication of the knowledge represented in aDMS is easy, but it is also
easy to introduce inconsistencies. Some of these inconsistencies can be found
by the DMS (depending on the to ol used), such as links leading nowhere, but

Supporting SoftwareProcesses Using Know ledge Management
21
Administrative information
Links to related experience packages
and documents
Rationale
Example
Context
Solution
Problem
Abstract
Classi-
fication
Fig. 6.
Structure of a quality pattern [31]
inconsistencies within the texts cannot be found.
3.6.
Summary
Table 1 gives an overview of the requirements on software process representation
notations as described in Sec. 3.1, and how the notations listed in Sec. 3.2 to Sec. 3.5
satisfy these requirements.
For the requirements described here, the structured plain text approaches clearly
seem most suitable, which was to be expected due to the requirement that the
representation scheme must allow free text for the description of tasks etc.
In particular, XML looks promising as the wayforward, since it supports the
combined representation of free text and structured elements as needed for the
automation of individual tasks. The challenge now lies in creating a document
type denition (DTD) for process models that includes both aspects adequately.
However, this is not an easy task since it amounts to dening a common meta-
model for software pro cess models in XML notation.
When talking about a
combined
representation, we really require that it is
one
integrated representation dealing with both aspects. Splitting the representation
into two separate parts, containing a formal process model on the one hand and
ahuman-readable description on the other, as suggested e. g. by [25], will lead to
consistency problems, just like design documents hardly ever describe the design of
the current implementation of a software system.

22
Handbook of Software Engineering and Know ledge Engineering
AI software business structured plain text
approaches process process XML Process DMS
modeling modeling patterns
expressiveness:
structured k. 0 + + +
;
0
unstructured k.
; ;
0/
;
+ + +
eectiveness:
structured k. + + 0 +
; ;
unstructured k.
; ; ;
+ + +
eciency:
structured k. + + 0 +
; ;
unstructured k.
; ; ;
+ 0 +
explicitness +/0/
;