University of Southern California Dissertations and Theses

A socio-technical approach to support collaborative engineering design

(USC Thesis Other)

A socio-technical approach to support collaborative engineering design

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content INFORMATION TO USERS This manuscript has been reproduced from the microfilm master. UMI films the text directly from the original or copy submitted. Thus, some thesis and dissertation copies are in typewriter face, while others may be from any type of computer printer. The quality of this reproduction is dependent upon the quality of th e copy submitted. Broken or indistinct print, colored or poor quality illustrations and photographs, print bleedthrough, substandard margins, and improper alignment can adversely affect reproduction. In the unlikely event that the author did not send UM I a complete manuscript and there are missing pages, these w ill be noted. Also, if unauthorized copyright material had to be removed, a note w ill indicate the deletion. Oversize materials (e.g., maps, drawings, charts) are reproduced by sectioning the original, beginning at the upper left-hand comer and continuing from left to right in equal sections with small overlaps. ProQuest Information and Learning 300 North Zeeb Road, Ann Arbor, M l 48106-1346 USA 800-521-0600 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. R eproduced with perm ission of the copyright owner. Further reproduction prohibited without perm ission. A SOCIO-TECHNICAL APPROACH TO SUPPORT COLLABORATIVE ENGINEERING DESIGN by Jian Cai A Dissertation Presented to the FACULTY OF THE GRADUATE SCHOOL UNIVERSITY OF SOUTHEN CALIFORNIA In Partial Fulfillment of the Requirements for the Degree DOCTOR OF PHILOSOPHY (MECHANICAL ENGINEERING) May 2002 Copyright 2002 Jian Cai Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. UMI Number: 3073755 __® UMI UMI Microform 3073755 Copyright 2003 by ProQuest Information and Learning Company. All rights reserved. This microform edition is protected against unauthorized copying under Title 17, United States Code. ProQuest Information and Learning Company 300 North Zeeb Road P.O. Box 1346 Ann Arbor, Ml 48106-1346 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. UNIVERSITY OF SOUTHERN CALIFORNIA The Graduate School University Park LOS ANGELES, CALIFORNIA 90089-1695 This dissertation, w ritten b y Jian Cai Under th e direction o f h..Jk § . D issertation Committee, and approved b y a ll its members, has been presen ted to and accepted b y The Graduate School, in partial fulfillm ent o f requirements fo r th e degree o f DOCTOR OF PHILOSOPHY .May—1H.»—-20.02 DISSERTATION COMMITTEE Chai rperson Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Dedication To My Parents Yongliang Cai and Qiaoyun Qin, and My Wife Yan Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Acknowledgements My first, and most earnest, acknowledgment must go to my advisor and chair of my Ph.D. committee Dr. Stephen C-Y. Lu. I joined University of Southern California graduate school and started my research work at the IMPACT lab nearly four and half years ago. I still remember clearly the advisements he gave me when I first met him in USC. Since that, Dr. Lu has been very helpful in ensuring my academic, professional, financial, and moral well being ever since. Many thanks also to committee members Dr. Yan Jin, Dr. Firdaus Udwadia, Dr. Stan Settles, and Dr. Geoffrey Shiflett. Far too many people to mention individually have assisted in so many ways during my work at USC. They all have my sincere gratitude. In particular, I would like to thank Du Li, Ping Ge, Kai-Lu Wang, Mohammad Danesh, Weihua Zhou, Li Zhao. Nan Jing, and other colleagues at USC. I also want to thank Dr. Michael Case and Dr. Francois Grobler from U.S. Army Corp of Engineers. They provided a lot of supports to the research projects I was working on. I am also indebted to the department of aerospace and mechanical engineering and the graduate school of USC. The deepest thanks go to my wonderful parents, who cultivate and educate me with their endless love. My final, and most heartfelt, acknowledgment must go to my lovely wife Yan. Her support, encouragement, and companionship have turned my study and research journey into a pleasure. in Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Table of Contents DEDICATION.................................................................................................................ii ACKNOWLEDGEMENTS...........................................................................................iii LIST OF FIGURES......................................................................................................viii ABSTRACT..................................................................................................................... x 1 INTRODUCTION................................................................................................... 1 1.1 THE PROBLEM AND MOTIVATION........................................................................................ 1 l .2 K e y R e s e a r c h Is s u e s ............................................................................................................ 2 1.3 A S o c io -T e c h n ic a l A p p r o a c h t o S u p p o r t C o l l a b o r a t iv e En g in e e r in g D e s i g n ........................................................................................................................................3 1.4 T h e s is O r g a n iz a t io n ............................................................................................................ 3 2 THE FUNDAMENTAL PROBLEMS...................................................................4 2.1 RECOGNIZING THE SOCIAL ASPECT OF COLLABORATIVE D ESIG N ........................4 2 .2 C o o r d in a t io n w it h S it u a t io n R e a l iz a t io n ...........................................................5 2.3 B u il d in g F e a s ib l e C o m p u t a t io n a l D e s ig n P r o c e s s M o d e l ........................ 6 2 .4 D e v e l o p in g A G e n e r a l a n d E x p a n d a b l e T a x o n o m y f o r D e s ig n C o n f l ic t s ............................................................................................................................................................6 2.5 S y s t e m a t ic a l l y S u p p o r t in g C o n f l ic t M a n a g e m e n t .......................................7 2.6 E v o l u t io n a r y C o l l a b o r a t iv e En g in e e r in g In f o r m a t io n S y s t e m 8 3 BACKGROUND REVIEW..................................................................................10 iv Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 3 . 1 O v e r v ie w o f E x is t in g A p p r o a c h e s ............................................................................ 10 3 .2 D e s ig n T h e o r ie s a n d M e t h o d o l o g ie s ...................................................................... 10 3.2.1 Procedure view.............................................................................................11 3.2.2 Decision view...............................................................................................13 3.2.3 Knowledge view............................................................................................18 3.3 DESIGN PROCESS MODELING................................................................................................19 3 .4 C o n f l ic t M a n a g e m e n t ..................................................................................................... 20 3.4.1 Artificial Intelligence approach................................................................. 21 3.4.2 Economic/behavioral approach................................................................ 21 3.4.3 Explicit engineering design models......................... 22 3.4.4 Contributions and limitations o f the previous approaches......................23 3.5 Pr o d u c t D a t a M a n a g e m e n t ...........................................................................................24 3.6 D e s ig n Ra t i o n a l e ..................................................................................................................25 3 .7 T h e R e q u ir e m e n t s o f a N e w A p p r o a c h ....................................................................27 4 THE SOCIO-TECHNICAL APPROACH TO SUPPORT COLLABORATIVE ENGINEERING DESIGN.............................................................. 30 4.1 T h e o r e t ic a l B a c k g r o u n d ................................................................................................30 4 .2 C o l l a b o r a t iv e D e s ig n S u p p o r t A r c h it e c t u r e ..................................................36 4.3 M o d e l in g C o l l a b o r a t iv e D e s ig n P r o c e s s ........................................................... 38 4.3.1 Requirements to model collaborative design process.............................. 38 4.3.2 Collaborative process model definitions....................................................39 4.3.3 Building collaborative design process models.......................................... 48 4.3.4 Task Coordination....................................................................................... 52 4.3.5 Process Planning and Scheduling.............................................................. 53 v Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4.4 Sy s t e m a t ic P e r s p e c t iv e R e p r e s e n t a t io n a n d A n a l y s i s ........................... 55 4.4.1 Concept structure hierarchy...................................................................... 55 4.4.2 Perspective state diagrams.........................................................................57 4.4.3 Perspective model Analysis........................................................................59 4.4.4 Perspective model Abstraction and Evolution..........................................65 4.5 T h e M e t h o d o l o g y t o S u p p o r t C o l l a b o r a t iv e En g in e e r in g D e s ig n 7 1 4.5.1 Overview o f the methodology..................................................................... 73 4.5.2 Development o f matrices from process......................................................74 4.5.3 Development matrices from perspective state diagrams ..................78 4.5.4 Conflict Detections...................................................................................... 78 4.5.5 Development o f control strategies......................................................... 82 4.6 In f o r m a t io n S y s t e m s t o a s s is t C o l l a b o r a t iv e D e s ig n In t e r a c t io n ... ..........................................................................................................................................................87 4.6.1 Realising perspective in information system............................................. 87 4.6.2 Building collaboration protocols............................................................... 89 4.6.3 XML in Web application architecture.................................................. 91 4.6.4 Applying MVC design pattern in XML-based process modeling..............94 4.6.5 Developing collaboration information infrastructures...........................107 4.7 A S c e n a r io .............................................................................................................................. 113 4.8 V a l id a t io n o f t h e T h e o r y a n d M e t h o d o l o g y ...............................................117 4.9 P r o t o t y p e Im p l e m e n t a t io n ......................................................................................... 118 4.9.1 System architecture....................................................................................119 4.9.2 Building design perspective model............................................................121 4.9.3 Constructing design process model...........................................................124 vi Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4.9.4 Supporting perspective, process, and conflict management....................125 4.9.5 Enabling business to business process integration................................128 5 IMPACTS OF RESEARCH.................................................................................130 6 CONCLUSION......................................................................................................131 7 FUTURE WORK.................................................................................................. 133 REFERENCES............................................................................................................ 134 APPENDICES..............................................................................................................141 APPENDIX A: A CPML Ex a m p l e ..................................................................................................141 vii Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. List of Figures F ig u r e 1 O v e r v ie w o f t h e e x is t in g r e s e a r c h a p p r o a c h e s ...................................................... 28 F ig u r e 2 D y n a m ic a l m o d e l s o f d e s ig n p e r s p e c t iv e s in c o l l a b o r a t iv e d e s i g n 33 F ig u r e 3 T h e S o c io -T e c h n ic a l d e s ig n s u p p o r t a r c h it e c t u r e ...............................................36 F ig u r e 4 A n e x a m p l e o f c o l l a b o r a t iv e d e s ig n p r o c e s s n e t .................................................41 F ig u r e 5 P r o c e s s p a t t e r n s : C o n c u r r e n c y a n d C h o i c e .............................................................46 F ig u r e 6 P r o c e s s l o g ic s it u a t io n s ......................................................................................................... 48 F ig u r e 7 D e s ig n p r o c e s s d e c o m p o s it io n ..............................................................................................50 F ig u r e 8 C o l l a b o r a t iv e d e s ig n p l a n , s c h e d u l e , a n d e x e c u t io n .......................................54 F ig u r e 9 A c o n c e p t s t r u c t u r e b u il t b y s t a k e h o l d e r s .............................................................55 F ig u r e 10 G e n e r a t e d e s ig n p e r s p e c t iv e m o d e l s b y c o n c e p t s t r u c t u r e ....................... 57 F ig u r e 11 T h e p e r s p e c t iv e m o d e l a n a l y s is f r a m e w o r k ........................................................... 60 F ig u r e 12 A p e r s p e c t iv e m o d e l n e t w o r k ........................................................................................... 62 F ig u r e 13 C l u s t e r in g a n a l y s is d e n d r o g r a m : n e a r e s t n e ig h b o r a l g o r it h m ............67 F ig u r e 14 C l u s t e r in g a n a l y s is d e n d r o g r a m : f u r t h e s t n e ig h b o r a l g o r i t h m .........68 F ig u r e 15 C l u s t e r in g a n a l y s is d e n d r o g r a m : a v e r a g e l in k a g e a l g o r i t h m .............69 F ig u r e 16 A m e t h o d o l o g y o f s u p p o r t in g c o l l a b o r a t iv e e n g in e e r in g d e s ig n ......... 71 F ig u r e 17 T h e S o c io -T e c h n ic a l a n a l y s is f r a m e w o r k o f t h e m e t h o d o l o g y .............74 F ig u r e 18 M a t r ic e s u s e d in P r o c e s s M a n a g e m e n t s o c io -t e c h n ic a l a n a l y s i s ......... 76 F ig u r e 19 A c o m p r e h e n s iv e S o c io -T e c h n ic a l a n a l y s is a p p r o a c h .................................... 84 F ig u r e 20 T h e r o l e s o f in f o r m a t io n s y s t e m s t o s u p p o r t c o l l a b o r a t iv e d e s ig n „ 8 8 F ig u r e 2 1 B u il d in g c o l l a b o r a t io n p r o t o c o l s o v e r t h e In t e r n e t ...................................90 F ig u r e 22 XML in d is t r ib u t e d w e b a p p l ic a t io n s ...........................................................................92 viii Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. F ig u r e 23 a p p l y in g MVC p a t t e r n in p r o c e s s m o d e l in g ...........................................................94 F ig u r e 24 T im e d e p e n d e n c ie s b e t w e e n t a s k a n d s t a t e s ......................................................... 100 F ig u r e 25 B a s ic c o l l a b o r a t iv e d e s ig n p r o c e s s m a n a g e m e n t ...........................................108 F ig u r e 26 P e r s p e c t iv e m o d e l in g a n d c o n f l ic t m a n a g e m e n t ..............................................110 F ig u r e 27 C o l l a b o r a t io n e n a b l e d b u s in e s s -t o - b u s in e s s s e r v ic e s .................................113 F ig u r e 28 D e t e c t in g c o n f l ic t f r o m P e r s p e c t iv e M o d e l St a t e D ia g r a m s ................. 1 14 F ig u r e 29 A d ju s t in g d e s ig n p r o c e s s t o m a n a g e c o n f l i c t .................................................... 117 F ig u r e 30 STARS s y s t e m a r c h it e c t u r e .............................................................................................120 F ig u r e 3 1 C o n c e p t s t r u c t u r e b u il d e r ............................................................................................... 123 F ig u r e 32 T h e p e r s p e c t iv e w in d o w c o l l e c t in g t h e p e r s p e c t iv e m o d e l s ....................123 F ig u r e 33 T h e p r o c e s s b u il d e r ................................................................................................................125 F ig u r e 34 T h e p r o c e s s m o d u l e d e t e c t s p r o b l e m a t ic t a s k ...................................................126 F i g u r e 35 P e r s p e c t i v e r e v i e w a n d c o n f l i c t r e p o r t i n t e r f a c e ..........................................127 F ig u r e 36 STARS s y s t e m s u s e SOAP w e b s e r v ic e s t o in t e g r a t e t h e p r o c e s s e s ... 129 ix Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Abstract Engineering design is essentially a technical activity to fulfill human purposes. Collaborative design is conducted by a group of people with different purposes, circumstances, and expertise. When stakeholders join the group and “co-construct” the design campaign, the collaborative design activity becomes a Socio-Technical process. Traditional design theories and methodologies ignore the social aspects o f collaborative design. They assume that stakeholders’ perspectives are relatively uniform and static during the design processes. However, in practice, the perspectives of stakeholders are adaptive to the design situations and evolve during their interactions with each other. This research develops a comprehensive approach to clarify the relationships among various technical and social factors in collaborative design. Furthermore, to successfully support collaborative design, it provides a methodology to facilitate design perspective reconciliation and conflict management during the design process. After the investigation of the fundamental characteristics of collaborative design, three critical issues are identified. They are design process, design conflict, and stakeholders’ perspectives. This research develops systematic methods to support design stakeholders’ interaction by analyzing the relationships among these issues. These methods build a new framework to represent, analyze, and control the design process, and to manage design conflicts. It takes the socio-technical standpoint toward collaborative design, which mainly considers the perspective differences among the stakeholders rather than only focusing on the data inconsistencies. The methodology provides three key functions: to identify the deficiencies of design process, to manage the conflict, and to improve the perspective reconciliation among the organization. This methodology eventually realizes a feedback x Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. control mechanism to manipulate the three critical issues in design, while most o f the exiting approaches view it as an open loop system. This research provides several contributions to the collaborative engineering design research fields. First, it reveals the fundamental characteristics of the socio-technical aspects of collaborative design. Second it constructs theoretical frameworks to illustrate the principles of conflict management and process improvement. Third, it develops a computational design process model, a perspective analysis model, a conflict management model, and information system architectures to support collaborative design. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 1 Introduction 1.1 The Problem and Motivation Design is one of the most challenging tasks in the engineering profession. Engineers create artifacts that must meet all physical, economical, and social requirements across the boundaries of the Science of Nature and the Science of Artificial [80]. To satisfy these requirements, engineers must collaborate closely with all the parties who share some direct and indirect interests throughout the life cycle of the design campaign. Therefore, the collaborative aspects of engineering design represent the most appealing subject of investigation within the general research areas o f design. When various persons from different disciplines work collaboratively over the distance and time boundary, the design process becomes very complicated since it involves numerous technical and social issues. Compared with individual design, collaborative engineering design has its intrinsic characteristics. The objectives of design are not uniform since various people join the design group and make decisions based on their own intentions. At the same time, the design knowledge is distributed in various individuals' minds and the information resources are dispersed in different sites. Accordingly, the design process is the integration o f many separated processes performed by different groups. These characteristics make the collaborative design more complex and difficult than individual design. In a design organization involving people with various backgrounds and expertise, each individual can only deal with a portion of the overall problem. Since the pace and scope of knowledge continue to expand, the amount of information communicated increases significantly. As collaborative design usually deals with large and complex systems, designers have to collect and interpret various design information by dealing with I Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. multitudinous product data. Then, two significant problems occur. One is the inefficiency of the management of the design process. The other is the occurrence of the conflicts generated when different individuals share the information [92]. Both can cause the delays in progress, the wastes of resources, or even the failure of the whole project. To enhance the productivity of collaborative design, it is critical to effectively manage the distributed knowledge, resources, and processes. We need to build a theoretical framework based upon the thorough understandings of the intricate relationships within collaborative design. By referencing such a framework, we can develop systematical methodologies to investigate and resolve the various problems occurred in the collaborative design. These methodologies can facilitate people to develop applicable information systems to support design collaboration. These are the focuses of this research work. 1.2 Key Research Issues To investigate the characteristics and relationships of collaborative design process and design conflict is the essential step to understand the conceptual nature of design knowledge, design environment, and design activity. It will provide a methodology to depict the dynamics of managing conflicts in design activities, and to reveal the intrinsic characteristics o f design coordination. It will emphasize the important issues for collaborative design support, such as situation-oriented coordination, adaptive process modeling, and systematic conflict management. Practically, by elaborating the methods to support collaborative design, it is possible to build computational models that can facilitate the representation and manipulation of complicated task interactions among design participants. Accordingly, design support systems, which take advantages of modem information technologies, can be built to assist the interactions and improve the quality of collaborative design. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 1.3 A Socio-Technical Approach to Support Collaborative Engineering Design The socio-technical design framework [55][56] explicitly depicts the fundamental issues and their relationships in collaborative design. This framework is based on the acceptance that collaborative engineering design is a human-based, interdisciplinary and socio-technical activity, and must be modeled as a co-construction process accordingly. Based on this theoretical framework, this research develops a socio-technical approach to support collaborative engineering design. 1.4 Thesis Organization This thesis first introduces the fundamental problems in collaboration engineering design. Then it reviews the existing approaches and discusses the requirements of developing a new approach to support collaborative engineering design. After that, in section 4, it describes the socio-technical methodology to support collaborative design and discusses in detail the process modeling, perspective analysis, and conflict management issues. It also introduces the information architecture and new communication protocols for building socio-technical collaboration system to assist process management and conflict management. A scenario and a prototype system are presented to demonstrate the application o f the methodology. After that, the validation o f the theories and methodologies are discussed. Section 5 points out the impacts of this research. At the end, Section 6 gives the conclusion and Section 7 discusses the future research work. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 2 The Fundamental Problems To support collaborative design, we have to deal with three complexities (i.e. the complexities of product, process, and organization). When people jointly design a large system with numerous components, to collect, record, and analyze the product data becomes a challenging problem. At the same time, the distribution of design processes creates obstacles for people to share the design information and coordinate their works. More importantly, when the design work is conducted by a group o f people with various interests and circumstances, the ways they interact with each other within the dynamic organization structures will influence the performance of the team and the quality o f the design. To effectively support collaborative design, we have to clarify these complexities and identify the key research issues. 2.1 Recognizing the Social Aspect of Collaborative Design The collaborative design process is essentially a knowledge integration process. When many heterogeneous groups work together on design projects over a long period of time, their knowledge toward the system, the product, and other people will keep on evolving [22] [66]. Design knowledge is more than ‘written scientific theories or the product documents [3]. The design professional expertise in particular is framed by a person's conceptualization of multiple, ongoing activities, which are essentially identifies, comprising intentions, norms, and choreographies [14] [24] [85]. The knowledge integration is a social construction process when different persons perform their tasks within various adaptive situations [7][16][17]. The situations will eventually impact the changing o f persons' roles. When stakeholders (i.e., all of the human participants who have influences toward the design process and the product features) play roles within a collaborative engineering design 4 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. process, special education or experience enable a stakeholder to make particular decisions or contributions to the process. Engineering design process models usually define roles within which stakeholders use or apply their technical expertise. However, even within well-defined technical roles, every stakeholder makes the role “his own” by adapting or executing the role based on his conceptions and circumstances. It is the social interaction that determines the variation or adaptability of these roles in a particular engineering design situation. As the roles evolving, the ways stakeholders participate design and their learning customs will vary, which will directly or indirectly affect stakeholders’ internal knowledge. Then, the deficiency in the social interactions among the group is one of the major sources o f design conflict. Hence, to understand the social aspects of design is critical for managing the design conflict and improving the quality of design tasks. It is necessary to have well-developed methodologies for describing and analyzing the social interactions in collaborative design activities. 2.2 Coordination with Situation Realization Understanding the nature o f collaborative design requires understanding the negotiation process among different stakeholders in the context of the emerging practice. In the design process, the communication breakdowns are often experienced because the designers belonging to different cultures use different norms, symbols, and representations [6]. To facilitate their coordination, the information requirements for each stakeholder must capture its domain expertise, as well as the particular viewpoints and perspectives toward the design problem and the community involved with the design campaign. Coordination in collaborative design has to be achieved by not only through sharing of product data, but also the realization o f the design situations of each other [40]. The design situation consists o f at 5 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. least two parts: the circumstances of decision maker and the stages of the design process. When people exchange the design information, they should understand under what circumstances this information is generated and in which situation it can be potentially used. Otherwise, it is difficult for them to interpret the purposes and implications of each other during the design coordination. Therefore, to represent and organize the situational knowledge is indispensable to support the coordination among different design groups. 2.3 Building Feasible Computational Design Process Model Due to the involvement of human being, design process is not only based on the nature law o f the artifact but also affected by people’s goals, skills, and circumstances. Within the collaborative design process, design information is driven by social, technological, scientific, and inter-disciplinary dependencies. The challenging problem is to build a computational process model, which can explicitly represent the attributes of the logics among design tasks and can reveal the complicated relationships among the dependencies. We must be sure that a collaborative design will not be too complex, and/or too detailed, to be modeled on computers by properly managing the “modeling granularity” o f a design process and its resulting conflicts. In order to build the feasible process model, we need methods to define and measure the complexity and abstraction of a group of design processes, and to assess the computability of the models. 2.4 Developing A General and Expandable Taxonomy for Design Conflicts Conflict is the situation in which beliefs, perspectives, and/or decisions of one or more stakeholders) become mutually incompatible with respect to the satisfaction o f some design requirements. Conflicts always occur in engineering design. Traditional approaches treat 6 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. conflicts as abnormalities in the process, and devote resources to eliminate them as much as possible. Conflicts will occur even more in collaborative design as the complexity o f the design process increases. It is necessary to clearly determine their roles in the design campaign. At different design stages, conflicts have different characteristics and should be treated differently. A major effort in the research is to investigate what constitutes a conflict and to understand some common features among these descriptions. Then, it proposes a logic structure for these descriptions to form a few generic groups so that conflict taxonomy can be developed. The taxonomy of design conflict should be general enough so that it can be applied to various design problems. On the other hand, it should be expandable to accompany new conflicts involved in the practical design process, since to foresee all types of conflicts before design is impossible. 2.5 Systematically Supporting Conflict Management Many methods and strategies have been developed to deal with different types of design conflicts. Each o f them is particularly useful in its special situation. We must clearly understand these conflict management (CM) strategies and the situations under which they will be effective. These characteristics will enable us to identify conflict management strategies, which are generic across a set o f design conflict situations. Then a logic category for these strategies can be developed. Managing conflicts is never a purely technical task. The same conflict can be resolved differently at different corporations due to their different cultures. Understanding o f engineering physics and corporate culture are both important to an efficient conflict management strategy. The question is how to capture those social aspects of the conflict management methods/strategies so that they can be used effectively in supporting collaborative design. Another important issue is how to provide not only the 7 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. strategies for people to resolve the conflict, but also the methods to guide them to explore new strategies. 2.6 Evolutionary Collaborative Engineering Information System Traditionally, an engineering information model, sometime called an integrated product model, is viewed as a static data storage system, which contains records of design decisions and plays a passive role during the design. In collaborative design, as the stakeholders’ involving, their requirements at hands generally determine the amount and the content of information to be shared. We should consider an engineering information model as a communication and coordination medium, rather than a data storage house, for stakeholders to share and discourse their viewpoints and decisions in collaborative design. It is impossible to completely define the features of this medium prior to use. At different stages of a design lifecycle, the types, amounts, and nature of information to be shared will be different. It is important that we study and correlate this different information sharing requirements with respect to different design lifecycle considerations. Such an understanding will enable us to develop information architectures, which are supportive of design tasks/activities at different stages of collaborative design. It will also enable the development of a consistent shared model that will meet all the Iife-cycle requirements in design. To achieve this, we should have systematic methods to represent/determine the information-sharing requirements before and during collaborative design. The ideal is to have an information system that can evaluate the information sharing characteristics for various design process models, and therefore to determine the information requirements of the design group. To accomplish this, the functions, architecture, and formats o f the information system must evolve during the design interaction process according to the 8 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. changing of the design situations. That will provide better usability for the design information systems. 9 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 3 Background Review 3.1 Overview of Existing Approaches Collaborative design activities are complicated and difficult to understand. There are many approaches dealing with different elements of engineering design from various perspectives [25][26]. Some from the engineering discipline focus on the systematic design process and investigate how the technical design decisions are made. Project and operational management approaches view design processes as workflows with task dependencies and information exchange. Computer science approaches (especially from the Data management domain) view design process as product data manipulation and storage. They build computer systems to aid design information management. The goals of these approaches are to solve the design problems from the technical viewpoints. Meanwhile, social sciences, such as sociology, organization theory, and social construction theory can also reveal some interesting issues about collaboration in real world, which provide us helpful hints to model collaborative design. Each category of the above approaches concentrates on a subset of design issues only. Some of them have provided suggestions on several design process models and conflict management models. In this section, we review the different groups and further discuss their relationships 3.2 Design Theories and Methodologies Design theories and methodologies provide the fundamental understandings o f the entities and procedures of decision-making and problem solving. These theories can be generally classified into three views, which are Procedure view, Decision view, and Knowledge view [39]. The research approaches from the procedure view treat designing as a unique or distinct process that needs to be carefully planned and systematically executed 10 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. (e.g., QFD [31], Systematic design model [68], Axiomatic design model [86], Life-Cycle Design [37], and Total Design [72]). The decision view emphasizes the decision-making process in design and models designer’s beliefs as value functions (e.g., Decision-Based design framework [32]). The knowledge view of design treats design as a knowledge-based problem solving process. Design decision-making is treated as an integral part o f application of knowledge (e.g., General design theory [100]). Basically, these design theories provide the guidelines to make technical decisions more systematically. Although the design process is modeled differently based on various design theories and methodologies, most of these design process models assume that engineering design is a pure technical activity and is independent of who does it. They ignore the human (who) issue and assume the perspectives of the design participants will not change or affect the design process itself. That omission has caused most of the inefficiency and difficulty in collaborative design. 3.2.1 Procedure view Many research approaches have studied the question of how the design product is created; that is, they have studied what processes, strategies, and problem solving methods that designers use. The methodologies proposed by these approaches intent to provide the canonical design procedure for designers to follow. Although some have attributes in common, few build on each other, and most express fundamental, incontrovertible philosophies of design [25][26]. Among these approaches, the most representative ones are the Systematic Design Methodology [68], the Axiomatic Design Model [86], and the Total Design Model [72]. Pahl and Beitz described a step-by-step approach to design, starting with product planning and clarification of the task and proceeding to the conceptual and embodiment design phases. They also introduced various specific methods (e.g., 11 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Requirements list, Gallery method, and Costing methods), which should be applied during different design phases. The essential part of this approach involves systematically analysis and synthesis following the guidelines in design progress. Suh proposed the Axiomatic design model with the belief that the subject of design should attain the same level of intellectual understanding that fields in physics. This approach to design begins with the premise that there are generalizable principles that govern the underlying behavior of the system being investigated. The design axioms (i.e., Maintain independence of functional requirement and Minimize the information content) are these general principles or self- evident truths that cannot be derived or proven to be true except that there are no counter examples or exceptions. In this model, the conceptualization within design process consists o f the mapping and decomposition in a zig-zag manner. The Total Design methodology proposed by Pugh focuses on the systematic procedure from the identification of the market/user need, to the selling of the successful product to satisfy that need. This methodology concentrates on user satisfaction and depicts a complete product delivery process. It also utilizes some methods and techniques (e.g., QFD, Taguchi Design of Experiments, and JIT) to facilitate designers to explore concepts and optimize product performance. With different focuses, these design methodologies try to solve two basic problems: to declare the criteria of a good product and to define the specifications of a good design process. The Axiomatic design model states that a good design meets its various functional requirements independently and simply. The Systematic Design approach uses the scientific and economic principles to evaluate the design options. They assume that their guidelines will work normally no mater who performs the design. In fact, no theory can capture all of design; rather, each theory provides one perspective, broad or limited, that may improve 12 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. design understanding and practice. Although these design procedure guidelines are valuable for people to generate design concepts and search design alternative, in the practice, their applications face two pitfalls. First, when designers with different design experiences want to use their own design methodologies, it is not easy for them to form a uniform habit of design in short time. Second, even using the same design theory, the groups with different technical and social backgrounds will create quite different products, since the people only partially follow the design guideline and jointly define the criteria and processes. No mater how specific the design guidelines are described in the textbook, designers will adapt them to the real design process according to the situations they perceive. To effectively assist design collaboration, we need theories/methodologies not only to explain how individuals make design decisions, but more importantly to help the organization create the shared understanding. 3.2.2 Decision view Different design stakeholders (e.g., customers, managers, designers, and manufacturing engineers, etc.) play their various roles in the design campaign. During this complicated and dynamic process, one o f the major roles of the stakeholders is to make their decisions with respect to the product, the design process, and the design team [81]. Since the inconsistency o f stakeholders’ objectives is one of the basic characteristics of collaborative design and causes the most complexity in it, a well-accepted view is that the collaborative design can be modeled as a multi-objective decision-making process. Based on this view, a lot of developed theories and methods from decision science, economics, operations research, and other disciplines are being applied to solve design problems [9][10][29][63][70][75]. Hazelrigg provided a framework for decision-based engineering design, which can be rooted 13 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. to mathematics through axioms such as the Von Neumann-Morgenstren axioms dealing with the assessment of human values. In his method, design is viewed to provide value to humans, and design decisions are made in some attempt to maximize that value [32]. It endeavored to deduct a basic understanding of the decision reasoning process [33][34]. Another important category is to apply Game theory as a multi-objective optimization methodology to support design. That was proposed as early as two decades ago [90]. Then quite a few relevant game theoretic approaches were developed for collaborative design. Rao and Freiheit provided a modified game theoretic approach to solve multi-criteria design problem. The modification is accomplished by combining the generation o f the Pareto optimal solution and the maximization of the super-criterion [75]. Grahdhi used a multi objective optimization algorithm based on generalized compound scaling techniques [29]. Petrie proposed a negotiation strategy to coordinate the distributed design agents by using Pareto optimality [70]. Lewis and Mistree also took a game theoretic approach to model interactions in multi-disciplinary design. This approach was to abstract the interactions in multidisciplinary design as a sequence of games among a set o f players [50][5l]. These approaches captured some basic attributes of the decision-making in collaborative design or generated their methods to handle some specific design problems. But, it is not easy to apply them to solve most of the problems especially existing in the early phases of collaborative design. The critical reason here is that the theoretical and mathematical foundations of value theory and game theory have their constraints to manage the complicated collaborative decision-making process [8]. In the following paragraphs, we will review the two representative approaches: Hazelrigg's design framework and the Game theory approach. The framework for decision-based engineering design proposed by Hazelrigg is based on Von Neumann-Morgenstren utility theory, which deals with the 14 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. assessment of human values [28][64][91], This framework views design as a decision making process to maximize the value to humans, which is the profit o f the company. Its purpose is to enable the assessment of a value for every design option so that those options can be rationally compared and a preferred choice can be taken. In this framework, design begins with an option set, consisting of all the configurations. Each configuration is represented by a parametric design vector, which is a designer’s representation of the system. The design configuration is further represented in terms of attributes to be recognized by the customers. Then the demand for a configuration can be generated and it gives the expected revenue of the particular configuration. The configuration vector and the exogenous variables also determine the expected costs consisting of all that could detract from revenues to result in net revenues or profits. Then the expected utility could be deduced from the expected revenue and the cost. By changing the design vector, the decision-maker can optimize the design with respect to their expected utility. Basically, this framework views design as a utility maximization process and set the design goal as to make more profit. However, in the real collaborative design problem, the decision-making process becomes too complex to be handled by these approaches. Collaborative design is conducted by a group of stakeholders with at least two categories of goals, which are the individual goals and the organization goals. Customers, managers, design engineers, and manufacturing engineers have different goals. The customers present their preferences about the product and wish the corporation to provide the better quality good with low price. The owners of the company also have their important voice in design process, such as to make more profit by reducing cost. The design engineers might view functionality more important. They have to concentrate on the safety and usability issues. Even within same kind of technical roles, 15 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the stakeholders might have different behaviors for the knowledge and personality differences. It is obvious that their design goals aren’t to just maximize the profit of the company. The design group as an organization also has its goals. The goals o f the design group can be simply conceived o f as a derivative of the individual goals of the stakeholders. However, they are more complex for the cultural and emotional influences. In the design process, individuals influence the goals, contents, and contexts o f each other [62]. As the design team evolving, conflicts among the individuals and the organizations are frequently occurring. Although the stakeholders are supposed to make decisions to satisfy their individual requirements, sometime they face the obstacles to make the decisions [61]. The reasons are various. First, the goals of the individuals are not always well defined. In the early stage of original design, this happens frequently when the concepts of the product have not been clearly figured out. Second, the norms, rules, and the coherent culture of the organization will force the individuals to adjust their goals to conform the organization goals. That causes the change of the preference of the decision-maker. Besides, the preferences of the individuals and organizations are not always easy to be described and compared. The utilities o f the designers and the organization are not always clear enough to be optimized. Besides, the outcomes of the design are manifold. It is impossible for the stakeholders to only rely upon a single preference function when they make the decisions. It is also uneasy to express the preferences and even difficult to quantify the preferences. On the other hand, a designer only has limited knowledge and computational ability. They usually make decisions by the sensible outcome or by experience. Even if the preferences were uniform during the design process, it is very hard for the designer to always recognize the ultimate consequences o f their decision. In large system design, a lot o f uncertain issues are involved and the decisions become fuzzy [27]. The probability o f the final outcome is 16 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. hard to be evaluated in the early stages o f design. Stakeholders are more intent on selecting the satisfactory options, rather than on maximizing their values. In the collaborative design problems, decision-making is even more complicated since the reactions of other decision-makers to the choice made by the focal decision-maker have to be taken into account. The models o f game theory are highly abstract representations of classes of real-life situations. The basic assumptions that underlie the theory are that decision-makers pursue well-defined exogenous objectives (they are rational) and take into account their knowledge or expectations of other decision-makers’ behavior (they reason strategically). The current applications of game theory to engineering design focus mainly on the non-cooperative static games. By viewing multi-objective decision-making as game playing, some research approaches tried to solve problems in parametric design stage. Most of them are to derive the Pareto-optimal set for design variables by using weighting, min- max, or goal-programming methods [29] [51] [75]. Although game theory models are applicable to the optimization problems involved in the parametric design stage, it can hardly be used to guide the conceptual design for the inconsistencies of the stakeholders’ situational knowledge. First, it is difficult to quantify the situation information as utility functions when stakeholders are struggling with exploring the ideas and do not know what options they can choose. Second, even stakeholders know what they exactly want to achieve, they still have limited access to others’ strategies due to the deficiencies of information sharing in design collaboration. Third, in practice, stakeholders normally intend to cooperate with others rather than to only maximize their own utilities. But, currently there are no well-established models for analyzing the cooperative game playing. 17 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 3.2.3 Knowledge view Some research approaches treat design as a knowledge-based problem solving process. They aim at clarifying the human ability of designing in a scientific way, and at the same time, producing the practical knowledge about design methodologies. The issues are how to query and represent design knowledge in a structured way and use them to direct the design process. Yoshikawa’s General Design Theory is a formal mathematical theory of design from the knowledge view. It proposed axioms and theorems to cast design in the framework of set theory. This framework implicitly assumes that designing is a mapping from the function to the attribute topology under certain constraints. A major goal of general design theory is to guide the construction of CAD system [100]. However, General Design Theory does not receive wide acceptance among the design professionals [76]. It is viewed as an abstract thinking model rather than a design methodology. Another possible reason is that its mathematical representations are too complex to be used to guide design process. Case- based reasoning (CBR) is another design approach belongs to the knowledge view. It is focused at using the solutions to past problems in developing solutions to new problem. It uses the similar problems as the basis for reasoning. Then, the critical issues in design process are the acquisition, organization, and reuse of design knowledge. Maher proposed a hybrid case-based design model to integrate specific design situations and generalized domain knowledge by representing specific cases as attribute-value pairs and representing domain knowledge as design concepts and constrains [59]. Bardasz et al. developed a case- based reasoning system, which contains a knowledge base of design plans, an evaluation module, and a blackboard-based adaptation module [5]. The CBR approach has two prerequisites: the existence of design cases and the reusability of design knowledge. The 18 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. performance of the knowledge-based system depends on the quality and quantity of the design cases acquired. However, it is not a trivial work to acquire a lot of useful design cases. Hence, most of the established CBR models have to be very specific to deal with some individual domains, where they can easily obtain design cases. Another pitfall of the CBR research is that they treat design cases as powerful mechanisms of knowledge representation. However, for the lager system that includes people with different perspectives, the evolution of the situation knowledge (i.e., the social impacts to the design process and to the product) are difficult to be simply denoted as design cases in the digital formats. 3.3 Design Process Modeling Various models have been proposed to represent, analysis, and standardize the design process [67][99]. The majority of approaches in this category are from the research of business operation and project management. 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 [2][47]. Accordingly, a set o f techniques to manipulate the design activities has been developed. Project Evaluation and Review Technique (PERT) [96] is widely used in the engineering project management [42][54][71]. Many techniques for design process modeling are also proposed. Steward used the Design Structure Matrix (DSM) to overcome the size limitations of other process representations [84]. Eppinger presented the signal flow graphs as a flexible tool for design process modeling [23][82]. Sanvido used an integrated design process model to represent the major functions and activities necessary for complex building design [79]. Bras developed design process models 19 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. by classifying all information into certain basic entities (e.g., phases, events, decisions, tasks, systems, and goals) [10]. The networks consisting of these entities describe design process and are represented in a form suitable for manipulation. In the recent years, many researchers proposed the methods to manage the concurrent engineering workflow on the Internet by using distributed agents for process and constraints maintenance [35] [46] [74] [78]. Although they present different ways to represent the dependencies among design activities, these tools have some limitations when they are used in collaborative process modeling. PERT method is widely used for identifying the critical path of the process and estimating the completion time, but it does not support representation of iterations in the process. State-transition Diagram is popular in logic design and object-oriented modeling. One o f its major disadvantages is that one has to define all of the possible states of the system beforehand. Signal Flow Graph provides a clear representation of design iterations, but it does not specify the presence of the stakeholders in the process. 3.4 Conflict Management The effective ways to solve the conflict problems will enhance the team productivity and improve the quality of the product. One of the critical objectives o f this proposed approach is to derive a theoretical basis that can be used to solve the different types of conflict during the design process. The current research approaches on design conflict management can be generally divided into three areas according to their theoretical backgrounds. They are artificial intelligence approach, economic/behavioral approach, and explicit engineering design models. 20 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 3.4.1 Artificial Intelligence approach Many AI researchers take the problem solving approaches to manage design conflict. Their approaches build searching algorithms, capture agent dependencies, or develop knowledge-base systems. Some of them view collaborative design as a distributed dynamic interval constraint-satisfaction problem and develop algorithms that use heuristics for distributed design [13][88]. Klein introduced the concept of conflict resolution expertise. His approach used computational models that actually encode conflict resolution expertise more explicitly and use it to maintain the dependencies during cooperative problem solving. In his cooperative design model, design agents can be viewed as being made up of a design component that can update and critique designs, as well as a conflict resolution component that resolves design agent conflict [44]. Dunsus tried to use many small, cooperating, and limited-function expert systems to build an integrated system to investigate conflict. It provides ways of discovering and testing the components o f negotiation, patterns of communication, functional primitives of design, and the types of knowledge needed [21]. Wong proposed a cooperative problem solving approach to handle the conflicts among distributed design agents [98]. He classified conflicts into schema conflicts, data conflicts, and knowledge conflicts, and proposed four modes o f conflict resolution (Inquiry, Arbitration, Persuasion, and Accommodation). 3.4.2 Economic/behavioral approach Other research works focus on the negotiation strategies of conflict management based on economic or behavioral theory. Bahler introduced a protocol o f evaluating compromise solutions to conflicts in collaborative negotiations [4]. The protocol is based on the notions of economic utility by which design advice systems can recognize conflict and mediate 21 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. negotiation fairly. The basic idea is to allow expressed preferences of design teams to be qualitative as well as quantitative. Several approaches are proposed to handle conflicts in design by modeling conflict as the multi-objective decision problem [40][46][70][51][94], One o f them is concerned with global metrics for optimization, decision support, and negotiation. The coordination function is supported by some optimization methodology, such as Pareto optimality and Multi-attribute utility [70]. Game theory has been used as a typical method for generating compromise solutions in many research approaches. Vincent examined the role of game theory in the engineering design process in 1983. He examined the multi-criteria optimization task from the perspective of team design [90]. A modified game theory approach to multi-objective optimization has been used in conflict resolution as a combination of optimization steps [75]. 3.4.3 Explicit engineering design models The engineering design models also have some mechanisms applicable to managing design conflict. For instance, QFD (Quality Function Deployment) is a structured process that establishes customer value using the “voice of the customer” and transforms that value to design, production, and supportability process characteristics [31]. The result of QFD analysis is a systems engineering process that ensures product quality as defined by the customers. This is essentially a methodology to solve/mitigate the conflicts among the diversified customer needs, which mainly exist in the early phases of engineering design. The Independence Axiom in Axiomatic design [86] states that the independence of Functional Requirements must be always maintained to reduce the random search process and minimize the iterative trial-and-error process. It claims that a product design ignore this axiom will face substantial conflicts. 22 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 3.4.4 Contributions and limitations of the previous approaches To summarize the above, we discuss the contributions and limitations of the previous works on CM. The Al-based approaches and the economic/behavioral approaches mainly focus on conflict management itself rather than its origin and influence in the whole process o f engineering design. However, as the design process being conducted and the design environment evolving, it is difficult to use one category of methods to deal with all o f the conflicts [43]. Most of them assume that 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 [8]. 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 insulated concepts in different perspectives. Only after the meanings are defined and shared among the stakeholders, utility theory can take effect to handle conflict. Conflict management is highly coupled with the design process modeling and organization transforming. For example, although game theory provides quite complicated methodologies to solve the conflict problems in economics, the use of them in engineering design requires a deep understanding o f the nature o f design process to adapt the game-playing models. The rightness o f the analysis (e.g., build utility functions and determine the strategies o f players) depends on the comprehension of the attributes of design participants, the design product, and the design situation. The other deficiency o f these approaches is that they mainly can contribute to conflict resolution (and somewhat detection), rather than conflict prevention (which is a very 23 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. effective way to handle conflict). Using the engineering design models to manage conflict is a prospective approach to solve the problem. But most o f the current design models do not take supporting collaborative design as one of their primary goals. They assume that strictly following their guidelines will significantly reduce the chance of conflict. 3.5 Product Data Management Several research approaches from CAD and CAE areas view collaborative design as individuals and groups accessing data and sharing the design information. Their focus is on establishing and maintaining the technological, scientific, and interdisciplinary dependencies of the information [ 18][60][77][87], The design systems built by them are to facilitate the storage and processing of various types of data for different designers. Sriram developed an approach that supports collaborative design by providing environments that necessitate data modeling, sharing, and management tools, network communication protocols, and a flexible framework for concurrency management of highly interleaved and interactive data transactions [83]. Krishnamurthy proposed a three-layered data model of versions, assemblies, and configurations that addresses the storing and managing of changes among designers [48]. In the recent years, Object-oriented models are widely used to represent the design entities for CAD applications [20][52]. Most o f the methodologies these approaches generated are to manipulate the accessing and changing of design data across disciplines. Accordingly, the design process is specified as the management o f design data in different abstraction levels. These approaches are explicit for modeling design process for computer implementation of CAD system. The conflicts in collaborative engineering design are handled as data transaction inconsistencies. They offer various technical strategies to resolve the conflicts in computerized systems. 24 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [49]. They derived a framework that can be used to define the scope of design rationale representations and assess their expressive adequacy. The earliest specific proposal for design rationale method is the “issue based information system” (IBIS), developed by Rittel. IBIS seeks to capture the issues that arise in the course of design deliberation, along with the various positions that are raised in response to issues, and the arguments for and against the positions. Several representations based on IBIS (e.g., gIBIS) have been developed to represent designers’ argumentation activities. Although the IBIS representation is simple to use, it does not capture the criteria space of design rationale explicitly and ignores the complicated relations among issues. Procedural hierarchy of issues (PHI) uses a broader definition of the concept issue, and provides a new principle for linking issues together [65]. It overcomes some of the limitations of IBIS by allowing a quasi-hierarchical structure among issues, answers, and arguments to explicitly capture the special dependencies. Although the quasi-hierarchy increases the expressiveness o f PHI, some important relations still cannot be easily expressed. Design space analysis is another approach to represent design rationale. It uses a semiformal notation, called QOC, to represent the design space around an artifact. The main constituents of QOC are Questions identifying key design issues, Options providing possible answers to the Questions, and Criteria for assessing and comparing the Options. QOC also takes account of justifications for the design that reflects considerations such as consistency, models and analogies, and relevant data and theory. The difference of QOC from PHI and IBIS is the addressing o f criteria space, which is important to capture the objectives of design. However, QOC cannot capture many aspects of arguments and does not represent the cross option dependencies. 26 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Decision representation language (DRL) is a language for representing and managing the qualitative elements o f decision-making. The units of the Issue Space, the Alternative Space, the Argument Space and the Criteria Space are, respectively, Decision problem, Alternative, Claim and Goal in DRL [49]. DRL can be viewed as pushing further the extensions that PHI made to IBIS by generalizing the hierarchical structure to more complex relations and by making explicit some other elements, especially those in the criteria space. It is more expressive for design decision representation since its representation objects capture various relationships among the decision elements. However, DRL does not capture some important aspects of design rationale, such as the mechanism to generate design alternatives. All of the design rationale models described above are considered to be general design reasoning representations. However, during collaborative design practice, design participants with various knowledge backgrounds face difficulties to achieve consensus about the design issues, arguments, and criteria. Also, without effective communication support mechanisms, design rationale information is concealed rather than expressed among the expertise. That causes a lot of inconvenience in collaborative design reasoning. However, most o f the traditional design rationale models do not focus on these problems. 3.7 The Requirements of a New Approach The established research approaches focus on different aspects o f design and provide considerable contributions for understanding the basic characteristics o f engineering design (Figure 1). However, it is noticed that these established approaches have their own limitations when applied in collaborative design. They usually assume that the perspectives of different stakeholders are independent and do not address the impact o f their social 27 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. interaction. They either ignore the social features of design or assume designers are purely rationale and simplify their preference as utility values. The design process is accordingly viewed as a series of pure technical activities, and the key issue “who” (e.g., the various people involved in the design, their distributed knowledge, their social networks, etc.) is not explicitly addressed. In fact, it is impossible to completely share the knowledge and purpose among designers in collaborative design [17]. Rather than being pure rationale, the stakeholders have an optimal or satisfied degree of consensus, which provides the desirable design result. Although the design methodologies and the workflow management techniques are applied, designers still face some failures of coordination due to their perspective differences and the inefficient design process management. Design Rational* Design Theory and Methodology D esg n Docum entation Customer Needs Represent Process Modeling F unctional Requirement Technical Decision Organization Design Parameter Make decision Exchange Generate enerate/get Designer Process Variable nformation Design Design D ata ’ Behavior Product Model Function Structure ' Product Deta Management Figure 1 Overview of the existing research approaches 28 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Therefore, a more comprehensive view is required to clarify the relationships among various technical and social aspects o f collaborative design. Collaborative design 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 research work derives a generic collaborative design process model, a perspective representation model, and a conflict management methodology based on a socio-technical design framework, which is suitable to represent, analyze, and support the collaborative design activities. 29 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4 The Socio-Technical Approach to Support Collaborative Engineering Design 4.1 Theoretical Background This research work is based on a socio-technical design framework, which explicitly depicts the fundamental issues and their relationships in collaborative design [55][56]. In this framework, initiated by a design objective, the design campaign evolves within the design environment. The outputs from design campaign constitute the design result (e.g., the final product), and the feedback to the evolution of the design environment and the design campaign itself. The framework contains two levels. The co-construction is relevant at the product and process level, while the evolution of design environment may be envisioned is relevant at the system level. Within this framework, Design Process Model and Conflict Management Model can be built to support the technical decisions and social interactions for both levels. The exciting finding from our research in this field is that one cannot utilize information to map from “what-to-design” to “how-to-design” in the design campaign without knowing the perspective of the “who” that generates the information. Similarly, conflict resolution and control, both elements of decision-making, in collaborative engineering design require the explicit modeling of stakeholder perspectives. While the need for using perspectives is essential for coordination across disciplines, across time and resources, and across organizational cultures, the development of the research ideas requires a general conceptual formulation. A dynamical modeling approach is used to illustrate the key concepts o f the socio- technical framework and to model the “understanding-sharing” among design stakeholders. 30 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The collaborative design campaign is viewed as a dynamic system, which identifies several key concepts of the socio-technical framework. One of the most essential concepts introduced by this approach is stakeholders’ perspective. Our understanding of perspectives begins with the acknowledgement that: • Each individual builds over her lifetime an evolving base of information that is “internal” to her; • Each individual has a perspective that evolves over time and acts like a “lens” through which she understands and collects data external to her; and • The data that each individual produces, or exchanges through any medium (e.g., computers, speech, and writing), is the external manifestation of her internal information, appropriately filtered through her “perspective lens”. Consider a collaborative design group consisting o f N individuals. At any instant of time, /, each individual 'j' can be described as having: a store of internal information, H j t ; a perspective P j, ; and, the external data, DJ t . A perspective consists of two parts, which are the “filtering” perspective pTt and “learning” perspective Pi, • Pf, is used by a stakeholder as a filter to access and generate data. Pj l i is her internal learning habit to update P f]. We assume that at some time t =t0, these entities HjJn, PJfa, and DJ t are partially known for each of the N individuals forming the design team. We view collaborative design as stakeholder generating and sharing information through their perspectives. The information is represented as various formats o f data. We shall denote the sum total of the data external to each individual at time t by E, — Dj t . If j we consider an increment in time (e.g., we consider, for simplicity, a discrete time dynamical 31 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. system), then we have the following relations governing the time evolution (i.e., for t = 0, I, 2,... )o f Hj,,Pjt, and DJt for each of the N individuals: basis of the total external data available to the enterprise by filtering it through her perspective lens, Pj t , and combining it with the internal information store, Hj t , she has up until then. This equation can also be viewed as representing the “learning” process, which is known to require both background information ( E, ) and mental bias ( Pj t ). The second equation states that this update in internal information causes the perspective lens through which she views the world to evolve in time. This equation together with the first may be viewed as encapsulating the “thinking” process. The last equation states that the external data one generates at time (t+l) is created by the updated perspective “acting on” the updated internal information. We note that this formulation has the advantage that it explicitly recognizes the difference between the information that is externally expressed by individual ‘ j ’ and the information internal to her. It shows “perspective” as an “operator” that acts on (interprets) both the external data that is encountered and the external data that is produced. The external data that each individual produces in turn is encountered by each of the others in the enterprise system, and interpreted by each individual according to that individual's perspective. (I) (2) (3) The first equation states that individual ‘ j ’ updates her internal information store on the 32 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Since we are interested in understanding-sharing, we next need to formalize our concept of understanding, Uj t of individual ‘ j ’ at time t. One way of doing this is to think o f the understanding of individual ‘ j ’ at time t with respect to the external data Dk l as an operator that depends on both the perspective of individual ‘ j ’ and on her internal information store, when it 'acts on' the data Dk t. Thus t / ><[D7,] = C/J( /> ,,/ /J, ) [ A J (4) Control Figure 2 Dynamical models of design perspectives in collaborative design As shown in Figure 2, this approach opens up several levels o f incompatibility that must be addressed during collaborative design. (We use the word incompatibility somewhat loosely to include inconsistency, irrelevancy, incompleteness, etc.) 33 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Hence, we may have at any time t, DJ t I Dk t, and/or, Pj t I Pk, , and/or H jt I H k l (5) where the symbol I stand for “incompatible with”. In collaborative design, these inconsistencies imply different types o f conflicts. Inconsistency in external data between two individual ‘ j ’ and ‘k’ is viewed as conflict relating to the product specification level. That is one generic form of conflicts focused by most current conflict management approaches. Incompatibilities in internal information may imply the knowledge conflict between different stakeholders. Since internal information is inside human minds, this kind of conflict is relatively difficult to detect and represent. Since perspective is the filter through which internal and external data are generated, the incompatibility between different perspectives is the major source of the above two sorts of conflicts. Given this realization, relation (4) shows that methods need to be able to handle design conflicts to bring about improved compatible understanding of external data. Thus, conflict management is essentially viewed as an understanding-sharing process. This framework leads us on towards a possible formulation of the concept of “understanding-sharing” between two individuals ‘ j ’ and ‘k’. We need to seek out information systems that: Make f/7,(D /f) n UkJ(DlJ) as “large” as possible for some time t > m ,D ,t e D(kj), (6) where D(kJ) is the relevant set o f data-discourse between individuals k and j, and m is a suitable time horizon which depends on the specific situation. (Though this concept can be further expanded when considering a set of individuals, we shall not pursue this here.) 34 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Understanding-sharing as described by (6) is seen to be an inherently dynamic, evolutionary process, across time. One way o f achieving (6) might be to influence the dynamical relations (1-3) through the use of a set of “controls”. In general, these controls will be time dependent and will depend on the internal information stores and the perspectives of the individuals comprising the design organization as well as the external data available at that time. Thus, instead of relations (1-3), we have, for each individual ‘ j ’, the following dynamical system (for t= 0, 1,2,...): ffw.i = W ) U « p (7) I + C ,,/lW w ,U/>.„£,) (8) (9) One of our purposes has been to identify concepts and obtain an initial conceptualization of perspective evolution in collaborative design; we shall use this to direct our attention to areas that we still do not fully understand yet. For example, the controls Cj may also be thought of as being provided through negotiation, and provision of additional information. Negotiation at the external data (CDj) level might involve, as it often does in may product data management systems, simply a check for its consistency. But our formulation clearly indicates that such a simple negotiation process may not be useful because the data Dj t generated by individual ‘ j ' may affect the internal information store of individual 'k' (see equation (7)) and hence possibly her perspective (see equation (8)). One can then see the possibility of causing an avalanche of other external data inconsistencies as time evolves despite having resolved the one specific to data inconsistency at hand. 35 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4.2 Collaborative Design Support Architecture The above dynamical model clearly depicts the three key control parameters to support collaborative design. First, to control the interactions of stakeholders’ accessing and modification of external data, we need a feasible design process and a well-structured organization. Second, stakeholders’ perspective interaction is a critical issue we need to consider when modeling collaborative design. Third, conflict management strategies can be used to effectively manage the dynamic relations in collaborative design. These three factors function together and influence the overall characteristics of collaborative design. ■ * Meaning defined on link Consist o f Close linkage Resolution Intervention Conflict influence Causes Effects Context echnical\ responsible for Design Process paniapa,e / Social Interaction play ._______ play Stakeholder I Information sharing < Perspective\ Model f drive/ Integrated Product Model has view of Purpose Context Content Function Structure Behavior Norm/Culture Procedure Form Figure 3 The Socio-Technical design support architecture 36 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Figure 3 expressively depicts various elements and their relationships in collaborative design. Design process model (includes technical design process and social interaction), conflict management strategies, and perspective model are the three critical components within the socio-technical design process. In a design campaign, stakeholders perform both technical roles and social roles based on their unique perspectives. The former is mainly conducted in the technical decision-making process while the latter is represented as social interactions. They are formed when stakeholders become part of a community undertaking a design campaign and begin to interact with other members of the community. 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 influenced by the organization structure, norm, and culture, technical decisions are coupled with the social-interactions during the design cooperation. Knowledge representation is critical for designers to capture the understanding and reasoning behind technical decisions. Effective information sharing mechanisms accelerate the process of achieving shared reality. During the design interaction, various conflicts will occur due to multiple task interdependencies and perspective differences. When treating engineering design as a purely technical process, conflicts are usually regarded as being abnormal and to be avoided as soon as possible [69][45]. As discussed in Section 3.4, there are different approaches that have been proposed by building utility functions for designers, by categorizing conflict resolution knowledge, or by capturing design rationale. However, when treating engineering design as a socio-technical process, conflicts must be systematically and explicitly dealt with as a resource to drive the social construction process and design innovations [S3]. To manage conflict near its source and root, social interaction should be considered as a controllable parameter to affect and change the design perspectives. In the early design stage, conflicts 37 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. are treated as a motivation to identify the deficiencies among design team and to generate creative ideas, while at the late stage conflicts should be prevented or resolved to achieve high efficiency. 4.3 Modeling Collaborative Design Process 4.3.1 Requirements to model collaborative design process As reviewed in the previous section, the established design process models focus on the properties relating the execution of activities but do not address the interactions of the individual perspectives of the stakeholders. Most of them generate the design process manipulation strategies for schedule maintenance or information management. They overlook some fundamental reasons of the conflict among the information transactions within the design activities. A key issue of a collaborative process model is to support task decomposition and coordination. To simplify the large design problem, it is common to decompose it to small tasks, 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 be achieved in collaborative design due to the various technical and social 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 well defined, 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. It is necessary to have a model to represent and simulate the design process and support stakeholders’ coordination during the early stage. In 38 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. collaborative design, the task decomposition and integration has to be achieved not only through the communication of contents, but also through the communication about the creation and evolution of shared meanings. The shared meaning is always defined by the interaction o f 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. In other words, 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. In collaborative design processes, the influence o f one’s decision making in a 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 to solve conflicts. Besides keeping the product data integrity, an effective 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 way of organizing design team and design process. To achieve these, it is critical to generate a design process representation model, which can facilitate the describing, tracing, and management of collaborative design interactions by referencing to design perspectives. 4.3.2 Collaborative process model definitions This research proposes to use a modified Petri nets model to represent the design activities and the coordination among stakeholders. Petri nets have the unique advantage to support process specification, representation, and evaluation at the same time [19]. Also, their mathematical properties help us in quantitatively analyzing the behavior of the design 39 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 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 [38], manufacturing system, supply chain). Necessary changes/improvements have to be made to adapt Petri nets to represent the design process. In the collaborative design process model, place and transition in Petri nets are equal to ■ ‘state” and “task” respectively. A design process is represented by an organization o f states and tasks. Task is the activity stakeholders have to perform during design process. State is the status (or a group of conditions) that the stakeholders want to achieve through tasks. Both of them can have time duration. The difference is that state is used to represent the measurable conditions in a process, and task is used to represent the means to obtain the progress. State can be visualize as the “what” in design process, while Task is similar to “how” to fulfill the “what.” The weights of the tasks can be used to represent their resource consumptions (the default value of the weight is one). The arcs represent the transform directions between states and tasks during the design. The token denotes the status of each individual state. State contains token if and only if it is active (i.e., the state 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 state in design process. Since different stakeholders can conduct tasks, we introduce the “stakeholder” into the notation. Each task and state has a set o f stakeholders associated. Formally, a Collaborative Design Process can be represented by a Petri net graph with the following definitions. 40 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. As shown in the example (Figure 4), a portion of building design process is represented in a graph with the above elements. We use PK ,P2,Py, P4 to denote the project manager, the design consultant, the market surveyor, and the architect respectively, which are marked on top o f the states and tasks. At the beginning o f design, the tokens are only contained in the beginning states (SI and S2). After stakeholders perform the tasks, the tokens from the upward states can be transferred to the downward states. M 0 is defined as the initial marking of a CDPN, which is a vector containing the token number for each state. For instance, at the beginning M 0 equals [1 1 0 0 0 0 ] since only state 1 and 2 possess tokens. If iV/0 equals [0 0 0 0 0 1], that means the all o f the tasks shown in the graph have been conducted since the token is only presented in the last state. The input and output relationships between task and states are denoted as: °S(l) the set of input states of task t, (i.e. the set of {s | (s, l)e - 4 } ) , S°(t) the set of output states of task /, (i.e. the set of {s | (/, s) e A } ), T ( s) the set of input tasks of state s, (i.e. the set of { /1 (/, s) 6 A } ), T° (y) the set of output tasks o f state s, (i.e. the set of { /1 (s, t ) e A } ). It is clear that finishing a task / consists with transforming the initial marking M 0 of the CDPN into a new marking A/(+1. Firing a task l e i includes two operations, which are removing a token from each se°S(t) and adding a token to each s e 5°(/) (assuming each arc has weight one). It could be formally defined as follows: Definition 2: A task can be fired in a marking M t iff V se S (t) : M f s ) > 0 . The firing of a task leads to the next state M m , which can be calculated by: 42 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. A / w ( 5 ) = A/jC^) —I if se°S(t) M,(s) +1 if J 6 S ‘(f) (10) M,(s) otherwise Thus, the execution o f a design process is represented by a task firing sequence cr =< f,,/2,... > , which relates to a transformation o f the marking A/0 -> M x M 2 .... The process incidence matrix U = [w( J ] is defined to represent the relationship between tasks and states in a CDPN. Definition 3: An incidence matrix U = [m , y ] is defined over all o f the states S = { 5 ,, s2 sn}, and the tasks T = where u'j = T(Si) j - T ' t s , ) 0 otherwise - 1 if t (II) For example the (n x q ) incidence matrix o f the above graph is C/ = - I 0 1 0 0 0 0 0 - 1 0 0 I 0 0 0 0 - 1 0 - 1 0 1 0 0 0 0 0 - 1 1 I - 1 The relationship between state transformation and incidence matrix can be expressed in the following transformation equation: Proposition 1: M T = M l +U (12) In Equation (3), Va = [v I,v2,...,vi/] is a counting vector for a task firing sequence cr with the following definition. 43 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Definition 4: The counting vector of firing sequence a is defined as Va — [v,, v2..... vy ], where v; is the number o f tasks ti included in cr. Given the firing sequence <r=< T l, T2, T3, T4, T5, T4> in the example, its counting vector Va equals [1 I 12 1]. Based on Equation (12), the final marking can be calculated as follows. T '- 1 0 0 0 0 ‘ I - I 0 I 1 0 -1 0 0 0 1 1 - 1 0 0 1 0 - 1 0 0 1 0 0 0 — + I s: + 0 0 I - 1 0 0 9 0 0 0 0 0 0 I -1 1 1 0 0 0 _0 _ 0 0 0 1 - I I 0 1 1 M =[0 0 0 0 0 I] shows that only State 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 M T = [/w ,ry] . If the one of output states of task / is within the set of taskj ' s input states (i.e., task /is immediately in front of task/ ) , we call this situation “sequential dependency”. Another situation is that two tasks are sharing the same input state or output state, which is named “joint dependency”. In both cases, its dependency factor is set to 1. Otherwise, it is said that there is neither sequential nor joint dependency between the two tasks. In a task dependency matrix, it is easy to identify the critical tasks (e.g., T3), which relates to many other tasks. Definition 5: An task dependency matrix M T = [mfj ] is defined over all o f the tasks T = {rt,/,,...,rv} where 44 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. i if (■$(*, >n-5(o) * < t> ) v (5° a ,) n 5- (tj) * *) (13) 0 otherwise It should be noticed that although two tasks may have no direct linkage (i.e., mjj = 0 ), they might still have indirect dependencies since one may transfer its influence through other tasks. For instance, although the dependency factor mlA = 0 , the output of T2 will still be embedded into the input o f T4. Thus, the task dependency matrix only shows the direct linkage relationships among the tasks in the process. To represent the assignment of stakeholders’ tasks from the CDPN, we define a task assignment matrix and task role matrix: Definition 6: A task assignment matrix M ^ = [mj’ j ] is defined over the stakeholder set P = {s,, s , ,..., s m } task set T = {/pf,,...,^} with the value n [ li f t, e { r|/^ p e rfo rm r) m, J [0 if tj € {t | p, perform f} Definition 7: A task role matrix RT = [rj ] is defined over the stakeholder set P = {pl,p 2,...,pm} task set T = { /,,/,,...,tv} with the value n is the number of non - zero items in column j of If a stakeholder has stronger control to a task, then the role ratio is bigger. For example, the task dependence matrix, task assignment matrix, and the role matrix of the above CDPN can be derived as: (15) 45 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. m t = M tp — 1 0 I 0 0 0 I 1 0 0 1 I 1 1 1 0 0 1 1 1 0 0 1 1 1 0 o o o r 1 0 I 1 0 0 I 0 0 0 0 0 1 1 I Rt = 0 0 0 0 1 1 0 1.6 0.8 0 0 1 0 0 0 0 0 0.4 1.2 I Besides the above basic definitions, we can also identify several situations for workflow control in CDPN. The purposes of defining these situations are to maintain the mathematic properties of the Petri nets and standardize the description formats. In CDPN. different workflow situations can be depicted by specific patterns consisted with tasks and states. Fork Task Concurrency Decision State Choice Figure 5 Process patterns: Concurrency and Choice 46 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The most widely used workflow patterns are Concurrency and Choice (Figure 5). If two tasks are parallel (e.g., T1 and T2 in Figure 4), they are allowed to be concurrently executed. The firing sequence < 7 is changed to < (Tl, T2), T3, T4, T5, T4> to denote the concurrent execution of Tl and T2. Definition 7: A “Concurrency” situation is when one task drives multiple output states, which initiate other tasks respectively. Firing the forking task will add a token to all of the output states. In a CDPN, we prescribe that one event cannot simultaneously initiate two tasks. The situation of a design state with more than one task in its output set indicates a “choice situation”. For example, state S6 in Figure 4 may have two output tasks (one is T5 and the other is not shown in Figure 4). In this case, only one of the tasks can get the token and be fried at one time. In design process, a state with " ’choice” represents a selection o f following tasks (e.g., a decision point). Definition 8: A “Choice” situation is when one state connects multiple output tasks. If there is one token in the state, then only one of the tasks can get fired. That means the state has to make a decision or choice. The " ‘choice” in a CDPN sometime implies design iteration, which might be caused by conflict or reworking. Given the possibilities of the options for each choice and the required time for each task, the execution time o f the whole design process can be estimated by other process simulation techniques (e.g., signal flow analysis methods [23]). Besides the concurrency and choice patterns, the logic relationships among the states and tasks are defined as the followings (Figure 6). Definition 9: A “State AND” situation is that one state can happen only if two previous states both happened. 47 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Definition 10: A “Task AND” situation is that one task can be fired only if two previous tasks were fired. Definition 11: A “State OR” situation is that one state can happen if any of the two previous states happened. Definition 12: A “Task OR” situation is that one task can be fired if any of the two previous tasks were fired. These workflow patterns and logic situations are the prime elements to construct complicated CDPN depicting the dependencies among tasks and states. 4.3.3 Building collaborative design process models Given the above definitions, a design process diagram, which has design tasks, states, and stakeholders being depicted on a structured way, can be represented as a set of matrices. T1 S2 O ' S3 S1&&S2-»S3 T1&&T2-»T3 S1 T1 T3 S1||S2-»S3 T1||T2*T3 Figure 6 Process logic situations 48 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. These matrices are used as the mathematical basis for the simulation/representation of the process model. As a collaborative design process representation tool, the design process diagram is effective in capturing and presenting the dependencies among different stakeholders’ design tasks. There are five steps to build the design process diagram: • Specify stakeholders • Specify process states • Specify process tasks • Specify dependencies among tasks, states, and stakeholders • Generate collaborative design process diagram There is no strict precedence among the above steps. In fact, the generation o f a design process diagram is a highly iterative process. Realization of the participants o f design process is the critical step before modeling the design process. Before drawing the diagram, the stakeholders have to investigate which persons will be involved in what tasks. Then, to generate the design process diagram, the design group, which involves the relevant “who”, needs to identify and specify the critical states and tasks in the design process. Design states are those situations that are perceived by the stakeholders and can be used to depict the status o f design process. Design tasks are the activities conducted by stakeholders to generate or achieve some design states. The dependencies among these states and tasks are the logical relationships among them. In a design process, there exist various dependencies among states and tasks, such as resource dependency, information dependency, and decision dependency. After the dependencies are depicted and articulated, they are used to relate design states and tasks together in the process diagram. Then, the stakeholders are marked on top of every task and state in the diagram. For instance, in a design process diagram 49 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. depicting a design plan, the stakeholders associated with a design task are those who are assigned with the work. The ones associated with a design state have perception of that state and will determine its occurrence. P2 P - stakeholder S - state T - task P4 S3 P1.P3 S5 T4 S6 T3 12 S4 P2,P4 S2 P2.P4 T2.5 Revise P4 P4 P4 P4.PS P4 P2,P4 A 92 P2.1 T2.1 72 2 T2.4 Study Ljlt Wnte customer requirements needs T4.1 Map requirements to building features T4.2 T4.3 Review similar Generate Layout layout Figure 7 Design process decomposition We can further arrange the design states and tasks along the time axis so that the time sequence among the tasks becomes clear. “Token” is used to identify the status of the current design process. The task can only be fired when each of its input states has at least one token. At the beginning of design, tokens only exist at the start states. Design process diagrams can be derived at different abstraction levels. The stakeholders with required expertise toward a certain design task can specify the details of the expansion o f a task. Then, with the similar steps to generate design process diagram, a hierarchy of 50 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. process diagrams can be built. For example, T2 and T4 can be expanded to more specific tasks and events (Figure 7). For each of the abstraction links, there is also a set of stakeholders associated, who will be in charge of that abstraction link. In this example, the stakeholders who are assigned with the task have the right to specify the detail tasks and events. When a task is expanded to a new process diagram, it is possible that some new stakeholders will be considered and included in the process. For example, the architect (P4) wants to ask the customers’ (P5) opinions about his building layout design. Then, the appearance of this new stakeholder (P5) might change the notes in the abstract process diagram. The roles of handling this are: • If a new stakeholder is involved in the new process diagram (detail process), the stakeholders who are in charge of the abstraction link will evaluate the role of the incoming stakeholders. • If the role of incoming stakeholder is critical to the new process (not a specific task in that process), then his name should appear in the immediate upper level of process. • The above step should be repeated in the upper level process until the role of the incoming stakeholders can be ignored. In this example, since P5 only have minor impact toward the execution of task 4, he or she is not shown in the general process diagram. Whether to expand a task or not depends on the complexity of the process and requirements o f the stakeholders. The objectives are to illustrate the process to a certain detail level so that the differences o f stakeholders’ perspectives are easy to be identified and design conflict can be clearly detected. 51 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4.3.4 Task 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 a major obstacle to concurrent task execution. Even for the routine design, as concurrency increases, 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 approach 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 o f 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. 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 o f 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 o f their decisions. Then, in collaborative design, it is impossible to totally remove the 52 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. interdependencies among the design tasks. Therefore, Coordination among design tasks appears to be critical to support successful design process. 4.3.5 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 planning 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 basis to decompose the task and organize the design process [42]. However, at the conceptual design stage, this product driven planning 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. One of the essential objectives o f design planning 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 o f design, to realize their roles in design process is an indispensable step in design planning. Then the way in which perspective evolution affects 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 the plan, short-term schedules are also necessary. They are different from design plan since they specifically focus on the 53 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. dependencies among sub-systems. In the CDPN graph, design schedule can be represent by interconnected Petri Nets with the coordination explicitly expressed. Information dependencies are implied in the task and event linkages. During the execution o f 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. Planing I Perspective — *• Realization Scheduling Dependency Recognition Coordination j Perspective Interfaces I Reconciliation Execution Perspective Evolving Figure 8 Collaborative design plan, schedule, and execution Therefore, our model represents collaborative design process in three levels with different considerations (i.e., planning, scheduling, and execution). Design perspectives should be serious considered in each level (Figure 8). Since we view collaborative design 54 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. process as a perspective evolution process, a coordination interface to clearly capture and support perspective reconciliation is vital to design process management. The following sections introduce a perspective model and a conflict management methodology, which support perspective reconciliation in design process. 4.4 Systematic Perspective Representation and Analysis 4.4.1 Concept structure hierarchy Product ___________J _________ Technical Decision * ' * Function Structure Behavior Design Methodology Energy Consum ption Function list Domains r a w in g ayafrrrj— . impact to environm ent FR1 Tasks FR2 Looking Design P aram eter A xiom a Norm Com pany Regulation Relationship specified by individual Relationship defined by group Figure 9 A concept structure built by stakeholders To generate the perspective models, the stakeholders first collectively build the Concept Structure. Concept Structure is an organization of the ontology that stakeholders propose and use in collaborative design [36]. Stakeholders should use both top-down and bottom-up 55 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. construction methods [89] to build the concept structure. It is possible to apply some templates (e.g., “product function template”, “design organization template”, “conflict types”, etc.) to clarify the concepts (Figure 9). These templates act as the contend-based skeletons for organizing the external data that stakeholder may share with others. For more routine design, stakeholders can extract many concept structures from previous product models and design documentations. When an individual proposes a new concept, he or she should first consider whether there are similar concepts in the structure. Thus, only the novel concepts can be specified and added. When stakeholders propose new concepts in design process, the concept structure is updated and is used to systematically organize these concepts and their relationships. The concepts are often best generated by individuals, while the concept selection and enhancement are often best performed by the group. Therefore, we classified the concept into two types. Shared concepts are those that have been well-defined from previous design and have widely accepted meaning among the stakeholders (e.g., “Requirement List”, “Function Structure”, etc.). Private concepts are perceived only by some particular stakeholders. Their names or meanings are not expressed around the group. Whether a concept is shared or not is relative to the purpose of a certain group, if a group o f people have shared purpose toward a concept, it would be better to have everyone to view it. Sometimes, a concept is not shared between two groups, but it might be shared within one group. After the concepts are identified, the dependencies among these concepts can be further clarified. For instance, the concept “function requirements” in technical decision will influence the “function” of product. The “structure” o f product is decided by the “design parameter” o f the design methodology. 56 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4.4.2 Perspective state diagrams Given the well-organized structure of design concepts, it is possible to ask the stakeholders to build the perspective model state diagrams (PMSD) at a certain time. A stakeholders’ perspective model state diagram attempts to depict the explicit relationships among his/her concepts (include the shared concepts and individual concepts) and his/her purpose and context information. The concepts listed in the PMSD are categories of perspective contents relating to stakeholders. They are not all information of the design stakeholders’ perspectives. In fact, using concept structure in the PMSD provides a structured way for us to systematically compare and examine the perspective differences among stakeholders. v e r s i o n * " ! .! ) ” ? * <»DOCTYPt p e r s p e c t i v e SYSTEM " P e rs p e c tiv e .d td * * > « O o c u w n t i t i o n > . . . < /O e o M tit« tio n > < R e te r_ p e s iq n C o n c e p t t » f * " P r o d u c t. Des ic m P e ra M C e r. E n v iro n m en t* * /^ < Purpose* « C x iC v ria > L o c * e io n s h o u ld b e C ar fro m r e a d < / C n t t r u > < C n t e r i a > . . . ^ / C r i t e r i a * ^ C o n te n t* < O p ttc n > 3 lte B i s n e a r ro a d < /O p tio n > < O p tlo n * 3 ite A i s t a x t r c a ro * d < /C p tio n > </C o n te n t* <C ontex£> < S e £ e r_ P e rs p e C tiv e rer* "O C _ 0 P _ 0 2 "/> < * e te r ~ P e ts p e C tlv « ret-"C S~D P~L C _0!* /> < /C o n te x t> < ’ DOCTYPE P e r s p e c t i v e 3Y3YEM " P « r ip e c ttv e .d C d " > <D o c u m e n ta tio n * .. ,< /O o e u A e n ta tlo n > < R e f e r_ D e s lq n C e n c c p t r e f * f r o d u c t .D e s lq n P a r a m e te r . L ocation** U s e r S a t l s C a c t i o n < / C r i t e r i a > c C r t C e t i a * . . . < / C n t e r i a * ^ C o n te n t* < C p tlo n * U s e r s e l e c t e d S i t e B < /C p tlo n > < /C o n te n c > < / P e r s p e c t i v e * Design Consultant Architect Figure 10 Generate design perspective models by concept structure 57 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Assume each stakeholder has already realized a purpose hierarchy (i.e., the stakeholder has specified his/her intentions within the design process). For each of the concept, there are a set of purpose, context, and content associated. The operation is to ask the stakeholders to: First, relate this concept to their purposes. There might be more than one purpose relating to one concept. For abstract concept, the purpose could be more general. For specific concept, the purpose is more detail. Second, specify the relationships of this concept to other concepts based on his/her context. If there are new concepts generated, add this to the PMSD architecture and set it as an individual concept. For each concept, declare his/her own knowledge/data about that concept and put them as parts o f the content of that concept. Therefore, a PMSD is the picture that depicts a stakeholder’s perception of design concepts and his/her related purposes, context, and content. Figure 10 shows two stakeholders perspective models (part of their PMSDs) toward some concepts. The following example illustrates the schema of PMSD using XML. <?XML version="1.0"?> <1D0CTYPE Perspective SYSYEM "Perspective.dtd"> <Perspective id="DC_DP_02" type="Product" stakeholder="Design_Consultant_l" time="2001-ll-10"> <Refer_DesignConcept ref= "Product.DesignParameter.Location"/> <Purpose> <Query name = "Why is this concept important to you"> </Query > <Query name = "What do you think others' goals of this concept will be in the design process"> User Satisfaction</Query > 58 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. <Query name = "How can you use this concept in the design"> </Query > <Query name = "List the most important criteria to satisfy your goals toward this concept"> </Query > </Purpose> <Context> <Query name = "When will you use this concept in the design process"> </Query> <Query name =" What are the related concepts"> </Query > <Query name =" Who do u think will need/change this concept"> </Query > </Context> <Content> <Query name =" If this concept relates to the product, list the document, or data you can find/provide"> </Query> <Query name =" Specify the most important things you know about this concept"> </Query > <Query name =" Other useful information about this concept"> </Query > </Content> </Perspective> 4.4.3 Perspective model Analysis It is possible to compare/analyze stakeholders’ perspective models and to determine the degree of agreement among stakeholders’ opinions. As shown in Figure 11, given the PMSDs for certain stakeholders, we can ask them to review the perspective models. Then it 59 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. is possible to use this review information to compare the perspective models and determine the similarity o f two stakeholders’ perspectives toward a shared concept. We can also aggregate multiple stakeholders’ perspective models and compare their general attitudes at different levels of abstraction. Furthermore, we can track the evolution of the perspective model based on the clustering analysis results. PM Network Perspective Review Perspective Model Clustering Analysis Perspective Abstraction Model Perspective Evolution Model Perspective Distance Matrix Figure 11 The perspective model analysis framework 4.4.3.1 Comparison approaches We define the similarity of two perspectives (e.g., i and j ) as the “distance” d, -. If d /j equals 0, it means two perspectives are compatible. If d t j equals I, then the two perspectives are opposite to each other. There are two approaches to determine the “distance” between perspectives: the intuitive approach and the analysis approach. The 60 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. intuitive approach relies on the insights of the stakeholder. The analysis approach uses mathematical algorithms to compare two perspectives. 4.4.3.2 Intuitive approach to determine the similarity of perspective models The simple intuitive way is to ask the perspective owners to review their PMSDs and derive the distances (i.e., the similarity ratios). The value of d KJ will be determined by d 'I J and d j j specified by stakeholder / and j respectively. A possible value o f d , ■ is the weighted average of the two estimations. When multiple perspective models interact together, their relationships become intricate. It might be difficult for stakeholders to precisely evaluate the similarity. 4.4.3.3 Algorithms to determine the similarity of perspective models Another way of comparing the perspectives is through “positional analysis”, which is based on a formal method used in Social Network Analysis [93]. In this case, the perspective models o f a group of stakeholders toward single concept are viewed as a network of opinions associated with each other (Figure 12). In this network, a stakeholder, who possesses a perspective model, has relationships to others’ perspective models. We define the relations as their perceptional attitudes toward each other. The rules are defined as: If Stakeholder P, agrees to stakeholder P j’s perspective model toward concept Cf (i.e., p ~ ( ), the perception relation is xt J = 1. If Stakeholder Pt disagrees to p, ! , the perception relation is x y = — I . If Stakeholder P( has no comments to p , r , the relation is xy = 0 . 61 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 1 2 4 7 Figure 12 A perspective model network For a given concept, a group o f perspective models are placed as a graph (i.e., perspective model network). The solid line indicates an " ‘agreement” and dot-line indicates a “disagreement”. This graph can be represented as a perspective interaction matrix as: 1 1 I 0 0 0 0 1 1 1 1 1 0 0 0 0 1 0 0 1 0 0 0 1 1 1 0 - I 0 0 1 0 1 0 0 0 0 0 0 0 I 0 0 0 0 -1 I 0 1 62 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The way we compare the perspective models is based on analysis o f the structure o f the perspective network. Two perspective models are compatible (or similar) if they are in the same “position” in the network. In social network analysis, position refers to a collection of individuals who are similarly embedded in networks o f relations. To precisely determine how the perspectives are involving together (i.e., the positional analysis), we need a formal definition of equivalence and a measure of the degree to which subset o f actors approach that definition in a given set of network data. If two perspective models are structural equivalent (i.e., their relationships with other perspective models are the same), we assume they are purely compatible and there are no detectable differences. That means they have same perception to others and others have same perception to them. In this case, these two perspective models are structural equivalent. Structural equivalence is defined as: Definition 13: Perspective model p \ r and p ^ ' toward a concept Cf are structurally equivalent if the relation x k l = x k J and x jk = x jk for k = 1,2,..., g . Since structural equivalence is a mathematical property, which is seldom actually realized in collected perspective data, we use Euclidean distance as a measurement of structural equivalence. Different from the d Lj defined in the intuitive approach, the Euclidean distance quantifies the similarity of the perspective models based on the analysis of stakeholders’ responses to each other. c c Definition 14: For perspective p , ' and P jf , d K J is the distance between rows i and j , and columns / and j of the perspective interaction matrix: 63 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The normalized distance is d t j = c c If p i ' and P j ’ are structurally equivalent, then the Euclidean distance between them will be equal to 0. The normalized distance matrix is shown below (Table I). For example, the normalized distance between 4 and 5 is 0.298812. 0 0.188981 0.353561 0.400893 0.422581 0.327329 0.4432 0.188981 0 0.400893 0.353561 0.377962 0.327329 0.48182 0.353561 0.400893 0 0.377962 0.353561 0.353561 0.566942 0.400893 0.353561 0.377962 0 0.298812 0.353561 0.626782 0.422581 0.377962 0.353561 0.298812 0 0.377962 0.582484 0.327329 0.327329 0.353561 0.353561 0.377962 0 0.353561 0.4432 0.48182 0.566942 . 0.626782 0.582484 0.353561 0 Table 1 The distance matrix showing the similarity of the perspective models If we want to compare stakeholders’ perspective models for more than one concept, we can generalize the above equation to measure structural equivalence across the collection of several perspective models (i.e., a perspective mode set). Definition 15: For perspective sets {p( C | ,p,C 2,...,pf"} and } for concepts C ,,...,C fi, xjjr is the perception relation from stakeholder i to stakeholder/on concept Cr . The value of the d tj is the distance between the perceptions from and to stakeholder i and j across the collection of R relations: 64 i .j Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. d U = a/S S t**- - X j k r ) 2 + ( X k,r ~ X k ,r Y ' ] V r= l *=l d u The normalized distance is d t , = — , • 7 i J l R g There exist different measures of structural equivalence. Euclidean distance and correlation are two typical methods in measuring positional structural equivalence. Correlation is preferred in measuring the pattern of perceptions between two perspectives (i.e., two stakeholders’ opinions). Euclidean distance is preferred in measuring the identity of the perspective relations. In our perspective model comparison, we use Euclidean distance since the purpose is to determine the similarity of the perspectives’ responses toward each other rather than the resemblance of the arrangements of the linkages in the graph. 4.4.4 Perspective model Abstraction and Evolution Within collaborative design, the participants and the organization interact together and build the shared reality in the social interaction process. It is indispensable to depict the structures of the perspective models at a certain point of time and the evolution of these models during design interaction. 4.4.4.1 Clustering Analysis to determine the relationship among perspective models Hierarchical clustering is a data analysis technique that is suited for partitioning the perspective models into sub-classes. It groups entities into subsets, so that entities within a subset are relatively similar to each other. We apply hierarchical clustering to the distance matrix to generate a tree structure (or a dendrogram), which shows the grouping o f the perspective models. 65 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The hierarchical clustering procedures can be divided into two different approaches: agglomerative and divisive. The agglomerative approach to cluster analysis, used by the nearest and farthest neighbor algorithms, is a bottom-up clumping approach where we begin with n singleton clusters and successively merge clusters to produce the other ones. The minimal spanning tree, on the other hand, uses the divisive approach, which is a top-down approach to successively split clusters to produce others. In collaborative design, the bottom- up clumping approach can be used to analyze the abstraction of various perspective models during the social interaction. The top-down approach is more suitable for investigating and separating the perspective models from a shared perspective model. There are three algorithms using the bottom-up clumping approach: nearest neighbor, furthest neighbor, and average linkage. Nearest neighbor algorithm, also called single linkage, uses the smallest distance between objects in the two groups. The distance between two clusters r and s is the similarity between two groups of perspective models. It is defined as: d(r,s) = m ia id u ),/ e (1 ,...,nr) , j e (l,...,«v) The computational method of nearest-neighbor clustering algorithm is: initialize C: C'=n; D(i)={x(i)}; I = l,...,n while (C'OC) { C'=C'-1; find nearest clusters D(i) and D(j); D'={D(i), D(j)}; return C clusters 66 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. .670309 - 0 3 4 5 1 2 6 7 D endroaram for sinalelinkaae cluster analysis Figure 13 Clustering analysis dendrogram: nearest neighbor algorithm Figure 13 shows the dendrogram generated by STATA program by using the nearest- neighbor clustering algorithm for the Euclidean distances on the perspective models. It shows the six levels of clustering hierarchies. The heights of the six levels are (0.28176342, 0.42754664, 0.49567636, 0.51225194, 0.55030247, 0.67030942) from bottom to top. In perspective abstraction analysis, nearest neighbor algorithm is optimistic since it considers the perspective groups are inclined to cluster together. Furthest neighbor algorithm, also called complete linkage, uses the largest distance between objects in the two groups. The distance between two groups is defined as: d (r, s) = max(d' j ), / e (1,..., nr ), / 6 (1,..., ns) Figure 14 is the dendrogram generated by using the furthest neighbor algorithm. It also has six levels with heights as (0.28176342, 0.42754664, 0.50211494, 0.5447655, 0.65211001, 0.95923659). Compared with nearest neighbor algorithm, the furthest neighbor 67 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. algorithm is pessimistic since it congregates the perspective models through evaluating the most different individuals. The average linkage uses the average distance between all pairs of objects in cluster r and cluster s. .959237 0 • 1 2 6 3 4 5 7 D endroaram for com oletelinkaae cluster analysis Figure 14 Clustering analysis dendrogram: furthest neighbor algorithm Figure 15 is the dendrogram generated by using the average neighbor algorithm. It also has six levels with heights as: (0.28176342, 0.42754664, 0.49889565, 0.52850872, 0.59294122, 0.83712245). These analysis results illustrate that the perspective models are grouped together at different levels of the clustering tree. In fact, these groups can be viewed as the abstractions o f the perspective models. Different levels present various generalizations o f the individual perspective models. A branch of the clustering tree at certain level implies an abstract 68 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. perspective model with certain granularity. The height o f the branch indicates the compatibility of the leaf perspective models. For instance, we can use a cutoff between level 4 and level 5 in Figure 15 to get three groups of perspective models as three clusters (e.g., P\.2.6’ P lA ,5’ P i )- .837122 ' : ----------- ----------------- --------------------- ------------------- ( Q 03 E £ 3 S ■a 2 0 • 1 2 6 3 4 5 7 D endroaram for averaaelinkaae cluster analysis Figure 15 Clustering analysis dendrogram: average linkage algorithm A cluster tree with simple structure and fewer levels means all of the perspective models have similar attitudes (or positions) toward others. Consider the simplest case, a cluster tree with only one level indicates all perspective models have equal distance from each other. Then, we can derive the global information by looking at the individual relationships. A cluster tree with fewer levels doesn’t mean the perspective models are more uniform. The height of the cluster indicates the distances (similarity) among the perspective models. If most o f the perspective models are within a cluster having short height, they are quite compatible with each other. In this case, the short branch illustrates a closely “shared” 69 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. perspective model. On the other hand, if the clustering levels are high, the perspective models are isolated from each other. It denotes that the perspective models are not well shared. We define the similarity o f the perspective models in a cluster tree as the average height. Definition 15: For a given clustering tree for a group of perspective models, the weighted average of the height o f the cluster levels is defined as: 2 "A /= l h, is the height o f cluster level n, is the number o f all perspective models under cluster level /. For example, for the weighted average height of cluster tree in Figure 12. nX J = (2 ,2,3.3,6,7) , the weighted average height is 0.54074. 4.4.4.2 Describe perspective model evolution The clustering analysis provides a systematic way to understand the structures of the perspective models and their evolution. Since the perspective models are changing during collaborative design, the evolution of the clustering tree can be used to depict the transform of the perspective models. For a given concept, a clustering tree at time t defines the £ relationships among perspective models p j i = l,...g . If at time t ■ + • 1 the number of levels of the clustering tree decrease and the average height also decreases, the perspective models are converging into fewer abstractions. This might indicates the stakeholders are achieving consensus. The derivative of the average height £ indicates the speed o f the changes of 70 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the distances among perspective models. Another approach is that we can investigate the changes of the patterns of the clustering tree within the collaborative design process and derive ways to interpret and interfere the perspective evolutions. 4.5 The Methodology to Support Collaborative Engineering Design As described in section 4.1, by examining the characteristics of the three control parameters (i.e., design process, stakeholders’ perspective, and conflict management strategies), it is possible to use them to achieve the observable output parameter, which is to manage design conflicts and improve the collaborative design quality. In this approach, conflict can be treated as a significant issue to identify perspective dependencies, to drive idea interaction, and therefore to improve design process. * time Design Process Model Rearrange Process / Perspective Models /Reconcile Perspective Conflict Management Strategies J Conflict Analysis Conflict Profile Figure 16 A methodology of supporting collaborative engineering design 71 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. To address this issue, we take a socio-technical approach to manage design process and conflict by representing and manipulating the design perspectives. This approach helps us to gain further understandings o f the intrinsic characteristics of these parameters and develop a methodology for supporting collaborative design. It can identify the strengths and limitations of different design theories and methodologies and discover the essences o f knowledge sharing and group decision-making during collaborative design. Furthermore, it helps people generate specific strategies to monitor, refine, and control the collaborative design process by successfully managing conflict within different negotiation mediums. The collaborative design support methodology can be viewed as a closed-loop system (Figure 16). It supports collaborative design by using conflict management strategies to control the interplay of design process model and stakeholders’ perspective models. It contains the following parts. • A feasible computational model of collaborative design process to represent the interactions of individual design tasks and to evaluate their affects to the product development, social interaction, and organizational evolution. • Generic methods to formally capture, represent, and analysis design perspectives and their interactions with each other. • Systematic strategies to manage design conflicts by a thorough understanding to their various causes, effects, and processes. • Control mechanisms to handle the interplay o f the three parameters by systematically analyzing their relationships to reconcile various design perspectives. 72 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4.5.1 Overview of the methodology The central focus of this research is to enhance the efficiency of collaborative design by controlling the interplay o f the design process, of the conflicts, and o f the stakeholders’ perspectives. Although “perspective” is critical for managing design interactions, traditionally it is not explicitly modeled in traditional information systems. Thus, it is critical to form the design perspective in a structured way so that the control mechanisms can be added. Also, to relate perspective models with design process models and design conflict model is indispensable for manipulating the entire design system. Our methodology not only uses an effective way of building perspective model and process model, but also provides an analysis procedure to identify the control factors in collaborative design. The control mechanism takes the social interaction features as means to detect, prevent, and resolve the conflicts. Also, it will help stakeholders to represent and adjust the design processes according to the analysis results. By adding “who” into technical decision-making process, it becomes a platform to support the con-construction among design stakeholders. The framework of the methodology is depicted in Figure 17. Since modeling stakeholders’ perspective is the key issue in our methodology, the first step is to identify the stakeholders involved in the design and to help them realizing their roles and purposes. These stakeholders jointly build the baseline process model, which is represented as a design process diagram. Then, by constructing the concept structure by the group interaction, the stakeholders can systematically build the Perspective Models. The Design Process Diagram and Perspective Model State Diagrams are transformed to matrices. They become the inputs of the socio-technical analysis. This analysis method will generate the Task Agreement Index and Perspective Abstraction Models to detect the conflicts in design process. Also, when referencing the analyzing procedure, it is possible to find conflict management 73 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. strategies and suggest stakeholders to apply them to affect the design process and design perspectives. (Who) Stakeholder Apply CM Strategy Socio-Technical Analysis Perspective Model States Design Process Diagram Baseline Decision Process Task Agreement Index Perspective Model Abstraction Figure 17 The Socio-Technical analysis framework of the methodology 4.5.2 Development of matrices from process A set o f matrices can be derived from the Process Model Diagram, the Concept Structure, and the Perspective Model State Diagrams. They provide the basics for the analysis work. The incidence matrix represents the design process diagram in terms o f the dependencies among the states and tasks. It also provides a way for describing the design 74 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. process information in a computational format. It is possible to reconstruct the process diagram in the computer from this matrix. Task dependency matrix captures the “rate of influence” among the tasks. The function o f this matrix is to identify the consequence of execution or corruption of one task during the design process. The effected tasks can be directly identified from this matrix. Task assignment matrix relates the stakeholders to the design tasks. In practice, this matrix is controlled by the stakeholder who has right to manage the design group and the design process. By looking at each column of task assignment matrix, it is clear to notice the stakeholders involved with a task. The rows within the task assignment matrix clearly depict stakeholders’ jobs. State participation matrix represents the stakeholders’ participation into different states. A stakeholder “participating” an event means that he or she plays some roles of deciding the status of an event and can make decisions of whether an state can happen or not. By comparing the task assignment matrix and state participation matrix, the differences among stakeholders’ roles are revealed. For example, although stakeholders PI has only Task T5 assigned, he will participate all of the states within the design process. It is clear that his role is to manage or monitor the process rather than to execute the process. Concept-Stakeholder matrix is generated from the perspective model state diagrams. It illustrates the stakeholders’ perspectives toward the design concepts. Task role matrix can be specified based on the task assignment matrix. It has similar structure as task assignment matrix but with different value. We use it to depict the difference of stakeholders’ influences toward all of the design tasks. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Control Incidence matrix (T-S) Task dependency matrix C T -T ) Task Agreement Index Process diagrams (T.E.S) Role m atnx (P-T) T ask assignm ent matnx State perception matrix (P-E) Perception Consistency Vector Concept Structure (C ) Task/Concept matnx (T-C) Concept/Stakeholder Matrix (C-P) Perspective State Diagram (P.S) Stakeholder (who) Task Perception Matrix Figure 18 Matrices used in Process Management socio-technical analysis Task-Concept matrix shows which concepts are involved (e.g., used, generated) within which task. It is generated from the concept structure and the design process diagrams. For each of the task, the stakeholders can specify a set of concepts that will have influences to its execution. Stakeholders’ perspectives are changed by interaction with others during design process. To analyze the relationships between design process and design perspective, we develop a mapping mechanism to link process diagram to perspective state diagram. Since each design task and state will handle a set of design concepts, we can define the relationships among task, states, and concepts. One the other hand, we define the role matrix, task perception matrix, and task consistency vector to represent the views o f stakeholders toward the design tasks. 76 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The perception matrix (V-T matrix) is generated by ask stakeholders to view the PMSD of each other and declare their attitudes toward each task. As shown in Figure 18, for each of the task, we can first find the concepts involved in that task from the T-C matrix. Then, from C-P matrix we can identify all o f the stakeholders who have perspectives toward a concept. After classifying stakeholders’ attitudes toward all of the concepts in o f a task, we can generally tell which stakeholders have same/different attitude toward a task. It should be noted that in the perception matrix, a person may have attitude but may not be assigned to the design tasks. When stakeholders view the perspective models for each others, it is possible to ask them to declare their attitudes toward the design tasks based on 1) his own perspective model related to that task: 2) his view toward others’ perspective models related to the task. Definition 8: A task perception matrix M lT = [/n( lJ ] is defined over the stakeholder set P — {/?],/7,,...,Pm} and the task set T = with the "attitude” value: l/rij if S' t tj ( t means positive attitude) /wjy = . - Mtij if st 1 tj ( t means negtive attitude) 0 if S' has no perception to fy rij is the number o f non - zero in column j . An example of the task perception matrix is shown below. M lT = 0 0 0 0 1 / 4 1 / 2 0 - 1 / 3 1 / 2 1 / 4 1 / 2 1 1 /3 0 - 1 / 4 0 0 1 /3 - 1 / 2 1 / 4 77 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4.5.3 Development matrices from perspective state diagrams During design process, the stakeholders specify their perspectives toward certain concepts as PMSDs. Each PMSD illustrates a stakeholder’s perspective model at a certain time. The perspective model network can be derived by asking stakeholders to review PMSDs and give feedback. Then the relationships among the perspectives can be represented as the perspective interaction matrix derived from the perspective model network. By calculating the Euclidean distance among the perspectives, we can generate the normalized distance matrices. It quantitatively represents the similarities among the PMSDs. Clustering analysis is then applied on these matrices to derive the abstraction of perspective models. 4.5.4 Conflict Detections 4.5.4.1 Detect task conflict After deriving the above matrices, we can use task perception matrix, task assignment matrix, and the role matrix to build the task consistency vector, which is defined as the following. Definition 9: A task consistency vector f^rv can be derived from the perception matrix: V = W TV VC PT ¥ I M,r is the declared task perception matrix, which can be derived from the following equations: M t r = M r r a Rt ilf p y — Af /v Af The operator a is defined as: 78 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. t e j ] = K y ] A l \ y ] where: # o f non - zero in a. c, , = (a, , x b: ,) -------------------------- — # o f non - zero in btJ To get the task consistency matrix, three steps are needed. Firstly, the task perception matrix is “filtered” through the task assignment matrix to represent all of the noticed attitudes of stakeholders. A/rr = M lT a M n, = " 0 0 0 0 1 / 4 ' '0 0 0 0 I ' 1 /2 0 - 1 / 3 1 /2 1 /4 A I 0 I 1 0 1 / 2 1 1/3 0 - 1 / 4 0 I 0 0 0 0 0 1/3 - 1 / 2 1 / 4 _ _0 0 I 1 I 0 0 0 1 0 - 1/2 0 1 0 0 1/2 0 1/2 0 0 0 0 1/2 - 1/2 1/2 Secondly, M ir is derived from the above matrix and the task role matrix Rr . The weighting factors of influence toward design tasks are considered at this stage. '0 0 0 0 1/2" 0 0 0 0 I ' 1 0 - 1 / 2 1 / 2 0 A I 0 1.6 0.8 0 0 1 0 0 0 0 1 0 0 0 _0 0 1 /2 - 1 / 2 1 / 2 0 0 0.4 1.2 1 0 0 0 0 1 / 2 I 0 - 0 . 8 0.4 0 0 1 0 0 0 0 0 0.2 - 0 . 6 1 /2 79 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Then, the task perception consistency vector is calculated by adding all o f the values in each column of the declared perception matrix. This means to consider all of the perceptions from the stakeholders for a task. V = iVf TV - TC I T v 1 0 0 0 0 1/2 1 0 - 0 .8 0.4 0 0 1 0 0 0 0 0 0.2 - 0 .6 1/2 I 1 - 0.6 - 0.2 1 Thus, it is easy to identify the low consistency (or potential conflict) on task T4. The above task consistency vector only addresses the conflict caused by stakeholders’ perspectives. By considering the dependencies among tasks, we can further derive the intensity of conflicts within tasks. It is done by calculate the task agreement vector. r ; = m t ® \tc\ = ‘1 0 0 0 0" 1 1 0 I 0 0 0 1 1 1 I I 0 0 -0 .6 = 0.6 0 0 1 I 1 -0 .2 0.12 _0 0 0 1 1 I 0.2 ® means to multiple all of the dependent tasks’ consistency factors together. The lower the value in T 'c , the higher the conflict intensity of that task. 4.5.4.2 Detect concept conflict Concept conflict indicates the incompatible viewpoints or decisions regarding to the concepts proposed and used in collaborative design. The perspective analysis can reveal the differences among the perspective models toward a concept. If a perception matrix has small d, j values, there is a high possibility of conflict among the stakeholders. 80 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The expected value o f the perception distance for a concept is: Its deviation is defined as: /( \ If d is close to 1, it indicates that the concept has high conflict ratio. The deviation A(/ approximates the spread o f the distances among the perspective models. It represents the creditabiiity of the conflict ratio d (a smaller deviation denotes a thinner spread of the d t / ). Considering the hierarchy of the concept structure, the conflict ratio of a concept also depends on the d of its child concepts. This is calculated by using the recursive accumulative conflict ratio d *: d° —s-d +^Tlwid ‘ , Concept set Cincludes all o f the immediate children o f the target concept. Weight s is the importance of d to d ° . The weights w,are for the child concepts. They has to satisfy: 4.5.43 Detect organizational conflict The clustering analysis breaks up the perspective models into different groups. Some of the groups can be mapped to the members of organizations. Hence, the distances among the different clusters of the perspective show the dissimilarity among organizations on a c m 81 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. concept. The different levels of the clusters might represent different sizes of groups. For example, stakeholder 1, 2 and 4, 5 in the previous example might belong to two groups respectively. The distance between these two groups is represented as height o f level 4. For a concept set C , if the clusters exit, we can discover the conflict between the groups by investigating the distances. 4.5.5 Development o f control strategies After identifying the various conflicts, one can check back to find the points to add control in collaborative design. The procedure of the above socio-technical analysis points out several ways we can use to manipulate design conflict based on the above mechanisms. The controls are added to affect the task consistency and perspective model similarity. The basic method is to use various means to manipulate the three inputs (i.e., the process diagram, the concept structure, and the perspective state diagram). This gives us guidelines to explore more strategies to handle the design conflicts in a comprehensive way. 4.5.5.1 Using the dynamical modeling approach The dynamical modeling approach suggests the use o f a set of “controls” to manage conflict and therefore to support collaboration. In general, these controls will be time dependent and will depend on the internal information stores and the perspectives o f the individuals comprising the design organization as well as the external data available at that time. For each individual ‘ j ’, the following dynamical system (for t= 0, 1,2,...) exists: t t j j . , +C».J (U H wA J ^ w,£i) V . = PlA fIj „ l) +Cr.J<UH,JUP,J,El) A . . . = ( » * » . ) + c o.j (U H jj j j ptJ , e , ) 82 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The controls Cy may also be thought o f as being provided through negotiation and provision o f additional information. Negotiation at the external data (CD -) level by simply checking for its consistency is not enough for supporting collaboration. It is indispensable to have support at the perspective {CP -) level and internal knowledge level (CH j ) . 4.5.5.2 Control mechanisms in the Socio-Tecbnical system Since various factors are functioning together intricately in the socio-technical system, it is very difficult to deduct the precise rules on the changing of the system. Although we identified various controls to affect the socio-technical system, we do not have means to predict the exact final effects. The real usage of the controls depends on the participants and the environment. Hence, it is feasible to view the methodologies a supporting platform for facilitate the socio-technical interaction. The system (e.g., a enterprise or a application) should define the quality measures to access the effects o f the control. These measures are based on the fundamental goals of the stakeholders. The normal quality measures are fast process execution, less rework, and low costs. When a conflict is detected in the design, suitable control strategies should be determined and applied. Figure 19 explains the different way of applying control mechanisms in collaborative design. First, it is possible to derive the monitoring signals (e.g., the task agreement index and the clustering tree). The process analysis uses the task perception matrix and process model to derive the task consistency index. This gives the basic indication of the conflict attributes of the collaborative process. The perspective analysis discovers the compatibilities among stakeholders' perspectives. Conflict intensity (i.e., the conflict ratio) is derived from the perception distance matrix. Clustering analysis further displays the hierarchy structure of the perspective models. 83 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Then, it is feasible for the decision-makers to notice the problematic elements in the collaborative design campaign and discover conflicts. The conflicts can be classified by three categories (i.e., the related concept, the group level, and the design phase) through tracking the concept structure, the clustering tree, and the task perception matrix. The system further analyzes the different conflicts to determine the proper strategies. The strategies will be implemented as controls to affect the execution of the process. For each of the conflict categories, the decision-maker can follow some guidelines or strategies to control the conflicts. Hence, the socio-technical methodology suggests a systematic and flexible way to apply the control mechanisms. The following describes some of the typical control mechanisms. f Internal > Information V Control J 'erspective' Control ) irganizatioi Control Process Control Data Control CM Analysis PSD (Process) PMSD (Perspective) Concept Structure Distance Matrix Task Agreement Index Incidence Matrix Task Perception Matrix Conflict Intensity Conflict Classification Clustering Tree Product Data Task Assignment Matrix Figure 19 A comprehensive Socio-Technical analysis approach 84 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4.5.5.3 Control Processes • Detect conflict earlier. By evaluating the feasibility of design tasks, which are in the plan but not be conducted yet, we can prevent some conflicts by noticing their potential existing earlier to the stakeholder. • Affect stakeholders’ perspectives. By providing information to stakeholders, it is possible to change the perception matrix and therefore to increase the consistency of a task. That requires directly adjusting the perspectives (their content, purpose, and context) to maintain the integrity o f the opinions toward design tasks. • Change the role of a stakeholder. We can change the task assignment matrix to modify stakeholder’ roles to change the resulting task consistency vector. • Add or remove stakeholders from a given task. It is even possible to add/remove stakeholders associated with a task to avoid the conflict situation. • Change the process diagram to reduce task conflicts. It is feasible to rearrange design states and tasks in the process to modify both the concepts structures and PMSDs to control the occurrence of design conflicts. 4.5.5.4 Control Perspectives It is possible to directly influence the perspectives (their content, purpose, and context) to maintain the integrity of the opinions toward certain concept or design task. • Identify the perspective models with low similarities and reveal the differences earlier. • Focus on the stakeholders who have singular perspectives and understand their rationale. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • Ask the stakeholder with different perspective models to talk to each other on certain issues. Build communication channels to increase their interaction chances. • Clarify the meaning/definition o f critical concepts so that people have shared understanding. Provide stakeholder different concepts to isolate their perspectives. 4.5.5.5 Control Organization The methodologies developed above provide mechanisms to analyze and affect the collaborative process and the perspective models. From these, we could further derive methods to handle other factors (e.g., the organization and product). We can monitor and manipulate the socio-technical interaction process by systematically applying these methods. • The clustering tree shows the grouping features of the perspective. If two stakeholders are separated form one group, the possibility of interaction will be decrease. • Moving the stakeholder with similar perspectives together might increase the clustering size. • Using different management structures will change the communication channels and the perception distances. 4.5.5.6 Control Internal Information This control mechanism is to affect the conflicts through influencing stakeholders’ internal information. That is realized by affecting the information access and comprehension during the design process. • Provide suitable trainings based on their perspectives and the job requirements. 86 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • Suggest the stakeholder review the relevant product information during certain tasks. • Record the discussions of the shared concept for future use. • Collect and provide the design documentations for critical tasks. 4.5.S.7 Control External Data This control mechanism is to affect the conflicts through appropriately providing and handling external data, which will be viewed and consumed by the stakeholders. Some o f the strategies are: • Use consistent checking and version control to maintain the product data integrity. • Track the changes of product data by referencing to the perspective changing. • Map the product data to perspective models so that the system realizes the specific impact of the conflicts toward design results. 4.6 Information Systems to Assist Collaborative Design Interaction 4.6.1 Realizing perspective in information system The methodology described in previous sections can be used as the underpinning for an original information system to assist the collaborative design interaction. Traditional CAD systems focus on representing and generating the knowledge of “what” related to product features. Various simulation tools are used to capture the knowledge of “how”. On the other hand, some design rationale methods (e.g. IBIS, QOC, and DRL) and knowledge management methods [41] [97] contribute to representing and documenting the knowledge of “why” during design. However, as the scale o f collaborative design increases, more social 87 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. and technical factors function together. When many distributed stakeholders use computers to coordinate their tasks, they may have little direct recognition of other’s intentions, preferences, and roles. The knowledge networks of the design team (e.g., knowledge of “who knows what”, “who knows who”, “who knows why”, etc.) and cognitive process of stakeholders evolve during design. Then, dealing with the understanding of “who” becomes indispensable to managing design conflict and successfully supporting design collaboration over the Internet. Context/Purpose Persi ectives Ontology Model Content BDB Integrated Enterprise Information Infrastructure Figure 20 The roles of information systems to support collaborative design As depicted in Figure 20, although various methods for product data integration are used in the current practices, their major focus is to map and link the various data from different isolated systems (e.g., CAD, CAE, etc.). In other words, they are trying to 88 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. accumulate, represent, and store the contents o f stakeholders’ perspectives especially at the parametric design stage. When inconsistencies among the data are detected, it is up to the people to really reveal the high-level sources o f the conflict, since the product model itself can hardly interpret the background information (i.e., the purposes and contexts). Hence, it is critical to facilitate the selection and utilization of the product data by helping the stakeholders notice the existing of others’ perspectives. This research develops the Socio-Technical Analysis Research System (STARS). It is a new information system to support design coordination by explicitly investigating and modeling the “people” aspects of collaborative design. This system can also be connected with the integrated product model by referencing the ontology model with the data abstraction model. They will function together and become the critical parts of the integrated enterprise information infrastructure. 4.6.2 Building collaboration protocolsThe information systems (e.g., STARS) The information systems (e.g., STARS) supporting the collaboration over the Internet will eventually realize a new paradigm for web-based engineering collaboration. It will provide a different level of abstractions on top of the current Internet communication functions. Previously, when talking about the Internet, people are always considering the four typical abstraction layers (Figure 21). Each layer provides services to the layer above it. It is necessary to have a protocol as a set of rules governing the format and meaning of the information exchanged by the peer entities within a layer. 89 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Intelligent Collaboration? t Service Integration I Information Sharing I Data Sharing Figure 21 Building collaboration protocols over the Internet From the Physical layer to Application layer, various protocols are built. For instance, the TCP/IP protocol defines the way of data communication. The HTTP protocol and HTML language provide effective means for information sharing over the network. As the development of the information technologies advances, higher layers are added to address and provide more functions. The lower layers are focusing on data transmission, while the higher layers are taking information sharing and knowledge integration as considerations. Currently, the web Service layer is being developed on top o f the web application layer. It describes specific business/process functionality exposed by companies, usually through an Internet connection, for the purpose of providing a way for another company or software program to use the service. Web service protocols (e.g., SOAP/UDDI) are specified to define the format o f the communication messages. Within the next couple o f years, the web service 90 CPML SOAP/UDDI Collaboration Collaboration Web Service Web Service TCP/UDP iN/ATM Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. technologies will be widely adopted. Its purpose is to provide a way for companies or software programs to share the service (i.e., special purposeful software). Since the service involves the “purpose” and “context” information o f people [30], we envision that there will be another layer on top of web-services. There will be collaboration information infrastructures to generate, publish, use, and co-construct the Web services in the organizational contexts. They can identify the people and their perspectives involved in the information-sharing process and provide control supports. On top of web service layer, the collaboration layer will be concerned with intelligent knowledge level interactions among various groups through the web services. It allows the stakeholders with different perspectives to jointly construct the shared meanings and integrate their processes. To achieve these, it also requires protocols to determine the collaboration implementation interfaces. The complexity o f the protocols increases from the basic layers (e.g., the physical and data link layer) to the higher layers (e.g., Web-service layer). The SOAP and UDDI protocol define the ways of finding and binding web-services on the web. It is built on top of the HTTP protocol, which is for basic web-based information transfer between applications. For the “collaboration layer”, the protocol will define the ways o f organizing the activities and using the web-services for the organization goals. The protocol has to describe the way people and organizations (not only the software) may interact. 4.6.3 XML in Web application architecture The XML-based Collaborative Design Process Modeling (CPML) technologies used in STARS realize a protocol for the collaborative layer. CPML uses XML as the basic format for process modeling. One o f the major goals o f using XML to represent design process is to 91 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. An XML document can be stored in relational database as a format that can be queried (e.g., Oracle 8i). Or it can be treated as a node in XML document repositories in Object- Oriented Database management systems. The database management systems take the responsibility to maintain the persistency and consistency of the XML files. In this case, XML is merely a special format of data structure in databases. In this circumstance, it is more suitable to treat a XML file as a document, which is relatively static and dose not require intensive updating (similar to HTML pages or CAD drawings). Otherwise, the data processing overhead is prohibitive. When XML is used as the format to transport data among the web applications, it is mostly handled as a data standard for communication. Since XML has a text-based format, it is convenient to be transmitted over HTTP. For example, XML files can be generated through a J2EE (Java2 Enterprise Edition) web application server. A Servlet/Jsp can easily send XML as response to the requesting agents with an understandable syntax. The parsing of XML files is handled by EJB (Enterprise Java Bean) with the DOM/SAX APIs inside the servers. The applications can exchange information over the Internet by simply requesting the JSP pages from each other. Another scenario is that the client (e.g., a web browser) reads XML through HTTP and interprets it via XSL. When transferring over the Internet, XML files are similar to messages with customized formats. Our fundamental goal is to derive a set o f feasible XML formats, which can enhance the collaboration system development and implementation. Since XML can be used differently under various contexts, there is no simple way to define how XML should represent a design process. The first critical step is to recognize what role the XML format will perform in the application architectures. Then, we have to understand its strengths and weaknesses in representing a design process. Some of the existing approaches ignored these and just plainly 93 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. mapped the Petri nets to their XML formats or used XML as a complicated programming language to define workflow [1]. It is difficult to apply these approaches in real system implementation. To overcome these constraints, we consider not only the correctness of the XML representation formats, but also the usability and scalability of the formats. 4.6.4 Applying MVC design pattern in XML-based process modeling There are generally three situations where process models are required to be represented as XML syntax: process data storage, process data interchange, and process data presentation. We need different formats, which have specific syntaxes to support each of these situations. Also, we need to define the interfaces among these formats. A useful approach is to examine the functionalities o f an information system and identify the requirements of XML formats for design process modeling. State Change State Query Change Notice View Selection User action Process Model • Capture the logic dependency •Encapsulate process state •Respond to state queries Process View • Define the presentation format • R equest updates from Models • Send selection to Controller • Allow controller to select View Process Controller Define process changing behavior • Updating process Model • Select different Views Figure 23 Applying MVC pattern in process modeling 94 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Model-View-Controller (MVC) architecture is a widely used design pattern for information systems (Figure 23). It separates three distinct forms o f functionality within an application. The Model represents the structure o f the data in the application, as well as application-specific operations on the data. A View (of which there may be many) presents data in some form to a user, in the context of some application function. A Controller translates user actions and user input into application function calls on the model, and selects the appropriate View based on user preferences and Model state. Essentially, a Model abstracts application state and functionality, a View abstracts application presentation, and a Controller abstracts application behavior. The MVC design pattern thus meets the design goal of rational system decomposition. There are many benefits to using MVC in a design. Separating Model from View (that is, separating data representation from presentation) makes it easy to add multiple data presentations for the same data, and facilitates adding new types of data presentation as technology develops. Model and View components can vary independently (except in their interface), enhancing maintainability, extensibility, and testability. Separating Controller from View (application behavior from presentation) permits run-time selection of appropriate Views based on workflow, user preferences, or Model state. Separating Controller from Model (application behavior from data representation) allows configurable mapping of user actions on the Controller to application functions on the Model. In an information system managing design process modeling, the Model captures the logic relationships among the tasks, states, and stakeholders. It encapsulates the states o f the process and can respond to the state queries. The View is an abstract layer providing the presentation formats to the user. It works on the query results from Process Models and illustrate the process data as readable formats. The Controller defines process model 95 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. changing behavior. It is a mechanism that can update the process model and select the correct View formats. When XML is used to represent the CDPN process model, it is a marked text file, which represents the data structure o f the logic relationships. The XML files can be stored as process documentations or be transmitted as process interchanges. When exchange process data, a good strategy is to separate the presentation style from the logic content, as different applications might have their own presentation requirements. How the data is presented is handled by the view format. Separating content (logic model) and style (view format) makes it possible to use multiple presentation formats for the same process. For example, if one application integrates a process model from another system, the geometric locations of the “tasks” and “states” in the process diagram are all changed. But the logic dependencies are kept the same. 4.6.4.1 XML Based Process Modeling Languages The MVC pattern provides a structured way for us to model the design process as XML formats. This research presents three modeling formats to address the logic model, style, and control of a design process. CPML (Collaborative Process Modeling Language) captures the logic structure among tasks, states, and stakeholders. All o f the topology related information is captured in a XML file. It does not contain information on how the process graph is drawn. To simplify the format, A CPML has four basic elements (task, state, arc, and stakeholder). Since these four elements are enough to depict all of the workflows, the usability of XML is enhanced in this way. That is one of the advantages o f CPML, comparing with other XML based process schema (e.g., XRL uses fourteen routing elements [1]). 96 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CPSL (Collaborative Process Style Language) represents the display format o f a process. It defines how a process viewer (e.g., a browser, a applet, or a application) shows the process to users. The concept is similar to using XSL to define how the XML are shown. Given the same CPML, a process viewer can use CPSLs to present the process differently. In the future, it is possible define the CPSL to map different CPMLs. For example, a CPSL can be used to show multiple processes on the same graph. The basic CPSL defines the coordination of the tasks, states, and arcs in a graph. Also, it specifies the line, shape, and text attributes of the processes. CPCL (Collaborative Process Control Language) defines the actions the system can take to modify the process model. It serves as a standard way for updating and modifying the process model. Since CPCL is mapped to XML parsing functions, distributed applications can use CPCL to control the remote process models or to share the process changing information. 4.6A.2 Semantics 4.6.4.2.1 CPML CPML defines four elements: task, state, arc, and stakeholder. To keep the language generic, we only define the most common attributes (e.g., start-time, token number, etc.). Users can customize the elements by adding <Param/> tags in the elements. A task has start time and end time. It may have status: “never execute”, “executing”, “executed”. The related stakeholder and his roles are marked as “assign”. It can also has sub process, which is another process model expanding a task. <task name="T2" status-'never execute" start_time=''mm/dd/yyyy" end_time=”mm/dd/yyyy"> 97 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. <sub-process name="Building2-requirement-T2" /> <description> Gather customer needs <description> <assign> <stakeholder>P3</stakeholder> <role>execute</role> </assign> A state has the following statuses: “never occur”, “occurring”, and “occurred”. The token number shows the current possessed tokens. <state name="Sl" status="occurring" token="l" start_time="mm/dd/yyyy" end_time="mm/dd/yyyy"> <description> Start of environment design </description> <param name="initial" value="yes" /> <assign> <stakeholder>Pl</stakeholder> <role>check</role> </assign> <assign> <stakeholder>P2</stakeholder> <role>check</role> </assign> </state> 98 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. A CPML process file can be used as a template, a workflow plan, or an execution snapshot. A template is just an abstract structure format and needs to be further elaborated. A plan has the complete logic dependencies, but does not require the detail status information of the tasks and state. An execution snapshot shows the status (e.g., the token number, start/end time, etc.) of each task and state. This usage property is marked as a “use_as” attribute in a CPML file. In the process, both task and state can have time duration. We have to define the time dependencies among them to prevent the ill situation (e.g., token disappear). There relationships are defined as follows: • A State expires (or stops) when all its tokens are removed by its output tasks. • A Task removes the token in its input State only at the end of its completion. • When a Task completes, its output State immediately gets the token and starts. Token# time Latency G)- * SI ] ~ o © 4 o O - *]- *©) l S2 SI T1 S2 SI T1 S2 Figure 24 Time dependencies between task and states 100 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. This is illustrated in Figure 24. Hence, in the process, the end of an input state, the end o f a task, and the start of an output state occur at the same time. If a task has not been completed, no token transmission happens. The end time o f SI, start time of S2, and end time of T1 are all the same. This rule guarantees that there is always at least one state occurring in the process. Otherwise, there might be consistency problems during the process analysis. The difference between start of T1 and start o f SI is called ‘'latency”. In practice, that means the time for T1 to wait for some extra condition to happen. Sometime, a state will have a “choice” condition, where one o f the output tasks will be selected. The token can only move toward the selected task. CPML has a mechanism called Valve to handle the choice situation. A valve is installed on an arc, which connects a state to a task. A token can be moved from the state toward the task if the valve in that arc is “open.” Whether the valve opens or not depends on the condition of the valve. Specifically, a valve is open if and only if the open condition (<opencond>) is true. The state controls the condition according to a set of logic rules. For a choice situation, only one of the output arcs of the state may open. The state determines the condition and sets the status o f the valves. The following example shows the choice situation (S6) in the process shown in Figure 4. <arc name="AcS6_T5" from="S6" to="T5" weight="l" <valve status="close" > <opencond>S6_Rework</opencond> </valve> </arc> <arc name="AcS6_T6" from="S6" to="T7" weight="l" 101 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. <valve status="open" > <opencond>S6_Continue</opencond> </va!ve> </arc> The two arcs have references to two conditions, which are determined in state S6. In S6, the status of the two conditions and their dependencies are given. The status of Condition “S6_Continue” has to be opposite to the one of “S6_Rework”. This constraint is defined in "S6_Cons,\ which is the constraint to the State. A State has to satisfy all of its constraints. The difference between condition and constraints is that the former specifies the decision and the later regulates the token movements. <state name="S6" status="never occur" token="0" start_time="mm/dd/yyyy" end_time=''mm/dd/yyyy"> <description> Layout Check <description> <param name="initial" value="no" /> <assign> <stakeholder>Pl</stakeholder> <role>cneck</roie> </assign> <assign> Ota keholder>P2</ stakeholder > <role>check</role> </assign> <assign> 102 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. <stakehoider>P4</stakeholder> <role>check</role> </assign> <condition name="S6_Rework" status="fales"> Layout check cannot pass </condition> <condi.ti.on namo="S6_Continue" status="trua"> Layout check passed </condition> <cons name="S6_cons" status="true"> numberOf (condition— TRUE) =1 </cons> </state> 4.6A.2.2 CPSL The CPSL defines the display attributes of the process in a graph context. The following shows the example. It defines the geometric attributes (e.g., font, location, line, etc )of the states and tasks in the graph. ctask id="Tl"> <textattr font="Courier New" size="9" just="Center" color="black"/> <lineattr type="Solid thick" thick="0" color="black"/> <fillattr pattern="None" co!or="white"/> <coord x="140" y="100"/> <box h="40" w="10"/> <dynamattr statusLeolor="red" status2color="green" status4color="gray" shrink="none" /> Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. < / t a s k > <state id="Sl"> <textattr font="Courier New" size="9" just="Center" color="black"/> <lineattr type="Solid thick" thick="l" color="black"/> <fillattr pattern="None" color="white"/> <coord x="100" y="100"/> ccircle r="20"/> <dynamattr statusicolor="red" status2color="green" status4color="gray" shrink="none" /> ctoken.atzr r="4" color="black" overlap="yes"/> </state> <arc id="Sl_Tl"> <lineatcr type="Solid" thick="0" color="black"/> <fiilattr pattern="None" color="white"/> <begin x="120" y="100"/> <end x="135" y="100"/> <arrow size="large" stye="bold"/> </arc> 4.6.4.2.3 CPCL The CPCL file defines the methods and actions to control and update CPML. It serves like a scripting language for convenient execution of series commands. This function is somehow similar to the build.xml configuration file of Ant, which is a very popular compile 104 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. tool. A set of actions can be grouped as targets. The targets depend on each other to perform complicated actions. <target name="Conflict_reps1" depends="Process_Clean" prccess=" Building2-requirement" > <!— below are structure (graphic) change operations — > <addTask name=" " status=" " . . . / > <deleteTask name=" " /> <addState name=" " status=" " . . . / > <deleteState name=" " /> <addArc name=" " £rom=" " to=" "... /> <deieteArc name=" " /> <addStakeholder name=" '*/> <aacLAsign stakeholder^' " to=" "/> <deletAsign from=" " stakeholder=" "/> <i— below are attribute change operations — > <setTaskA.ttr task=" " paraia=" " value=" "/> <setStateA.ttr state=" " param=" " value=" " / > <setArcArtr arc=" " param=" " vaiue=" "/> <setStakeholderA.ttr param.=" " vaiue=" "/> <1— below are choice condition update— > 105 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. <addValve arc=" " name=" " status=" " cond=" "/> <deleteValve arc=" " name=" "/> <addCond state=" " cond=" " status=" " / > <deleteCond state=" “ cond="/> <addCons state=" " cons=" ' ' status=" '*/> <deleteCond state=" " cons="/> <setCond state=" ” cond=" ” status=" "/> <setCons st:ate=" ' * cons=" ” status=" " / > <!— below are execution status update— > <fireTask task=" “ /> <fireTasks > <task name=" " / > <task name=" "/> </fireTasks> </target> 4.6.4.3 Examples The XML file in Appendix is the complete CPML representation of the process shown in Figure 4. 106 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4.6.5 Developing collaboration information infrastructures 4.6.5.1 Supporting collaborative design at different levels The socio-technical methodologies described above provide systematic ways of supporting collaborative design practice. Derived from these methodologies, the collaborative engineering information systems (CEIS) can be developed and adopted in the collaborative engineering design at different functional levels. A system that can manage the design process provides the possibility for identifying and improving the coordination among stakeholders. This is the first level of the collaboration support. Then, perspective modeling and conflict detection can be applied upon the process management to achieve the second level of collaboration support. The first level and second level of collaboration support focus on improving the group performance within an enterprise. Once the information systems are widely deployed. There is possibility for realizing collaboration within larger domains (i.e.. Collaboration enabled business-to-business services). 4.6.5.2 Basic collaborative design process management One of the primary functions of a CEIS is to provide an interface where users can browse through to realize what is going on in the team. The process management typically starts when the user initiates/edits a process. Once a user logins on the system through web browser, the system will identify his role. The users can point the project they want to modify or can construct a project. The system will provide the decision-makers some templates to begin their complicated job. They can select the templates o f the process they want to follow. Then, the user with a management role can set the overall objective o f the project and link the project to a set o f products. He or she could assign/remove different engineers to/from the project team. Then the manager and other engineers can jointly draw 107 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the process diagrams for the project. The manager will specify the resources and other attributes of the project. The engineers will help the manager to find the logical dependencies of the states and tasks. They can browse through the process builder to select the tasks and further expand the process diagram. The system provides user interfaces for them to modify task attributes or provide suggestions to other’s process. Plan Information Execution Information T a s k s list S ta te s list T a s k s D u ratio n S ta te s D u ratio n T a s k S ta te D e p e n d e n c y R e s o u r c e E stim atio n T a s k a s s ig n m e n t P r o c e s s D eco m p o sitio n % • T a s k startffin ish tim e • S ta te s sta rt/fin ish tim e ► • T a s k S ta te D e p e n d e n c y • C h a n g e • R e s o u r c e C o n su m p tio n • S ta k e h o ld e r ro le c h a n g e P r o c e s s te m p la te G e n e ra l T a s k A ttribute G e n e ra l S ta te A ttribute ■ i ----- - m iV jj Process Template •D e p e n d e n c y m a in te n a n c e • P ro c e s s te m p la te sto re • P ro c e s s s e a r c h e n g in e •C o n n e c tio n to p e rs o n a l o rg a n iz e r • P ro c e s s u p d ate/m o d ificatio n D e p lo y e d p r o c e s s c h a rt P r o c e s s p la n sim u latio n R e s o u r c e c o n s u m p tio n c alcu latio n S c h e d u le C o n flict M ag. R e s o u r c e C onflict M ag. D elay t a s k w a rn in g H u m a n w o rk lo ad e stim a tio n P r o c e s s p e rfo rm a n c e s ta tis tic s Process Monitoring Figure 25 Basic collaborative design process management After the plan process is built, the system can simulate the process. It calculates the process duration and resource consumption. It also detects the logic error that might occur. During the process execution, the system shows the users the plan process and the real execution process. When there is delay or violation of the real process, the system will give warning to the user and mark it on the diagrams. The outside people (e.g., customer, 108 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. consultant) are allowed to view some tasks/states of the process. They can provide suggestions to the processes but cannot modify them. Based on the warnings, users can change the process plan, so that the real process can be affected. For example, they might add some tasks, or relocate some resources. During the process, the system automatically sends email to the users to remind the milestones or the changing of the diagrams. Then, the informed users directly find the changed parts of the process that relate to their interests. The system will store the plan and the real executed process diagrams after the process have been finished. They are categorized and can be searched from the system database so that users can review the old processes before initiating any new processes. The process information is shared with other IT tools, such as the cost reporting tools, CAD version control tools, and human resource tools. It also provides the input for business intelligence tools, which are used by the companies. Figure 25 shows the data processed through the system. The challenge is that the system has to support concurrent access of the information in the process database. At the same time, the speed o f the process-editing tool should not be too slow. Otherwise the user might lose patience to use it. 4.6.S.3 Perspective modeling and conflict management The second level of functionality implements the perspective models and the control mechanisms. It is based on the process management functions. When users declare the perspective model into the system, they can view the evolution o f the shared understanding within the group. Once a user selects the projects, the system shows him or her the concept structure displaying a tree structure containing ail of the various terms that people use in the projects. The user can also view the concept definitions and dependencies. They can also review the product data that relates to the concept through hyperlinks. The system can 109 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. identify “shared” or “private” concepts based on whether all users within same project agree with the definition of a concept. A user can propose a new concept in the system and point out the dependencies to other concepts. He might also add/edit concepts to his own workspace. The user with a management role can remove/add concepts according to the discussion of the groups. For each of the relevant concepts, a user declares own purposes to use that concept and specifies what documents will relate to the concept. Concept Structure Perspective Declare • B a s e c o n c e p t term •S n a re d / private c o n c e p ts •C oneept-S takeftokJef relation •C o n cep l-C o n cep t r e ta tn n s n e •C o n cep t-T ask relatxxtsftip •C o n cep t-S tate relation snip • B a s e C o n c e p ts •P re -u se d c o n c ep ts •C o n cep t relation e a s e d o n d e sig n M etnodologies ■C oncept relation B a se d o n g roup conditions • Industrial sta n d a rd s •D a m a n c o n c ep ts Concept T emplate I 4 * m m i r L •C o n cep t tem p late sto re •D ep en d en cy m ain ten a n c e •S o o o -T ecn m cai A nalysis •C o n cep t s e a rc n e n g in e •in teg ra te with p ro c e s s m odel •P ersp ectiv e m o d el update/m odification • C o n tex t, p u rp o se , co n te n t for e a c fi c o n c e p ts /re ta tio n sn p s • C u rren t s ta tu s o f c o n c e p ts • P e rsp e c tiv e C h a n g n g report • P r o c e s s feasibility (ta s k c o n sisten cy ) estim atio n 4 • S ocial N etw ork g rap n • C o n c e p t tra c k n g w rth n p ro c e s s • Conflict d e te c tio n n p ro c e s s • Conflict d e te c tio n n g ro u p • Conflict d e te c tio n r c o n c ep ts » P ro d u c t d a ta m a p p n g to co n cep ts • P ro d u c t d a ta m a p p n g to p ersp ectiv e m o d el • Conflict m an a g e m e n t guideline • C onffict/P erspectrve cftangm g profile Perspective Reconciliation Figure 26 Perspective modeling and conflict management Engineers/managers can view others’ “purpose”, “content”, “context” for the shared concepts. They declare degree of agreement or add some comments. During the process, a user can check the evolution o f the concept structure. The manager sees the conflict profiles calculated by the system. These profiles show the number o f unsolved conflicts according to 110 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the process. The system will also mark the process plan diagrams to illustrate the tasks with high conflict possibility. To achieve that, the system asks the engineers to view other’s comments toward the shared concept so that they can immediately notice the difference among their understandings. When the user points on the conflict profile, the system displays a list of the conflict types. It also finds the conflict management strategies and provides some guidelines and suggestions. Some of these guidelines are generated from the history of other project with similar cases. The system doesn’t intent to resolve the conflicts automatically. It provides facilitates to support the ways of managing conflict and sharing perspective. The basic idea is that it helps the group know the existence and influence of each other. The data process diagram is shown in Figure 26. 4.6.5.4 Collaboration enabled business-to-business services When multiple CEIS systems run together among the enterprises, the design information can be shared among different groups. The systems will enhance not only the collaboration within a group, but also the collaboration across the boundaries of companies. Current business-to-business transactions are focusing mainly on the supply chain management. What transferred between the different servers is mainly product order and financial information. In the future, there will be systems to transfer enterprise knowledge between different systems. Figure 27 shows the data processing of collaboration enabled e-business. The following scenario describes the usage of the CEIS systems. Company A wants to find a partner to develop an advanced fast-speed web-phone. The manger o f the company wants the cell phone to support videoconference. The managers search on the service center provided by the CEIS and finds a couple o f companies having the techniques o f video processing (since III Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. some technical terms used in these companies are similar to company A). Company A searches the CEIS and finds the information of those companies. Company B is noticed since it registered as an institute listed as a service provider. Company A and Company B then decide to jointly develop the product. They organize individual groups. These engineers never meet each other and have different backgrounds. To facility the communication, they decide to share some of the information in their CEIS systems. Then, company A can access some concept structures o f company B, which are very relevant to the joint project. The two companies discuss the meanings of the different concepts in their concept structure and derive a mapping dictionary to translate the concepts. They find that it is easy to merge the process o f the two companies through integrating their CPML diagram templates. When the managers decided to follow the same process, they set up a shared project in their collaboration systems. For the engineers in each company, they can still keep most of their own terms (some modification might incur) during the design. But the meaning becomes clear to other company. During the project, Company A and B might feel some process of the product development are really difficult to manage since there are no templates to follow. They can search on service center and find the templates available from Company C. If Company C wants to share the experiences of some of its projects, Company A and B can order the CPML templates through the service center. Their collaboration information systems help them do it automatically. 112 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Concepts Perspectives Concepts Perspectives Concepts Perspectives C o n cap t-P ro d u ct M apping P ro c ass-S a rv ic a M a p p n g •Concepts •Perspectives • S h a m g /M a p p n g C o n cep ts • P ersp e c tiv e Com parison • P ro c e s s integration Enterprise integration B2B Figure 27 Collaboration enabled business-to-business services 4.7 A Scenario This section describes a scenario to explain the application of the socio-technicai methodologies. It presents different conflict management approaches and discusses their potential influences to the conflict problem. Necessary assumptions are made to simplify the analysis. In the collaborative design process described in section 4, a design conflict occurs. The conflict is described as: “At the first meeting, the client’s design consultant states that the building is to be placed at location A on the site. The architect listens to the client’s reasoning but notes that this location is not ideal from either an aesthetic or a functional point o f view, since it would be too close to a major road intersection.” 113 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Technical Decision G a U w client sp ace u sage j information: S p a c a allocation requirem ent 1 analysis: Product P ersonnel schedule; P ersonnel toads: S p a c a usaga: < luilding spaca usaga n o t available A Architect Technical Decision W wbng for tha layout from th e d esign consultant Product S p aca allocation; I — S p a c a u saga: nlding environment; Building regulation; Building sh ap e. m atanaL^ i^SuW ing should not O s' [ vary n e a r to road intersection. B u ilding lo ca tio n n o t - a v a ila b le ^ Organization T he role is not wail defined yet I Building location is > > • c h o sen by u sers. [ Organization I Us«r prefer loc* io n A. | Product Report to owner. View clients a s information source: ! ■ : | location A is n e a r road: \ ] location B is far from road: : Only A and B and C a re •! feasible S p ace usage: P ersonnel schedule: Functionality. Organization Design Consultant Client C M atnx structure organization I D ependency noticed Inconsistency noticed Figure 28 Detecting conflict from Perspective Model State Diagrams Comparing the Perspective Model State Diagrams can help us notice the dependencies and differences o f views among the stakeholders. At certain design stage, the conflict can be detected by tracking and mapping the “perspective state” of different stakeholders. In this section, we discuss two situations separately. The first is the one without assistance o f the conflict detection methods. The second considers the application of our approaches. According to the design process, the PMSDs of the design consultant and architect at the early design stage can be depicted. The design consultant first proposes the design plan and the clients and architect only accept without detail reasoning. Since there is no interaction at this stage, most of the design perspective elements o f the architect and the client are left empty. At the conceptual design stage, the contents of the PMSD elements for each stakeholder are increased. However, due to the loss o f coordination, the differences and 114 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. dependences are still not noticed by them until the next stage. When the architect is discussing with the design consultant about the detail feature o f the building, they realize that there might be a conflict. In this example, when the PMSD elements are compared with each other at early stage (Figure 28), although there is still no direct meeting between the stakeholders, the system can detect a potential conflict during the design process. The attitudes of stakeholders are shown in the following matrix derived from the PMSD. A/,t — Assume we give Stakeholder S2 and S4 equal right for conflict detection. Then a potential conflict in task T3 can be detected by looking at the task consistency vector. 0 0 0 0 1 / 4 1 / 2 0 - 1 / 3 1/2 1 /4 1 / 2 1 1/3 0 - 1 / 4 0 0 1/3 - 1 / 2 1 /4 A /cy = A Rp — "0 0 0 0 1/2" "0 0 0 0 f I 0 -1/2 1/2 0 A 1 0 1 0.8 0 0 1 0 0 0 0 1 0 0 0 _0 0 1/2 -1 /2 1/2 _0 0 1 1.2 1 _ 0 0 0 1 0 - 0 . 5 0 I 0 0 0 0.5 0 0.4 0 1/2 0 0 - 0.6 1/2 0 0 0 I 0 - 0 . 5 0 1 0 0 0 0.5 0 0.4 0 1/2 0 0 - i r - 0.6 1/2 1 1 0 - 0.2 1 To control the design process and manage this design conflict, we want to transfer the ill-structured design process to good one. An approach to achieve this is to derive the 115 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. mechanism to modify the consistency vectors. The obvious way is to change the perspectives o f the stakeholders so that the task consistency is improved. For example, if we suggest stakeholder P4 to discuss with P2 on Task T3, they may share some ideas and reach a status of consensus. That means the inconsistency of Task T3 have been reduced. The perception matrix and the task consistency vector are changed to 1 ■ 0 0 0 0 1 /4 1 1 / 2 0 1/3 1 /2 1/4 1 1 / 2 1 1/3 0 - 1 / 4 V = » V TC I - 0 . 2 0 0 1/3 - 1 / 2 1/4 I Since designers’ perspective will largely depend on the interactions among the design tasks, arranging the design process to a desired manner becomes an effective approach to coordinate the perspectives of the stakeholders. The socio-technical methodology provides an algorithm to help people rearrange the design process to reconcile the design perspectives and resolve conflict. When conflicts happen, from the dependency matrixes the system can identify the affected design tasks in process view. Then a possible solution is to modify some tasks or search for a new task to remove the conflict source. Sometimes, effective handling o f design conflict will eliminate the task iterations and shrink the design process. For instance, after the methodology detects a conflict in task T4 of the process diagram (Figure 29), it will suggest several ways of control that conflict by examining the perspective models involved in the related tasks. A possible solution is to add a task before state S5 so that the necessary design information is derived earlier. Then the process is modified to prevent a conflict. 116 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. P1.P2 P2 P1.P2 P1.P4 * P1.P2.S4P1 S1 T1 S3 \P2.P4 P1.P3 P3 P1.P S1 T1 S3 \P2 P4 P1.P2.P4 P1.P3 P3 P1, Task may have conflict Original process Modified process T5 Figure 29 Adjusting design process to manage conflict 4.8 Validation of the Theory and Methodology The socio-technical approach provides models and methods to assist and improve the collaborative engineering design practice. It is important to ensure that the theories and methodologies are on a sound basis. The normally used ways to validate a methodology include mathematical proof, experiment, simulation, and practical usage. Mathematical proof and simulation are more suitable to well-defined and close systems. Experiment and practical usage are more suitable to open systems, which are not precisely defined and might involve new parameters. Since the socio-technical methodology developed in this research is more inclined to be a descriptive model and an open system, it is difficult to use complete 117 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. mathematical deductions to prove its effectiveness. This research uses experimental approach to corroborate the correctness of the theory and methodology. The validation contains tree steps. First, the experiment infrastructures are built. The STARS system is developed as an experiment apparatus. It demonstrates the usability and applicability of the methodology. This research also develops a simplified procedure to help stakeholder apply the methodology in their real practice. Second, the experiment data collected by the experiment infrastructures are collected and analyzed. Groups of stakeholders working in a national construction research institute have been using the socio- technical methodology in small projects. They were asked to fill a set of survey forms to provide design information, such as the collaborative process and perspectives. Another way is to use STARS to collect collaborative design data as the users enter information based on the feedback control provided by the system. Third, the results by using the socio-technical methodology are investigated and compared with the way without using it. The stakeholders who participated the experiment considered that using the systematic methods could improve their design at least in two ways. The collaborative design processes are easier to be planed and managed using CDPN as a modeling tool. The conflicts could be detected earlier in the process and the causes are more comprehensible when applying the analysis methodologies. 4.9 Prototype Implementation The STARS system is developed as a prototype system to validate the socio-technical theories and methodologies. It demonstrates the feasibility and computability of the analysis algorithms. On the other hand, it collects process and perspective data once stakeholders use it as a collaboration support tool. By investigating the data, we can determine the effectiveness o f the socio-technical approach and therefore improve it. 118 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. As mentioned in Section 4.6, STARS system provides a web-based environment that supports the design process representation, conflict management, and knowledge integration within the design group [57]. Its objective is not to substitute the current CAD or MIS tools, but to fill the gaps of design coordination, which are ignored in the current design support technologies. Stakeholders’ perspectives are modeled in the system and their roles in the design tasks are depicted. Advanced communication tools with networking and server-client database accessing functions support the stakeholders to declare, share, and modify their perspective models. The system provides functions to detect, analysis, and track the conflicts during design process. It also supports the business-to-business process communications. STARS has some unique features. First, the system takes responsibility to detect the conflicts among stakeholders’ perspectives and thus support their knowledge integration. Second, it helps design group to manage the decision process for design coordination by referring to the conflict management strategies. Third, it explicitly maintains social dependencies and organizational changes within the design group. Fourth, STARS traces the merging of design knowledge in the design process and captures the new concepts and ideas. 4.9.1 System architecture As shown in Figure 30, on the client side, each stakeholder uses a set of unique web- based interfaces to declare his or her perspective and access the design information. These HTML and Java applet Swing interfaces in the Internet browsers are connecting with a perspective management system on the server. To facilitate the applets’ communication with the server applications, Java Servlets are implemented on the sever side. By using HTTP for communication with servlets through serializable java object, the applets are made 119 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. compatible with network firewalls. Stakeholders access the product data, the organizational data, and others’ perspective models when they operate their own workspaces. Client Client Stakeholders Client L^TM U SchpTJl L^nMWSchpJ L ^fT M L JScriprjj Internet fwww. TCP/IP. HTML. XML..) 4- HTTP Servlets/JSP (JSDK) Service M anager P r o c a u BulderATIewar Product Buildar/Vlaww C o rtlc t Viewer Perspective Model Bulder/Vlewer Organization Viewer Organization M anagem ent GUI /View .Control Perspective M ana gem ent Process M anagem ent M anagem ent M anagem ent Enterpnse Connector Stakeholder EJB Conflict EJB Process Task/State Model _______ l _______ V y . ---- ----------- f r a r l DBMS Figure 30 STARS system architecture In the perspective management module, perspective models are transformed to XML files by Java Servlets. When analyzing the data within those files, the system uses XML parser and DOM API to create Java object models (e.g., Enterprise Java Bean). Thus, perspective models written in XML are transformed and can work with other Java programs. The server provides several modules (e.g., Conflict Management, Process Management, Product Management, and Organization Management) to support the interactions and negotiation among stakeholders. While the functional structure and the form o f the product are built during design, a conflict management system analyzes the situation o f design 120 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. conflicts occurred and applies management strategies (i.e., detection, prevention, and intervention). The process management system is a CPML based modeling tool for design planning, scheduling, and simulation. The product management system controls the accessing o f various technical data and keeps its integrity. It can also exchange product data with other CAD applications by using standard product data format, such as STEP [12]. The organization management system tracks the organization structure evolution and social- network changes [93] and can communicate this information to other existing management information systems. The clients can also directly access some design data from system database. That is supported by using Java servlets and Enterprise Java Bean to communicate with the enterprise information systems. The system knowledge repository stores and updates the conflict management guidelines. While used by other systems, these guidelines can be transformed to XML format and fed back to the perspective interfaces of the stakeholders. 4.9.2 Building design perspective model One of the most important features of STARS is to support the representation and management of the design perspective interactions. A Perspective Model in the system is a cluster of data that represents the design perspective information o f a stakeholder. To get the Perspective Models, the stakeholders first collectively build a concept structure by using Concept Structure Builder (Figure 31). Then, by using the Perspective Model Builder (Figure 32), they declare their perspective information according to the concepts that they recognized. Concept Structure is an organization o f the ontology elements that stakeholders propose and use in collaborative design. The system uses both top-down and bottom-up construction 121 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. methods [89] to support stakeholders to build the concept structure. It first provides some templates (e.g. “product function template”, “design organization template”, “conflict types”, etc.) for the stakeholders to clarify the concepts. For more routine design, many concept structures can be extracted from previous CAD product models and preloaded in the ij File Edit View Favorites Tools Help • > Back Forward & Step & Refresh a Home a a 53 r» l Search Favorites History Mail . I LHts STARS 2.0 is g process control g framework devel> realizes the cone the system and 1 client database ( using a mechan knnwtoilns rnrel — Add New Corce Pteete Concept ShMsPerepeata. LMtoSMte UnfcloPrakict L M to T e rm JavaAppIstWindaw T S t c m l o r Coll.n.-crntinr. -------- ~-----------------~-------- P ro c e s s C o n cep t Social Interaction P ro d u ct O rganization i" ........... ft vt.-w 'ii.nts.ilt ii.ik-riuM f x(jUjriT prtjvidtnl by A1RT Brtwdbdndltttianbelti- -161 xl Oesign Campaign I p Conflict Q Social Interaction I p Technical Decision 9 S product P Function Requirem ents © Reserve Building Q Process veneoie ? £ 3 Custom er N eeds @ Location P rsllien ce i @ Oesign P aram eter 9 ^ Organaaoon C* Ip Matm Organization ProoerV 1 Value Nam e Location Preference Definition The purpose/preference f b ru firto se le c ts . Shared Shared t o e individual Proposer John Doe Propose Time 2002-02-15 Descnpeon | http i m p a c t usc.edufCERL/StarsPra/CN isp Reading data.. Finished reading data, to concepts returned i T est___________________________________ I 0 1 AppiatsUrtKt ~ '§ c Local / i system. When stakeholders propose new concepts in design process, the concept structure is updated and is used to systematically organize these concepts and their relationships. 122 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Figure 31 Concept structure builder PerspecUvelnfomiatlon r Information Fortn- Name Stakeholder Building_Locatlon [stars Concept DeclareTime 16 2002- 02-16 Speciiy the m o st important things you know about this concept This Building Location is Chosen by Users. Other useful information User survey shows that aost o£ the users prefer Location A. List docum ents, data you u se or provide with this concept Please See the website for the building environment aap.j Add New Remove | Java Applet Window Subm i Cancc* Figure 32 The perspective window collecting the perspective models Dependencies o f the Perspective Models are maintained in the concept structure. The change of design perspective models will be reflected to the concept structure. During design, stakeholders can perceive others’ perspective models if there are dependencies. A Perspective Model represented by XML can contain a group o f criteria depicting his/her valuations toward the design concept. The Purpose can either be a simple string or a defined criteria object, which has specific format defined by the users. The Content in the perspective model illustrates what the stakeholder knows about the design concept. It may contain several options the stakeholder proposes to satisfy the purpose. The Context of a 123 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. perspective model indicates the situational condition. It specifies the linkages to other related perspective models, which may have different time and stakeholder attributes. Stakeholders can construct and modify the data in their perspective models. They can also view and evaluate other’s perspective model by referencing the concept structure. The system can notice the linkages among their perspective changes by tracking the modification of the concept structure. 4.9.3 Constructing design process model Rather than to prescribe the detail jobs for all of the stakeholders, the process views provided by STARS is intended to facilitate them to notice what is happening and who is i :>it I xpioror providod by A f o # T Broadband In te rn e t LnJxJ I Vtow Proem £ 3 Protect Stars 9 ^ 3 Process Template | l ) Reserve Unit n Soak Store D Digging Permit Application Contract Application 9 € 3 Conceptual Design J f ) Market Survey 9 € 3 RequirementAnaiysis 381 Proposal 3 3 Location Selection 9 < 3 Preliminary Design 33 Oralt Layout 3Sl Detail Design & Embodiment Design TaskS J~.\ Uski Tt»actuto*ur*tonto:l00a)KwNtotfMptontoMoftto:9tfflyt Hi* actual coal to: 40 unit* wNto pton tom to: 5 unto |jo v a Applet Window Now loading process oDioct pieass w J a v a A pplet W indow Applet stated . O S Local mtranet A doing what at any time. 124 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Figure 33 The process builder In the CPML modeling tool, the collaborative design process is represented by an organization o f states and tasks. Time and resource consumption is associated with each task. As shown in Figure 33, a process diagram can be built jointly be a group of stakeholders. The diagram shows the sequence of tasks and the corresponding responsible stakeholders). By assigning activities to a stakeholder, the relationships among stakeholders in the process become very apparent. The process module can simulates the plan process and detect the process deficiencies (e.g., the schedule conflicts or over budget problem). 4.9.4 Supporting perspective, process, and conflict management The system provides an algorithm to help stakeholders rearrange the design process to reconcile the design perspectives and resolve conflict. When conflicts happen, from the dependency matrixes the system can identify the affected design tasks in process view (Figure 34). Then a possible solution is to modify some tasks or search for a new task to remove the conflict source. The effective handling of design conflict will eliminate the task iterations and shrink the design process. A mechanism to manage stakeholders’ interaction is implemented by generating and analyzing these perspective models. By referencing the concept structure to the perspective models, the perspective management system in the system can process the information within the perspective models. It first detects the dependencies among the perspective models and then presents related items to different stakeholders. Through Perspective Viewer, the stakeholders can detect the inconsistencies of their understandings with each other. When the perspective models are parsed for analysis, the system will notify both stakeholder the dependence and present them other’s related perspective information. 125 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. n n n flirt Hptpctorl in T4 T5 is added before T4 Original Process Process Modified Figure 34 The process module detects problematic task A conflict will be initiated in the system when it detects the incompatibility among the perspective models (Figure 35). Conflicts can be classified in the system according to the involved stakeholder and related concepts [56]. Given a type of conflict, some general strategies can be found from the knowledge repository in the system, which are human- readable. Also, the system will suggest the stakeholder to review the concept structure and tell him which stakeholders also have perceptions toward that concept. Then, by studying other’s relevant perspective information and following the suggestions, the system helps the users notice the differences and thus conducts a change of the perspective. Therefore, although there is no face-to-face meeting between the stakeholders, the system provides a platform for them to handle design conflict by using the dependencies as anchor points to integrate their individual perspectives and form a shared concept and meaning. 126 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. rPerspactfce- li Purspuctiva Ravlaw Information « ]O n » Review Form- Perspectlve Confict 16-«ira-2002-02-1B | Review Time I Overall: 12002- 02-16 0.8 [ Agree Specify the most Important things you tow about Oils concept H u s Building Location is Chosen by Usees. Strong Disagree: Disagree Agree I Strong Agree 'H ot Understand her usatUI Information gsec survey shows I n Strong Disagree c h a t e o s t oc th e | (^Disagree i •-< l i a t ’ -binr-M jIt I rttv v rtt* ( K D lA M C onflU t R atio 1 I Agree iderstand I Disagree e e i Aisee___ _________ d @ |lacal rtttrat /, Coes usees have the c o rte c t in fo zsau o a? Location A Is near the toad ccoss Coaaent :* I Figure 35 Perspective review and conflict report interface Since conflict management requires stakeholders’ negotiation, the objective of the conflict management function in the system is to support stakeholders to handle the conflicts systematically rather than to automatically resolve them. By maintaining the dependencies among design concepts, design process, and perspective models, the system facilitates the stakeholders to notice the existing o f some potential conflicts. Rather than to always treat a conflict as abnormal situation, we take a comprehensive approach. In the early design stage, conflicts can be considered as a motivation to identify the deficiency o f the team and to create ideas, while at the late stage conflicts should be prevented or resolved to achieve high 127 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. efficiency. Some of the general conflict management guidelines (e.g., adjust design process, find relating stakeholders, and change their roles) are implemented in the system. Working with STARS, the users can implement more guidelines based on their experiences. When stakeholders have successfully resolved a conflict, they may add more suggestions in the knowledge repository to facilitate the design in the future [73]. In STARS, perspective reconciliation is also achieved by supporting social interaction. It helps the stakeholders to view the evolution of organization structure and realize their own roles in the project. The system keeps a social network model [93] inside, which depicts stakeholders’ perception of existing of each other. When two stakeholders have contact, there is a link associated with them. By helping stakeholders to connect their design perspectives together, the system creates channels of communication for situation realization and background knowledge capturing. Stakeholder can read the design conflict profile from web-browser and perceive the convergence of design ideas. Based on the conflict management strategies, different conflict profiles might be achieved by the system. In short, to help the design stakeholders manipulate their perspectives as a way to converge them faster provides an effective way of conflict management and collaboration. 4.9.5 Enabling business to business process integration STARS system supports the business-to-business process integration through using CPML messages with the web services. The process module generates the CPML-based representation for the process graph drawn in the design panel. This XML-based document can be shared with other groups and integrated with distributed STARS systems. Suppose there are multiple STARS systems running on different companies. These companies have a collaborative project and want to integrate and access the process models 128 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. over the Internet (Figure 35). They first publish the service definitions on the Apache SOAP server, which provide the service registration and look up. Then, the STARS system used by one of the companies can look up the service and access the process information though the SOAP messaging. The process investigator in one company parses the received CPML and integrates the process model into its STARS system. It is also possible to use CPCL and CPSL to deliver view and control information among different STARS systems. That means, companies can share and control the collaborative process in cooperation. These functions basically realize a web-service based collaboration information sharing mechanism over the Internet. Apache SOAP publish lookup STARS2.0 Process Investigator Figure 36 STARS systems use SOAP web services to integrate the processes 129 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5 Impacts o f Research This research is an original attempt to incorporate the social aspect in engineering design and eliminate the restrictions of the established design theories. By taking a new perspective toward the collaborative design, it builds theoretical frameworks, which add the social factor in the loop and illustrate the principles o f conflict management and process improvement. This linkage provides a way to finally incorporate the knowledge from social sciences into engineering domains and to leverage their advantages. Besides, this research realizes a combined model to make process, conflict, and perspective management computationally feasible. This model accomplishes a collaboration protocol for the next generation o f Internet-based information systems. These impacts will eventually redefine the ways collaborative engineering design should be modeled and supported. 130 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 6 Conclusion This research develops a socio-technical approach to systematically support collaborative engineering design. By reviewing the existing literatures within wide relevant areas and studying the attributes of human collaboration during design process, it identifies the restrictions of the established design theories and methodologies. By investigating the key issues relating to the collaborative design, it obtains deep understandings of the design process, stakeholders’ perspective, and the design conflict. Furthermore, by taking a new perspective toward the collaborative design, this research builds a theoretical framework, which illustrates the principles of conflict management and process improvement in collaborative design. This theoretical framework reveals the fundamental characteristics of the socio-technical natures of collaborative design. Based on the framework, this research provides methodologies to understand these characteristics. These methodologies utilize and extend the effective methods from various domains, such as knowledge management, distributed information system, and social network analysis. They realize a feedback control system for improving the collaborative design productivity. This research develops a computational design process model (CPML), a perspective analysis framework, and a new conflict management model. These models provide the basis for socio-technical collaboration support. The design process model provides methods for design organization to represent, organize, and control the distributed processes. A principal function of the process model is to analysis the evolution of the design situation and to facilitate the management of design conflict. The perspective analysis framework provides methods for capturing perspectives and understanding their relationships. It facilitates the control of the evolution of the shared perspectives. When working with the design process model, and the perspective analysis framework, the conflict management model can assist 131 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. people to detect, resolve, or even to prevent the conflicts during design. These models are the critical parts to guide the current development of the design information systems. This research designs information system architectures to support design coordination. The major aim of STARS is to provide a platform to facilitate the collaborative design activities over the Internet. Using STARS helps the engineers to realize the status of the overall process and to identify individual positions. The perspective models sharing function provides an efficient way for understanding the meanings during communication. Since its basic feature is to improve the coordination among stakeholders, this information system architecture has potential usefulness for generic collaboration over the Internet. The socio-technical approach has some limitations. First, there is complexity for gathering the analysis input. For example, to externalize the perspective information, the stakeholders have to declare their understanding based on the queries. This may be an extra work for them to do during design. Second, although there could exist some predefined conflict management guidelines implemented in the system, the methodology assumes the final decision should be made by the users rather than by the information system. Stakeholders may implement more detail conflict management strategies into the system when they have enough experience. 132 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 7 Future Work The future research work includes two aspects: the theory refinement and the model improvement. First, to refine the theory, it is necessary to establish more analysis methods based on the validation results. It is useful to design and organize specific experiments for each of the steps in the analysis procedure (e.g., building process, analyzing conflict). Once the detail data within each step is captured and studied, the inaccuracies and limitations of the methodology can be detected. On the other hand, testing various design domain scenarios with the socio-technical methodology will ensure that it is generic enough to be applied in wide design domains. Once the methodologies are well applied, new research issues will be raised. There will be theories to quantify and predict the evolutions of stakeholders’ perspectives under different circumstances. Furthermore, the methodologies can be derived to manipulate or even automate the negotiation process based on the predictions. Second, it is possible to further polish the models. The collaborative design process model can be improved by applying the advanced analysis and simulation techniques. Considering the learning habit will enhance the perspective model. Besides, it is necessary to gain deeper understanding of social interactions and their relations to technical decisions occurred in more real-life collaborative design cases. Based on the thorough understanding of the characteristics of design perspective interaction, the socio-technical methodology and the design support system can be improved significantly. 133 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. References [1] Aalst, W., Kumar, A., (2000). XML Based Schema Definition for Support of Inter- organization Workflow. 21s t Inemational Conference on Application and Theory of Petri Nets, Aarhus, Denmakr. [2] 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. [3] Arias, E., et. al., (2000). Transcending the Individual Human Mind-Creating Shared Understanding through Collaborative Design. ACM Transactions on Computer-Human Interaction, Vol. 7, No 1., 84-113. [4] Bahler D. (1995). Mixed Quantitative/Qualitative Method for Evaluating Compromise Solutions to Conflict in Collaborative Design. AIEDAM, Vol. 9. [5] Bardasz, T., Zeid, I. (1993). BEJAVU: Case-Based Reasoning for Mechanical Design. A I EDAM, Vol. 7(2), 111-124. [6] Baron, R. A., (1984). Reducing Organizational Conflict: an Incompatible Response Approach. Journal o f Applied Psychology, Vol. 69, No. 2, 272-279. [7] Berger, P., Luckman, T. (1966). The social construction o f reality A treatise in the sociology of knowledge. Doubleday, New York. [8] Binmore, K. G. (1987). Why Game Theory “doesn’t work”? In Analyzing conflict and its resolutions: some mathematical contributions, (Bennett, P.G. Eds.), 23-42.0xford University Press, Oxford. [9] Borg, J. C. et. al. (1999). Guiding Component Form Design Using Decision Consequence Knowledge Support. AIEDAM, 13, 387-403. [10] Bras, B. A., Mistree, F. (1991). Designing Design Process in Decision-based Concurrent Engineering. SAE Transactions Journal o f Materials &Manufacturing, Vol. 100, 451-458. [11] Burgess-Yakemovic, K. C., Conklin, J. (1990). Report on a Development Project Use of an Issue-based Information System. Proceedings o f the Conference on Computer- Supported Cooperative Work. 105-118. New York: ACM [12] Burkett W., Yang Y. (1995). The STEP Integration Information Architecture. Engineering with Computers, Vo I II, 136-144. 134 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [13] Campbell, M. I., et. al. (1999). A-Design: An Agent-based Approach to Conceptual Design in a Dynamic Environment. Research in Engineering Design, Vol. 11, 172-192. [14] Carley K. M., Prietula M. J. (1994). ACTS Theory: Extending the Model of Bounded Rationality. Computational Organization Theory, Lawrence Erlbaum Associates, UK, 1994, 55-88. [15] Carroll, J., Rosson,M. B. (1990). Human-Computer Interaction Scenarios as a Design Representation. Proceeding o f the 23 rd Annual Hawaii International Conference on System Sciences, 555-561, Los Alamitos, CA: IEEE Computer Society Press. [17] Clancey, W. J. (1993). Guidon-Manage revisited: A Socio-Technical Systems Approach. Journal o f Artificial Intelligence in Education Vol. 4(l):5-34. [16] Clancey, W. J (1997). The Conceptual Nature of Knowledge, Situations, and Activity, in Feltovich, P., Hoffman, R. and Ford, K., Eds. Human and Machine Expertise in Context, 247-291. AAAI Press, CA. [18] Darr T., Brimingham W. P., (1996). An Attribute-space Representation and Algorithm for Concurrent Engineering. A l EDAM. [19] David, R. Alla, H. (1992). Petri Nets and Grafcet. Prentice Hall, Cambridge. [20] Deng, Y.-M. (1998). A Design Perspective of Mechanical Function and Its Object- oriented Representation Scheme. Engineering with Computer, Vol. 14, 309-320. [21] Dunskus, B. V. (1995). Using Single Function Agents to investigate conflict. AIEDAM, Vol. 9, No. 4 299-313. [22] Dym C. L., Levitt R. E. (1991). Toward the Integration of Knowledge for Engineering Modeling and Computation. Engineering with Computers, Vol. 7, 209-224 [23] Eppinger, D. S. (1997). Generalized Models of Design Iteration Using Signal Flow Graphs. Research in Engineering Design. Vol. 9, 112-123. [24] Erickson, T., Kellogg, W. A. (2000). Social Translucence: An Approach to Designing Systems that Support Social Processes. ACM Transactions on Computer-Human Interactions, Vol 7, No. 1, 59-83. [25] Finger, S., Dixon, J. R. (1989). A Review of Research in Mechanical Engineering Design, Part I: Descriptive, Prescriptive, and Computer-Based Models of Design Process. Research in Engineering Design, Vol. 1, 51-67. [26] Finger, S., Dixon, J. R. (1989). A Review of Research in Mechanical Engineering Design, Part II: Representations, Analysis, and Design for the Life Cycle. Research in Engineering Design, Vol. 1, 121-137. 135 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [27] Fogel, D., et. al. (1999). Inductive Reasoning and Bounded Rationality Reconsidered. IEEE Transactions on Evolutionary Computation, Vol. 3. No. 2., 142-146. [28] Fundenberg, D., Tirole, J. (1996). Game Theory, The MIT Press. [29] Grandhi, R.V., Bharatram, G. (1993). Multi-objective Optimization o f Larg-Scale Structures. AIAA Journal, Vol. 31, No 7. [30] Goh, C. H., et. al. (1999). Context Interchange: New Features and Formalisms for the Intelligent Integration of Information. ACM Transactions on Information Systems, Vol. 17, No. 3, 270-293. [31] Hauser, J. R., Clausing, D. (1988). The House of Quality. Harvard Business Review, May-June, 63-73. [32] Hazelrigg G. A. (1996). A Framework for Decision-Based Engineering Design. Working Paper. [33] Hazerlrigg, G. A. (1997). On Irrationality in Engineering Design. Transactions o f the ASME,Wo\. 119, 194-196. [34] Hazerlrigg, G. A. (1996). The Implications of Arrow’s Impossibility Theorem on Approaches to Optimal Engineering Design. Journal o f Mechanical Design, Vol. 118, 161- 164. [35] Huang, G. Q.. et. al. (2000). Agent-based Workflow Management in Collaborative Product Development on the Internet. Computer-Aided Design, Vol. 32, 133-144. [36] Huhns, M. N., Stephens, L. M. (1999). Personal Ontologies. IEEE Internet Computing, Vol: 3., No. 5., 85 -87. [37] Ishii, K. (1995). Life-Cycle Engineering Design. Transactions o f the ASME, Vol. 117, 42-47. [38] Jenson K. (1996). Coloured Petri Nets: basic concepts, analysis methods and practical Use, Vol. I, Springer, New York. [39] Jin Y., Lu, S. C-Y. (1998). Toward a Better Understanding of Engineering Design Models. In Universal Design Theory,(Grabaowski, H., et al., Eds.), Shaker Verlag, Aachen, Germany, 71-86. [40] Kannapan, S., Taylor, D. (1994). The Interplay o f Context, Process, and Conflict in Concurrent Engineering. Journal o f Concurrent Engineering Research and Applications, Vol. 2, 183-196. [41] Katzenstein, G., Lerch, F. J. (2000). Beneath the Surface of Organizational Processes: A Social Representation Framework for Business Process Redesign. ACM Transactions on Information Systems, Vol. 18, No. 4, October 2000, 383-422. 136 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [42] Kerzner, H. (1998). Project management: A systems approach to planning, scheduling, and controlling. John Wiley & Sons, Inc., New York. [43] Kilker, J. (1999). Conflict on Collaborative Design Teams: Understanding the Role of Social Identities. IEEE Technology cmd Society Magazine. Fall, 12-21. [44] Klein, M. (1995). Conflict Management as A Part o f An Integrated Exception Handing Approach. AIEDAM, Vol. 9, 259-267. [45] Klein, M. (1991). Supporting Conflict Resolution in Cooperative Design systems. IEEE Transactions on System, Man, and Cybernetics, Vol. 21, No. 6, 1379-1390. [46] Kraus, S., Wilkenfeld, J., Zlotkin, G. (1995). Multiagent Negotiation under Time Constraints. Artificial Intelligence, Vol. 75, 297-345. [47] Krishnan V. (1997). A Model-based Framework to Overlap Product Development Activities. Management Science, Vol. 43(4), 437-451. [48] Krishnamurthy, K., Law, H. K. (1997). A Data Management Model for Collaborative Design in a CAD environment. Engineering with Computers, Vol. 13, 65-86. [49] Lee, J, Lai, K-Y. (1996) .What’s in Design Rationale?, In Design rationale: Concepts, techniques, and use. Hillsdale, NJ: Lawrence Erlbaum Associates, 1996. [50] Lewis, K., Mistree, F. (1998). Collaborative, Sequential and Isolated Decisions in Design. ASME Journal o f Mechanical Design, Vol. 120(4). 643-652. [51] Lewis K., Mistree F. (1997). Modeling Interactions in Multidisciplinary Decision: A Game Theoretic Approach. AIAA Journal, August, Vol. 35. [52] Liang, J., et. al. (1998). An Object-Oriented Database Management System for Computer-Aided Design of Tall Buildings. Engineering with Computers, Vol. 14, 275-286. [53] Linde, H. J., et. al. (1999). Powerful and Structured Innovation using Contradictions for Gaining Orientation. Journal o f Engineering Design, Vol. 10, No. 3, 205- 222. [54] Little P. (1998). Project Management and Management of Design: Teaching and tools. AIEDAM, Vol. 12, 49-50. [55] Lu, S. C-Y., Cai, J. (1999). Modeling Collaborative Design Process with a Socio- Technical Framework. Proc. Sixth ISPE Int'/ Conf. Concurrent Engineering, Bath, UK. [56] Lu, S. C-Y., Cai, J., Burkett, W., Udwadia, F. (2000). A Methodology for Collaborative Design Process and Conflict Analysis. CIRP Annals. 49(1), 69-73. [57] Lu, S. C-Y., Cai, J., (2000). STARS: A Socio-Technical Framework for Integrating Design Knowledge over the Internet. IEEE Internet Computing, Vol. 4, No. 5, 54-62. 137 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [58] MacLean, A., et. al. (1991). Questions, Options and Criteria: Elements of Design Space Analysis. Human-Computer Interaction, Vol. 6, 201-250. [59] Maher, M. L., Zhang, D. M. (1991). CADSYN: Using Case and Decomposition Knowledge for Design Synthesis. Artificial Intelligence in Design '91, Gero, J. S., ed. Butterworth-Heinemann: Oxford, 137-150. [60] Majumder D., Rangan, M. R., Fulton, E. R. (1994). Information Management for Integrated Design Environments. Engineering with Computers, Vol. 11, 227-245. [61] March, J. G. (1978). Bounded Rationality, Ambiguity and the Engineering of Choice. The Bell Journal o f Economics, Vol. 9, No.2 [62] March, J.G. (1989). A Chronicle of Speculations: About Organizational Decision- Making. In Decisions and Organizations, March, J.G. (Eds). Blackwell, Oxford UK. [63] Marston, M., Mistree, F. (1997). A Decision Based Foundation For Systems Design: A Conceptual Exposition. CERL conference in Collaborative Design Theory and Multi-media Design System 1997. [64] Mas-Colell, A., Winnston, M. D., and Green, J. R. (1995). Microeconomic theory. Oxford University Press. [65] Moran T. P., Carroll J. M. (1996). Design Rationale: Concept, Techniques, and Use, New Jersey, Lawrence Erlbaum Associates. [66] O’Leary D. E., (1998). Enterprise Knowledge Management, IEEE Computer, March, 54-61. [67] Park, H., Cutkosky M. R., (1999). Framework for modeling dependencies in collaborative engineering process. Research in Engineering Design, Vol. 11, 84-102. [68] Paul, G., Beitz, W. (1996). Engineering design- A systematic approach, Second Edition, Springer, London. [69] Pena-Mora, F., Sriram, R., Logcher, R. (1995). Conflict Mitigation System for Collaborative Engineering. AIEDAM. Vol. 9, 101-124. [70] Petrie. C. J., et al. (1995). Using Pareto Optimality to Coordinate Distributed Agents. AIEDAM, Vol. 9, 269-281. [71] Prasad, B., (1999). Enabling Principles of Concurrency and Simultaneity in Concurrent Engineering. AIEDAM, Vol. 13, 185-204. [72] Pugh, S. (1991). Total design : integrated methods for successful product engineering. Wokingham, England. 138 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [89] Vet P. E., Mars N. J. (1998). Bottom-Up Construction of Ontologies. IEEE Transaction on Knowledge and Data Engineering, Vol. 10, No. 4. [90] Vincent, T.L. (1983). Game Theory as a Design Tool, Journal o f Mechanisms, Transmissions, and Automation in Design, Vol. 105. [91] Von, Neumann J, Morgenstem O (1980). Theory o f games and economic behavior. Princeton University Press. [92] Wall, J. A., Calister, R. R. (1995). Conflict and Its Management. Journal o f Management, Vol. 21(2), 515-558. [93] Wasserman S., Faust K. (1994). Social Network Analysis: Methods and Applications, New York: Cambridge University Press. [94] Wellman M. P. (1995). A Computational Market Model for Distributed Configuration Design. AIEDAM, Vol. 9, 125-133. [95] Whitney, D. E. (1996). Why Mechanical Design cannot be like VLSI Design. Research in Engineering Design, Vol. 8, 125-138. [96] Wiest, J. D., Levy F. K. (1977). A management guide to PERT/CPM. Prentice-Hall, Englewood Cliffs. [97] Wilbur, W. J. (1998). The Knowledge in Multiple Human Relevance Judgments. ACM Transactions on Information Systems, Vol. 16, No. 2, 101-126. [98] Wong, S. T.C. (1997). Coping with Conflict in Cooperative Knowledge-based Systems. IEEE Transactions on Systems, Man, and Cybernetics—Part A: Systems and Humans. Vol. 27, No. 1, 57-71. [99] Yassine, A. A. Falkenburg, D. R. (1999). A Framework for Design Process Specifications Management, Journal o f Engineering Design, Vol. 10, No. 3, 223-234. [100] Yoshikawa, H. (1981). General Design Theory and a CAD System. Man-Machine Communication in CAD/CAM, (Sata, T., Warman, E., Eds). 1FIP. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Appendices Appendix A: A CPML Example <?xml version="l.0"?> <!DOCTYPE process SYSTEM ”cpml.dtd"> <process name="Building2-requirement" parent="" use_as="plan"> stakeholder name="Pl" url=" "> <description> project manager </description> </stakeholder> <stakeholder name="P2" url=" " > <description> design consultant </description> </stakeholder> Stakeholder name="P3" url=" "> <description> market surveyor </description> </stakeholder> Stakeholder name="?4" url=" " > 141 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. < d e s c r i p t i o n > architect </description> </stakeholder> <assign> <stakeholder>Pl</stakeholder> <role>read/write/execute</role> </assign> <state name="Sl" status="occurring" token="l" start_time=”mm/dd/yyyy" ead_time="mm/dd/yyyy"> <description> Start of environment design </description> <param name="initial" value="yes" /> <assign> <stakeholder>PK/stakeholder> <roie>check</roie> </assign> <assign> <stakeholder>P2</stakeholder> <role>check</role> </assign> </state> Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. <state name="S2" status="occurring" token="l" start_time="mm/dd/yyyy" end_time="mm/dd/yyyy"> <description> Beginning marketing investigation </description> <param name="initial" value="yes" /> <assign> <scakeholder>PK/stakeholder> <role>cneck</role> </assign> <assign> <stakeholder>P3</stakeholder> <role>check</role> </assign> </state> <state name="S3" status="never occur" token="0" s t art_t ime=''mm/ da / yyyy" ena_t ime="mm/ dd / yyyy"> <description> Preliminary Building Location Selected </description> <param name="initial" value="no" /> <assign> <stakeholder>Pl</stakenolder> <role>check</role> </assign> <assign> Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. <stakeholder>P2</stakeholder> <role>check</role> </assign> </state> <state name="S4" status-'never occur" token="0" start_time="mm/dd/yyyy" end_time="mm/dd/yyyy"> <description> Investigation report submission <description> <param name="initiai" value="no" /> <assign> <stakeholder>Pl</stakeholder> <role>check</role> </assign> <assign> <stakeholder>P3</stakeholder> <roie>check</role> </assign> </state> <state name="S5" status="never occur" token="0" start_time="mm/dd/yyyy" end_time=''mm/dd/yyyy"> <description> Start layout design <description> <param name="initial" value="no" /> Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. <assign> <stakeholder>PK/stakeholder> <role>check</role> </assign> <assign> <stakeholder>P4</stakeholder> <role>check</role> </assign> </state> <state name="S6" status="never occur" ccken="0" s t a rt_t ime=”mm/dd/yyyy" end_time=”mm/da/vyyy"> <description> Layout Check <description> <param name="initial" value="no" /> <assign> <stakeholder>Pl</stakeholder> <role>check</role> </assign> <assign> <stakeholder>P2</stakeholder> <role>check</role> </assign> <assign> <stakeholder>P4</stakeholder> <role>check</role> Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. </assign> ccondition name="S6_Rework" status="fales" > Layout check cannot pass </condition> <condition narae="S6_Continue" status="true" > Layout check passed </condition> <cons name="S6_cons" status="true"> Only one condition can be ture </cons> </state> <task name="Tl" status="never execute" start_time="mm/dd/yyvy" end_time="mm/dd/yyyy"> <aescription> Select 3uiiding location <description> <assign> <stakeholder>PK/stakeholder> <role>execute</roie> </assign> </task> <task name="T2" status="never execute" start_time="mm/dd/yyyy" e nd_t ime="mm/dd/yyyv"> <sub-process name="Building2-reauirement-T2" /> <description> Gather customer needs 146 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. < d e s c r i p t i o n > <assign> <stakeholder>P3</stakeholder> <role>execute</role> </assign> </task> <task name="T3" status="never execute" start_time="mm/dd/yyyy" e ad_t ime="mm/dd/yyyy"> <description> Identify building requirements <description> <assign> <stakeholder>P2</stakeholder> <role>execute</role> </assign> <assign> <stakeholder>P4</stakenolder> <role>execute</role> </assign> </task> <task name="T4" status="never execute" start_time=”mm/dd/yyyy" end_time=''mm/dd/yyyy"> <description> Draw preliminary building layout Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. < d e s c r i p t i o n > <sub-process name="Building2-requirement-T4" /> <assign> <stakeholder>P4</stakeholder> <role>execute</role> </assign> </task> <task name="T5" scatus="never execute" start_time=''mra/dd/yyyy" end_time="mm/dd/yyyy"> <description> Revise layout <aescription> <assign> <stakeholder>Pl</stakeholders <role>execute</role> </assign> <assign> <stakeholder>P4</stakeholder> <role>execute</role> </assign> </task> <task name="T6" status="never execute" start_time=”mm/dd/yyyy" end_time=''mm/dd/yyyy"> <description> After S6 <description> 148 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. < / t a s k > <arc name="AcSl__T1" from="Sl" to="Tl" weight="l" /> <arc name="AcS2_T2" from="S2" to="T2" weight="l" /> <arc name=" AcT 1__S3" from="Tl" to="S3" weight="l" /> <arc name="AcT2_S4" from="T2" to="S4" weight="l" /> <arc name="AcS3__T3" from="S3" to="T3" weight="l" /> <arc name="AcS4 _T3" from="S4" to="T3" weight="l" /> <arc name="AcT3_S5" from="T3" to="S5" weight="l" /> <arc name="AcS5_T4 " from="S5" to="T4" weight="l" /> <arc name="AcT4_S6" from="T4" to="S6" weight="l" /> <arc name="AcS6_T5" from="S6" to="T5" weight="l" <valve status="close" > <opencond>S6_Rework </opencond> </valve> </arc> <arc name="AcS6_T7" from="S6" to="T7" weighc="l" <valve status="open" > <opencond>S6_Continue </opencond> </valve> </arc> <arc name="AcT5_S5" from="T5" to="S5" weight="l" /> </process> Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

