Upload
lamkhanh
View
215
Download
0
Embed Size (px)
Citation preview
IMPACT LABORATORY
IMPROVING MANUFACTURING PRODUCTIVITY WITH ADVANCED COLLABORATION TECHNOLOGY
A Generic Collaborative Engineering Design Process Model for Conflict Management
By
Lu, S. C.-Y. and Cai, J.
Department of Aerospace and Mechanical Engineering University of Southern California
Los Angeles, CA 90089-1111
IMPACT WORKING PAPER No. WP00-03
2000
UNIVERSITY OF SOUTHERN CALIFORNIA
A Generic Collaborative Engineering Design Process Model for Conflict Management
Stephen. C-Y. Lu, Jian Cai1
The IMPACT Research Laboratory, University of Southern California, Los Angeles, CA 90089, USA
Fax: 1 (213) 740 6668, Email: [email protected]
Manuscript Pages: 32
Tables: 1
Figures: 13
1 Correspondence and reprint requests to: Jian Cai, The IMPACT Laboratory, Suite 101, Denney Research Building, University of Southern California, Los Angeles, CA90089-1111
Abstract
Collaborative engineering design involves various stakeholders with different perspectives. The design process is
relatively complex and difficult to handle. Various conflicts always happen among the design tasks and affect the
design team performance. Therefore, to represent collaborative design process and capture the evolution of design
perspectives in a structured way is critical to manage the design conflicts and improve the collaborative design
productivity. This paper provides a generic design collaborative design process representation model based on a
Socio-Technical design framework. This model has a topological format and adopts process analysis techniques
from Petri Nets. By addressing both the technical and social aspects of collaborative design activities, it provides a
mechanism to identify the interdependencies among design tasks and perspectives of different stakeholders. Based
on this design process model, a methodology of detecting and handling the design conflicts is developed to support
collaborative design coordination.
Keywords : Design Process Representation; Collaborative Design; Petri Nets; Conflict Management
1. Introduction
The increasing complexity of modern production makes design process more and more difficult to handle since
numerous technical and social issues are involved. The design activities are influenced not only by the technological
factors but also the interactions among various stakeholders with different perspectives. To deal with this
challenging problem requires an effective collaborative design process model, which can clearly depict the
characteristics of collaborative design activity and provide methodologies to improve design productivity.
Traditionally, there are a lot of approaches dealing with different elements of engineering design process from
various perspectives. They can be generally classified to three groups. The first group, which is mainly from the
engineering discipline, focuses on investigation of how the technical design decisions are made and generating
formalized design methodologies. Design process models are often implied in these design theories and
methodologies, such as Systematic design model (Paul & Beitz, 1996), Axiomatic design model (Suh, 1990), QFD
(Hauser & Clausing, 1988), General design theory (Yoshikawa, 1981), etc. Basically, these design methodologies
provide the guidelines for designer to make technical decisions more consciously and systematically (Jin & Lu,
1998). The second group views design process as workflow with task dependencies and information exchange.
Approaches in this category are mainly from the research of business operation and project management. From this
aspect, design is viewed as an information driven process among design activities. Design organization is viewed as
a stochastic processing network in which engineering resources are “workstations” and design tasks are “jobs” that
flow among them (Adler & Mandelbaum, 1995; Sanvido & Norton, 1994). Accordingly, a set of techniques to
manipulate the design activities has been developed, such as signal flow (Eppinger, 1997) and design process
network (Bras & Mistree, 1991). Besides the above two groups, several research approaches from CAD and CAE
areas view collaborative design as individuals and groups accessing data and sharing the design information. Design
process is accordingly specified as the managing of the product data in different abstraction levels. During this
process, the technological, scientific, and interdisciplinary dependencies of the information could be established and
maintained by handling the product model (Majumder et al., 1994). The information systems built by them are to
support the storage and processing of various types of data interested by designers (Sriram et al., 1997;
Krishnamurthy & Law, 1997).
These three classes of approach focus on different aspects of design and provide considerable contributions for
understanding design characteristics. Design theory research provides a clearer picture of design rationale and
decision making process. Design activity manipulation furnishes characterizing design operations and identifying
the dependencies of design tasks in the organization. Design data management supports information storage and
access typically in design automation. However, it is noticed that these traditional approaches have their own
limitations when applied in collaborative design. These approaches normally assume the indifference of perspectives
of different stakeholder and ignore their social interactions. Design process is accordingly viewed as a series of pure
technical activities, and the key issue “who” is not explicitly addressed. In fact, it is impossible to completely share
the knowledge and purpose among designers in collaborative design. Rather than being pure rationale, stakeholders
have an optimal or satisfied degree of consensus, which provides the desirable design result. Although design
methodologies and workflow management techniques are applied, designers still face some failures of coordination
due to their perspective differences and the inefficient design process management.
Therefore, a more comprehensive view is required to clarify the relationships among various technical and social
aspects of collaborative design. Collaborative design process model based on this perception will generate effective
coordination mechanisms for task planning, scheduling and monitoring, for detecting and managing design conflicts
and for tracking and controlling design roles of stakeholders. This paper describes a generic collaborative design
process model based on a Socio-Technical design framework, which is suitable to represent, analyze and evaluate
the collaborative design activities. We use Petri Nets as topological process modeling tools and adapts it for
collaborative design process modeling. A methodology of design conflict management is developed with the design
process representation model. The outline of this paper is as follows. In Section 2, we discuss the fundamental issues
of collaborative design process modeling and introduce a Socio-Technical design process modeling architecture.
Then the basics of collaborative design process representation model are described in Section 3. Section 4 presents a
methodology to manage design conflict by using the collaborative design process model. After that a prototype
collaborative design support system, which is a computer implementation of the methodology, is discussed. At the
end, Section 6 offers conclusion and future research issues.
2. Characteristics of Collaborative Design Process
The central objective of engineering design is to achieve the prospective artificial objects having desired
properties. As pointed by Herbert Simon, an artifact can be thought of as a meeting point – an “interface” between
an “inner” environment, the substance and organization of the artifact itself, and an “outer” environment, the
surroundings in which it operates (Simon, 1996). During the design process, it is design stakeholders’ task to define
the features within the inner environment of the product (e.g. form, structure, and behavior), which should be
appropriate to its outer environment. Due to the involvement of human being, design process is not only based on
the nature law of the artifact but also influenced by people’s goals, skills, and circumstances. Therefore, within the
collaborative design process, design information is driven by social, technological, scientific, and inter-disciplinary
dependencies. Design process is therefore should be modeled by revealing the complicated relationships among
them. We proposed a Socio-Technical Design framework to address the fundamental characteristics of collaborative
design process.
2.1 Technical decision and Social interaction
In collaborative design, stakeholders (e.g. customer, manager, and design engineer) participate into design
campaign with both technical roles and social roles. Based on their roles, the ways stakeholders understand design
and manipulate the activity are non-uniform. They usually adjust the attitudes based on the feedback from others.
Design process is thus consisted with not only technical decision making but also social interaction. That means the
representation of design process should consider the dynamics of perspectives of the individuals. Without realization
of variances of roles and perspectives among the stakeholders during design interaction, it is difficult to identify and
manage the various design conflicts. However, traditional design process models do not address design perspectives
and their social interaction. They either ignore the social features of design or assume designers are purely rationale
and simplify their preference as utility values.
The important negotiations among the collaborative design decisions are about “why” and “who” besides “what”
and “how”. We believe a well-formed collaborative design process model has to facilitate the stakeholders to realize
the perspective difference with each other and support them to detect and evaluate the inter-dependencies and
resolve conflicts. Besides keeping the product data integrity, design information system should provide the
“language” or “medium” for design participants to declare and depict their perspectives and aid their
communication. These will definitely affect the current design organization structure and design process. Therefore,
it is critical to generate a design process representation model, which can facilitate the describing, tracing, and
management of collaborative design interactions.
2.2 Design Perspectives
Defining design perspective is one of the essential issues in design process modeling. In collaborative design,
stakeholders’ perspectives can be visualized as “lenses” they wearing during design process. Each stakeholder has
his/her unique viewpoints and circumstances, which further define their roles in the design campaign. For the same
object, they may have different perceptions and make different decisions. In the Socio-Technical framework a
perspective is defined as the combination of:
• a purpose with which the stakeholder participates in an engineering design campaign;
• a context within which the stakeholder participates in an engineering design campaign; and
• a content relevant to the purpose and context, i.e., the experience, background, education, knowledge, an
insight that the stakeholder brings to bear within an engineering design campaign.
Collaborative design process is also a perspective evolution process. At the start of design, it is obvious that the
“what”, “how”, “when”, “where” and “why” are interpreted differently by different perspectives. During design, the
participants and the organization interact together and build the shared reality (Berger & Luckman, 1966) (i.e. the
institutional understanding of the world) in the social interaction process. While a technical design process model
(e.g. Axiomatic Design Model) may serve as a basis or starting point for technical decision making, it is always
dynamically adapted and modified by the participants during the course of the design campaign. The design
perspectives of the stakeholders are affected and the shared reality is formed while the function, form and behavior
of the product are being defined. It should be pointed out that most of the conflicts in the collaborative design are
caused by the discord among the stakeholders’ perspectives. Therefore, to represent the perspectives of the
stakeholders and investigate their influence to the design process is indispensable in design process modeling and
conflict management.
2.3 Coordination among stakeholders
Collaborative design problems are usually complex and have to be decomposed to sub-problems, which are often
assigned to different individuals separately. Although some design methodologies suggest designers to increase the
probability of success by maintaining the independence of sub-problems (e.g. Axiomatic Deign Model), it is
difficult to achieve in collaborative design due to the various dependencies among tasks. On the other hand,
individuals normally have limited capability to identify the influences of their decisions to others. Due to lack of
coordination effort, the meanings about design objects might not be defined well, especially at the conceptual design
stage. All of the above makes the decomposition and integration of design sub-problems a rather complicated
analyzing and synthesizing process. In collaborative design, integration has to be achieved not only through the
communication of contents, but also through communication about the creation and evolution of shared meaning.
The shared meaning is always defined by the interaction of design perspectives. That reveals one of the essential
aspects of collaborative design process modeling, which is to represent and manage the interactions among the
individuals’ perspectives during this decomposition and synthesis process. In collaborative design process, the
influence of one’s decision making in specific domain to others’ decision making in different sub-problems should
be represented and evaluated. Furthermore, the design process representation model has to help design stakeholders
to detect and evaluate the inter-dependencies among their design activities and solve conflicts. Therefore, design
coordination relates to not only the dependency identification among the design decisions, but also the management
of changing and interaction of the design stakeholders’ perspectives.
2.4 Socio-Technical design process architecture We believe collaborative design process should be modeled in a comprehensive picture, which includes not only
the technical elements but also the social issues. It is necessary to have a design process model, which can represent
and keep track of the state of collaborative design (e.g. the solved problem and the coming problem, the changing
product model, and the evolving perspectives of different stakeholders). Also, the negotiation and interaction pattern
among the stakeholders’ design perspectives should be explicitly represented and captured. These requirements are
the major differences between the design process models dealing with collaboration and those for individual design.
Detection
Resolution
Intervention
Causes Effects Context
Perspective
Purpose Context Content
Technical Role
Social Role
KnowledgeRepresentation
Information sharing
Function Structure Behavior Norm/Culture Procedure Form
Meaning will be defined
Consist of
Inter-link
mutual influence mutual influence
responsible for
Mut
ual i
nflu
ence
manage
participate
play play
design
represent
has view of
drive/change within/
generate Organization IntegratedProduct Model
TechnicalDecisions
SocialInteraction
Stakeholder
Conflict
ConflictManagement
Figure 1 The Socio-Technical design process architecture
The Socio-Technical design process architecture provides a more comprehensive view to model collaborative
design process (Lu et al., 1999). In Figure 1, the different elements and their relationships in collaborative design are
clearly depicted. From the Socio-Technical viewpoint, technical decisions , social interaction, and conflict
management are the tree essential elements in collaborative design process. In a design campaign, stakeholders
perform both technical roles and social roles. The former is conducted in the technical decision-making process and
the latter is in the social interaction. Normally, the characteristics of the design problem and the perspectives of the
stakeholders predetermine their technical roles. However, they are not static during the design process. In most
situations, their roles are adaptive while the perspectives evolve. That will also go back to influence the technical
decision making process. By making technical decisions based on their technical roles, design stakeholders create,
modify and evaluate the product features. Since the involvement of social roles, which are normally influence by the
organization structure, norm, and culture, technical decisions are coupled with the social-interactions during the
design cooperation. Knowledge representation (e.g. CAD drawing, Ruled based system, etc.) is critical for designers
to capture the understanding and reasoning behind technical decisions. Effective information sharing mechanisms
(e.g. Group discussion, Brain storming, Information management system, etc.) accelerate the process of achieving
agreement of the shared perspective. During technical decision and social interaction, various conflicts will occur.
Handling conflict only in technical domain without considering the design perspectives is insufficient since the
critical causes are ignored. To manage conflict near its source, social interaction should be considered as a
controllable infrastructure to affect and handle the design perspectives.
3 Representation of Collaborative Design Process
The Socio-Technical design process modeling architecture provides the guideline for us to develop models to
represent the process of collaborative design. In the following sections, we discuss a generic process representation
approach. It applies Petri Nets as the process modeling tools and thus has topological features suitable for
calculation and analysis.
3.1 Definitions
The reasons for selection of Petri Nets as basic process modeling tools are obvious. Although there are various
available tools, Petri Nets have the unique advantage to support process specification, representation and evaluation
at the same time (David & Alla, 1992). Also, their mathematical properties help us in quantitatively analyzing the
behavior of the design process. Furthermore, elementary Petri Nets have the simple graphical appearance, which can
become a convenient and precise language for communicating among design stakeholders. However, it should be
noticed that collaborative design process is relatively complicated and unstructured compared with other process
system (e.g. Computer code (Jenson, 1996), Manufacturing system). Some modifications are necessary to make
Petri Nets more suitable and effective for design process modeling. In this section we introduce some basic
definitions and their applications in representing collaborative design process.
A Petri net graph represents a general process with two types of node named places and transitions. Directed arcs
join some places to some transitions. Each place may contain one or several tokens represented by dots. The
following transitions of one place can only be executed when the required tokens are available. A weight can be
associated with each transition, which is a positive number. The marking of the Petri net is a vector that contains the
values of marking in all places.
In collaborative design process, place and transition are equal to “event” and “task” respectively. Design process
is represented by an organization of places and transitions. The weights of the tasks can be used to represent their
resource consumption. The default value of the weight is one. The arcs represent the transform directions between
events and tasks during the design. The token denotes the state of each individual event. Event contains token if and
only if it is active (i.e. event is happening). Thus the whole state of design process can be expressed by a marking
M , which is a vector having the token numbers of each event in design process. Since different stakeholders can
conduct tasks, we introduce the “stakeholder” into the notation. Each task and event has a set of stakeholders
associated. Formally, a Collaborative Design Process can be represent by a Petri net graph with the following
definitions.
Definition 1: A Collaborative Design Process Net (CDPN) is a tuple ),,,,,( MWASTECDPN = with a
set of labels:
},...,,{ 21 neeeE = is a finite set of design events,
},...,,{ 21 qtttT = is a finite set of design tasks,
},...,,{ 21 msssS = is a finite set of design stakeholders,
)}(){( ETTEA ××⊆ U is a finite set of directed arc connecting event and task,
},...,,{: 21 pwwwTW → is weight function attached to the design task,
,...}2,1,0{:0 →EM is the initial marking.
E1
E2
E3
E6E5
E4
T1
T2
T3 T4
T5
Beginning marketinginvestigation
Start of environment design
Select Buildinglocation
S1, S2 S2 S1,S2
S1, S3 S3 S1, S3
Preliminary Building location Selected
Gather customer needs
Investigation reportsubmission
Identify building requirements Draw preliminary
building layout
Revise layout
Layout check
Start layout designS2, S4 S4
S1,S4
S1, S4
S1,S2,S4
Figure 2 An example of Collaborative Design Process Net
As shown in the example (Figure 2), a portion of building design process is represented in a graph with the
above elements. To explicitly address the stakeholders in design process, each event and task has a set of
stakeholders associated. We use 4321 ,,, SSSS to denote project manager, design consultant, market surveyor, and
architect respectively, which are marked on top of the events and tasks. At the beginning of design, the tokens are
only contained in the start events (E1 and E2). After stakeholders preformed the tasks, the tokens from the upward
events can be transferred to the downward events. 0M is defined as the initial marking of a CDPN, which is a
vector contains the token number for each events. For instance, at the beginning of design 0M = [1 1 0 0 0 0 0]
since only event 1 and 2 possess tokens. If 0M equals [0 0 0 0 0 0 1], that means the all of the tasks shown in the
graph have been conducted since the token is presented in the last event.
The input and output relationships between task and events are denoted as:
to the set of input events of task t, (i.e. the set of }),(|{ Atee ∈
ot the set of output events of task t, (i.e. the set of }),(|{ Aete ∈
eo the set of input tasks of event e, (i.e. the set of }),(|{ Aett ∈
oe the set of output tasks of event e, (i.e. the set of }),(|{ Atet ∈
It is clear that finishing a task t consists with transforming the initial marking 0M of the CDNP into a new
marking M . Firing a task Tt ∈ includes two operations, which are removing a token from each te o∈ and adding
a token to each ote ∈ (assuming each arc has weight one). It could be formally defined as follows:
Definition 2: A task can be fired in a state 0M iff 0)(: 0 >∈∀ eMte o . The firing of a task leads to the next
state M , which can be calculated by:
∈+∈−
=otherwise )(
if 1)( if 1)(
)(
0
0
0
eMteeMteeM
eM o
o
(3.1)
Thus the execution of design process are represented by a task firing sequence >=< ,..., 21 ttσ , which relates
to a transformation of the marking 0M àM .
Process incidence matrix ][ , jiuU = is defined to represent the relationship between tasks and events.
Definition 3: An incidence matrix ][ , jiuU = is defined over all of the events },...,,{ 21 neeeE = , and tasks
},...,,{ 21 qtttT = where
∈−∈
=otherwise 0
if 1 if 1
,o
o
ij
ij
ji etet
u (3.2)
For example the ( qn × ) incidence matrix of the above graph is
−−
−−
−−
=
110001110000110001010001000001
U
Incidence matrix captures the interdependencies among the tasks and events. The relationship between state
transformation and incidence matrix can be expressed in the following transformation equation:
Proposition 1: TTT VUMM σ•+= 0 (3.3)
Where ],...,,[ 21 qvvvV =σ is a counting vector for a task firing sequence defined as:
Definition 4: The counting vector of firing sequence σ is defined as ],...,,[ 21 qvvvV =σ , where iv is the
number of tasks it included in σ .
Given the firing sequence σ =< T1, T2, T3, T4, T5, T4> in the example, its counting vector σV equals
[1 1 1 2 1]. Based on the equation (3.3), the final marking can be calculated as follows.
=
−−
+
=
−−
−−
−−
+
=
100000
100011
000011
12111
110001110000110001010001000001
000011
TM
M =[0 0 0 0 0 0 1] shows only event 6 is active, which means the process shown in the graph might be
finished.
The task dependencies are also easy to be identified from a CDPN, which is denoted by task dependence matrix
][ ijdD = . If the one of output events of task i is within the set of task j ’s input events (i. e. task i is immediately
in front of task j , the dependency factor is set to 1. We call this situation “sequential dependency”. Another
situation is that two tasks are sharing the same input event or output event, which is named “joint dependency”. Its
dependency factor is set to 0.5. Otherwise, it is said that there is sequential or joint dependency between the two
tasks.
Definition 5: An task dependency matrix ][ ijdD = is defined over all of the tasks },...,,{ 21 qtttT = where
≠∨≠≠
=otherwise 0
)()( if 5.0 if 1
, φφφ
oooo
oo
III
iiji
ji
ji tttttt
d (3.5)
Also, to represent the assignment of stakeholders’ tasks from the CDPN, we define a task assignment matrix as:
Definition 6: A task assignment matrix ][ ijhH = is defined over the stakeholder set },...,,{ 21 msssS = task
set },...,,{ 21 qtttT = with the value
∉∈
= } perform|{ if 0
} perform|{ if 1, tstt
tstth
ij
ijji (3.6)
For example, the task dependence matrix and task assignment matrix of the above CDPN can be derived as:
=
5.0100015.0000015.0000015.0000105.0
D
=
11100000100010110000
H
3.2 Concurrency and Choice
It should be noticed that although two tasks may have no direct linkage (i.e. 0, =jid ), they might still have
indirect dependencies since one may transfer its influence through other tasks. For instance, although the 04,2 =d ,
the output of T2 will still be embedded into the input of T4. Thus, the task dependency matrix only shows the direct
linkage relationships among the tasks. If two tasks are parallel (e.g. T1 and T2 in Figure 2), they are allowed to be
concurrently executed. The firing sequence σ is changed to < (T1, T2), T3, T4, T5, T4> to denote the concurrent
execution of T1 and T2.
To represent the degree of concurrency of a design process, we define the concurrency ratio of a process as:
Definition 7: The concurrency ratio of a design process is the proportion of the paralleled tasks in a firing
sequence of CDPN.
σ
σNN
Rc p=)( , (3.7)
where pN is the number of tasks which are in parallel and σN is the number of tasks in σ .
For σ =< (T1, T2), T3, T4, T5, T4>, 33.062
)( ≈==σ
σNN
Rc p
In a CDPN, the situation of a design event e with more than one task in its output set oe indicates a “choice
situation”. For example, task E6 in Figure 2 may have two output tasks (one is T5 and another is not shown in
Figure 2). In this case, only one of the tasks can get the token and be fried at one time. In design process, an event
with “choice” represents a selection of following tasks (i.e. a decision point). Choice in CDPN implies design
iteration, which might be caused by conflict or reworking. Given the possibilities of the options for each choice and
required time for each task, the execution time of the whole design process can be estimated by other process
simulation techniques (e.g. signal flow analysis methods (Eppinger, 1997)).
3.3 Task decomposition and design coordination
In collaborative design, concurrency is normally encouraged since parallel task execution may reduce the design
time and save resource. However, the perspective differences and communication faults will cause contradictions
among the concurrent tasks. For instance, in original design, the lack of experiences and knowledge usually becomes
major obstacle of concurrent task execution. Even for routine design, as concurrency increase, failure of
coordination will raise conflicts and damage the whole design process. Thus there is a tradeoff between task
parallelism and minimizing coordination effort. There are two approaches dealing with this problem. One approach
is to use design methodology to reduce the dependencies among design tasks. For instance, Axiomatic Design
Theory suggests to de-couple or uncouple the product function requirements so that design tasks can be more
independent. The other approach is to effectively support the communication and manage the conflicts among
design tasks. The first is focusing on task decomposition and the second is considering task coordination.
Design task can be decomposed based on various issues, such as the features of product, organization structure,
or designers’ disciplines. The Socio-Technical design process architecture emphasizes the importance of three
groups of activities in collaborative design, which are technical decision making, social interaction and conflict
management. Technical decision making deals with the specification of product feature, such as customer needs
analysis, product functional structural developing, and CAD drawing. Social interaction consists of various
communications about the concept, meaning and reasoning involved in design process. Conflict management
includes conflict detection, resolution, and intervention. This classification provides a hierarchical structure of
design task. If the technical aspects of design are only considered, the task of technical decisions could be carefully
decomposed by selection of “uncoupled” functional requirements and design parameters so that the sub-tasks are
relatively independent. However, tasks of social interaction and conflict management are relatively complex and are
highly coupled. When conducting these tasks, people do not have precise predictions on the effects of their
decisions. Then, in collaborative design, it is impossible to totally remove the interdependencies among the design
tasks (e.g. technical decisions, social interactions, conflict management). Therefore, Coordination among design
tasks appears to be critical to support successful design process.
E1 E3T1
T2E2 E4
E5T3
E2
N
E1 E3T1 E5T3
T1
T2 E4
T3
S1:
S2:
N1
N2
T4
T5
E6
E6
E6
T5
T4
S1 S1,S2 S1,S2S1 S1,S2
S2 S2S2
S1
S1,S2
S2
Figure 3 Representation of task decomposition in design process
In our design process representation model, task decomposition could be explicitly depicted. As shown in Figure
3, a CDPN (e.g. 21 || NNN = ) can be viewed as an integration of several sub-processes (e.g. 1N , 2N ) and be
carefully decomposed to sub-nets. Each sub-net has only individual stakeholder associated. The inter-dependencies
among stakeholders’ local processes are represented by either task sharing or event sharing. After decomposition,
each stakeholder deals with a smaller network graph, which is much simpler for analysis. That could be easily
confirmed by comparing the dimensions of incidence matrix of original net ( 56× ) and decomposed nets
( 34 × , 43× ). Moreover, by looking at decomposed CDPNs, one can conveniently identify the synchronization
and priority relationship among individual tasks. Therefore CDPN have the ability to clearly represent the
decomposition or modularization of a complex process.
3.4 Process planning and scheduling
Design process planning is particularly critical to design collaboration, since the assignment and arrangement of
design tasks will affect the quality of product and the cost of design process itself. Various approaches are provided
to address the design process planing issues. They generate the design plan based on norm, by separating product
parts, by identification of critical tasks, or by noticing information dependencies. One of the popular approaches
adopted in engineering project management is using product working-structure as the base to decompose the task
and organize the design process. However, at the conceptual design stage, this product driven planing is not
sufficient. Its applicability is limited since product features are in fact defined and changed during design by group
decision making. One could hardly work on a component of product without interaction with others. The evolving
perspectives of the stakeholders will always require the adaptation of product and design process.
Planing
Scheduling
Execution
CoordinationInterfaces
Perspective Realization
Dependency Realization
Perspective Reconciliation
Perspective Evolving
Figure 4 Design plan, schedule and execution
One of the essential objectives of design planing should be realization of stakeholders’ perspectives (i.e. their
purpose, context, and content during the design process). Especially when the stakeholders are not familiar with
each other at the beginning of design, to realize the roles of “who” in design process is an indispensable step in
design planing. Then the way in which perspective evolution affect the product specification process can be
determined. After the realization of design perspectives, refining the design methodologies applied and evaluating
resources consumption become possible. Besides plan, short-term schedule is also necessary. It is different from
design plan since it specifically focuses on the dependencies among systems. In the CDPN graph, design schedule
can be represent by interconnected Petri Nets with coordination explicitly expressed. Information dependencies are
implied in the task and event linkages. During the execution of design process, individual stakeholders face more
granular process networks, which are built based on the design schedules. Discovery of conflicts and failures of the
previous design process reveals the deficiencies of the design plan and schedule. According to the feedback from
design task execution, the design plan and schedule for next period are recomputed and applied. Design process
continues in this “rolling-horizon” manner until the end.
Therefore, collaborative design process may be represented in three levels with different considerations (i.e.
Planning, Scheduling, and Execution). Design perspectives should be serious considered in each level (as shown in
Figure 4). Since we view collaborative design process as a perspective evolution process, a coordination interface to
clearly capture and support perspective reconciliation is vital to design process management. In the following
section, we introduce a conflict management methodology to realize perspective reconciliation in design process.
4 Managing Design Conflict by a Socio-technical Approach
Conflict can be treated as a significant issue to identify perspective dependencies, drive idea interaction and
therefore to improve design process. Traditionally, quite a few approaches are proposed to handle conflicts in design
by modeling conflict as the multi-objective decision problem (Kraus et al., 1995; Kannapan & Taylor, 1994; Lewis
& Mistree, 1997; Petrie et al., 1995). Most of them assume design stakeholders are purely reasonable and their
preferences can be represented by utility functions. However, utility theory has intrinsic limitations on conflict
management and collaboration support (Binmore, 1987). The critical reason is that in collaborative design, the
meanings and concepts are defined during the interaction rather than before the interaction. Many conflicts are
actually caused by the not-shared concepts in different perspectives. Only after the meanings are defined and shared
among the stakeholders, utility theory can take effect to handle conflict. To address this issue, we take a Socio-
technical approach to manage conflict by manipulating design perspectives.
4.1 Overview of methodology
Design conflict as a dynamic situation has its causes, contexts and effects (Wall & Calister, 1995), which could
be of technical nature, managerial nature or social-interaction nature. Conflicts of various types at different
abstraction levels might occur when inconsistent local realities (i.e. individual meanings) are merging to a shared
reality. To achieve a satisfying performance of the design team, conflicts should be effectively managed by
investigating, understanding, and manipulating the perspectives of stakeholders. When treating engineering design
as a purely technical process, conflicts are usually regarded as being abnormal and to be avoided as soon as possible
at all costs (Kannapan & Taylor, 1994; Klein, 1995; Peña-Mora et al., 1995). On the other hand, when treating
engineering design as a socio-technical process, conflicts might be systematically and explicitly dealt with as a
resource to drive the social construction process and design innovations. By realizing this, we take a more
comprehensive approach to manage collaborative design conflicts. In the early design stage, conflicts might be
treated as a motivation to identify the deficiency of the team and to generate new ideas, while at the late stage
conflicts should be prevented or resolved to achieve high efficiency.
A categorization of the different conflicts is derived from the Socio-Technical framework. Its aim is to find
mappings between the different types of conflicts in design, and conflict management strategies that have been
developed in the social, political and organizational management literatures. It should be emphasized that conflict
management may involve not just the detection, prevention and resolution/extinction of conflict, but also the
encouragement and control of conflicts in a desired manner. Of great significance is the development of tools to
measure and monitor the ‘rate’ at which conflict resolution occurs so that confluence of viewpoints in the socio-
technical construction process can be achieved. Consequently, to manage conflict, we need first to identify the roles
of the stakeholder and understand their perspectives. Then the conflict could be diagnosed and its causes and context
will be identified. By applying the intervention methods and adjusting stakeholders’ perspectives based on the
analysis, the conflict process is controlled.
Task Execution
Analyze Create/Change PSD
4
Manipulate PSDs and CDPN
Planning and Scheduling
Collaborative DesignProcess Net Diagram
Perspective State Diagram
Generate CDPN3 2
1
Conflict Management Strategies
Figure 5 Methodology of design process and conflict analysis
As showed in Figure 5, the methodology of conflict management in design process can be viewed as a
coordination interface between design plan and task execution. It has four basic steps:
1. Analyze the design plan and schedule;
2. Generate the collaborative design process net diagram (CDPN);
3. Create Perspective State Diagrams (PSD) for each of the stakeholders;
4. Manipulate PSD and CDPN.
In the following sections, the detail of each step will be discussed by illustrating an architecture design scenario.
4.2 Collaborative design process representation
Design process graphs can be generated from a preliminary design plan or design record, which can be simple
descriptive words or PERT diagrams. At the beginning of design, a plan could be very informal and may omit many
real-world necessary activities. Additional work has to be conducted to transfer the informal description to
structured forms. Consulting to the design group about detail information is sometime necessary to clarify important
issues.
S1:
S6:
S2:
S3:
S4:
S5:
S7:
E2 E5
E4
E6 E7 E8 E9T2 T7T 6T5 T8 E10T9
E13 T10
E14 T11 E16
T6 E8 T8 E10 T11 E16
E1 E3T1
T3
T4
E12 E15T10
E15
E11
Conceptual design Embodiment design
T12
Figure 6 CDPN of the design example
In the architecture design scenario, there are seven types of stakeholder considered in building design: Sponsor,
Client, Design Consultant, Architect, Engineering consultants, Building authority, and Building Users. They have
various perspectives and play various roles in the design process. Their perceptions of design tasks and events are
intensively different at the beginning of design. Figure 6 shows the CDPN graph covering the schedule of
preliminary design and early part of conceptual design. To make the stakeholder more explicit, tasks and events are
arranged in rows with each stakeholder assigned. Shared tasks and events are shown in all of related stakeholders’
rows and indicated by dot line linkages. It is clear that stakeholder S2 and S3 conduct most of the preliminary design
tasks, while others’ roles are to provide related information for their decision making. The incidence matrix, task
dependencies matrix and task assignment matrix are generated from above CDPN.
−−−−
−−−
−−
−−−
−−
−−
−−
=
110100000000101100000000
010100000000001100000000001100000000000100000000000110001000000011000000000001110000000000110000000000010100000000001010000000000111000000000001000000000010000000000001
U
T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12E1
E2
E3
E4
E5
E6
E7
E8
E9
E10
E11
E12
E13
E14
E15
E16
A loop dependency squarehas the format of:
1 ….-1: :-1…..1
Figure 7 Identification of design iteration of design process in incidence matrix
In the CDPN, design tasks iterations are depicted as a circular linkage from choice event to previous tasks. In
practice, design iteration might also imply occur of conflicts. If the opportunity of conflicts has been considered
during the scheduling, possible process iteration should be explicitly expressed in the graph. Task dependencies and
iterations are represented more obviously in the incidence matrix. As shown in Figure 7, design iteration could
happen if a loop dependency square exists in the incidence matrix among two tasks. Three iterations are easily
identified by finding loop dependency squares. The critical choice events in design process can be detected after
identification of design iteration. These events are viewed as the key nodes within the process graph.
4.3 Perspective state tracking
Due to the differences of the roles, experiences, and backgrounds, stakeholders’ perceptions of the design
campaign have various attributes. Their views of the product, the design organization and other stakeholders are
neither uniform nor static. To analyze the design perspectives of the stakeholders and the evolution of the
perspectives, we applied a systematic approach to capture the purposes, contexts and contents of the different
stakeholders. Purpose is the stakeholders’ goal or concern toward the objects in design campaign. Content is the
contained information of the perspective, which generates messages to be communicated. Context places the
information within the overall product lifecycle context. The principle objective of design perspective tracking is the
recognition of the stakeholder perspectives and the identification of the means by which they transfer the content of
these perspectives (i.e., "communicate") among themselves. Deign perspectives can be represented by a structured
format. For example, the Design Consultant has a perspective of forecasting facility usage requirement, which can
be described as follows:
Object: Product :: Functional Requirement :: Facility usage requirement
Purpose: Project the usage schedule, demand, and use of the facility by the USAR units based on historical data and usage estimations of the units using the facility.
Content: • Historical personnel load and mission data • Analysis procedures and parameters • Forecasts
Context: • Lifecycle: requirements analysis • Information type: requirements data (demand forecast data), historical usage data
Table 1 A perspective representation example
Our approach organizes and presents stakeholders’ perspectives in collaborative design by using “perspective
state diagrams”. A Perspective State Diagram (PSD) represents the “view” of a stakeholder in a particular time of
collaborative design and can be visualized as a picture of the perspective status of one stakeholder. As shown in
Figure 8, perceptions of a stakeholder to the key elements (i.e. product, technical decisions, organizations, social
interactions, etc.) of collaborative design are represented by filling the boxes of the elements in the DPM
architecture. In the collaborative design process, each stakeholder has serial state diagrams, which describe the
adjusting and evolution of their perspectives. At any given time in design process, a state diagrams for each
stakeholder can be depicted. However, due to the limitation of the information that can be derived, sometime it is
difficult to “fill in” certain boxes for less-familiar stakeholders. In the example, most of the boxes of the PSD of the
design sponsor were left empty since they normally do not notice details about the building. The loss of
understanding of the perspectives of the stakeholder might mean some coordination problems among the design
stakeholders. It is necessary for the design management system to search more information to fill in these boxes and
achieve further understanding to stakeholders’ perspective.
Detection
Resolution
Intervention
Causes Effects Context
Perspective
Purpose Context Content
Technical Role
Social Role
KnowledgeRepresentation
Information sharing
Function Structure Behavior Norm/Culture Procedure Form
Meaning will be definedConsist of Inter-link
mutual influence mutual influence
responsible for
Mut
ual i
nflu
ence
manage
participate
play play
design
represent
has view ofdrive/change within/
generate Organization IntegratedProduct Model
TechnicalDecisions
SocialInteraction
Stakeholder
Conflict
ConflictManagement
Outlook;Building Structure;
Safety;Reliability;
Satisfy the Cost, Time and quality
constraints;Coordinate with the consultant
engineers;
Size and layout of spaces;
Construction material;
Location, site area;
Preliminary design;Detail design;
Space allocation methods;
Construction process;
Architecture technique;
Past experience with USAR;
Architecture designregulations;
Relationships within the design
tem.
Project scheduling;Task dependence;
Administration regulation;
Architect as the project manager;
Principle difference;Objective difference;
Communicationmistake;
Resource limitation;
Understanding of the product and process;
Rework and delay;Organization
structure change;
Concepts clarification;
Understanding improvement;
Monitor;Control;
Negotiation;
Meet authority, client; consultant;Negotiation with
them;
Personal conflict;Group conflict;Organization
conflict;
Review design;Enlist consultant;
Detail space layout;Integrate work
Develop drawing;Generate
architecture doc.
Provide service to USAR;
CAD drawing;Design Manual;
Knowledge system.
Architect
Conceptual design
Figure 8 A perspective state diagram in conceptual design stage
When looking through the boxes of different stakeholders’ PSDs, related issues and inconsistencies can be
noticed. The related issues of perspectives reveal the dependencies and links of the local realities of the stakeholders,
while their inconsistencies imply conflicts. The dependencies can be used as anchor points to integrate the individual
perspective models and forming a larger meaning community. The conflicts can be managed to reconcile the design
perspectives. For example, one of the purposes in the “Function” box of the design consultant is “to satisfy the
personal load requirements”, while the one belonging to building authority is “to provide public service under
environmental rules”. Their differences may become the source of conflicts in future design decision making. To
notice this type of difference at the early design stage will improve the coordination among stakeholders. By
tracking perspective evolution, our approach provides a systematic and operational way to analyze the design
process by identifying the dependencies and conflicts.
4.4 Manipulating design process and perspectives
After the Perspective State Diagrams (PSDs) and the Design Process Graphs (CDPNs) are derived, one can
analyze and manipulate them to support perspective evolving and manage design conflict. At least, two operations
can be performed. The first is to examine the perspective state diagrams between/through adjacent points in time and
identify/reconcile conflicts in perspectives. The second is to iterate between step 2 and 3 to achieve the desired
effect (i.e., the desired conflict rate profile) by rearranging the design process to reconcile the contents of the
perspectives. While the design process is handled to control the conflict manner by applying these two approaches,
the efficiency of human design is improved by providing support to their negotiation.
As mentioned in the previous sections, at certain design stage, conflict can be detected by tracking and
comparing the “perspective states” of different stakeholders. If design perspectives are not tracked, due to the loss of
coordination, the chances of noticing difference and dependence are relatively low. Then, some design deficiencies
are not noticed until conflicts occur. For example, if tasks are executed according to the old schedule shown in
Figure 6 and design perspectives are not tracked, architect (i.e.S1) and design consultant (i.e. S2) might realize a
fatal conflict on the location selection after they discuss detail features of the building (after Task 9 in the schedule).
Since considerable jobs have already begun, that conflict will cause a lot of rework and waste time and money. As
shown in Figure 9, if perspectives are tracked and the PSDs of the design consultant and architect are depicted, an
inconsistency can be noticed by comparing the contents of the PSD elements for each stakeholder. Although there is
still no direct meeting between the stakeholders, a potential conflict on building location selection is identified much
earlier.
Gather client space usage information;
Space allocation requirement analysis;
Gather client space usage information;
Space allocation requirement analysis;
Technical Decision
Personnel schedule;Personnel loads;
Space usage;Building location;
Personnel schedule;Personnel loads;Space usage;
Building location;
Product
Space allocation;Space usage;
Building environment;Building regulation;
Building shape, material..
Space allocation;Space usage;
Building environment;Building regulation;
Building shape, material..
Technical Decision
Waiting for the layout from the design consultant
Waiting for the layout from the design consultant
Product
Report to owner;View clients as information
source;
Report to owner;View clients as information
source;
Organization
The role is not well defined yet The role is not well defined yet
Organization
Building location is chosen by users.
User prefer location A;
Building should not bevery near to road
intersection.Building location not
available
Design Consultant
Architect
Building space usage not available
Space usage;Personnel schedule;
Functionality;Looking;
Space usage;Personnel schedule;
Functionality;Looking;
Product
ClientOrganization
Matrix structure organization. Matrix structure organization.
location A is near road;location B is far from road;Only A and B and C are
feasible
Dependency noticed Inconsistency noticed
Figure 9 Comparing perspectives of three stakeholders
In this methodology, the formal algorithm of conflict detection is defined as:
ConflictManagement:: Detection(PSD_VariableA, PSD_VariableB, time) {
if (PSD_VariableA.type = PSD_Variable B. type) AND ( PSD_VariableA.value <> PSD_VariableB.value) Then (New Conflict) Else if (PSD_KnowledgeA RELATES PSD_VariableB) AND (PSD_KnowledgeA NOTsupport PSD_VariableB) Then (New Conflict) Else (No conflict detected) ….
}
Arranging the design process to a desired manner becomes an effective approach to coordinate the perspectives
of the stakeholders. The objective is to manipulate the PSDs as a way to converge them faster and therefore to
resolve conflict. The patterns of PSDs will largely depend on the interactions among the design tasks. For exa mple,
a new schedule can be proposed to let architect involve into the design campaign earlier so that he can identify the
key issues in layout design. After analyzing the task assignment matrix and task dependency matrix, a new task T8.1
is added to let the architect join the design and declare his concerns. Thus, the location decision conflict will be
prevented. A comparison of the old and new design process is showed in Figure 10. It is obvious the design
iterations are reduced while concurrency of process is increased.
DesignConsultant
Architect
Client
E8 E9T7 T8 E10T9
E13 T10
E14 T11 E16
E12 E15T10
E15
E11
T12
T8:Analyze personalloads
T9:Create layout T10:Review layout
T7:Create usage schedule
E8 E9T7 T8 E10T9
E13 T10
E14 T11 E16
E12 E15T10
E15
E11
T12
T8.1:Identify features related to layout
T9:Create layout T10:Review layout
DesignConsultant
Architect
Client
E9.1 T8.1 E9.2
Original Process
Revised Process
Figure 10 Rearrange design process to manage conflict
5 Information System to Support Collaborative Design
Several critical issues that arise in developing collaborative design support systems can be identified based on
the above discussion. First, it is necessary to have a system that can explicitly capture the perspectives of the
stakeholders and assist their interactions. For different stakeholders, the representation of their views of product and
organizations should capture individual attributes. Stakeholders’ goals, contexts and contents should be modeled in
the system in a structured way and be communicable to other stakeholders. Secondly, it is important for the system
to trace the merging of perspectives in the design process. Furthermore, by referencing to system knowledge base, it
might be able to evaluate the potential consequences of stakeholders’ decisions to collaborative design. Besides, it is
also critical to support design conflict management by facilitating both technical and social negotiations.
StakeholderStakeholder
Process dataProcess data Product dataProduct data Knowledge Repository
Knowledge Repository Organization dataOrganization data
Network Connection (www, TCP/IP, XML..)
Java/XML/HTML
SQL/AccessST/DPMS Infrastructure
Java application
Perspective Management
Conflict Management
Process Management
OrganizationManagement
Product Management
StakeholderStakeholder StakeholderStakeholder StakeholderStakeholder
Figure 11 STDPM system structure
The Socio-Technical Design Process Management (ST-DPM) system is a prototype implementation of the
methodology of manipulation of collaborative design process and conflict. It is quite different from the traditional
proposed information systems, which manage conflict by using exception handling approach (Klein, 1995) or by
eliminating data inconsistencies (Srirm et al., 1992). The objective of STDPMS is to provide a computerized
environment that supports the socio-technical coordination among stakeholders during conceptual design. The
system structure is shown in Figure 11. During design process, stakeholders’ perspectives are modeled in the system
and their various roles are depicted. Communication tools with network and server-client database access functions
enlighten the stakeholders located in different place to notify his and others’ perspectives. Several subsystems (e.g.
Conflict management, Process Management, Product Management, and Organization management) are provided to
support design interaction and manage design information. The system knowledge repository tracks the evolutions
of product and organization data. These changes will become feedback to the perspective models of the stakeholders
and influence the design process in the future.
ST-DPMS has several unique characteristics. First, the integrated product model is built on the information
structures represented by the perspective models of the stakeholders. To explicitly capture the perspectives of the
stakeholders and assist their interactions, interfaces with different contents are provided. The login window
explicitly shows the PSD framework by referencing the Socio-Technical architecture (Figure 12). Individual
perspective interfaces are used as views of the integrated product model. They capture and provide related design
information during the design process. Design stakeholders are dealing with the information they care about with
individual interfaces. It is the system’s responsibility to maintain the dependencies and detect the conflicts among
the information from individuals. Second, ST-DPMS can help the group to refine the design process by referring to
the conflict management strategies. As shown in Figure 13, information of design tasks and the state of design
process are explicitly shown to the individual stakeholders. The conflict management model analyzes the causes,
effects and contexts of detected conflicts. Then the strategies (e.g. remove task dependencies, add new task,
rearrange schedule, etc.) are applied to manipulate the design tasks and control the conflicts. The interactions of
perspectives supported by the system force the stakeholders to notify the effects of their own decisions to the others
and the group. The design issues identified by the system are discussed in the design team and the conclusions could
be achieved. Third, ST-DPMS will record and trace the merging of perspectives in the design process. As shown in
Figure 13, after conflict is detected, the history of interaction and conflict inconsistency ratio is displayed. When
Figure 12 Interfaces provided to stakeholders
design issues and solutions are proposed during the design activities, the new concepts and ideas are captured by the
system. Consensus is treated as a common knowledge and stored in the system, which could be retrieved. That will
become very helpful to the future design. Fourth, when it is fully developed, the system can support the learning of
the rationale of the technical design decisions and conflict resolutions during the design process, like some proposed
systems such as iDCSS (Klein, 1995), and SHRAE-DRIM (Peña-Mora, 1995). The dynamic perspective mo dels are
supposed to capture the stakeholders’ local realities, their evolutions in design process can be also captured and
proposed to the team. That means the system is not only able to learn the design expertise and the design rationale,
but also can improve designers’ recognition and the organization structure, norm and culture.
Figure 13 Process view and conflict view in STDPM
6 Conclusions
This paper presents an original methodology for generic collaborative design process representation and conflicts
analysis with the belief that collaborative design process is not only a technical decision making process conducted
by a group of expertise, but a socio-technical interaction process among all of the stakeholders.
By using Petri Nets as convenient tools for topological and computational process illustration, a systematic
representation method of collaborative design process is developed. Several essential issues in collaborative design,
such as design state transformation, task dependencies, and task decomposition, can be clearly expressed by
applying the techniques of process modeling. This representation method provides the basics for collaborative
design process and conflict analysis. By investigating the relationship between perspective evolution and structure of
design process, conflicts can be effectively detected and analyzed. Managing design conflict becomes a coordination
infrastructure among design stakeholders to support the refinement of design process. By using conflict management
to identify the deficiencies of design process, this methodology realizes a feedback control mechanism to manipulate
collaborative design process, while the traditional approaches view it as an open loop system. The methodology also
provides a framework for information system development for collaborative design support. The aim of ST-DPMS
is to provide not only the design process management facility but also an integrated information support system for
collaborative design by capturing the perspective views of the stakeholders and handling the conflicts. Following
this direction, a series of design process management methodologies can be derived and implemented.
Our future research work will further refine the collaborative design process mo del by applying the advanced
analysis techniques of Petri Nets. Also, we hope to gain deep understanding of social interactions and their relations
to technical decisions occurred in more real-life collaborative design cases. Based on the further understanding of
the characteristics of design perspective interaction, the collaborative design process model and the design support
system can be improved significantly.
Acknowledgements Partially funding of this research was provided by the Construction Engineering Research Laboratories of the U. S.
Army, Corps of Engineers. We thank Mr. Eric Griffth and Dr. Mike Case for their continuous support. We are also
grateful for the help from Dr. F. Udwadia and Mr. W. Burkett, who have given us a lot of incentives to write this
paper.
References
1. Adler, P., & Mandelbaum, A.(1995). From Project to Process Management: An Empirically-Based Framework for Analyzing Product Development Time, Management Science, Vol. 41, No. 3, pp. 458-484.
2. Berger, P. & Luckman, T. (1966). The Social Construction of Reality A Treatise in the Sociology of Knowledge. Doubleday, New York, 1966.
3. Binmore, K. G. (1987). Why Game Theory “doesn’t work”?, Analyzing Conflict and Its Resolutions : Some Mathematical Contributions, P.G. Bennett.
4. Bras, B. A. & Mistree, F. (1991). Designing Design Process in Decision-Based Concurrent Engineering, SAE Transactions Journal of Materials &Manufacturing, Vol. 100, pp. 451-458.
5. David, R. & Alla, H. (1992). Petri Nets and Grafcet, Prentice Hall. 6. Eppinger D. S. (1997). Generalized Models of Design Iteration Using Signal Flow Graphs, Research in Engineering
Design. Vol. 9, pp. 112-123. 7. Jenson K. (1996). Coloured Petri Nets: Basic Concepts, Analysis Methods and Practical Use, Volume 1, Springer. 8. Jin Y., & Lu, S. C-Y. (1998). Toward a Better Understanding of Engineering Design Models, Proceedings of
Universal Design Theory Workshop, May 12-13. 9. Hauser, J. R. & Clausing, D.(1988). The House of Quality, Harvard Business Review, 63-73, May-June. 10. Kraus, S., Wilkenfeld, J., & Zlotkin, G.(1995). Multiagent Negotiation under Time Constraints, Artificial
Intelligence, Vol. 75, pp. 297-345. 11. Kannapan, S., & Taylor, D. (1994). The Interplay of Context, Process, and Conflict in Concurrent Engineering,
Journal of Concurrent Engineering Research and Applications, Vol. 2, pp. 183-196. 12. Klein, M. (1995). Conflict Management as a Part of an Integrated Exception Handing Approach, AIEDAM, Vol. 9,
pp. 259-267. 13. Krishnamurthy, K., & Law, H. K. (1997). A Data Management Model for Collaborative Design in a CAD
Environment, Engineering with Computers, Vol. 13, pp. 65-86, 1997. 14. Krishnan V. (1997) A Model-Based Framework to Overlap Product Development Activities, Management Science,
Vol.43, No. 4. 15. Lewis, K., & Mistree, F. (1997). Collaborative, Sequential and Isolated Decisions in Design. Proceedings of
DETC’97. 16. Lu, S. C-Y., Udwadia, F., Burkett, W., Cai, J. (1998) . Conflict Management in Collaborative Engineering Design
IMPACT Lab Technical Report. 17. Lu, S. C-Y, & Cai, J. (1999). Modeling Collaborative Design Process with a Socio-Technical Framework, Proceedings of 6th ISPE International Conference on Concurrent Engineering, Bath, United Kingdom, 1999.
18. Majumder D., Rangan, M. R., & Fulton, E. R. (1994). Information Management for Integrated Design Environments, Engineering with Computers, Vol. 11, pp. 227-245.
19. Paul, G. & Beitz, W. (1996). Engineering Design- A Systematic Approach, Second Edition, Springer, London. 20. Peña-Mora, F., Sriram, R.& Logcher, R.. (1995).Conflict Mitigation System for Collaborative Engineering,
AIEDAM, Vol.9, pp.101-124. 21. Petrie, C. J., et al. (1995). Using Pareto Optimality to Coordinate Distributed Agents, AIEDAM, Vol 9, pp269-281. 22. Sanvido, V. E., Norton, K. J., (1994). Integrated Design-Process Model, Journal of Management in Engineering,
Vol. 10, No. 5,pp. 55-62. 23. Simon, H. A., (1996). The Sciences of the artificial, Third Edition, MIT Press, Massachusetts. 24. Smith, P. R. & Eppinger, D. S. (1997). Identifying Controlling Features of Engineering Design Iteration,
Management Science, Vol. 43, No. 3. 25. Sowa,J.F. & Zachman, J. A. (1992). Extending and Formalizing the Framework for Information Systems
Architecture, IBM System Journal, Vol. 31,No 3. 26. Sriram, D., Ahmed, S. & Logcher, R. (1992). A Transaction Management Framework for Collaborative
Engineering, Engineering with Computers, Vol. 8, pp. 213-232. 27. Suh, N.P., (1990). The Principle of Design, Oxford Universtiy Press, Oxford. 28. Wall, J. A. & Calister, R. R. (1995). Conflict and Its Management, Journal of Management, Vol. 21, No.2, pp.
515-558. 29. Yoshikawa, H. (1981). General Design Theory and a CAD System, In Man-Machine Communication in
CAD/CAM, T. Sata, E. Warman. IFIP.