MIT LIBRARIES
3 9080 02239 0246
{
V
^w
ft
f
;'i t '
y * \
;
^
^
'a
-1.
L^
K
HEWEY
HD28
.M414
H
Combining Local Negotiation
And
Global Planning
In Cooperative Software
Development Projects
Kazuo Okamura
CCS TR
#163, Sloan School
WP
#3662-94
August 1993
CENTER FOR
COORDINATION
SCIENCE
Massachusetts Institute of Technology
Sloan School of Management
Cambridge, Massachusetts
Combining Local Negotiation
And
Global Planning
In Cooperative Software
Development Projects
Kazuo Okamura
CCS TR
#163, Sloan School
August 1993
WP
#3662-94
MASSACHUSETTS
or rr.CHNOI
NOV
1
f^lSTITUTE
DGY
4 2000
LIBRARIES
Combining Local Negotiation And Global Planning
In Cooperative Software Development Projects
Kazuo Okamura
Center for Coordination Science
Massachusetts Institute of Technology
One Amherst
Street (E40-179)
Cambridge
MA 02139
Information Systems Research Laboratory
Matsushita Electric Industrial Co., Ltd.
1006 Kadoma, Osaka 571
Phone: +81-6-906-2443
JAPAN
Email: okamura@isl.mei.co.jp
August 1993
ACKNOWLEDGMENT
The author would
helpful
comments on
Science
at the
like to
thank
Thomas Malone
earlier drafts of this paper.
for his generous advice.
The research support of
Massachusetts Institute of Technology
is
Bob Halperin provided
the Center for Coordination
gratefully acknowledged.
Combining Local Negotiation And Global Planning
In Cooperative Software Development Projects
ABSTRACT
In cooperative software development, each
redundancies inevitably arise
among
them.
changes without sacrificing programmers'
are concerned with
flexibility, and,
their
own
plans and conflicts or
two main problems:
first, to
control
second, to guide change activities to conform
methods of change request management focus on the management process
project policies. Traditional
structure based
We
programmer has
on project policies while cooperative development methodologies concern mainly with the
conflict resolutions
among each
changes. In this paper,
proposal of changes. Based on plan integration
it
describe an architecture which deals with
seamlessly supports both change coordination through
management process
negotiations and the change
we
to
have changes converge
until they
meet
the project
goals.
To appear
in
Proceedings of the
COOCS
93
ACM Conference on Organizational Computing Systems
Milpitas (near San Jose) California,
Permission to copy without fee
commercial advantage, the
copying
is
by permission
all
ACM
of the
and/or spectfic permission.
or part of this material
copyright notice and the
is
November
1-4,
1993
granted provided that the copies are not
title of
the publication and
Association for Computing Machinery.
its
made
or distributed for
date appear, and notice
To copy otherwise,
is
given that
or to republish, requires a fee
.
INTRODUCTION
One of
the
major problems
in software projects is
Programmers change software based on
development
parallel
own
is
Sooner or
plans.
allowed as
much
later, conflicts
them might compete with each other
how
manage changes
to
to software artifacts.
certain plans. In cooperative software development, in
as possible, each
programmer may take actions based on
among
or redundancies will inevitably arise
for software
these plans.
modules while others might have the
and reduce the
A
therefore, a crucial part of cooperative software
is,
of
goals.
performance and productivity.
activities
project's
their
Some
common
These problems hinder the programmers'
proper change control mechanism
which
development
environments.
In this paper,
we are
concerned with the two main problems
1
To
2.
To guide programmers' change
in
change control:
control changes without sacrificing programmers' flexibility
activities to
foUow
project policies
Studies of cooperative software development mainly discuss the
programmers merge
[22, 1] help
their
work when
first
problem. Several systems
conflicts are found. Kaiser [12] extends the traditional
database transaction model to give programmers flexible controls over transactions. Softbench
provides an event-based architecture in which programmers are notified
when some
changes
programmers
to
source code, or tool invocations. In these systems,
for resolving conflicts
25], the second
management
tools
can
change
problem
process.
assist
among
is
treated as configuration control
The elements and
activities to
comply with
that are responsible
the structure of the process are rigidly defined so that
the project constraints.
it
If,
in controlling
management
programmers'
however, change request management
can easily becomes a bureaucratic system
to
[11].
Therefore
the pros and cons of these methodologies in mind, our approach to the problems
is
first
until they
is
to describe
in the
AI
an architecture which deals with proposal of
meet the project
goals.
describe the concepts underlying our approach and outline our assumptions about the
context of the architecture.
which
we wish
an attempt
seamlessly supports both change coordination by programmers and the management process to
have changes converge
We
it
their creative activities.
planning paradigm. In this paper,
It
is
avoid diverting the
extend change request management concepts based on plan integration framework [24]
changes.
[2,
which focuses on the change request
very important to consider programmers' individual viewpoints and try
With
changes, such as
management methodology
change request managers or the configuration control board
programmers from
to
the
their tasks. In the traditional configuration
performed only from the project viewpoint,
is
it is
state
[4]
Then we describe
the
PCRM(Plan-based Change Request Management) system
an experimental implementation of our architecture and discuss
its
three aspects: the change plan
integration algorithm, contlict and redundancy resolution through negotiations, and customizable
representation of a change
management
process.
CHANGE REQUEST MANAGEMENT BASED ON PLAN INTEGRATION
A
typical
change request form [25]
in traditional
informal plan description for the change because
it
management
configuration
is
essentially an
contains the information such as the purpose of the
change, items to be changed, when the change can be done, and the expected effect of the change. These
correspond
to a goal, resources, a pre-condition
and a post-condition of a plan description, respectively.
management can be performed through
Therefore, change request
integrating change plans into a
consistent project plan for the changes.
Plan integration
is
usually useful in a relatively static environment. Software development
such a environment because
it
is
software system [21]. However,
not
difficult to discern and/or articulate all the constraints a-priori for a
when
the assumptions
made
at a particular integration point is
invalidated by later changes in the environment, one can express the discrepancies as
which
is
will be inputs to the next plan integration. Therefore,
easily and repeatedly, plan integration
if
new change
requests,
the integration procedure could be
would be a worthwhile support
development. Not only the result of the integration but also the process
for
change control
itself
would be very
done
in software
useful. If
could be done through social protocols, programmers could reach an agreement about change activities
it
in
the project.
In our architecture,
and are then passed
to the
who
change request management system
performs the integration. The plan
integration process proceeds with checking relationships
and resolves them. Programmers can take part
among
to resolve the conflicts
project policies.
The
that
and the redundancies
in
such a
concentrate on their
goals
plans to find conflicts and redundancies,
and, therefore, the
management
also important for the
management
in the resolution process,
system can respect their original intentions as much as possible.
system
own
change plans are written by programmers
It is
way
that the
change plans can comply with
integration process with such features ensures that every affected
programmer has
reached global consensus on the integrated plan for changes which meets the project's goals.
Change plan
(1)
integration in the
list
Resolving conflicts and redundancies through negotiations.
A
tailorable
The system has
flexible
of possible actions to resolve conflicts and redundancies.
programmers by creating
(3)
features:
Selection strategies of actions to resolve conflicts and redundancies.
strategies to select a
(2)
PCRM system has the following
a
communication channel and suggesting
representation of project's change
The system mediates between
the
the possible actions.
management
policies.
customization are provided to tailor the system according to project requirements.
Several levels of
Our Assumptions
We
make
which allow us
several assumptions
to concentrate
on the problems
in
change request
management
Some form
-
of version and configuration management system (such as
identify software items to be changed,
-
Programmers
and
-
to
which allows them
CVS
[3]) is available to
PCRM system.
to
work
in
both their local work space
by the version and configuration system. Whenever they want
to
software items in the global space, they have to propose the changes.
There exists a base system (which, for example might be the previously released system) from which the
new system
-
can be accessed by the
are in a networked environment
as well as the global space provided
make changes
it
RCS,
One
is
evolved.
of the programmers operates the
PCRM system
as a
Change Request manager
(the
CR manager).
OVERVIEW OF THE PCRM SYSTEM
Figure
1
shows how change request information
is
processed in the
^«aK*<f «w>»w w (irtiT HT>i
i
^ - »t>n:m^
n
^,
PCRM system.
..
,
theCR
Manager
^@|-^(^)-^f^
ISSUES +
CHANGE PLANS
Figure
1.
Initiation of
1:
Plan
Work Space
Change Request Management
with the
PCRM
System
Change Plans
A change request process starts when programmers in a project receive problem reports from
of a target software or write their
turn
them
into
own
reports.
Then
the
users
programmers screen these informal reports and
two formal descriptions called ISSUEs and
CHANGE
PLANs. An ISSUE
is
a problem
description that includes the information about a type of the problem, software items related to the
problem, the original reporter, and the originator of the ISSUE.
A
type of a
ISSUE can
be either a bug, an
enhancement or
TASKs
and a goal
that
is
to solve
One problem
functionality.
A CHANGE PLAN
a refinement.
a plan description
is
which consists of
an ISSUE. For example, the goal could be to
report might be turned into several
CHANGE TASKs
CHANGE
fix a
CHANGE
bug or enhance some
ISSUEs and solving one ISSUE might
CHANGE TASK would
solve several ISSUEs. One of the simplest examples is a CHANGE PLAN with a single CHANGE TASK
which solves an ISSUE of a software bug. A complex example is a CHANGE PLAN for a function
enhancement in the next software release, with a set of CHANGE TASKs of several programmers.
require several
PLAN.
Conversely, a single
Preparation for the Integration
2.
The
ISSUEs
The
CR
PLANs
3.
in a
CR
manager
in the project collects
to identify relationships
manager can
reject
among them. The most
ISSUEs and
and valid ISSUEs are the
redundancy
PCRM
is
system
important relationship
is
the equality
among them.
CHANGE PLANs at this point. A set of the CHANGE
results of the preparation.
starts integration of the
found, the system creates a
one of the actions which
conflict
the related
from programmers and screening
Change Plans
Integration of
The
CHANGE PLANs
is
list
given
CHANGE
TASKs. Whenever
a conflict or a
of possible actions based on project policies and executes
determined by negotiations among the programmers. After resolving every
and redundancy, the system outputs an integrated plan for the requested changes. This plan may
be an input to another integration
The Architecture
The
if
necessary.
PCRM System
of the
architecture of the
PCRM
system
is
shown
in
Figure
2.
The main
part of the system consists
of a set of agents: the plan integrator, the negotiator, the knowledge base, and the user interface agent. The
kernel of the system
is
the plan integrator
and the action executor.
implemented
the.se
We
which contains the consistency checker, the conflict
resolver,
have enhanced Oval [16] with a Prolog-based inference mechanism and
agents as special Oval agents. Users of the system can create change-related
descriptions as semi-structured Oval objects and exchange them over a network using Oval's
communication mechanism, which has a conversation tracking function similar
In the rest of the paper,
we
will describe in details
how
the
PCRM
to the
Coordinator [27].
system integrates
CHANGE PLANs
into a consistent plan.
INTEGRATION OF CHANGE PLANS THROUGH NEGOTIATIONS
The basic plan integration algorithm used by the PCRM system is an enhanced version of [24).
framework includes
(i.e.
a
mechanism
for reasoning about resources focusing
CHANGE TASKs in our case) which consume and
theoretical basis for our approach in
on situation-dependent operators
produce resources. Therefore
which handling software resources
CHANGE TASKs. There are three major enhancements in our algorithm:
His
is
it
provides a good
an indispensable aspect of
Team members
Emails
An Action
Conflict
Consistency
Checker
Resolver
Possible actions to resolve the conflict
^
A
Conflict
Open
:
Precondition, Unsafe Causal Link, Resource Deficit
-^v.
Conflict
resolution
rules
Figure
1)
2:
Executor
Prolog
Knowledge Base
Negotiation
Strategies
The
PCRM
the Project
Knowledge
System Architecture
Conflict resolution strategies based on domain knowledge.
We
enhanced the original algorithm by
adding tailorable strategies to include project policies for managing change requests.
2)
Conflict and redundancy resolution through negotiations.
The
original algorithm constructs integrated
plans by applying every possible conflict resolution operations without user interaction. In change
request management, however,
it is
highly desirable to have affected programmers participate in the
decision making process so that they can arrive at a consensus on
3)
how
to resolve conflicts.
enhanced the algorithm by adding a negotiation support mechanism for
that purpose.
Handling software resources. In the original algorithm, a resource has
its
However,
amount of
if
a resource
it,
is,
for example, a software
in the original sense.
We
amount and
module, one cannot consume
it,
is
We
have
consumable.
nor change the
have extended definitions of consumption and amounts of
resources.
Although discussing correctness
enhancements do not
of the algorithm
is
beyond the scope of
this paper, the
affect the correctness of the original algorithm since our algorithm is a
specific variant of the original one.
domain-
REPRESENTING CHANGE PLANS
In this section we formally define CHANGE
PLANs.
A CHANGE PLAN consists of:
1)
A set of CHANGE TASKs
two special
or tasks. Each task must have a goal, preconditions, and effects. There are
tasks: the initial task
and the
I
final task
G^.
I
has no precondition, and has the effect of
amounts specified
asserting the propositions and producing resources in the
in the initial state.
G
has no
and has preconditions specifying the propositions and lower bounds on resource production
effects,
specified in the goal state.
2)
A
partial order
< on
order. TTie initial task
We say
tasks.
I
If
C
A set of causal
precondition of j.
of
some resource
each resource
We say that
r
is
CHANGE TASK which
Amount
i
must precede
r is
and the
is
r
A
final task
G
must follow every other
consumer
any consumer
C of
C
of
that follows P,
might follow C.
that
r
r
<i, p,
j> where
i
and
j
are tasks such that
i
< j,
the guaranteed resource supply (GRS), a lower
modeled
it.
task.
and
Two
unordered with respect to each other are mutual competitors.
consumed by
is
r
i
and p
asserts p,
bound on
is
a
r that
might precede
consumed and produced
is
in
the level of
GRS
produced by the suppliers of
the competitors of
as a resource that
The
and B can be executed
values in
ordering that extends the partial
total
a supplier for each
can be calculated as the amount of
uses
any
of S (the state immediately preceding S's execution). The
of a software resource
GRS
in
and the
a competitor for
value of S
r
that
must
S.
equal amounts by a
CHANGE TASK may also produce a new version of the resource
used
at the
initial
same time using
and B are both
number of
to indicate the
simultaneously executed using the resource. The
TASKs A
task,
j
the estabhsher of j.
is
S
precede S minus the amount of
software resource
that are
i
in the input state
with respect to resource
6)
then
r is
form
links of the
4) Associated with each task
A
j
must precede every other
consumers of the same resource
5)
<
each producer P of some resource
that
each consumer
3)
i
1.
amount
a
module
Although how
resource depends on execution environments,
to
is
parallel tasks, that are allowed to be
always
M
.
if
the
1.
For example, 2
amount of
M
is
CHANGE
increased to 2
execute these parallel tasks with the same
A and B may create a binary
branch
in a version tree
of the
module M.
'
To make
initial
time.
and
a
CHANGE PLAN
final tasks
PCRM system allows user to write a CHANGE PLAN without specifymg the
system automatically adds the two special tasks to the CHANGE PLAN at the integration
description simpler, the
In such a case, the
The amount of
7)
executed
at the
a software resource cannot be increased
same
time. If such a task
is
withdrew
amount should be decreased. The amount of
existing tasks
more than
after the
number of
the
amount of
a software resource
the resource
always related
is
tasks allowed to be
is
increased, the
number of
to the
the
which use the resource and there should be no "stock" of it.
CONFLICTS AND REDUNDANCY
Our algorithm
initial
at this
producer of
relevant resources and has the effect of asserting
all
CR
point because they have been already screened by the
CHANGE PLANs
includes the aggregate goals of
contradiction
(i.e.
some goal
PCRM
unintegrable, and the
PLANs must be
to
all
and G.
ISSUEs. ISSUEs
G
manager.
be integrated.
I
the
are consistent
has a precondition which
precondition of
If the
I is
G
contains a
CHANGE PLANs are
programmers that the CHANGE
the negation of another goal), then this set of
is
CR
system notifies the
manager and
the
reformulated to enable successful integration.
Our algorithm proceeds by
different
CHANGE TASKs:
a plan by creating two special
first initializes
resolving conflicts and redundancies between
CHANGE PLANs. The conflicts that may
CHANGE TASKs
in
arise during plan integration are unsafe causal links
^resource deficits and open preconditions, which are resolved by either adding precedence constraints,
adjusting resource amounts or adding a
resolved by deleting the redundant
CHANGE TASK.
new
CHANGE TASK.
CHANGE
Redundant
TASKs
are
These conflicts and redundancies are formally
defined as follows:
-
A causal link <i, p, j> is unsafe if there is some k that deletes p which might occur between
ak
-
is
and
j.
Such
called a clobberer.
A resource deficit <C,
Precond(C,
-
i
An open
r),
r> occurs
where Precond(C,
precondition
is
when
the
r) is
a pair <p, j>
there
a
is
consumer
C
of
amount of r required by
where p
is
some resource
C
and
is
1
r
if r is
a precondition of j and there
is
such that GRS(C,
r)
<
a software resource.
no causal
link of the
form
<i, p, j>.
-
A CHANGE TASK
1)
i
is
redundant
For each causal link of the form
and possibly
after
each clobberer
2)
The
3)
For each resource
set of resources
r
used by
i
<i, p,
j> there
C of the causal
is
a node
k
that asserts
r.
i,
there
is
a
p such that k
is
possibly before
j
link.
are included in the set of resources used
produced by
resource deficits with respect to
if:
way
to reorder
by
k.
consumers and producers of
r
to
avoid any
An Example
The following example
illusiraies
and redundancies defined above. Suppose
this
intuitive interpretations
that a
team of programmers
files.
The modules responsible
for these operations are GetMail, Objeciifier,
Regarding these operations, there are three ISSUEs
ISSUEa: There
is
a
minor bug
ISSUEb: Saving many objects
in the current release
in
saving objects.
is
too slow.
ISSUEc: POP3(Post Office Protocol) support
solve these ISSUEs, three
TASK in
CHANGE PLANs
in
saving objects
Tb: Speed up saving objects
Tc:
Table
1
Add new
shows
e-mail protocol
the detail of these
is
In
P0P3
CHANGE TASKs.
and SaveObject.
of the system:
needed.
are created.
it:
Ta: Fix the bug
Name
working on an e-mail system.
is
system, e-mail messages are (1) received, (2) convened into internal object-oriented data, and (3)
saved into
To
and possible resolutions of the conflicts
Each
CHANGE PLAN has
one
CHANGE
In Table
Re and Rn means
1,
the current release of the system and the next release, respectively.
SaveObject(Rc) means a version of the module SaveObject used
UPDATE_MODULE(R, M)
module
replaces a version of the
in the current release
of the system.
M in the release R with a newly created
version.
The following
Open
-
conflicts or redundancies, therefore,
arise in this
example.
precondition
Tc assumes
One of the
there
new
a
is
release that includes the
possible solutions
* to add a
new
new
task
same version of
Objectifier as the current release does.
is:
Td
that tentatively initializes a
release.
Redundancy
-
ISSUEb can cover ISSUEa, Ta
If
-
may
* to
withdraw Ta
* to
merge Ta and Tb
Unsafe causal
is
redundant to Tb. Possible solutions
include:
link
While Tc updates GetMail with an assumption
the next release,
may
Tb
that the version of Objectifier in the current release is also in
updates Objectifier in the next release.
A causal
link:
<Td, Tc, includes(Rn, Objectifier(Rc))>
is,
therefore, unsafe with Tb. Possible solutions
* to
merge Tb and Tc
* to
move Tb
(i.e.
-
Resource
to
after
may
include:
Tc
add the precedence constraints Tc < Tb)
deficit
Both Ta and Tb modify SaveObject. Some of possible solutions
* to
move Ta
after
* to increase the
(i.e.
* to
Tb
are:
or vice versa
amount of the resource and
to allow a parallel
the
GRS
values in
Ta and Tb
development)
merge Ta and Tb
Another resource
deficit
may occur among Tb and Tc
regarding GetMail and can be handled in a similar
way.
Based on possible interpretations of
of solutions to programmers.
The
conflicts
final decision
and redundancies, the
by the programmers
may
PCRM system suggests a set
vary from a low level one like
)
ordering their tasks to a high level one like merging their tasks and changing their original strategy.
Sometimes programmers may decide
in
to defer solving conflicts or
such a case, the integration process
is
useful
m
a
redundancies
until
execution time. Even
sense that the programmers can be aware of the
conflicts or redundancies in their tasks priori to executions.
THE CHANGE PLAN INTEGRATION ALGORITHM
Now, we
the
formally define the plan integration algorithm used
in the
PCRM system.
change plan integration algorithm. The system defined actions are printed
two execution modes
in
CR
manager and negotiation among programmers;
algorithm produces possible integrated plans and
we mainly
STEP
1
non-bold
italics.
There are
our algorithm. In the interactive mode, the algorithm produces one integrated plan
through interaction with the
paper,
in
Figure 3 shows
describe
how
the algorithm
lists
works
in the
batch mode, the
of necessary negotiations to be pertormed. In
in the interactive
mode.
this
In the algorithm described in Figure 3, 77? F has different semantics in
batch mode,
it
means "Construct a new plan Q' by applying every
Q and add Q' to the plan work space".
interaction
mode,
it
execution procedure
while
will describe later.
simply applies the action of
it
its
list
Do
argument
called a possible action
is
Table 2 shows the system defined actions
list
execute.
Action
mode, so
that
the other hand, in die
and invokes the interactive
in the
mode,
mode.
PCRM system.
Although some of them are not
explicitly in the algorithm described above, they are in a possible action
interactive
On
also performed interactively in the interactive
in the batch
In the
action spectTied in the arguments to plan
Neither interaction nor negotiation occurs.
put the actions into a
we
two execution mode.
programmers can choose one of
list
as default actions in the
the every possible actions the
PCRM
can
and ihe kxal juslificalion
rules.
the execution of an action.
action
(<-
(<-
is
If
The
PCRM system
some of
tries to
prove the predicates
the predicates are found to be true,
it
in the rules
means
which support
that the corresponding
very likely lo be accepted. Figure 4 shows an example of a part of such rules for the action
(can-move ?x ?y ?reason)
(managerial-move ?x ?y ?reason))
(can-move '.'x ?y '.'reason)
(technical-move ?x ?y ?reason))
(<-
(can-move ?x ?y ?reason)
(other-move ?x ?y ?reason))
(managerial-move ?x ?y ?reason)
(<-
(managerial-move ?x ?y
(<-
(more-important-task ?x ?y ?reason))
'.'reason)
(<- (more-important-task ?x ?y ?reason)
(from '.'ix ?person-x)
(from '.'iy '.'person-y)
(more-important ?person-x '?person-y))
(issues
MOVE.
'.'x
'.'ix)
(issues ?x
'.'iy)
This example represents the fact that a
might precede a
CHANGE TASK
"more-important
'
Ty
CHANGE TASK
derived from a person Y's report
with the person Y. This rule justifies
MOVE(Tx,Ty)
relations like "more-important" could be defined explicitly in the
objects using the object link
Figure
2.
4:
A
mechanism
Tx derived from
in
if
a person X's report
the person
X
has a relation
with a high priority. Primitive
knowledge base or
in the
corresponding
Oval.
Part of Justification Rules for
"MOVE"
Negotiation Phase
After justifying the actions, the
commitment
selected by
to
A)
PCRM system selects an action of the highest priority. To achieve a
execute the action, the system
role definitions and
tries to establish
conversation channel
among
the
members
B) the negotiation table described below.
A) Role definitions.
Members of a
-
OWNER. <OWNER,
An
-
project can have the following roles.
anObject>
OWNER of a task, a resource, or an action is a person who is primarily responsible for the object.
SUBSCRIBER. <SUBSCRIBER. anObject>
A SUBSCRIBER of a task,
a resource, or an action
is
a person
who
is
interested in the object's state.
-
DELEGATExDELEGATE,
<a
role definition>,anAction>
A delegate of someone's role with an action is a person who perform
the role
when
the action
is to
be
executed.
The
PCRM
system has several default rules
to define
PERSON
OWNER.
For example, an
OWNER of an
ORIGINATOR or PERSON
RESPONSIBLE field of the object. The CR manager has the OWNER roles of every ACTION objects.
object
is
assigned to a person whose
On
die other hand,
operation
(i.e. it
SUBSCRIBER has more
has two tasks as
its
arguments), the
SUBSCRIBER of the other after the execution.
provide information on dependencies
the dependencies. For instance,
assign die
dynamic
If die
A
in
aspects.
the
When
an executed action
is
a binary
PCRM system assigns each OWNER of the tasks to a
version and configuration
resources,
a resource
is
SUBSCRIBER
management system could
roles could be defined to reflect
"depends on" a resource B, the
PCRM
system would
OWNER of die resource A to die SUBSCRIBER of die resource B.
Any role
how
if
among
object
to use a
of a person can be delegated to anyone by the person or the
PCRM operator.
Example of
DELEGATE role is discussed later.
B) The negotiation table
This table
is
used to select participants of a negotiation. Table 3 shows one
of the default
configurations of the negotiation table setting.
Each entry
a
commitment of
in the negotiation table
the action execution
and
corresponds
who
to
an action and shows
should be notified.
who
should be asked
to get
A value of a cell <action,person(s)> in
the table specifies one of die following kinds of interaction or notification, regarding the event of execution
of the action.
-
ASK
NOTIFY-B
NOTIFY-A
NOTIFY
The
The
The
The
person(s) are asked before the event.
person(s) are notified before the event
person(s) are notified after the event.
person(s) are notified both before and after
die event.
-
TENTATIVE
Proceeds with a tentative approval, (described
later)
Persons
Action
-
No
no value
If
them
the
PCRM
to negotiate
entry for
interaction required.
system finds
each other
to arrive at a
MERGE(i,j) shows:
of the task
i
and task
j
that multiple persons
1)
consensus about the commitment.
OWNER of the action
in
(i.e.
the
CR
should be asked by the system about the
both tasks are notified before the negotiation; 3)
resources used
should be asked for a commitment, the system ask
both tasks are notified after the
if
manager
MERGE
the negotiation
MERGE action.
NEGOTIATION, Resource Deficit
is
In
Table
3, for
example, the
as a default) and
action; 2)
OWNERs
SUBSCRIBERS
done successfully,
OWNERs
of
of the
3.
Execution Phase
PCRM system repeats negotiations until one of them succeeds. In case that every attempts
failed, the PCRM manager can proceed by either repeating the negotiation phase again, using a tentative
The
approval, or executing one of the action with the manager's authority. Every execution
is
recorded for the
backtracking.
Tentative Approval and Backtracking
In case the
from
their
PCRM system cannot get an
immediate answer from members who are busy or away
work, the integration phase could proceed with a tentative approval.
the system to continue the integration without waiting the answer from the
person(s)> in the negotiation table has a value
TENTATIVE
members, or
ASK,
instead of
CR
If (1) the
manager
tells
(2) a cell <action,
the system automatically
A tentative approval can be changed to real one during the
tentative approval left in the plan when
executes DONE
proceeds with a tentative approval of the action.
integration.
The system checks
if
there
action at the end of the integration.
restore
any previous
state
is
any
it
A simple backtracking mechanism
supported and the system could
is
of the integration.
REPEATING INTEGRATION
When programmers
integration, they
may need
can set the status of the
are performing
to
some of
modify the plan due
CHANGE TASKs
CHANGE TASKs
to the later
changes
an integrated plan after an
in
in the situation. In
in the plan to either active,
dead or
such a case, they
inactive
,
which means
being executed, being withdrawn, or waiting for execution respectively. This integrated plan with the
status information
can be re-integrated with other new
CHANGE PLANs
status information plays an important role in both the action prioritization
The standard
possible.
",
justification rules include rules such as "Active tasks
"Dead
tasks should be withdrew first.
",
and
is
known
architecture with
human
as replanning [26].
The
next integration. The
phase and the negotiation phase.
should not be modified as
less as
"Inactive tasks have a higher priority than
tasks because inactive tasks have already been approved".
environment
at the
The problem
strategy described above
adapt a plan to a changing
to
is
new
a
way
of replanning in our
assistance.
THE KNOWLEDGE BASE
The PCRM knowledge base consists of three major parts:
1) conflict resolution strategies
which
includes the main algorithm; 2) the coordination strategies which includes the actions, the justification
rules, the roles,
and the negotiation
table; 3) the project
target software or the structure of a
knowledge such
as relationship
among
users of a
development team. In the current implementation, knowledge
is
represented in one of two ways:
-
Any Oval
object and
its
relationship can be used to represent knowledge.
contains links to Oval object's types.
The
PCRM
A
knowledge base object
system periodically checks changes
in objects of the
types and incoqioratc their information into the knowledge.
Each object knows what
parts of
its
information or fields should be exported as knowledge. This mechanism enables user to combine the
PCRM
system with the existing Oval applications [14] such as employee databases, decision making
systems or schedule management
-
A knowledge
object in a
knowledge base object contains knowledge
in a
Prolog notation. The conflict
resolution strategies and the coordination strategies are represented in this way.
CUSTOMIZATION OF THE CHANGE REQUEST MANAGEMENT PROCESS
Different project has different polices on how to deal with software changes. The PCRM
can he tailored
in the
system
following ways.
Customizing Change Request Information
Because every data
ISSUE
is
in the
PCRM
system including
defined as a semi-structured object in Oval which
is
CHANGE
PLAN.
a "radically tailorable[ 16]" system,
easy to customize: (1) their definitions by adding or deleting user-defined
them by defining
links,
Customizing the
and
Life
(3)
CHANGE TASK,
it is
fields, (2) relationships
and
quite
among
views of them by selecting appropriate display formats.
Cycle of Changes
PCRM life cycle editor that is a part of the user interface agent, displays a life
cycle view of a CHANGE TASK. This state transition is automatically derived from the definition of the
actions in the PCRM system. The life cycle editor helps the CR manager understand the life cycle and
In Figure 6, the
customize the
state transition
,
by
(1) defining a
PCRM LIFECVCLE
new
action and (2) modifying the existing actions.
EDITOR: Default Dennltion (Uer1.2)
Any
agent.
and post-integration jobs can be defined as a new action
Suppose every
the cost of
the
pre-
its
manager
that is
executed by an Oval
CHANGE PLAN in a project should be analyzed by a project manager to estimate
new
change, prior to the integration. This can be modeled by defining a
action and assigning
OWNER of the action. The life cycle editor creates an action object and also generates
which executes the action whenever the status of any CHANGE PLAN becomes
to the
an Oval agent
REQUESTED. When
the action
manager so
can do his/her job with the
that he/she
The system defined
is to
how
to
to the
CHANGE PLANs.
actions that are executed by the plan integrator can be also customized by
creating a subtype of them. Although
for example,
be executed, the system creates a communication channel
change the
some
status of a
characteristics of
them cannot be changed, user can customize,
CHANGE TASK when a negotiation for an action fails.
Customizing Negotiations
Role definitions and the negotiation table define
how
negotiations should be done.
The
PCRM
system provides several standard configurations which can be customized by changing role assignment or
changing values of the
cells in the negotiation table.
It is
also possible to
model a new
role
who performs
a
special job in negotiations such as technical reviewer or configuration manager. For example, suppose a
member in
a project has a role
<DELEGATE, <OWNER, aCHANGE_TASK> MODR>
for every
CHANGE TASK.
TASK when
the
MODR
This means that the
action
(i.e.
the action
member
is
treated as
OWNERs
which increases the amount of
of every
CHANGE
a resource)
is
being
MODR action in the negotiation table has the ASK attribute for OWNERs of
the tasks, the system asks the member to give a permission every time
attempts to execute the MODR
action over the CHANGE TASKs. Because the execution of MODR action with a software module as a
executed. If the entry of the
it
resource
may mean
configuration
creating a version branch of the module, this negotiation ensures the
manager can have a chance
to decide
whether a version branch
is
member who
is
a
required or noL
Customizing Action Prioritization
The
strategies
justification rules of the actions are used to prioritize actions
on how
among Oval
to deal
,
the
with conflicts and redundancies. The rules have predicates over relationships
objects that represents the project knowledge.
prioritization
and therefore, determine
The primary
can be done by modifying the fact information
in these
level modifications to the action
Oval
objects.
The another
level
modifications can be done by customizing the rules which determine the interpretation of the fact
information.
rules.
The
PCRM
system has rule
libraries to help the
CR
manager
to construct the justification
KNOWLEDGE
BASE: Rule Library Ver1
2
concept which
currently out of the scope of our work. Another difference
is
the project's policies on change request
Softbench
[4] features
been made.
It is
is that
our system can model
management.
an event notification mechanism that notifies a change event
the opposite approach of notification
compared
when
the change has
to ours.
Kaiser [12] has extended the u^aditional database transaction models to support the notion of long-
programmer
term transactions. Their concepts for cooperative development: activity interaction and
interaction could provide a very
because these concepts could
fit
mechanism based on
by separating the
basis to
change requests. Lifespan [25] provides
that support the life cycle of
CCC [7] provides a life cycle support of change requests
PCMS [19] concentrates on providing flexibility for the life
the life cycle.
cycle into four phases.
life
combine our framework with execution environments
well to our support of replanning with the task status information.
There are several systems
notification
good
cycle of software items and change requests. In these system, however, the coordination
programmers
is
by the capability of
limited
the check-in check-out
model
[9].
their configuration
management systems which
Conflict and redundancy
Huff, et
management could be
built
on
their
in software
and project
in organizations
the
are based on
Madhavji [15] defines a universal model of changes
development environments. The model can represent changes
among
policies.
model.
[10] apply the planning paradigm to software development, featuring a truth
al,
maintenance system. Croff,
et al, [6] use negotiation
among
agents including
human
to
handle the
exception happens during plan execution. Unlike our system, these systems focus on intelligent plan
execution process. Martial [17] describes a conversation model for resolving conflicts using temporal
relationship
among
doesn't use any
plans of office activities. Although the model has a similar negotiation mechanism,
domain
Perry, et
specific
knowledge and
[23] discuss a general
al,
its
conflict resolution strategies are not customizable.
model of software development.
components: policies, mechanisms and structures. One of our goals
cooperation. Systems related to policy enforcement such as
us various ideas
how
it
ISTAR
is
to support
[8],
Darwin
It
consists of three
what they
[18],
call
enforced
and [19] can provide
to represent project polices.
CONCLUSION
In this paper,
we have described
a change request
management system which supports
integration
of change plans into a consistent plan. The integration algorithm and strategies to resolve conflicts and
redundancies were described
enhancements written
In the future
in
in detail.
The current implementation
CommonLisp and
we expect to work on
is
based on Oval with several
running on networked Apple Macintosh.
the following aspects of the
PCRM system:
-
Experimcniation
We
to
-
would
like lo test
our system
in practical situations to
study effective negotiation protocols, as well as
explore representations of project policies on change request
Integration with version and configuration
We
management
management
plan to extend our architecture by incorporating a version and configuration
management system
or
software database.
-
Reasoning about time
Temporal reasoning and scheduling capability should be added
to
our system
to
support project
management of software development
-
Recording the reasons
Information about a negotiation process
because
could explain
it
is
how and why
very useful at an execution time as well as after the execution,
the decision
was made
combination of group decision making support such as [14], the
mechanism
to record the reasons of
With
in the negotiation process.
rcRM
a
system could provide a
changes.
REFERENCES
[
1]
Adams,
E.,
Honda, M., and Miller, T. Object Management
in a
Case Environment,
in Proc.
of 1 1th
International Conference on Software Engineering, IEEE, 1989.
[2]
and Patrinostro,
Ayer, S.
J.
Control.
& Management,
CVS
[3]
Berliner, B.
[4]
Cagan, M. The
11:
HP
F.
Software Configuration Management: Identification, Accounting.
McGraw-Hill,
Inc.,
Parallelizing Software
1992.
Development,
Softbench Environment:
An
in Proc.
of USENIXVO, 1990
Architecture for a
New
Generation of Software
Tools, in Hewlett-Packard Journal, 1990.
[5]
Curtis, B., Kellener,
[6]
Croft,
W.
M.
I.,
Over,
J.
Process Modeling,
in
Communications of ACM, Sep. 1992.
B. and Lefkowitz, L. S. Knowledge-Based Support of Cooperative Activities,
in
Proc.
of 21st International Hawaii Conference on System Science, 1988
[7]
Dart
S.
Concepts
in
Configuration Management Systems,
Software Version and Configuration Control.
ACM,
Proc. of International Workshop on
1991.
[8]
Dowson, M.
Integrated Project Support with IStar, in
[9]
Feiler, P. H.
Configuration
Management Models
in
in
IEEE Software, Nov. 1987
Commercial Environments.,
CMU
Engineering Institute Technical Report, CMU/SEI-91-TR7. Pittsburgh, PA. March 1991.
SoftM-are
[10]
Development Process,
in Proc.
Development Environments,
[11]
A
Huff, K. E. and Lesser, V. R.
Humphrey, W. Managing
Plan-based Intelligent Assistant That Supports the Software
of the 3rd Software Engineering Symposium on Practical Software
ACM,
1989.
the Software Process,
SEI Series
in
Software Engineering, Addison-
Wesley Publishing Company, 1989.
[12]
A
Kaiser, G.
Rexible Transaction Model
for Software Engineering, in Proc.
of 6th International
Conference on Data Engineering, EEEE, 1990.
[13]
[14]
Lee,
J.
Lee, G. Oval Application Catalogue,
Amherst
[15]
A tool for managing group design,
Sibyl:
St.
MIT
in Proc.
ofCSCN'90,
ACM,
1990
Center for Coordination Science Technical Report,
1
Cambridge, MA., Sep. 1992
Madhavji, N. H. The Prism Model of Changes,
in Proc.
of 13th International Conference on
Software Engineering, IEEE, 1991.
[16]
Malone,
T., Lai, K.,
Cooperative Work,
[17]
and Fry, C. Experiments with Oval:
in Proc.
A Conversation
Martial, F.
ofCSCW
Model
'92,
ACM,
radically Tailorable Tool for
1992.
among
for Resolving Conflicts
Proc. of Conference on Office Information Systems,
[18]
A
Minsky, N. H. Law-Governed Software Process,
ACM,
Distributed Office Activities., in
1990.
in Proc.
of International Software Process
Workshop, IEEE, 1990
[19]
Moffet,
J.
D. and Sloman, M.
S.
The Representation of
Conference on Office Information Systems,
[20]
Montes,
J.
Narayanaswamy, K. and Goldman, N. "Lazy" Consistency:
ofCSCW
'92,
ACM,
A
ACM,
in Proc.
ACM,
of
of
1988.
Basis for Cooperative Software
1992.
Harrison, W., Ossher, H., Seeney, P. Coordinating Concurrent Development, in Proc. of
'90,
[23]
in Proc.
in Proc.
1991.
Workshop on Software Version and Configuration Control,
Development,
[22]
System Objects,
and Haque, T. A. Configuration Management System and More!,
International
[21]
ACM,
Policies as
CSCW
1990.
Perry, D. E., Kaiser, G.
Models of Software Development Environments,
International Conference on Software Engineering, IEEE, 1988.
in Proc.
of 10th
[24]
Rosenblill. D. Supporting collaborative planning: The Plan Integration Problem. Ph.D. thesis,
Dcpanment of Electrical Engineering and Computer
[23]
Whitgitt, D.
Method and Tools for Software Configuration Management, Wiley
engineering practice. John Wiley
[26]
Science, M.I.T., 1991.
&
Sons,
series in software
Inc., 1991.
Willkins, D. E. Practical Planning: Extending the Classical
AI Planning Paradigm, Morgan
Kaufmann, 1988.
[27]
Winograd, T.
A
Language/ Action Perspective on the Design of Cooperative Work,
Supported Cooperative Work:
CA.
1988.
A Book
of Readings.
1.
Greif, Ed.
in
Computer
Morgan Kaufmann, San Mateo,
k\3
023
Date Due
MIT LIBRARIES
3 9080 02239 0246
,-mmMmmm^m.
^