An analytical approach to functional design

PDF

A hierarchical co-evolutionary approach to conceptual design

PDF

A work structure based approach to collaborative engineering design

PDF

Cognitive modeling of iteration in conceptual design

PDF

A framework for value -based conceptual engineering design

PDF

General and explicit equations of motion for mechanical systems

PDF

A cognitive approach to creative conceptual design

PDF

Investigation of a switching G mechanism for MEMS applications

PDF

Collaborative negotiation for early stage parametric design of mechanical systems

PDF

A document-driven approach to conceptual design

PDF

A literature survey on a managerial perspective on the process of innovation management

PDF

Experimental study of full scale concrete wall construction using contour crafting

PDF

Extending the COCOMO II software cost model to estimate effort and schedule for software systems using commercial -off -the -shelf (COTS) software components: The COCOTS model

PDF

Efficient methods for nonlinear parabolic PDEs

PDF

Experimentation and analysis of contour crafting (CC) process using uncured ceramic materials

PDF

An energy method for seismic design

PDF

Investigation of several important phenomena associated with the development of Knudsen compressors

PDF

A synthesis reasoning framework for early-stage engineering design

PDF

Automotive engine model linearization

PDF

A global study of nonlinear dynamical systems by a combined numerical-analytical approach

Asset Metadata

Creator Cai, Jian (author)

Core Title A socio-technical approach to support collaborative engineering design

School Graduate School

Degree Doctor of Philosophy

Degree Program Mechanical Engineering

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag business administration, management,engineering, industrial,engineering, mechanical,OAI-PMH Harvest

Language English

Contributor Digitized by ProQuest (provenance)

Advisor Lu, Stephen C-Y. (committee chair), Jin, Yan (committee member), Settles, F. Stan (committee member), Shiflett, Geoffrey (committee member), Udwadia, Firdaus (committee member)

Permanent Link (DOI) https://doi.org/10.25549/usctheses-c16-220131

Unique identifier UC11339050

Identifier 3073755.pdf (filename),usctheses-c16-220131 (legacy record id)

Legacy Identifier 3073755.pdf

Dmrecord 220131

Document Type Dissertation

Rights Cai, Jian

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the au...

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus, Los Angeles, California 90089, USA